Appearance
Skip to content
Are you an LLM? You can read better optimized documentation at /checkout-flow.md for this page in Markdown format
The Checkout Flow
This page describes what happens when a customer initiates a payment through a brand's platform. It covers every step from the moment the brand sends the customer to checkout, through payment processing, to the final redirect back to the brand.
Overview
Payment Nexus hosts the checkout experience. The brand's platform never handles payment details directly — it sends the customer to Payment Nexus with a pre-configured session. Payment Nexus handles the interaction with the customer and the PSP, then redirects the customer back.
The full flow involves three parties:
- Brand Platform — the website or app the customer is using
- Payment Nexus — the payment orchestration layer (checkout UI + processing)
- Payment Service Provider (PSP) — the payment processor that handles the actual charge
Step 1 — The Brand Initiates a Session
Before the customer sees a checkout page, the brand's platform calls the Payment Nexus API to create a checkout session. This call includes:
- Who the customer is (their ID in the brand's system)
- How much they should pay, and in which currency
- Whether the customer is allowed to change the amount
- A set of destination URLs — where to send the customer after each possible outcome
Payment Nexus creates a Checkout Intent Ticket (CIT) to record the session, then responds with a time-limited checkout URL. The brand redirects the customer to that URL.
Session expiry
The checkout URL is valid for 15 minutes from the moment it is opened. If the customer does not complete the flow within that window, the session expires. The CIT remains in Payment Nexus but is never linked to a payment.
Step 2 — The Customer at Checkout
The customer arrives at the Payment Nexus checkout page and selects a payment method. The available methods depend on which channels the brand has enabled.
Payment channels come in two types:
| Type | What the customer sees |
|---|---|
| Form | Payment details are entered directly on the Payment Nexus checkout page |
| Redirect | The customer is sent to the PSP's own payment page to complete the transaction |
When the customer confirms their payment, a Payment Intent Ticket (PIT) is created and linked to the CIT. The PIT records everything about the payment attempt — status, amounts, PSP references, and the final outcome.
Step 3 — The Payment is Processed
Payment Nexus submits the payment to the PSP. What happens next depends on the PSP and the payment method:
Requires additional authentication — Some payment methods require the customer to complete a verification step (such as a 3D Secure challenge from their bank). Payment Nexus holds the payment in a waiting state while the customer completes that step, then resumes processing.
Pending — Some PSPs do not return an immediate result. Payment Nexus records the payment as pending and waits for the PSP to notify it of the outcome. Background reconciliation jobs also check back on pending payments at regular intervals in case a notification is missed.
Step 4 — The Customer is Redirected
Once the payment reaches a final outcome, Payment Nexus redirects the customer to the destination URL the brand configured for that outcome. Each outcome has its own destination, but Destination on Completed acts as a fallback for success and failure if the specific one is not set. If no destination is configured at all, the customer stays on Payment Nexus:
When no destination is configured, the customer stays on a result page within Payment Nexus showing the payment status, amount, and transaction reference, with an option to start a new payment. No error is shown.
Destination on Completed
Destination on Completed is not a separate outcome — it is a fallback used when a success or failure destination is not set. Brands use it as a catch-all landing page when they don't need to distinguish between the two outcomes.
What Operators See
From the management portal:
- The CIT records the checkout session — what was configured, when it was created, and whether a payment was initiated from it.
- The PIT records the payment attempt — its status, amounts, PSP references, and how it was resolved.
- If a payment is stuck in a non-final state, operators can use Refresh from PSP on the PIT to fetch the latest status from the provider, or use Disposition to set the outcome manually.