Failed payments and the orders they leave behind

Every store has them. Orders sitting in a state that is neither paid nor cancelled, created when a customer reached checkout, started a payment and did not finish it.

They are easy to ignore because they represent no money. They are also the reason a store's order count, conversion rate and inventory position can all be quietly wrong at the same time.

Three ways a payment does not complete

Declined. The customer's bank or card issuer refused it. A clear outcome, communicated back to your store, usually fast.

Abandoned mid-flow. The customer was redirected to a bank or wallet screen and never came back. Nothing was declined, because nothing was attempted. Your store is left holding an order awaiting a payment that will never arrive.

Timed out or interrupted. The payment was attempted, and the answer never reached your store — a dropped connection, a closed tab, a redirect that failed. This is the dangerous one, because the customer may genuinely have paid.

The first is tidy. The second is untidy but harmless. The third is where real money goes missing in both directions.

The orphan order problem

An interrupted payment can leave the gateway holding a successful transaction that your store believes failed.

The customer has been charged. Your store shows an unpaid order. Nobody ships anything. Some days later the customer asks where their parcel is, and the answer requires somebody to open the gateway portal, find a transaction with no matching paid order, and work out what happened.

That transaction will also appear in your settlement report, and the money will appear in your payout. It will match nothing in your sales records, because the sale it belongs to was never recorded as a sale. The usual outcome is a small unexplained surplus each cycle that gets absorbed somewhere — see when the payout arrives before the report.

The reverse also happens: your store marks an order paid on an optimistic redirect, the payment is later reversed or never captured, and you have recorded revenue against money you do not have.

Both are caused by trusting a redirect rather than the gateway's own record of what happened.

Why the count matters more than the cost

Failed payments cost you nothing directly. Most gateways charge on success.

What they cost you is information, in four places.

Conversion measurement. If failed attempts sit in the same order table as real orders, your conversion rate is a fiction and so is your average order value.

Inventory. A store that reserves stock at checkout has stock committed to orders that will never be paid. On a fast-moving line that is lost sales, not just untidy data.

Customer contact. A declined payment is a customer who wanted to buy. A gentle follow-up recovers a meaningful share of them, and none of that is possible if the records cannot be distinguished from noise.

Failure-rate drift. The single most useful signal in this whole area is a rising decline rate on one method. It usually means a configuration problem, a gateway issue or a fraud filter set too tight, and it is invisible unless somebody is counting.

What to do with the residue

Reconcile against the gateway, not the redirect. The gateway's record of a transaction is the truth. Your store's order status is a claim about it. Where they disagree, the gateway wins, and the design job is making sure a disagreement gets noticed rather than assumed away.

Keep failed attempts out of your sales data. Not deleted, because the decline pattern is useful. Separated, so nothing aggregates them with real orders.

Expire abandoned orders on a fixed clock. Long enough for a slow bank redirect, short enough to release inventory. Then cancel them and release the stock, automatically.

Query the exceptions daily. Any gateway transaction with no paid order, and any paid order with no gateway transaction. Both lists should normally be empty, and the day they are not is the day you want to know — see keeping automated books healthy.

Track the decline rate by method. One number per method per week. A jump is a problem you can fix in an afternoon if you see it, and a slow revenue leak if you do not.

Where the money genuinely sits in limbo

Two situations create real, temporary exposure rather than untidy records.

Authorised but not captured. Some setups authorise a card at checkout and capture later, when the order is picked or shipped. Between those points the customer's funds are held and yours have not moved. An authorisation that expires uncaptured is a paid order that silently becomes unpaid, and the expiry window is set by the card networks, not by you.

Captured then reversed. A payment succeeds and is reversed before settlement, usually for a fraud or risk reason. Your store recorded a sale, the payout never included it, and the difference is a reconciliation exception rather than an error in your books. See chargebacks on your own store for the disputed version of the same problem.

Both need to be visible as states, not merged into paid and unpaid. A system with only two payment states cannot represent what is actually happening.

Common questions

What happens to an order when the payment fails?

It stays in your store as an unpaid or pending order, holding whatever stock it reserved, until something cancels it. Nothing removes it automatically unless you configure that, so a store with no expiry rule accumulates orders that will never be paid, and those records then distort order counts, conversion rates and inventory availability.

Can a customer be charged for a payment my store shows as failed?

Yes, and it is the most common serious version of this problem. If the payment succeeded at the gateway but the confirmation never reached your store, the customer is charged, your store shows the order unpaid, and the transaction appears in your settlement with no matching sale. The fix is to reconcile against the gateway's own transaction record rather than trusting the browser redirect.

Should failed payments be deleted?

No. Keep them, but separately from real orders so nothing aggregates them into sales figures. The decline pattern by payment method is one of the most useful diagnostics you have, because a rising decline rate on one method usually indicates a configuration, gateway or fraud-filter problem that is otherwise invisible.

How long should an unpaid order be held before cancelling?

Long enough for a slow bank or wallet redirect to complete, and short enough that reserved stock is released promptly. The exact window depends on your payment mix and how tight your inventory is, but the important part is that the rule exists and runs automatically, rather than someone tidying up manually when they happen to notice.

Related: chargebacks on your own store · the gateway reference that joins everything · keeping automated books healthy