Contents
Overview: 4 stepsPayment data flow① Open S2S access② Vault the card③ Charge via proxy (+ isolation)④ Upgrade to FlowFAQGet supportGlobal payments, firmly in your own hands
This guide walks you from opening your PSP's S2S access, to vaulting card tokens 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.
Want to know what KeepPay is first? Vault → ｜ Flow → ｜ Unfamiliar terms? 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 projects
We provision your tenant, assign vault space 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
- ❌ Tokens are locked to that PSP — switch / add a channel and the cards can't come along (migration needs the old PSP's cooperation, or users re-enter)
- ❌ Add more PSPs = separate vaults each — data fragmented, hard to reconcile
- ❌ A ban / price hike / outage holds you hostage; even network tokens and card updates are bound to that PSP
- ✅ Tokens are your portable asset — switch / add channels with zero migration, invisible to users
- ✅ One vault for every PSP — data stays unified; reroute on a ban
- ✅ Plaintext never touches your environment, minimal PCI scope (the base is licensed; you don't get PCI-certified yourself)
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 project |
| ③ | 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 project
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. 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.
Projects & data isolation
A project (app) is your isolation unit in the vault, deciding "where a token lives and who can access it". Fix the structure at signup (project first, category second): each project's cards stay separate with locked permissions — changing it later is costly. Not sure how to split? Tell us at signup and we'll configure paths and permissions in one go.
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.
Upgrade to Flow for a smarter money flow Coming soon
Vault is the prerequisite for Flow — cards are already in your vault, so the Flow upgrade is zero-migration: not a line of capture code changes; just switch the target channel from "a specific one" to "let Flow decide", and get smart routing, failure cascade, smart recovery, and subscription auto-reroute.
The full orchestration capabilities (routing / cascade / recovery / reroute + cascade demo) are on the Flow → page — not expanded here.
FAQ
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.
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.
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.
How long does integration take?
Usually a few days to enable your channel, vault the cards, and run the first charge (depending on the channel review); upgrading to Flow orchestration later needs no re-collection of cards.
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.
What if my channel does not support this kind of integration?
Send us your list of channels and KeepPay will confirm feasibility; if a channel truly does not support it, you can switch to a supported same-region channel — with us alongside you the whole way.
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.
Unfamiliar terms? Glossary → ｜ Compliance details? Security & compliance →
Get the card token back first — flexibility comes after
We'll walk this path with you.