CleonPay
Documentation Get in touch
Payments

Accept the methods your
customers already use.

A Dutch customer expects iDEAL. A Belgian expects Bancontact. Someone in Shanghai expects WeChat Pay. Offering only cards quietly costs you the sale.

checkout.yourshop.com
Order 1001€10.50
iDEAL
Bancontact
VISA Card
paysafecard
Pay €10.50

The customer sees
their own bank.

Every method hands off to the place the customer already trusts: their banking app, their wallet, a code they take to a cash machine. You send them to one URL and we take care of what happens there.

Methods your account is not enabled for are never shown, so a customer is not offered a route that cannot complete.

Same shape,
every method

Change method and the rest of your integration stays as it is. The response always carries a URL to send the customer to. 

{
  "id": "3743881d-0fce-416c-b3de-8bc3f5d414b1",
  "object": "payment",
  "status": "awaiting_customer",
  "amount": 1050,
  "currency": "EUR",
  "method": "ideal",
  "redirect_url": "https://ideal.example/pay/...",
  "reference": "order-1001",
  "livemode": true
}

Fulfil on the webhook,
not the redirect

A customer returning to your success page means their browser came back. It does not mean the money moved. Every payment is confirmed by a signed webhook, retried for 24 hours, and safe to receive more than once. 

{
  "id": "evt_01H...",
  "type": "payment.settled",
  "created": "2026-08-21T13: 15: 26.438Z",
  "data": { "payment_id": "3743881d-0fce-416c-b3de-8bc3f5d414b1" }
}

Refunds

Full or partial, within each scheme's own window. Where a method has no refund mechanism at all, the API says so rather than failing at the bank.

Cancellation

Close a payment the customer abandoned, before the bank has authorised it.

Reporting

Every payment carries your reference and the bank's, so a query from either side resolves to the same transaction.