One payment, from cart to bank statement.
Follow a single payment through Pleezpay: six stages, one integration, and one record of everything that happened along the way.
Stage 1: The shopper pays.
Your shopper pays on a hosted checkout that runs on your own domain, such as checkout.yourstore.com. We verify that you own the domain and look after its certificate. Your logo, your colours and your button corners lead; Pleezpay appears only as a small seal under the pay button.
Cards, wallets, bank transfer, pay-later and local methods share one checkout. Card details are typed into an isolated card frame, and the payment page carries no analytics, no ad pixels and no third-party scripts.
Stage 2: Pleezpay picks the route.
First, Pleezpay works out which providers can take this payment at all: the currency, the country, the method the shopper chose, each provider’s health and the profile of your business. Providers that can’t take it are never tried.
Then the order set for your account applies. Each provider account keeps its own limits, such as the smallest and largest order and a daily cap, so a provider agreement is never exceeded by accident. Every decision is stored on the payment, with the rules that matched and the reason each other provider was skipped.
pay_2Lw8rT4nPqCard · EUR · Netherlands
- Can take it
- Provider A, Provider B
- Left out
- Provider C · daily cap reached
- Chosen
- Provider A
Stage 3: If a provider says no, the next try goes elsewhere.
When a provider declines a payment, Pleezpay doesn’t charge again on its own. If the shopper tries again, that next try is routed to a different provider, not back to the one that just declined. The shopper stays on the same checkout.
A provider that is paused, under maintenance or failing is left out until it recovers. If the method a shopper chose isn’t available anywhere, the checkout says so, rather than switching them to something they didn’t pick.
Stage 4: The result is confirmed and recorded.
A shopper landing on your thank-you page proves nothing. Pleezpay confirms every outcome with the provider that holds the money, and keeps re-checking open payments until each one has a final answer. A late approval is put back on record rather than written off.
Every movement is written to a double-entry ledger. Entries are added, never edited, so a correction is a new line and the history stays intact. Requests carry an idempotency key, so a retried call returns the first payment instead of charging twice.
- 09:14:02Shopper returned to the storePending
- 09:14:05Provider confirmed the paymentCaptured
- 09:14:05Ledger entries written
Stage 5: Settlements and payouts add up.
Each payout comes with a statement: the payments behind it, the refunds, the fees and any reserve a provider or your agreement holds or releases. Every line is its own row, so you can trace a figure on your bank statement back to the payments that made it.
Your accountant can tick it off line by line, and so can you.
Statement, 13–17 Oct
Stage 6: Disputes are answered on time.
When a shopper’s bank opens a dispute, it lands in your dashboard against the original payment, with its deadline. You attach the evidence, submit it, and the outcome is recorded on the same payment, so the ledger and the case never drift apart.
Limits and allow or deny rules on country, email, card range and IP address help stop the next one early.
3 disputes need evidence by Fri 24 Oct.
Two ways to connect.
The WooCommerce plugin.
Install the Pleezpay plugin and your store keeps its own checkout. The plugin sends Pleezpay the order reference, the amounts and the items; Pleezpay sends the payment status back to the order.
Shoppers see a payment option called “Pay by card, wallet or bank”. You can rename it.
The API.
Create a payment, send the shopper to the checkout, and wait for a signed webhook. Then ask the API for the payment’s status: the webhook tells you something changed, the API is the authority.
POST /v1/payment-sessions
Idempotency-Key: order-10482
{
"amount": 12840,
"currency": "EUR",
"reference": "order-10482"
}