WooCommerce 11.1 adds a refund calculation REST endpoint, and multicurrency extensions add another layer of amount, precision, and exchange-rate behavior. A store may display the current browsing currency while the original order, payment gateway, refund request, tax ledger, and accounting export use different values. Partial quantities, coupons, shipping, compound tax, fees, zero-decimal currencies, and rate snapshots make simple total comparisons unreliable. The release gate needs deterministic orders and line-level evidence in the original transaction currency.
Use this for WooCommerce stores that sell or settle in more than one currency, use a currency switcher, calculate taxes, export to accounting, or refund through a gateway with its own precision rules.
Quick answer
Freeze the WooCommerce 11.1 build, multicurrency plugin, base currency, order currency, exchange-rate source and timestamp, decimal precision, tax settings, and gateway behavior. Create deterministic orders in two-decimal, zero-decimal, and high-precision currencies. Compare the calculation response with original order lines and the admin preview, then post one authorized refund per required mode. Reconcile order currency, base-currency reporting, tax, gateway settlement, stock, email, webhook, and accounting output. Never recalculate an old order using today's exchange rate unless that is the written contract.
What to check first
- Record base, display, order, refund, settlement, and accounting currencies plus exchange-rate source, rate timestamp, decimal precision, tax mode, HPOS state, and extension versions.
- Create fixture orders with partial quantity, coupon, shipping, fee, inclusive tax, exclusive tax, mixed rate, zero-decimal currency, and rounding-boundary amounts.
- Capture original order lines, stored exchange metadata, requested refund lines, calculation response, admin preview, and an independent expected calculation.
- Post one approved test refund and reconcile the WooCommerce refund object, gateway amount, order note, stock choice, customer email, webhook, and finance export.
- Repeat the fixture after the stable 11.1 release and every multicurrency or tax extension update that can change the calculation contract.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| USD two decimals | Partial item plus tax | Preview and posted cents agree |
| JPY zero decimals | Shipping and coupon | No hidden fractional amount |
| EUR historical rate | Old order refunded today | Original rate contract applies |
| Mixed tax | Fee and shipping tax | Line and ledger totals reconcile |
Decision rule
Approve multicurrency refunds only when calculation, admin, posted refund, gateway, tax, stock, email, webhook, and accounting evidence agree under the order's documented currency contract.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze currency and version contracts
- Build deterministic precision fixtures
- Compare every calculated line
- Post and reconcile gateway evidence
- Repeat on the stable release
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze currency and version contracts | Record base, display, order, refund, settlement, and accounting currencies plus exchange-rate source, rate timestamp, decimal precision, tax mode, HPOS state, and extension versions. | Every fixture preserves the original order currency and required exchange-rate snapshot. |
| Build deterministic precision fixtures | Create fixture orders with partial quantity, coupon, shipping, fee, inclusive tax, exclusive tax, mixed rate, zero-decimal currency, and rounding-boundary amounts. | Zero-decimal and rounding-boundary orders contain no unexplained fractional drift. |
| Compare every calculated line | Capture original order lines, stored exchange metadata, requested refund lines, calculation response, admin preview, and an independent expected calculation. | The posted gateway refund matches the approved calculation in the expected currency. |
| Post and reconcile gateway evidence | Post one approved test refund and reconcile the WooCommerce refund object, gateway amount, order note, stock choice, customer email, webhook, and finance export. | Base-currency reporting and accounting exports reconcile to the documented conversion method. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
order_id=WC-111-FX-07
base_currency=USD
order_currency=EUR
order_rate=0.914725
calculated_refund=51.96 EUR
posted_refund=51.96 EUR
gateway_refund=51.96 EUR
base_ledger=56.80 USD
parity=pass
Production verification checklist
- Every fixture preserves the original order currency and required exchange-rate snapshot.
- Zero-decimal and rounding-boundary orders contain no unexplained fractional drift.
- The posted gateway refund matches the approved calculation in the expected currency.
- Base-currency reporting and accounting exports reconcile to the documented conversion method.
Why this usually happens
- The extension uses the current display currency instead of the order currency stored at checkout.
- The preview and gateway round at different stages or decimal precision.
- An old order is converted with a current exchange rate rather than its recorded rate snapshot.
- Tax, shipping, fee, and coupon lines are aggregated before conversion in one system and after conversion in another.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test WooCommerce multicurrency refunds.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references