Checkout integrations

A checkout integration works when the basket, payment service and order system agree on the current order and its payment outcome. Map who owns each value, how records are joined, and which outcome permits fulfilment. Check those handoffs when a basket changes or a payment is interrupted.

Map the handoffs

For an order charged in AUD, compare the AUD amount at review, payment submission and order creation. Matching numbers with different currency labels are not a match.

Stripe vs PayPal: Key differences for Australian businesses

Define the event interface

Treat the provider’s event endpoint as a defined boundary between payment processing and the store’s order logic. Stripe sends webhook events to an HTTPS endpoint as JSON payloads, including asynchronous changes such as a bank confirming a payment.

For Stripe, registered webhook endpoints must be publicly accessible HTTPS URLs. Stripe permits one endpoint to handle several event types, or separate endpoints for particular types.

Stripe allows up to 16 registered endpoints. Document which event types each endpoint handles and which order actions those events can trigger.

Keep orders and payment attempts traceable

Give the purchase a stable store reference. Retain the provider references and outcomes needed to distinguish its attempts; the exact identifiers depend on the provider.

Define what leaves the order awaiting payment, what keeps it pending and what permits fulfilment. If authorisation and capture are separate, specify which outcome is sufficient for the action the store will take.

A browser return can show the customer the order’s known state, but it cannot be the sole automatic fulfilment trigger.

Stripe’s hosted Checkout guidance says a customer may pay without reaching the landing page and uses webhooks for dependable fulfilment. It also requires fulfilment to tolerate repeated calls for one Checkout Session.

Other integrations need their own documented outcome rule.

Set the server-side fulfilment contract

For Stripe Checkout, the fulfilment function runs on the server and accepts a Checkout Session ID. It retrieves that Session with the line items expanded, checks payment_status to decide whether fulfilment is required, fulfils the items and records the fulfilment status for that Session.

Use those operations as acceptance criteria for the integration: the order action must be based on the retrieved Session and its payment status, and the resulting fulfilment record must be associated with that Session. Stripe says the function must correctly handle multiple calls with the same Session ID.

Order fulfilment process with Stripe Checkout

Recalculate before payment

A discount, quantity, address or delivery change may alter the amount payable.

Identify the systems that decide promotion eligibility and delivery charges, then produce one current order snapshot for checkout, payment and order management. If a provider session already contains an older amount, follow that product’s supported update or replacement process before the buyer pays.

Keep reporting values separate from the charge. Define and interpret analytics event values according to the relevant reporting specification; they are not automatically the amount charged to an Australian shopper.

Handle late and repeated outcomes

Record incoming provider events and apply an order transition only when the event matches the intended payment and the current order state permits it. Design event processing so repeated or concurrent handling cannot cause an invalid order transition.

Keep processing or unknown payments out of fulfilment until the store’s release condition is met. If an outcome is unknown, investigate the existing attempt before inviting another charge. Customer and staff messages should reflect the state the integration can actually establish.

Account for delayed state changes

For Stripe subscriptions and payment methods with delayed success notifications, Stripe requires automatic fulfilment using webhooks. Subsequent payment state changes occur only after the Checkout Session completes, so an immediate browser return is not enough to establish the later outcome.

Include these cases in the integration’s acceptance criteria where they apply: identify which later state change updates the order, and confirm that fulfilment follows the established payment outcome rather than the initial redirect.

Choose how fulfilment is operated

Stripe describes manual fulfilment using information in its Dashboard, payment notification emails or reports, and automatic fulfilment through an integration.

It says the manual approach can suit low-volume or experimental ventures, while recommending automation for most situations.

If the store automates fulfilment, Stripe’s guidance combines webhooks with a customer redirect: webhooks ensure each payment can trigger fulfilment, while the redirect can give customers immediate access to services or fulfilment details.

Keep the redirect’s customer-facing role separate from the system’s dependable fulfilment decision.

Manual vs automated fulfilment: considerations for Australian stores

Check the connected journey

Use representative orders to check an ordinary payment, a changed basket, a failed attempt with a retry, and an interrupted return. Add a delayed outcome when the offered method supports one.

Compare the displayed total, payment record, order timeline and analytics event for each path. Record which paths were exercised in the permitted test environment and which still need account-specific confirmation.

For a Stripe Checkout integration, compare the recorded order state with the customer-facing outcome for a relevant order, and confirm any mismatch has a documented investigation path.

Protect checkout information

Where the Privacy Act 1988 applies, the OAIC says covered entities must take reasonable steps to protect personal information they hold from misuse, interference, loss and unauthorised access, modification or disclosure. The OAIC’s guide says reasonable steps include technical and organisational measures for information held after 11 December 2024.

The OAIC guide also says entities should destroy or de-identify personal information once it is no longer needed, unless an exception applies.

Include information handling in the integration review: identify where personal information passes between checkout, payment and order systems, and who is responsible for protecting it and deciding when it is no longer needed.

The guide is guidance, not legally binding.

Australian data protection requirements under the Privacy Act 1988