Web · Practical guide
Payment successful—but where is the order?
The checkout edge cases every ecommerce business should discuss before accepting its first customer payment.
A confirmation screen is not the whole transaction
Picture a customer who completes payment and closes the browser before returning to your store. If the store depends only on that return page to create the order, the customer and the operations team may see different outcomes. A reliable checkout needs a way to reconcile payment state without relying on one uninterrupted browser visit.
Map the journey from cart to order, payment attempt, confirmation and fulfilment. Give each state a clear meaning. “Pending”, “paid” and “ready to dispatch” should not be interchangeable labels, because different people and systems act on them.
Confirm payment through a trusted backend path
Ask how the server verifies the payment provider’s result and connects it to the expected order and amount. Do not accept a browser message as sufficient proof that an order has been paid. Keep secret credentials on the server and use the provider’s documented integration approach.
For an example of why defensive handling matters, Stripe documents that webhook events can be delivered more than once and are not guaranteed to arrive in generation order. It recommends signature verification and duplicate handling. Other providers have their own rules; review the documentation for the provider actually selected.
Make retries safe for the customer
A customer who sees a spinner may tap the payment button twice. A provider may retry a notification. The application should not turn those repetitions into two shipments or conflicting order records. Ask the engineering team to explain how repeated operations are recognised.
Test a double tap, a refreshed confirmation page and a repeated provider notification. Check both the customer’s order history and the administration view afterwards. An interface that displays one order is not enough if the backend has created duplicate fulfilment work.
Decide what happens when stock changes
For limited stock or appointment slots, a delay between selection and confirmation matters. Agree whether stock is reserved, how long a reservation lasts and what happens if payment arrives after that reservation expires. These are business rules that the software needs to express clearly.
Use an example involving the final available item. Let two test customers attempt to buy it, then interrupt one payment. The expected outcome should be written before testing starts, including what each customer sees and what operations must do if manual intervention is required.
Design refunds and exceptions as normal operations
A complete checkout also needs a clear way to handle cancellations, refunds and uncertain payment status. Decide who can perform each action, what information they need and how a customer receives an update. Do not make support teams guess from screenshots sent over chat.
Keep order identifiers and payment references connected so authorised staff can investigate. Avoid exposing sensitive payment information in ordinary logs or support messages. Give the team a clear escalation route for a transaction that cannot be reconciled automatically.
A useful pre-launch checkout rehearsal
Use the provider’s test environment for successful, failed, cancelled and delayed outcomes. Repeat the journey on mobile and desktop. Check notification failures, duplicate events, order history, stock and the operations queue—not only the final confirmation screen.
Keep real transactions out of an informal test session. If a controlled live verification is needed, agree the amount, account, refund handling and responsible person explicitly. The objective is a checkout whose customer experience and operational records tell the same story.