Payment taken but no order created: where to look

Open the gateway dashboard, find the transaction by payment ID, amount and time, and note its status, the reference your site sent and whether the callback shows as delivered. Also record the card network response, the three-step authentication result and the settlement status, since some gateways show a charge as authorised long before the money is captured.

If the gateway shows no success, the shopper was not charged, and a pending hold on a card authorisation often clears itself without any refund. Captured means your own system is next.

Keep the payment ID. Every later check starts from it, so screenshot the gateway record and paste it into the ticket before settlement reports are archived and today’s detail is summarised.

A lost callback explains most cases. The shopper pays, the gateway tells your server and your server never records it, while the browser redirect after payment proves nothing because a closed tab skips it.

Read the web server log. Look near the payment time for the incoming request, its response code and signature check failure, because a 500 error, a timeout and a firewall block each look different.

Gateways retry failed callbacks for a period, so orders can appear late once your endpoint recovers, which means the handler must cope with the same event arriving twice. Some gateways offer a replay button for failed events, but press it only after the handler is fixed, otherwise the same callback simply fails again and clutters the log.

Arrival is not the same as saved. Find where the handler read the cart, checked stock and wrote the order row, since an expired cart, a sold-out item or a database lock can halt it.

Search the order table by merchant reference for a row with a failed or pending status, and check whether the payment record was written while the order rolled back. Support staff should be able to open that row and see the cart snapshot, the stock check result and the exact error stored with the failed attempt.

If the handler charges before it reserves stock, you see money without orders when stock runs out, as in a sale when many carts want the last unit.

Blank pages cause retries. You may then find two charges and one order, or one charge and a second order created from the retry, depending on where the first attempt stopped.

Compare the two payment IDs and cart IDs, because a good checkout uses an idempotency key so the same cart cannot create two orders. Check that yours does. Retries also happen on the server side when a timeout makes your own code resend the order request, so search the application log for repeated calls with identical carts.

Refund the duplicate through the gateway, note the reason against the order, and tell the shopper which charge was reversed and when to expect it.

Write one test per failure. Run each in the gateway sandbox. Fail the callback with a 500 error, delay it by several minutes, send it twice, close the tab before the redirect, and let the cart expire during payment.

Each case needs an expected outcome. That outcome is one order and one charge, or an automatic refund with a clear message to the shopper, and anything else counts as a defect.

Add a nightly job that lists captured payments with no matching order, and review that list every morning before the first shopper writes in. Give finance the same list. They match gateway settlements against the order register, and a payment with no order would otherwise sit unexplained in the books until the month closes.