Contents
What is KeepPayCore conceptsThe integration flowData flow (by role)Step 1 · S2S accessStep 2 · Vault the cardStep 3 · Charge via proxyContainers & isolationFlow orchestration (soon)Security & complianceFAQGet supportGlobal payments, firmly in your own hands
This guide walks you from opening your PSP's S2S access, to vaulting card data in your own name, to charging with a token via an ephemeral proxy — keeping your card data and revenue in hand. Multi-channel orchestration (Flow) is coming soon.
What is KeepPay
Payment infrastructure for teams operating globally. Your card data is your asset; you choose the channels.
Cross-border payments get stuck on three things: compliance too heavy to self-build, card data locked to a channel, and a single channel wobbling into lost orders. KeepPay solves it in two steps with two products — you carry neither the PCI burden nor any single processor's leash.
KeepPay Vault
Your own card vault. Cards are tokenized in the browser, plaintext never reaches your servers, and tokens live in your own name, isolated per project. No PCI build-out. Available now.
KeepPay Flow · OrchestrationComing soon
Smart payment orchestration on top of the vault: one integration to route across the PSPs you choose, reroute automatically when a channel dies, and smartly retry declined charges.
Two steps, zero migration. Use Vault first to get card data back in your hands; once you're live, upgrade to Flow orchestration (coming soon) without re-collecting a single card. Cards are already vaulted — the upgrade disturbs no one.
Core concepts
A few words run through the whole guide. Understand them and the rest of the integration flows easily.
| Concept | What it is | The one thing to know |
|---|---|---|
| Token | A meaningless string that replaces the card number | The PAN is tokenized before it leaves the browser; afterwards your system only ever touches the token, never the real card number. |
| Vault | The compliant store holding all your tokens, in your name | Not held at some processor — this is the key to "card data is your asset". |
| Container | A directory path inside the vault used to partition | Isolate tokens per project; projects can't see each other. |
| Channel / PSP | The payment service provider that actually charges (e.g. Stripe, Adyen, Checkout.com) | KeepPay forwards neutrally — who you connect, switch to, or run in parallel is up to you. |
| S2S access | A server-to-server PSP endpoint that can receive raw card data (PAN / expiry / CVC) | Prerequisite: the PSP must open it under PCI eligibility — that's "step one". |
| Ephemeral proxy | The mechanism that detokenizes the card in-transit and forwards it to the PSP | Detokenization happens only in transit; your servers never touch the plaintext PAN. |
| AOC | PCI DSS Attestation of Compliance | Provided by KeepPay to your PSP; you need no PCI certification of your own. |
Full terms in the Glossary →
The integration flow
From opening a channel to your first charge, the whole flow looks like this — the first three steps lock your data down; orchestration (coming soon) makes the money flow smarter.
- ① Open your PSP's "S2S access" (under PCI eligibility)
Have your chosen channel open a server-side endpoint that can receive raw card data. PSPs usually require a PCI attestation first — that attestation is provided by KeepPay, so you need no PCI certification. - ② Open your KeepPay account and project containers
We provision your tenant, assign vault containers and access per project, and hand you the console. - ③ Capture cards into the vault
Drop the KeepPay secure capture element on your checkout; the card is tokenized on the spot and stored in your own vault — plaintext never hits your servers. - ④ Charge via the KeepPay proxy (S2S)
At charge time the ephemeral proxy detokenizes in transit and forwards securely to the PSP you opened in step one. - ⑤ Upgrade to Flow for a smarter money flow Coming soon
Add more PSPs and configure smart routing, failure cascade, and smart recovery to stop lost orders before they happen.
Step one's S2S enablement usually takes a few days (depending on PSP review); after that Vault capture can go live within days. Flow orchestration is enabled on demand once live, with no need for any user to re-enter their card.
The big picture: payment data flow
One diagram for the whole responsibility boundary: how card data flows, how tokens flow, and whether plaintext ever touches your servers. The plaintext PAN appears only in segments ① and ⑤; your merchant server only ever touches tokens.
| Step | Direction | What happens |
|---|---|---|
| ① | KeepPay element → KeepPay server | The card is captured in the secure element and tokenized (plaintext PAN, only on this segment, on KeepPay's side) |
| ② | KeepPay server → user client | Returns the token, stored in your vault and isolated by container |
| ③ | User client → merchant server | Submits the token to your backend |
| ④ | Merchant server → KeepPay server | Charges using the token |
| ⑤ | KeepPay (ephemeral proxy) → PSP | Detokenizes in transit and forwards via S2S to the PSP (plaintext PAN) |
| ⑥ | PSP → KeepPay server | The synchronous auth result returns to the KeepPay proxy that made the call |
| ⑦ | KeepPay server → merchant server | Returns the result to the merchant as the synchronous response of call ④ |
| ⑧ | Merchant server → user client | Returns the payment result to the user |
| ⑨ | PSP → merchant server (async) | webhook straight to the merchant: succeeded / refund / dispute / renewal — bypasses KeepPay |
Key takeaway: the plaintext PAN (orange) appears only on ① element→KeepPay and ⑤ KeepPay→PSP; the merchant server only ever touches tokens and results. The synchronous result returns via ⑥ PSP→KeepPay→⑦ merchant; final events arrive by ⑨ async webhook straight to the merchant, bypassing KeepPay (which is also why KeepPay does not see the final transaction outcome by default).
Open your PSP's "S2S access"
This is the prerequisite for the whole integration and the most overlooked step: get the channel's "permission" first, and card capture and charging downstream will work.
The essence of KeepPay (neutral vault + orchestration) is that, at the moment of charge, KeepPay securely delivers the card to your chosen PSP over "server-to-server (S2S)" inside a compliant environment. So the first thing is to confirm / enable that your PSP accepts this S2S access. Three things to line up:
A PSP S2S endpoint that "receives raw card data"
i.e. a server-side endpoint that can receive PAN / expiry / CVC (not just a hosted checkout or redirect page). Most major PSPs support it, but usually by "request to enable" rather than open by default.
Enable it with a PCI attestation (AOC)
PSPs require a PCI DSS attestation to open these endpoints. That AOC is provided by KeepPay — you need no PCI certification of your own. Hand it to the PSP and it's usually enabled within days.
Allowlist KeepPay's outbound IPs
Some PSPs restrict by IP and need KeepPay's outbound IPs allowlisted for charge requests to pass. We provide that IP list.
This step in one line: get a "permission" — your chosen PSP lets KeepPay, on your behalf and within compliance, deliver the card over S2S to charge. Later, switching or adding channels just means running this step again for the new PSP; the card data always stays in your vault and users never re-enter it.
Not sure which access your current / desired PSP supports? Send us your channel list and KeepPay will confirm S2S feasibility, provide the AOC, and handle the IP allowlist — with you the whole way.
Vault the card into your own vault
Lock your global users' cards safely into a vault that is yours — no PCI burden, and never beholden to any single channel.
The core is one sentence: the plaintext PAN never passes through your servers. Capture and tokenization both happen inside KeepPay's secure environment; your system only ever touches tokens.
(secure element)
store in your container
the token
via S2S at charge
① Front end: drop in the secure capture element
Place KeepPay's secure card capture element on your checkout. It runs inside a KeepPay-hosted secure iframe, so the plaintext PAN never enters your page DOM or servers, shrinking your PCI scope to the minimum. The element can be styled to your brand.
② Tokenize and store in your vault
When the user submits, the card is tokenized on the spot and stored in your vault, isolated by project container. Your backend receives a token, not a card number; everything afterward runs on that token.
Compliance base. Tokenization and storage are backed by an organization audited and approved at PCI DSS Level 1; the plaintext PAN lands neither on your servers nor on KeepPay's business servers.
Charge via the KeepPay proxy (S2S)
The card is vaulted; at charge time KeepPay's ephemeral proxy detokenizes in transit and delivers securely to the PSP you opened in step one.
- ① Your backend initiates the charge
Charge with the token (not the card number), passing amount, currency, and target channel. Specify one channel when single-channel. - ② The ephemeral proxy detokenizes and forwards
The proxy temporarily restores the card in transit and forwards over S2S to the PSP for authorization — your servers never touch the plaintext PAN. - ③ Result returns, plus webhook callback
The auth result returns in real time as the synchronous response of this call; final status changes (succeeded / failed / refunded) are pushed by the PSP asynchronously via webhook to the endpoint you registered. - ④ Reuse the token for the next charge
For renewals / repeat purchases, reuse the same token — no re-entry. KeepPay carries network transaction identifiers to improve renewal approval rates.
You've now run a complete charge without touching the plaintext PAN or building PCI yourself, and the card data sits safely in your own name.
Containers & data isolation
A container is a directory inside the vault that decides "where a token lives and who can access it". When projects share one account, containers give clean data isolation.
- Partition by project: prefer "project first, category second" so each project's cards stay separate.
- Lock permissions: each project can access only its own container — real isolation, not just naming.
- Plan ahead: moving tokens between containers later is costly, so fix the structure at signup.
Not sure how to split containers? Tell us your project structure at signup and we'll configure the paths and permissions in one go.
A smart brain for your money flow Coming soon
Below are orchestration capabilities coming soon on top of Vault (routing / cascade / smart recovery / subscription auto-reroute). Vault is the prerequisite — cards are already in your vault, so the Flow upgrade is zero-migration: not a line of capture code changes; you just switch the target channel from "a specific one" to "let Flow decide".
Smart routing
Auto-select the best channel by region, card type, cost, and success rate. Rules are configured visually in the console, no code.
Failure cascade
When the primary channel wobbles (risk control, jitter, ban), the same charge auto-reroutes to the next healthy channel — stopping lost orders before they happen, invisible to the user.
Smart recovery
For high-decline cases like short-drama and subscriptions, retry declined charges at the best time on the best channel to recover what can be recovered.
Subscription auto-reroute
When the renewal PSP is banned overnight, the next renewal auto-reroutes to a healthy backup PSP — members never notice, no lost orders.
Failure cascade: another route often gets it through
(risk/jitter)
This is one of the two payoffs of the "vault" model — the card isn't locked to one PSP, so another route often goes through, commonly lifting approval by ~5–10%. See Vault →
Security & compliance
The plaintext PAN never lands in your environment, shrinking your PCI scope to the minimum. Below are the base's key capabilities.
| Capability | What it means |
|---|---|
| End-to-end tokenization | Cards are tokenized at the front end; plaintext never enters your servers, nor KeepPay's business servers. |
| PCI DSS Level 1 | Tokenization and storage are backed by an organization audited and approved at PCI DSS Level 1; your PCI scope drops to the minimum. |
| Attestation of Compliance (AOC) | KeepPay provides the PCI attestation to your PSP to open S2S access; you need no PCI certification of your own. |
| Secure S2S forwarding | At charge, the ephemeral proxy detokenizes in transit and forwards over S2S; plaintext never lands. Supports PSP-side IP allowlisting. |
| 3DS / SCA | Supports 3-D Secure and Strong Customer Authentication for compliant charging in Europe and beyond. |
| Data isolation | Tokens isolated by project container, permissions locked to specific containers; projects can't see each other. |
More in Security & compliance →
FAQ
What exactly is "S2S access", and why is it step one?
Server-to-Server (S2S) means the PSP exposes a server-side endpoint that can receive raw card data. KeepPay uses it to securely deliver the card to your channel at charge time. PSPs usually keep it closed by default and require a PCI attestation to enable it, so it has to be arranged first before card capture and charging can work.
Do I need to get PCI certified myself?
No. Cards are tokenized in the browser and plaintext never touches your servers; the PCI Attestation of Compliance (AOC) needed to open S2S with your PSP is provided by KeepPay.
What if my PSP does not support S2S?
Send us your list of channels and KeepPay will confirm feasibility; if a channel truly does not support it, you can switch to a same-region channel that supports S2S.
How long does integration take?
Step one (S2S enablement) depends on the PSP review, usually a few days; after that Vault card capture can go live within days. Upgrading to Flow orchestration (coming soon) requires no re-collection of cards.
We already use Stripe / Antom / Airwallex — why KeepPay?
They lock card data inside their own systems. KeepPay is a neutral vault — the cards are your asset, you can integrate any acquirer/PSP at once, switch any time, and are never locked in.
Which payment methods and PSPs are supported?
Card payments first: you can integrate any card processor / acquirer that offers an API to receive cards, with ready-made examples for Checkout.com / Stripe / Adyen. Connect whoever you want — no fixed connector list.
Where is my card data stored, and is it safe?
As tokens in a compliant vault. Tokenization and storage are backed by an organization audited and approved at PCI DSS Level 1; plaintext never lands on your or our business servers.
Can I use Vault only, without Flow?
Yes. Vault and Flow are decoupled — you can use the vault for tokenization plus forwarding to a fixed channel, and turn on Flow (coming soon) for multi-channel orchestration later, with no migration and no asking users to re-enter cards.
Get support
Native-language, dedicated hand-holding — real people you can always reach, not cold tickets.
Book a demo
See how KeepPay keeps your card data and revenue in hand. We'll propose an integration plan for your business and channels.
Dedicated support
From the Growth plan, a dedicated chat group walks you through S2S enablement, go-live, and tuning.
Get the card back first — flexibility comes after
We'll walk this path with you.