Checkout
The Checkout component captures payment details from your customers. It is delivered as an iFrame via shuttle.js, so card data and PCI scope stay inside Shuttle and never reach your platform.
It renders as a modal popup or inline in your own page, and handles one-off payments, recurring and scheduled agreements, saving a payment method without charging it, saved payment methods, wallets, bank debits and gateway-hosted payment pages. Whatever the customer picks, your page gets the outcome back the same way.
Integrating
Create a checkout server-side, embed it, handle the browser events, and handle the webhooks. Each step is set out in the Checkout Integration Guide, and the request itself in the Checkout Creation API.
The one decision to get right before you build is the nonce you send on the checkout. It is the idempotency key, and it is what stops a customer who reloads, comes back later or finishes on another device from paying twice. Derive it from the thing being paid for rather than letting Shuttle generate one — see When a payment is interrupted, which also sets out what exists in Shuttle at each point of a payment and how a broken one resolves.
What the customer sees
The screens are documented in the Checkout user guide.
| Screen | What the customer does there | Guide |
|---|---|---|
| Payment form | Chooses a payment method, enters or picks a card, confirms the amount and pays | Payment form |
| Receipt | Sees the outcome and their reference | Receipt |
| An interrupted payment | Returns to a checkout they have already paid, or abandons one part-way | When a payment is interrupted |
What each submission is allowed to do, what is refused and why, and what reaches your webhooks, is in Business Rules — start with Take a one-off payment, which owns the rules every checkout submission shares whatever shape of agreement it creates.
Configuring
What the form offers is set in two places, and it is worth knowing which is which:
- The merchant's own configuration, made in Merchant Setup: which processors are connected, which payment methods are offered, and any rules limiting a method by currency or amount. You do not control this per checkout; the merchant does.
- The checkout request, made by you: the amount and currency, whether they are fixed or the customer may change them, the agreement shape, whether a card may be saved, which screens are skipped, and where the customer is sent afterwards. See the Checkout Creation API.
A merchant can preview the result of their own configuration from Merchant Setup before taking a live payment.
Reference
Updated 20 days ago