Why gateway settlements do not match your store orders

Open one payout statement from the gateway. It lists every transaction, deducts processing fees, subtracts refunds and chargebacks, and sometimes holds back a reserve, so what reaches your bank is only the remainder.

Your store records something else. It logs the gross order value on the day of purchase, before any fee, refund or dispute touches the money, so a gap shows the moment you compare totals.

Reconcile by rebuilding the payout line by line from the fee report, the refund list and the dispute log, then tying every remaining line to one store order. Anything left over is the mystery.

Cut off hours rule everything. A gateway closes each batch at a fixed hour, so an order paid at 11:58 at night may land in tomorrow’s batch and a Friday evening order may wait. Weekends and bank holidays stretch the delay further, because the gateway may pay only on working days and the bank may credit the next morning.

Time zones add confusion. The store may log in one zone and the gateway report in another, so the same order falls on different dates and the daily totals never agree.

Match on transaction ID, never date. Dates only tell you when to expect money, while the transaction ID names the exact order, the exact fee line and the exact refund that belong together.

Authorise first, capture later. Many stores authorise the card at checkout and capture only at dispatch, so a shipment of three items from an order of five captures part of the amount. The balance is voided or captured in a second step, and until that step closes the order total and the settled amount will not agree.

Webhooks fail more often than people expect. A restart or a timeout can drop the message saying payment succeeded, so the order sits as pending in the store while the money has reached the gateway.

Run a nightly job that asks the gateway for every transaction from the last two days and compares each status with the store record. Idempotency keys on retries stop duplicate captures. Log every mismatch with the gateway reference, the store status and the time, so a repeat offender such as one slow endpoint becomes obvious within a week.

COD orders skip the gateway entirely. The courier collects the money, deducts its own charge and remits in a weekly or fortnightly batch, sending a manifest that lists each airway bill number. Courier charges vary by weight slab and zone, so the remitted figure rarely equals the collected figure, and small differences on many parcels add up to a visible shortfall.

Treat each remittance as its own settlement. Match the courier’s airway bill numbers to store orders, flag any parcel marked delivered with no cash remitted, and check that returned-to-origin parcels show no money due.

The report has one row per order. Columns run in a fixed order: order total, gateway amount, fee, refund, net settled, payout reference, bank date and status, with unmatched rows sorted to the top.

Set a rounding tolerance. Review exceptions daily, because a gap a month old needs bank statements, courier manifests and chat logs to trace, while yesterday’s gap needs one glance.

Start with last month. Export the payout files, match fifty orders by hand and note the cause of each difference, whether fee, refund, batch cut off or dropped webhook.