The amount shown by a hosted payment page or wallet should match the final WooCommerce order total. A difference can result from checkout changing after the payment object was created, currency conversion, tax or fee calculation, stale sessions, or incorrect minor-unit handling.
Do not complete a mismatched payment during diagnosis. If a customer already paid, reconcile the provider and order before changing either record.
Preserve both amounts
Record WooCommerce order ID or draft reference, checkout amount, provider amount, currency and timestamps. Capture line totals, shipping, tax, discount and fees using controlled data.
Compare:
WooCommerce cart total before redirect
stored order total
provider payment amount/currency
captured/refunded amount
gateway request referenceNever capture card details, wallet tokens or full payment payloads.
Identify when the payment object is created
Some gateways create a payment intent when checkout loads; others wait until Place order. If the cart changes afterward, the provider object must be updated or replaced safely.
Inspect gateway logs for creation and update requests. A cached or delayed checkout script may use an old intent after coupon, shipping or address recalculation.
The transaction reference should link one logical checkout attempt to one provider object.
Compare stored order and cart
If WooCommerce created an order, its total is more durable than a number in the browser. Read order line items, fees, shipping, tax and discounts.
Do not edit the order total merely to match an unexplained provider amount. Determine which calculation was contractually shown to the customer and whether payment occurred.
Checkout draft orders may be replaced during retries, so correlate by order key and provider reference, not time alone.
Check currency and minor units
Providers normally expect amounts in the currency’s smallest unit. Most currencies use two decimals, but not all. A custom integration multiplying every amount by 100 can be seriously wrong.
Use the gateway extension’s currency support and provider documentation. Multi-currency plugins must pass the active order currency and final converted amount.
Avoid floating-point arithmetic in payment code; use WooCommerce formatting and integer minor units as required by the provider.
Trace tax, shipping and fees
Address changes can alter tax and shipping immediately before submission. Dynamic payment buttons may display an earlier total if they do not listen for WooCommerce checkout updates.
Custom fees must be deterministic and must not depend on a browser-only value. Search for fee hooks and confirm they do not run twice.
Test coupons, free shipping and taxes individually to find the first component that diverges.
Rule out cache and session crossover
Checkout and payment-configuration responses must not be shared page cache. Inspect Cloudflare, hosting and WordPress headers.
Use two isolated sessions with different carts. Each payment window must show its own amount. If the provider response is correct but the embedded widget is stale, inspect JavaScript state and generated assets.
Do not purge evidence until recording the failing request references.
Repair and reconcile
Correct the payment-intent lifecycle, currency conversion, rounding, fee, tax or cache boundary. If money moved, refund or adjust only through the provider’s supported process and document the order.
Never create a second charge to compensate for an incorrect first amount without explicit customer authorisation and a reconciled refund.
Verify changing totals
Test initial cart, coupon application, address/shipping change, quantity update and payment-method switch. The provider amount should update to the final stored WooCommerce total every time.
Confirm one order, one capture, correct currency, stock and email. Recurring monitoring should compare captured gateway amounts with WooCommerce order totals and alert on any non-zero difference.