Quick answer
If a PayPal Standard renewal amount no longer matches after a subscription price change, compare the actual gateway transaction with the renewal order and the original profile. Subscriptions 9.2 adds an expected-payment-amounts filter, but accepting an amount is not the same as changing the amount charged by PayPal.
Establish whether money actually moved
Begin in the payment provider and the store, not with a custom validation snippet. Identify the transaction, its status, currency, timestamp, and related recurring profile. Then locate the matching subscription and renewal order. A failed notification, an unmatched payment, and an unpaid renewal need different actions.
Do not mark an order paid because the customer says a payment was attempted. Equally, do not ask the customer to pay again before checking whether a completed transaction already exists. Preserve a redacted evidence trail so support and the person reconciling payments can work from the same facts.
Compare components, not only the grand total
Break the renewal order into recurring product amount, tax, shipping, discounts, and any relevant adjustments. Record which component changed and when. A currency difference or a tax-address change must not be disguised as a normal subscription price update.
Use a worksheet with one row for the gateway amount and another for the store expectation. Add the profile creation time and the price-change time. The purpose is to explain why two values differ. Do not round away the discrepancy until you have checked the currency precision and the actual values used by each system.
Understand the narrow role of the new filter
The 9.2 advisory introduces woocommerce_subscriptions_paypal_standard_expected_payment_amounts for adding acceptable renewal amounts when a subscription price changed after profile creation. That is a validation extension point. It is not documentation that every historical difference should be accepted, nor a replacement for updating a billing agreement through supported procedures.
Before implementing it, inspect the installed version and current vendor guidance for its arguments and calling context. This guide deliberately does not provide a permissive copy-and-paste callback. A callback without transaction identity, currency, and business-rule checks can turn a diagnostic problem into incorrect payment acceptance.
Build a safe comparison fixture
Use a test store and supported payment sandbox. Create one fictional subscription with a known original amount and record the profile relationship. Document the intended price-change procedure and the expected renewal behavior before running it. Keep real customer payment tokens and production fulfillment systems out of the fixture.
Capture the gateway result, notification-processing evidence, subscription record, and renewal order together. If your environment cannot reproduce the provider behavior safely, use redacted historical evidence for analysis and involve the gateway maintainer. Do not force a live renewal to obtain a convenient test case.
- One transaction must map to the intended renewal.
- A second notification must not create another paid order.
- An unexplained lower amount must remain an exception.
- A currency mismatch must not pass because the digits match.
Define acceptance and escalation rules
Have the merchant or payment owner approve the legitimate expected amount. Separate correcting an integration from deciding whether to grant a credit, collect a difference, or honor an earlier price. Those commercial decisions should not be hidden inside a technical callback.
Record the exact reason for any accepted alternative and keep its scope narrow. Monitor exceptions by subscription and transaction rather than treating all renewals as equivalent. If the evidence does not explain a difference, stop the automatic exception path and send that case for review.
Do not confuse reconciliation with migration
If the store is also moving away from PayPal Standard, maintain a separate migration plan. A new payment integration may use a different agreement and notification flow. Do not assume that fixing the old validation path transfers existing recurring agreements to the new gateway.
Preserve the original payment history while testing the replacement. Coordinate any customer communication with the merchant, and confirm that old and new processing paths cannot both act on the same intended renewal. A clean checkout with a new customer does not prove that existing subscribers migrated correctly.
Close with evidence, not a green order status
The final record should explain what was charged, why that amount was legitimate, where the payment was applied, and how repeated notifications behave. Check the next normal renewal through ordinary operations. Keep the change reversible at the code level without undoing unrelated customer orders.
Illustrative diagnostic worksheet, not results from a customer site.When to bring in help
Bring the redacted transaction ID, subscription ID, price-change time, and amount breakdown to WooCommerce payment support. Do not provide gateway passwords or full customer payment details. An unexplained payment difference needs reconciliation, not a broad filter that accepts anything.
Related troubleshooting
Plan the wider PayPal Standard migration.
Helpful references
Subscriptions 9.2 developer advisory.