BNPL Direct Integration
Overview
BNPL from your own server is a redirect flow, and it uses the same authState pattern as every other CrissCross method that needs the customer to go somewhere. There is no BNPL-specific endpoint and no SDK.
The shape is: create a session, initiate the payment, send the customer to the URL you get back, and wait for the webhook.
Pre-requisites
- BNPL enabled on your account, with a settlement option agreed. See Buy Now, Pay Later.
- A session created with
integrationType: "direct"and an HTTPSredirectUrl. - The session amount within your BNPL limits, and a
ZAR/ZAFsession.
The flow
Create a checkout session
amount is in minor units — the example is R4 500.00, a basket size where an instalment plan is worth offering.
Confirm BNPL is eligible
Do not offer BNPL in your UI without checking. Eligibility depends on your configuration and on the session’s amount, currency and payer location:
Offer BNPL only if an entry with "type": "bnpl" is present.
Initiate the payment
You do not send the instalment term. The customer chooses it, between two and six months, inside the flow.
Redirect the customer
BNPL always returns PENDING with a redirect authState — there is no synchronous success, because the customer has not chosen a plan yet:
Send the customer to authState.redirectUrl as returned. Do not rebuild it, embed it in an iframe, or open it in a background tab — the flow collects card details and must run as a top-level navigation.
Store transactionId against your order before redirecting. It is how you match the webhook.
Handle the return
The customer comes back to the session’s redirectUrl with ?status=completed, ?status=failed or ?status=cancelled.
This is a display signal only. ?status=completed means the customer finished the flow, not that the payment is settled — and ?status=cancelled is the ordinary outcome of a customer who was not approved or who declined the terms, which is not an error. See When a customer is not approved.
Confirm with the webhook
The webhook is authoritative. Match on transactionId, sessionId or merchantReference, verify its signature, and only then fulfil. The payload carries paymentMethodId: "bnpl" and the instalment term the customer chose. See Webhook Events.
A customer who abandons the flow entirely still produces a webhook when the session expires.
Cancelling before completion
A BNPL payment that has not been completed can be cancelled — for example if the customer returns to your site and empties their basket:
Cancelling produces a webhook. A payment the customer has already completed cannot be cancelled — refund it instead.
Polling
Prefer the webhook. If you need to check state directly — reconciling after an outage, or driving an order status page — read the transaction rather than polling in a tight loop:
A customer can sit in the instalment flow for several minutes, so a PENDING BNPL transaction is normal and not a sign of a problem.
Things that will bite you
- There is no synchronous success. Any BNPL initiation that returns anything other than
PENDINGwith a redirect is a failure to initiate, not a completed payment. ?status=cancelledis expected traffic, not an incident. Affordability declines arrive this way.- Do not iframe the redirect. It collects card details and needs a top-level navigation.
- Settlement is not one entry per order under instalment settlement. Reconcile on the transaction. See Settlement Reporting.
Additional resources
- Buy Now, Pay Later — settlement options, supported workflows, refunds and reconciliation.
- Full and Partial Refunds — refunding a BNPL payment.
- Webhook Events — the authoritative payment outcome.