Payment flow overview

/docs/global/payments/overviewGlobal

Every payment — created through Hosted Checkout, a Payment Link or the raw API — moves through the same lifecycle. React to status changes with webhooks rather than polling.

Lifecycle

PENDING

Open

Payment created; waiting for the customer to complete checkout.

PROCESSING

Open

Details submitted; the rail is authorising — 3DS challenge or wallet OTP.

PAID

Terminal

Funds captured. Settlement begins on your next payout cycle.

FAILED / EXPIRED

Terminal

Authorisation declined, or the link lapsed before payment.

REFUNDED / PARTIAL_REFUND

Terminal

Full or partial amount returned after capture.

Reconciliation

PARTIAL_REFUND and REFUNDED are distinct terminal states. A partially refunded payment still counts toward collected revenue, minus the refunded amount. See Refunds & Cancellations.

What triggers each transition

From	To	Trigger
PENDING	PROCESSING	Customer submits card details, wallet PIN or bank redirect
PROCESSING	PAID	The rail confirms authorisation and capture
PENDING	EXPIRED	The link's `expiresInSec` window elapses unpaid
PAID	REFUNDED	You call `POST /merchant/refunds` for the full amount

How a payment is routed

Your server

Creates the payment through the API and stores the returned reference.

BINKPAY

Routes the payment to the right rail and runs the authorisation.

The rail

Card network, wallet or bank returns the outcome.

Your webhook

Receives the final status. This is the signal you act on.

Was this page helpful?