Customer paid but no order appeared: review the checkout handoff

Define the link between payment and order

Start with one sample purchase and write down the records it should create. The order needs enough information for staff to identify the customer, confirm the items, check the amount and currency, and find the related payment. Decide which reference connects those records.

For example, a shop selling a printed notebook should be able to trace one purchase from its checkout reference to its payment record and delivery details. A receipt alone does not tell the packing team whether the address is complete or the correct product was selected.

Test what happens when the browser disappears

Stripe explicitly advises against relying only on the checkout landing page for fulfilment. Its guidance uses signed webhook events, accounts for repeated or concurrent calls and delayed payment success, and records fulfilment status.

In a controlled test environment, complete a payment and close the browser before the confirmation page loads. Check whether the order still reaches the expected state. Then reopen the order through the normal customer route. Record whether the customer and staff see consistent information, rather than treating a missing confirmation screen as proof that payment failed.

Use a small matrix of difficult cases

Include a straightforward successful purchase, an abandoned checkout, a failed payment, a repeated payment event and a delayed payment that later succeeds. For every case, specify the expected payment state, order state, customer message and staff action before running the test.

For the repeated-event case, look for duplicate orders, duplicate stock deductions or duplicate delivery instructions. For delayed payment, check that the order remains understandable while payment is pending and becomes actionable only under the business's agreed rules. These expectations should reflect the payment methods actually offered.

Make reconciliation part of operations

Choose a manageable review period and compare payment records with orders using the shared reference. Flag paid transactions with no matching order, orders that appear paid without supporting payment records, and amount mismatches.

Give each exception a next action and an owner. A customer-support colleague should know where to investigate before asking someone to pay again. Record corrections so the next review can distinguish a resolved exception from a newly discovered problem.

Keep a record that survives the project

Save the test date, environment, sample references, expected result, observed result and unresolved issues. Repeat the relevant cases after changes to checkout, order handling or payment methods. This gives the business a practical acceptance record instead of a vague statement that checkout was tested.