After a percentage coupon, the total displayed in the store differs from the amount initially sent to PayPal. A later one-cent correction can coincide with payment failure in the affected workflow. The reviewed case names PayPal Payments 4.1.3 and HTTP 422 with PAYER_ACTION_REQUIRED; vendor support subsequently identifies 4.2.0 as a correction. This guide covers that version-specific incident and comparable remaining symptoms. Q1
Do not classify every 422 as a rounding defect
The error alone does not establish a one-cent discrepancy. Amounts before and after each stage make this particular pattern testable. For existing orders, reconcile any authorisation or actual capture before asking customers to try again.
WooCommerce distinguishes tax-inclusive and tax-exclusive price entry and provides rounding settings. Include these in the technical comparison; do not change them arbitrarily to make an incorrect payment amount appear consistent. Q2
Trace the amount through the workflow
- Preserve the exact cart: Record products, quantities, prices, coupon type, shipping, currency and relevant tax and rounding settings. Reproduce that cart on staging rather than testing an unrelated coupon.
- Compare calculation stages: Match the shop total, initial PayPal creation amount, any subsequent update and intended capture amount. Use the same operation references and timestamps throughout.
- Locate the difference: For a currency with two decimal places, comparing whole minor units can help. For example, 20.01 versus 20.00 becomes an explicit difference instead of being confused with rounded intermediate displays.
- Check the version: If the affected older combination is installed, evaluate a suitable supported release containing the documented correction on a backed-up copy. The reference to 4.2.0 is not a recommendation to remain pinned to that version indefinitely.
- Isolate additional calculations: If the discrepancy remains, test custom pricing filters, currency conversion, coupon extensions and shipping rules individually. A different sandbox result does not automatically disprove a live incident; document the differences.
Define the completion test
The agreed amount should remain consistent across creation, approval and capture. Then inspect order notes and payment mapping. Do not conceal the discrepancy through manual penny adjustments, skipped customer approval or repeated live collections.
Retain the original cart and its expected total as a regression sample. That is more meaningful than simply confirming that a different product can be purchased without a coupon.
Frequently asked questions
Should I change taxes or the coupon percentage?
Not as an unsupported workaround. The intended business values remain the baseline; correct the calculation stage shown to be wrong.
Does PAYER_ACTION_REQUIRED always mean this problem?
No. Without a demonstrated amount discrepancy, investigate the specific provider response separately.
Is a successful sandbox purchase sufficient?
It is a valuable test, but only comparable settings make it relevant. Account for differences from the original workflow.
Information for assistance
Provide versions, a reproducible test cart, calculation settings and the redacted amount sequence. Do not send complete payment data or customer credentials.
KAN KAI WORKS can compare the calculation path and the amounts sent to PayPal. Get help with this case.
Prepare a findings note
Summarise your observations for your enquiry. The note is created in your browser and is not saved or sent here. You can then copy it into the contact form.
Unknown is fine. Do not enter passwords, customer data or complete confidential logs.
Support with this issue
KAN KAI WORKS can compare the calculation path and the amounts sent to PayPal.
Sources and scope
Sources checked: 5 November 2026. The original incident has not been independently reproduced.
