A checkout recovery message can be sent hours after the original cart was calculated. During that time a coupon may expire, a sale may end, inventory can change, the customer location can alter tax, shipping rates can update, or a multi-currency plugin can use a new exchange rate.
Use this for WooCommerce stores with checkout recovery, coupons, dynamic pricing, tax plugins, shipping calculators, subscriptions, multi-currency, or prices that change by customer role.
Quick answer
Treat the recovery link as a new pricing decision, not a frozen receipt. Recalculate the cart on open and again before payment, explain any meaningful change, and make sure the order, payment request, confirmation page, emails, and analytics all use the accepted final amount.
What to check first
- Save a synthetic abandoned cart with product prices, quantities, coupon, discount allocation, shipping method, customer location, tax lines, currency, exchange rate, and expected total.
- Expire the coupon and end one sale before opening the recovery link, then record the recovered cart message and recalculated lines.
- Change the shipping address across tax jurisdictions and make one original shipping method unavailable.
- Run one multi-currency case with a changed exchange rate and verify rounding at line, tax, order, and payment levels.
- Complete payment only after confirming the customer-facing total matches the gateway amount, WooCommerce order, emails, analytics purchase event, and refund basis.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture original price lines | Save a synthetic abandoned cart with product prices, quantities, coupon, discount allocation, shipping method, customer location, tax lines, currency, exchange rate, and expected total. | The recovered cart explains expired or invalid discounts without a silent price jump. |
| Change one pricing input | Expire the coupon and end one sale before opening the recovery link, then record the recovered cart message and recalculated lines. | Tax, shipping, currency, and rounding are recalculated from current valid inputs. |
| Reopen the recovery URL | Change the shipping address across tax jurisdictions and make one original shipping method unavailable. | Gateway, order, confirmation, email, analytics, and refund records share the final total and currency. |
| Recalculate before payment | Run one multi-currency case with a changed exchange rate and verify rounding at line, tax, order, and payment levels. | A stale recovery URL cannot bypass current inventory or promotion rules. |
Why this usually happens
- Abandoned checkout data can preserve a snapshot while WooCommerce pricing rules continue changing.
- Coupons and shipping rates have their own validity windows and conditions.
- Tax is calculated from the current taxable location, which may not match the original partial checkout.
- Currency and rounding plugins can calculate at different stages of recovery and payment.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
cart_case: REC-TOTAL-06
saved_total: 128.40
saved_currency: USD
coupon: SAVE20
coupon_status_on_open: expired
shipping_method_on_open: unavailable
recalculated_total: 142.18
payment_request_total: 142.18
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture original price lines
- Change one pricing input
- Reopen the recovery URL
- Recalculate before payment
- Reconcile every output
Decision rule
Never charge the saved amount when current catalog, coupon, tax, shipping, or currency rules produce a different valid total. Show the change clearly and require the customer to accept the payable amount.
What to tell the client or owner
Share the product and coupon rules, saved cart lines, original and current addresses, tax and shipping plugins, currency settings, timestamps, recovered output, gateway request, order totals, email, and analytics payload.
Production verification checklist
- The recovered cart explains expired or invalid discounts without a silent price jump.
- Tax, shipping, currency, and rounding are recalculated from current valid inputs.
- Gateway, order, confirmation, email, analytics, and refund records share the final total and currency.
- A stale recovery URL cannot bypass current inventory or promotion rules.
Mistakes to avoid
- Do not promise that recovery preserves every original price.
- Do not update only the visual cart while sending a stale amount to the gateway.
- Do not test tax with the same address in every case.
- Do not ignore zero-decimal and multi-currency rounding rules.
Questions teams ask during testing
Should an expired coupon remain valid in a recovery link?
Only if the merchant intentionally defines and implements that policy. Otherwise WooCommerce should apply current coupon rules and explain that the saved discount is no longer available.
What amount should the purchase event report?
Report the amount the customer actually accepted and paid, using the same order ID and currency as the completed WooCommerce order.
When HandL WP should help
HandL WP can isolate stale recovered totals across WooCommerce, tax, shipping, currency, payment, and analytics layers before real customers see contradictory amounts.
If this is active on a production site, test WooCommerce recovered cart totals.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references