One platform. Every payment, orchestrated.
You build one integration against the Pleezpay API. Behind it, we manage the provider relationships, route each attempt, verify every outcome against the provider that holds the money, and hand you a single status model you can build a business on.
- One integration
- One status model
- Reconciliation-verified
How a payment moves through Pleezpay orchestration
Your checkout or API call enters Pleezpay through a single integration. The orchestration layer routes the attempt, applies risk checks, and reconciles the result against the provider. From there the attempt reaches one of several payment providers. A declined attempt on one provider is re-routed and recovered on another. Every outcome leaves Pleezpay as a signed webhook and an entry in the immutable ledger.
- Route
- Risk checks
- Reconcile
- PSP A
- PSP Bdeclined
- PSP Cre-routed, recovered
One integration. Multiple providers behind it.
When a payment arrives, Pleezpay first works out which providers are actually eligible for it: the currency, the country, the payment method the customer chose, the profile of your business. Ineligible providers are never tried. The remaining ones are attempted in the priority order configured on your account.
That configuration is ours to maintain, not yours. Pleezpay holds the provider relationships and adjusts the order as your volume and market mix change, so you are not renegotiating contracts or rewriting integration code every time the picture shifts.
- Eligibility before priority
- Each attempt is first filtered to the providers that can actually take it: currency, country, payment method, the provider's certification and health, and your business profile. Only then is the order applied.
- Priority rules per method and currency
- A published route version holds ordered rules keyed by payment method and currency, most specific first. A Bancontact payment in Belgium and a card payment in the UK follow different rules through the same API.
- Caps and warmup on every provider account
- Minimum and maximum order amounts, a daily volume cap in a stated currency, and a warmup ramp for a newly connected account are enforced before routing, so the limits in a provider agreement are never exceeded by accident.
- Health and circuit state
- A provider in maintenance, with a credential error or with an open circuit is excluded until it recovers. When the method a payer chose is unavailable, the payer is told so rather than handed a different method.
- Controlled splits for new providers
- A share of eligible traffic can be directed to a newly connected provider while the rest stays where it is, so approval can be compared before volume moves.
- Overrides with an expiry
- Our operations team can pin a method or currency to a provider, or stop a method outright, for a set period. An override can never resurrect a provider that eligibility, risk or health already excluded.
- Every decision on record
- The route decision, the rules that matched and every rejected candidate with its reason are recorded on the attempt, so the answer to why a payment went where it did is a lookup, not a guess.
- Managed for you
- You do not maintain routing tables. Pleezpay holds the provider relationships and tunes the configuration on your account as your mix changes, inside the limits each provider agreement sets.
On the roadmap: performance based smart routing across providers, and retries that respect card scheme rules. Today routing is eligibility, priority and caps, managed by us, and deliberately predictable rather than clever.
A payment page on your domain, not ours.
The hosted payment page runs on a checkout domain you own. You point a subdomain at Pleezpay, we verify that you control it, issue and manage the TLS certificate, and serve the page from there. Customers stay on your brand from cart through to confirmation.
The page carries cards, iDEAL, Bancontact and Klarna today, and runs under a strict Content Security Policy with no third party scripts at all: no analytics, no pixels, no external fonts. Card details are typed into a dedicated, isolated card document with a script allowlist of one and no inline code, and they travel from there only to the connected provider that processes the payment. It is the one surface that touches payment details, so we keep it as small as it can be.
- Your domain, verified
- Serve the payment page from checkout.yourbrand.com. We verify domain ownership before it goes live and terminate TLS on it, so the customer never leaves your brand to pay.
- Cards, iDEAL, Bancontact, Klarna
- The methods available to your account today, presented to the customer with the same session and the same status model behind them.
- No third party scripts
- The payment page runs under a strict Content Security Policy with no analytics tags, no ad pixels and no external fonts. Fewer moving parts on the page that handles money.
- Built for the redirect reality
- Customers close tabs, lose signal and hit back. The page is designed so none of that decides the outcome of the payment.
Statuses you can trust.
This is the part of Pleezpay we care about most, because it is where most payment integrations quietly go wrong. Your order state, your fulfilment, your books and your support queue all depend on one question: did this payment actually succeed?
Pleezpay answers it by asking the provider that holds the money, not the customer’s browser. Every attempt that is not in a final state gets re-verified against the provider until there is a confirmed answer. A customer who closes the tab, loses signal on the redirect back, or never reaches your success URL changes nothing about the outcome.
Writes are protected by an enforced Idempotency-Key, so a retried request returns the original payment instead of creating a second one. An approval that lands late is reinstated rather than written off. And when the platform genuinely cannot tell, it says so: the attempt is quarantined for review instead of being guessed into a status your accountant will have to unpick later.
- Every open attempt re-verified
- Anything not in a final state is polled back against the provider that holds it until the platform has a confirmed answer, not an assumed one.
- Redirects never move money
- A customer landing on your success URL updates nothing. The status changes when the provider confirms it, which is why a closed tab costs you nothing.
- Duplicate charges prevented
- Idempotency-Key is enforced on write endpoints. A retried request returns the original result instead of creating a second payment.
- Late approvals reinstated
- A payment that lands after your timeout is not lost. Reconciliation reopens it, corrects the status and fires the webhook so your order state catches up.
- Exceptions quarantined, never guessed
- Anything the platform cannot resolve with certainty is flagged for review rather than force-closed. We would rather tell you a payment is unresolved than tell you the wrong thing.
Immutable double-entry ledger
Every movement, whether a capture, refund, fee, reserve or payout, is written as balanced double entry lines that are appended, never edited. A correction is a new entry, so the history of what you were told and when stays intact and auditable.
Itemized settlement statements
Every payout you receive, whether a connected provider pays it to your own account or it is made under your Pleezpay agreement, is reconciled to the transactions behind it, the fees applied and any reserve that provider or agreement holds or releases. You can trace a figure in your bank account back to the individual payments that produced it, and refunds route back to the provider that captured the original charge.
Controls before the charge, records after it.
Risk rules are evaluated before an attempt is routed anywhere. You get per transaction, daily and monthly limits, plus allow and deny rules on country, email, card BIN and IP address. Blocked attempts are recorded with the reason, so you can see what your rules are actually doing rather than guessing.
After the fact, disputes get a structured workflow: record the case against the original payment, attach the evidence, track the outcome. Around all of it sits the ordinary security work: invitation only accounts, role based access, tenant isolation, encrypted provider credentials and an audit trail on privileged actions.
- Limits that hold
- Per transaction, daily and monthly ceilings evaluated before an attempt is routed, so a bad day cannot become a bad month.
- Allow and deny rules
- Country, email, card BIN and IP rules on your account. Block the patterns you have already seen; allow the ones you know are good.
- Disputes on record
- A structured workflow to record a dispute, its evidence and its outcome against the original payment, so the ledger and the case never drift apart.
- Security as engineering practice
- Invitation only accounts, role based access, tenant isolation between merchants, provider credentials envelope encrypted under a restricted root key, a strict CSP on the checkout surface and an audit trail on privileged actions.
Enterprise grade controls, stated specifically. Card entry is isolated on its own document, provider credentials are envelope encrypted under a restricted root key, accounts exist only by invitation, and every privileged action is audited. The connected providers that process card payments carry their own PCI DSS validation as service providers. Pleezpay does not present their certificates as its own and does not hold a PCI DSS, SOC 2 or ISO certificate today; we say where a control is designed for a standard rather than audited against it, and the assessed cardholder data environment of the vault programme is on the roadmap.
Four calls to take your first payment.
The API is versioned REST over JSON at /v1. Sandbox and live keys are entirely separate environments, so you can build the whole flow, including failure cases, before anything touches real money.
The shape is deliberately boring: create a session, send the customer to the hosted page, handle the signed webhook, then confirm against the platform. That last step matters. Treat the webhook as a nudge and the API as the authority, and your order state stays correct even when a delivery is delayed or a browser never comes back.
Illustrative shapes, shown to explain the flow. Field names and the full event list live in the API reference you get with your sandbox keys.
- 01Create a payment session
POST /v1/payment-sessions Authorization: Bearer sk_live_... Idempotency-Key: order-10482-attempt-1 Content-Type: application/json { "amount": 4900, "currency": "EUR", "reference": "order-10482", "return_url": "https://your-store.com/order/10482", "customer": { "email": "[email protected]" } }Send an Idempotency-Key. Replay the same key and you get the same session back, never a second charge. - 02Redirect the customer
201 Created { "id": "pay_01HZ...", "status": "pending", "checkout_url": "https://checkout.your-store.com/s/01HZ..." }The response carries the hosted page URL, on your own verified checkout domain. - 03Receive the signed webhook
POST https://your-store.com/hooks/pleezpay Pleezpay-Signature: t=1754380800,v1=9f2c... Content-Type: application/json { "type": "payment.captured", "created_at": "2026-08-05T09:20:00Z", "data": { "id": "pay_01HZ...", "status": "captured", "amount": 4900, "currency": "EUR", "reference": "order-10482" } }Verify the signature and the timestamp before you trust the body. Replays are rejected; failed deliveries retry with backoff. - 04Confirm against the platform
GET /v1/payments/pay_01HZ... Authorization: Bearer sk_live_... 200 OK { "id": "pay_01HZ...", "status": "captured", "reconciled_at": "2026-08-05T09:20:04Z" }The webhook tells you something happened. This call is the authority: it reflects the reconciled state, not the browser's.
- Versioned /v1 REST API
- Predictable resources over plain HTTP and JSON. Sandbox and live keys are fully separate, so nothing you test can touch real money.
- Signed, replay-protected webhooks
- 15 event types, signature and timestamp on every delivery, automatic retries with backoff, a delivery log you can inspect and a circuit breaker that stops hammering an endpoint that is down.
- Dashboard your team can use
- Transaction search, payment detail with its full status history, and CSV export for the people who would rather work in a spreadsheet than an API.
Not shipped yet. Being built next.
We keep this list separate from everything above on purpose. If it is on this page as a capability, you can use it today. If it is here, it is coming. Ask us where it stands before you plan around it.
- Cascading retries
- A soft decline on one provider automatically re-attempted on the next eligible one, under your rules.
- Coming
- Vault & tokenization
- Pleezpay-held tokens so a card stored once stays usable across providers.
- Coming
- Performance-based routing
- Priority order tuned by observed approval behaviour per method, issuer and market.
- Coming
- Inline checkout fields
- Embedded and headless payment fields for teams that want checkout fully inside their own UI.
- Coming
- SDKs
- Typed server-side libraries over the same /v1 API you can already call directly.
- Coming
Route smarter. Get paid more.
One integration, multiple providers behind it, and reconciliation deciding what actually happened. Apply and we will walk you through onboarding.
Or leave your email and we’ll reach out.