The page the payer sees
A link or a redirect opens the checkout on the client’s domain: the amount, the merchant’s name, the methods for this payer and a form that adapts to the method — card fields with 3-D Secure, the wallet’s button, a QR code, a list of banks, bank details with a reference. Twenty-nine languages, right-to-left layouts, local formats of amounts and dates. The page is a few hundred kilobytes with its fonts and loads from the client’s domain, so a payer on a mobile connection sees the form before they would have looked away.
Every method, one page
| Method | What the payer does on the page |
|---|---|
| Card | Enters the number, expiry and CVV in fields that validate as they type; passes 3-D Secure in the issuer’s window when the issuer asks |
| Apple Pay, Google Pay | Taps the wallet’s button and confirms on the device; the card never appears on the page |
| Open Banking | Chooses their bank from a list in their language and confirms in the banking app; the page waits and shows the result |
| QR methods (PIX, PromptPay, QRIS, Kaspi Pay) | Scans the code with their banking app; the page polls for the confirmation |
| Bank transfer and virtual accounts | Copies the account details and the reference; the page explains the deadline and reports when the transfer arrives |
| Wallets (MoMo, Kaspi, Payme, M-Pesa) | Confirms in the wallet’s app or enters the wallet’s number; the page follows the wallet’s flow |
| Crypto | Sees the address, the exact amount and the network; the page shows the confirmations as they come |
The list of methods is not configured on the page: it is the result of the routing for this payment’s country, currency and amount, so the payer sees only methods that will work.
Built for conversion and compliance
- Loads fast: no third-party scripts, fonts and styles from the page’s own origin, the smallest markup that still looks like a banking app.
- Card numbers go from the payer’s browser straight to the vault over TLS and are encrypted there under KMS keys; the page never sees a stored card and stores nothing on the device.
- Security headers, subresource integrity and a self-check of the page’s elements, as PCI DSS requires for payment pages; a check that runs on every release.
- A timer to the payment’s expiry, a cancel button that tells the merchant, and status pages for success, pending and error that return the payer to the merchant.
- Google Pay and Apple Pay with the client’s merchant identifiers, registered per domain.
- Stored cards for returning payers where the merchant has the payer’s consent: a one-click payment with the CVV only, or without it for merchant-initiated charges.
Under the client’s brand
Each network defines its domain, logos, colours and mail; the checkout, the receipts and the merchant cabinet follow. The domain is connected by the platform’s operators; the logo and the colours are stored per network and change without a release. A white-label partner can run many brands on one platform, each isolated from the others, and give each brand its own checkout domain.
For the merchant’s developer
The checkout is opened with the payment’s reference returned by the API; nothing else is needed. A merchant that wants its own page instead uses the API server-to-server with its own PCI scope, and can still use the hosted page for the methods that require a redirect. Either way, the webhooks, the journal and the trace are the same.