Introduction
Refunds sound simple until finance opens the gateway CSV and WooCommerce disagrees on amounts or dates. Voids cancel uncaptured authorizations; refunds reverse captured settlements—different timelines, fees, and audit trails. Support agents who use the words interchangeably create chargeback risk when customers expect money back faster than network rules allow.
This guide pairs with chargebacks vs refunds, authorization and capture, and payment failure recovery. It is written for WooCommerce operators who need finance-grade clarity without drowning in processor jargon.
Stores that issue store credit instead of card refunds should still reconcile liability in WooCommerce or your CRM—customers perceive “refunded” the same whether the money path is card or credit; mismatched messaging drives disputes.
B2B buyers paying by card on invoice terms may request partial credits against specific PO lines; your WooCommerce refund lines should mirror what finance posts to the ERP. If the gateway only supports full transaction refunds, document the workaround (two-step refund, manual adjustment) before audit season.
Quick answer
Train staff to say void only before capture closes, refund after capture. Log gateway transaction IDs in order notes. Reconcile daily or weekly using gateway reports as primary for money movement, WooCommerce as primary for SKU and tax lines—then document known timing lags in your help center.
1. Void vs refund
| Action | When | Customer bank view |
|---|---|---|
| Void | Auth not captured or still voidable | Hold disappears (may take days to clear) |
| Refund | After capture | Credit posts per issuer SLA |
Partial refunds after partial capture need line-item discipline in WooCommerce so accounting can tie credits to specific capture events.
2. What WooCommerce “refund” does
The admin refund button asks the plugin to call the gateway. If the integration does not support API refunds, teams refund in the portal and forget Woo—inventory and tax reports drift. Verify per plugin docs (how to evaluate payment gateway plugins).
For stores using automated exports to ERP, define whether “refunded” in Woo must precede manual portal refunds or can lag by one business day. Ambiguity here causes month-end fire drills.
3. Timing and customer expectations
State business policy clearly: “Refunds post within X business days after approval.” Do not equate the WooCommerce timestamp with the bank posting date—issuers batch credits.
Subscriptions add complexity: a failed renewal may trigger dunning while a separate refund is in flight—subscriptions article. Document how your team cancels future charges when issuing full refunds.
4. Subscriptions and partial refunds
When only part of a subscription period is refunded, ensure the gateway credit matches the proration your policy promises. WooCommerce Subscriptions and third-party subscription engines each have different hooks—test downgrade and upgrade paths in staging before advertising new refund policies.
Free trials and signup fees: Customers may dispute the first capture if they believed the trial was entirely free. Align marketing copy with gateway descriptors before you scale paid acquisition—refund reconciliation cannot fix a mismatch between ad promise and card statement text.
Tax lines: Partial refunds in Woo must reduce tax lines consistently with your jurisdiction’s rules. If your gateway sends a single lump credit while Woo breaks out VAT per line, ERP exports may disagree until you map line-level refund APIs—confirm whether your integration supports line-item refunds end to end.
5. Reconciliation workflow
- Export gateway settlements and refund batch IDs.
- Join to WooCommerce order ID via gateway reference in notes or meta.
- Investigate mismatches greater than one cent before month-end close.
- Escalate duplicate refunds (Woo + portal) immediately.
- Weekly: sample five refunds and confirm customer-visible amounts match internal ledgers.
Webhook gaps can desync status—webhook monitoring belongs in the same runbook.
Exception queue: Maintain a short list of known benign mismatches (rounding, FX, processor fees absorbed by the merchant) with finance sign-off. Everything else gets a ticket until resolved—otherwise the same five orders appear every month as “mystery cents.”
Tools: Whether you use spreadsheets, BI, or ERP connectors, the join key should be immutable gateway transaction IDs stored at capture time, not customer email alone.
Support macros: Build canned responses that distinguish “refund initiated” from “refund posted to card” so agents do not over-promise. Link to your policy page and, where helpful, the issuer’s typical posting timeline if your processor publishes one.
Disputes during refund in flight: If a customer files a chargeback while a refund is processing, coordinate with your processor—duplicate money movement creates operational pain. Chargebacks vs refunds covers the conceptual split; your runbook should name internal owners for each scenario.
Audit trail: Export a monthly sample of refunds with gateway references attached for finance review—even small stores benefit from a paper trail when questions arise months later.
FAQ
Why does Woo show refunded but the customer sees nothing?
Issuer pending, weekend batching, or partial refund applied to the wrong tokenized instrument (wallet vs physical card).
Can we bulk-refund in gateway only?
Possible but dangerous for inventory—prefer Woo-first when supported.
How do chargebacks interact with refunds?
A refund does not always prevent a dispute if the customer disputes before the credit posts—coordinate with chargebacks vs refunds.
What about multi-currency refunds?
FX rates on the refund date may differ from the capture date—finance should own the policy statement.
