“Paid” looks reassuring beside an online order, but it does not answer the accountant's question: where is the money now? The bank may only have authorised a hold. The provider may have collected the payment without settling it. A partial cancellation may have changed what the merchant is entitled to receive. Understanding the balance requires the order's payment history, not just its latest status label.
Keep order status, payment status and fulfilment status separate. An order can await picking after payment is complete, while delivered goods can still have a provider settlement outstanding. Under IFRS 15, revenue recognition follows the transfer of control of the promised goods or services under the contract, rather than the arrival of the gateway's bank transfer. Bank reconciliation therefore does not replace an assessment of revenue timing, and money received is not automatically earned revenue.
One order, four movements
A customer buys two products from a Saudi online store for a total of SAR 920. For this payment-tracing example, assume the provider supports authorisation followed by capture, and a product worth SAR 230 is cancelled before capture. The figures are gross payment amounts; they do not establish a tax rate or a particular charging policy.
The payment history first shows an authorisation of SAR 920, followed by an actual capture of SAR 690 and cancellation of the unused hold. When the provider settles, it deducts documented charges of SAR 12, leaving a bank credit of SAR 678. The correct reconciliation connects that transfer to the SAR 690 capture, not the SAR 920 authorisation. The SAR 230 difference is not a cash refund if it was never collected. Creating another refund merely to close the order would be a mistake.
If the provider had collected the full SAR 920 and subsequently refunded SAR 230, the evidence trail would be different even though the final net payment was the same. You would need the capture reference, refund reference and actual refund status. If charges were collected outside that settlement batch, the expected bank credit would change too. These distinctions explain why total cancelled order value is an unreliable substitute for the amount actually awaiting refund.
Ask what “refunded” means in your application. Has a request been sent to the gateway, accepted by the provider, or confirmed as completed? Customer service may close a ticket after initiating the request while the refund remains pending. Customer messages should reflect the evidence available, without promising a completion date that the payment method's terms do not support.
What belongs in the payment history?
Use the order number to group events, not as a key that permits only one payment movement. An order can have a declined attempt, a successful attempt, a partial capture and a later refund. Each event needs its own reference, type, amount, currency, timestamp and status, together with a settlement reference when available. A currency or merchant-account mismatch is enough to reject automatic matching, even when the numbers appear equal.
If the gateway sends the same success notification twice, the integration should recognise the existing event reference instead of recording another receipt. Events can also arrive out of sequence. Check the provider's transaction details before letting an older notification move a completed payment back to pending. These are proposed implementation controls, not a claim that every gateway uses identical mechanisms or terminology.
Reconcile the provider balance as a connected movement: begin with the amount receivable, add confirmed collections, then account for transfers, fees and refunds in accordance with the statement. Where the contract provides for a reserve or retained amount, track it separately with its release conditions. An amount does not disappear simply because it is unavailable for withdrawal today.
Do not test a payment integration by issuing a real refund to an arbitrary customer. Use the approved test environment, and inspect operational documents with appropriate read-only access when verifying production behaviour.
Before signing off the close, select a completed order, a partially cancelled order and an order with a pending refund. Trace each to the bank or to an explained open balance. Ask for the underlying movement rather than a green status badge. This small sample can expose duplicate receipts, confusion between authorisation and capture, and refunds closed before completion—errors that can remain hidden behind a plausible monthly total.
Sources & further reading
Visit the original source to explore the concept and its wider context.
General educational content. Appropriate treatment depends on your business and accounting policies; consult your accounting professional when applying it to business records.
