> KeepPay onboarding guide: open your PSP S2S access, vault card tokens in your own name, charge via an ephemeral proxy, and learn about the upcoming Flow orchestration. KeepPay Onboarding Guide · Getting Started # Global 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 →](/en/vault) ｜ [Flow →](/en/flow) ｜ Unfamiliar terms? [Glossary →](/en/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. 1. **① 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. 2. **② Open your KeepPay account and projects** We provision your tenant, assign vault space and access per project, and hand you the console. 3. **③ 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. 4. **④ 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. 5. **⑤ 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 Traditional integration Merchant system → a PSP's checkout / elements → **card token stored in that PSP's own vault** - ❌ 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 The KeepPay way Merchant system → **cards into your own neutral vault** (tokens in your name) → one token set charges any 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). * * * Onboarding · Step 1 ## 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: 1 ### 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. 2 ### 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. 3 ### 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. Onboarding · Step 2 ## 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. User browserenters card (secure element) → KeepPay Vaulttokenize store in **your** project → Your serveronly gets the token → Ephemeral proxyforwards to PSP 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. Onboarding · Step 3 ## 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. 1. **① 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. 2. **② 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. 3. **③ 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. 4. **④ 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. * * * Step 4 · After ## 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 →](/en/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. 🌐 ### Website Back to [keeppay.net](/en/) for more product info and scenarios. Unfamiliar terms? [Glossary →](/en/glossary) ｜ Compliance details? [Security & compliance →](/en/security) ## Get the card token back first — flexibility comes after We'll walk this path with you.