Checkout Finished, Payment Still Pending: When May Your App Release the Order?

A completed checkout journey is not always a successful payment. If your shop accepts a method whose result arrives later, agree when the order may enter fulfilment and what the customer sees while it waits. Do not let a page called “success” become the only instruction to dispatch goods or open paid access.

This decision differs from deliberately reserving a card payment for later capture. Here the payment method itself may still be processing after the customer finishes checkout. The following uses Stripe Checkout as a documented example, not a claim that every payment integration behaves identically.

Describe the waiting period before building the screen

In a fictional shop selling training materials, a buyer completes the bank-payment steps and returns to the shop. The team needs to know whether it may send the materials now. Ask the payment implementer which provider state establishes the agreed release condition. A completed browser flow, an order number and the customer’s assurance are not substitutes for that check.

Stripe’s fulfilment guide explains that some payment methods do not complete immediately. For delayed methods, it documents a later checkout.session.async_payment_succeeded event and also recommends handling checkout.session.async_payment_failed. Agree a pending state and both later outcomes, not just the happy path.

For the first version, you might choose to hold fulfilment until the configured successful-payment condition is verified. If the business deliberately accepts earlier release, record that as a separate risk decision. Do not disguise it as a technical guarantee of payment.

Give customers a useful pending result

A pending page should explain that payment confirmation is outstanding, identify the order and offer an appropriate way to check its status. Avoid a generic “try again” invitation that may encourage another payment while the first remains unresolved. Do not invent a universal processing time or promise that later success means money can never be reversed.

Specify the message for later failure and who handles cases that remain unresolved. A failed payment and a cancelled commercial order are separate decisions. In particular, decide whether staff should contact the customer, offer a supported payment continuation or close the order under the reviewed business policy.

Do not depend on the shopper returning

Stripe explicitly warns that a customer can pay successfully and lose connectivity before the landing page loads. Its guide therefore requires webhooks for reliable automated fulfilment rather than relying only on that page.

Ask for a demonstration in which the customer never returns to the shop. The order must still be evaluated against the provider’s verified state through the implemented server-side path. Conversely, manually opening a return URL must not itself prove payment or grant access. Page wording should reflect the server’s result, not a hopeful interpretation of the URL.

One payment must not create two releases

The guide warns that fulfilment can be called repeatedly, even concurrently, for the same Checkout Session. Require the developer to show the order-to-session relationship and a durable record of the release action. A browser return and a delayed event must not each create their own shipment or entitlement.

External effects need particular care. Recording a local event once does not make a warehouse request or email transactional. Agree how a lost response is reconciled with the existing operation before another attempt. Keep uncertain actions visible rather than quietly marking them failed and starting unrelated replacements.

Demonstrate the complete handover

Use provider test mode and harmless orders to show pending followed by success, pending followed by failure, a missing customer redirect, repeated and concurrent notifications, and an interrupted downstream release. Compare the provider state, internal order and actual fulfilment record.

Put these outcomes in the acceptance criteria. Bring the supported payment methods and release policy to your shop-app discussion. The deliverable is a trustworthy handover from payment evidence to fulfilment, not merely a reassuring confirmation page.

Source boundary

The source supports the Stripe-specific delayed events, redirect limitation and repeated-call warning. Customer wording, risk ownership, durable action tracking and reconciliation are proposed requirements to implement and test, not certified properties of a custom integration.