The steps of a checkout flow
- Order summary: what is being bought, the amount and the currency
- Choice of payment method
- Entry of details, or selection of a saved method or a wallet
- Authentication, where the method or the rules call for one
- Authorisation, and the result shown to the buyer
- Confirmation to the merchant's system, and a receipt
How a checkout flow is built
The merchant's server creates a payment with the gateway and receives a session. The buyer then pays on a page hosted by the gateway, in fields embedded in the merchant's own page, or through the merchant's own form calling the API.
Not every method answers at once. Bank transfers, some wallets and crypto payments confirm later, so the flow has a pending state, and the final result reaches the merchant in a server-to-server notification.
Why the failure paths matter
Most of the work is in what goes wrong. A declined card should lead to another attempt or another method, not to a dead end.
A buyer who clicks twice must not pay twice, which is what idempotency keys are for. A buyer who closes the tab after paying still has to get the order, so the notification, not the browser, is the record of the outcome.
Where a checkout flow shows up in a platform
Modules that do the work
- CheckoutA hosted checkout for cards, wallets, bank payments and crypto, routed to the best provider.
- AuthenticationSign-in, passkeys and second factors for customers and staff, on your identity provider or ours.
- Card acquiringCard acceptance on the phone, in store and online, through the acquirer you choose.
- NotificationsEmail, SMS, push and in-app messages in your brand, through the providers you choose.