WooCommerce Payment Gateway Reconciliation
TROUBLESHOOTING ROUTE
Reconcile the order before the bank deposit
A net payout combines transactions, fees, refunds and timing. Start with an order-to-gateway match, then group the verified movements into the settlement that should reach the bank.
01 · MATCH
Join order and gateway references
Compare gross amount, payment status and identifiers before introducing fees or payout timing.
02 · EXPLAIN
Classify every difference
Separate fees, refunds, chargebacks, reserves and delayed transactions rather than deleting unmatched rows.
03 · CLOSE
Retain period evidence
Save extracts, matching logic, exceptions and the approved accounting treatment for the final settlement.
Give each exception a value, owner and next action
The control is complete when unexplained items remain visible and assigned, even when the bank total can be made to agree.
What must balance
Reconciliation is not a comparison of WooCommerce sales to the bank deposit. Match the order to the gateway transaction first, then account for fees, refunds, chargebacks, timing and payout grouping before comparing the net settlement to the bank.
This process is designed for finance and ecommerce teams sharing one control. If the store also connects to inventory or accounting, see the accounting handover guide and Mitrend ecommerce systems.
Use a four-way match
| Record | Key fields |
|---|---|
| WooCommerce order | Order number, date, gross total, payment method, order status |
| Gateway transaction | Gateway reference, paid amount, status, fee and refund reference |
| Gateway settlement | Payout ID, included transactions, deductions and settlement date |
| Bank/accounting | Net receipt, bank date and ledger allocation |
Reconciliation sequence
- Export the period’s WooCommerce paid, refunded and cancelled orders without overwriting historical extracts.
- Export gateway transactions and settlements for a date range that allows for payout timing.
- Match the WooCommerce order number or stored gateway reference to each transaction.
- Separate gross sales, gateway fees, refunds, chargebacks and other deductions.
- Group transactions by payout ID and compare the calculated net payout to the bank receipt.
- Move every unmatched item to an exception register with an owner and resolution date.
Exception diagnosis
| Symptom | First checks |
|---|---|
| WooCommerce paid, gateway missing | Wrong reference, test/live credentials, delayed notification or manually changed status |
| Gateway paid, WooCommerce pending | Payment callback/notification logs and duplicate protection |
| Refund in one system only | Whether it was automatic or manually processed in the merchant portal |
| Settlement lower than expected | Fees, refunds, chargebacks, reserves and payout timing |
| Duplicate stock or finance entry | Repeated webhook/notification handling without idempotency |
Close the period with evidence
Retain the extracts, matching logic, exception register and approved journal or accounting import. Do not delete an unmatched row to make the totals agree. A carried exception should have a reason, owner, value and next action.
Refund control
WooCommerce distinguishes automatic gateway refunds from manual refund records. Confirm the gateway transaction and order notes before assuming a status change returned funds. Payfast also documents merchant-wallet and transaction conditions that can affect a refund.
Sources checked
Reviewed by
Mitrend Digital editorial team
2026-07-16
Evidence used for this page
Reviewed against WooCommerce refund behaviour and current Payfast refund guidance. Includes an original four-way reconciliation model and exception table.
Turn the guide into a practical next step
This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.
Implementation detail: WooCommerce payment reconciliation
Reconciliation joins four records that often disagree: the store order, payment gateway transaction, bank settlement and accounting entry. A repeatable exception process turns those differences into owned decisions instead of unexplained balances.
Decisions to make before changing the system
- Which identifier links the order, gateway transaction, settlement and accounting record?
- How are fees, partial refunds, chargebacks and currency differences recorded?
- When does an order become fulfilable and when is a manual review required?
- Who owns unmatched payments, duplicate orders and missing settlements?
- What period and cut-off rule keeps reports comparable each month?
- Which status or field is protected from casual editing after reconciliation?
- How are cash-on-delivery or manual EFT orders separated from gateway sales?
- What evidence is retained for an adjustment or write-off?
A controlled implementation sequence
- Define the four-record model and identifier hierarchy with the finance owner.
- Export a known period from the store, gateway, bank and accounting system.
- Match exact, partial, refunded, fee-only, delayed and unmatched records.
- Classify exceptions by cause, amount, age and owner instead of hiding them in a total.
- Post controlled corrections with notes and approval evidence.
- Review recurring exceptions and fix the upstream checkout, status or integration rule.
Acceptance controls that protect the outcome
| Control | Implementation detail |
|---|---|
| Identity | Every matched line has a stable reference and the source record can be opened. |
| Amount | Gross, fee, refund, tax and net settlement treatment is explicit. |
| Timing | Order date, gateway date, settlement date and accounting period are not conflated. |
| Exception | Unmatched or duplicate records have a queue, owner, age and next action. |
| Approval | Manual corrections and write-offs have a reason and reviewer. |
| Learning | Recurring differences become a system or process improvement backlog. |
Keep a redacted reconciliation sample, exception log, adjustment approval and month-end sign-off. The sample should show both a clean match and the most common failure, not only the easy rows.
Do not reconcile by counting orders alone. A gateway fee, refund or delayed settlement can create a real amount difference even when every order appears present.
What a useful handover includes
- A field map for order, gateway, bank and accounting identifiers.
- A monthly reconciliation workbook or report definition.
- An exception taxonomy with owner and response target.
- A correction and approval procedure for manual adjustments.
- A sample sign-off pack that another reviewer can reproduce.
- A list of upstream fixes for recurring mismatch causes.
A useful reconciliation process tells finance what is true, operations what can be fulfilled and the implementation team what must be repaired next.
Month-end exception review
A reconciliation process becomes useful when it creates a short list of decisions before the period is closed. Review unmatched payments by age, value, channel and likely cause. Separate timing differences that will resolve from real missing, duplicate or incorrectly posted transactions. The reviewer should be able to open the source records, record the correction or escalation, and leave a reason for the next person. This turns month-end from a search through four systems into a controlled review of known exceptions.
- Sort unmatched records by age and value before investigating the oldest material items.
- Separate pending gateway settlement from a missing order or duplicated payment.
- Confirm refund, chargeback and fee treatment with the finance owner.
- Lock the reviewed period or record any late adjustment with approval evidence.
- Feed recurring mismatch causes into the checkout or integration backlog.