A suspected Adaptive Pricing amount mismatch can lead to a refund request, a card dispute, or merchant uncertainty. The evidence must show what WooCommerce calculated, what Stripe processed, which currency applied, what changed afterward, and whether the affected plugin version was active at the time.
Use this for support, finance, developers, and agencies handling a specific customer case after the Stripe for WooCommerce payment validation advisory.
Quick answer
Freeze the case timeline before editing the order. Capture the original order data, transaction and PaymentIntent identifiers, integer amounts, currencies, exchange-rate context, capture and refund events, order notes, customer messages, access logs, plugin version history, and patch timestamp. Redact unnecessary personal data and avoid duplicate refunds.
What to check first
- Export the order as it existed at payment time, including line items, coupon, shipping, tax, fee, total, currency, transaction ID, status history, and notes.
- Capture the Stripe PaymentIntent, Charge, Balance Transaction, refund, and dispute identifiers with event timestamps and integer minor-unit amounts.
- Record the plugin version and Adaptive Pricing state at transaction time plus the update or mitigation timeline.
- Preserve relevant application, webhook, and access-log references without copying full card, address, or unnecessary customer fields.
- Choose one case owner who coordinates customer communication, refund approval, dispute response, accounting treatment, and closure evidence.
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 |
|---|
| Freeze the original case | Export the order as it existed at payment time, including line items, coupon, shipping, tax, fee, total, currency, transaction ID, status history, and notes. | The case timeline reconciles order, payment, refund, dispute, and patch events. |
| Join all payment identifiers | Capture the Stripe PaymentIntent, Charge, Balance Transaction, refund, and dispute identifiers with event timestamps and integer minor-unit amounts. | Currency and minor-unit amounts are explicit at every financial step. |
| Build the timestamped timeline | Record the plugin version and Adaptive Pricing state at transaction time plus the update or mitigation timeline. | The customer action has one approver and no duplicate reimbursement. |
| Choose the financial action | Preserve relevant application, webhook, and access-log references without copying full card, address, or unnecessary customer fields. | The retained evidence is sufficient but excludes unnecessary personal and payment data. |
Why this usually happens
- Order edits can overwrite the context that explains the original payment.
- Stripe, WooCommerce, and accounting systems may use different identifiers for the same case.
- A dispute deadline can encourage rushed evidence collection and duplicate financial action.
- Over-collecting customer data creates privacy risk without improving the amount comparison.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case_id: AP-2026-0042
order_id: 18422
transaction_id: ch_redacted
payment_intent: pi_redacted
order_total_minor: 12840
charged_minor: 12840
refunded_minor: 0
dispute_id: none
patch_completed_at: 2026-07-21T15:10:00Z
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.
- Freeze the original case
- Join all payment identifiers
- Build the timestamped timeline
- Choose the financial action
- Record closure and monitoring
Decision rule
Refund only after confirming the amount and checking existing refunds and disputes. If the transaction is already disputed, coordinate the refund and evidence path with the payment team so two processes do not reimburse the same amount.
What to tell the client or owner
Share the redacted case ID, order and payment identifiers, amounts, currencies, event timeline, affected-version evidence, patch status, customer request, refund or dispute action, approver, and monitoring result.
Production verification checklist
- The case timeline reconciles order, payment, refund, dispute, and patch events.
- Currency and minor-unit amounts are explicit at every financial step.
- The customer action has one approver and no duplicate reimbursement.
- The retained evidence is sufficient but excludes unnecessary personal and payment data.
Mistakes to avoid
- Do not edit order totals before exporting the original state.
- Do not paste full customer records into tickets or shared chat.
- Do not confuse a PaymentIntent with a settled balance transaction.
- Do not send a refund while another operator handles the dispute without coordination.
Questions teams ask during testing
Does the advisory prove a specific disputed payment was wrong?
No. It identifies an affected configuration and version range. The individual case still requires an order-to-payment comparison and a timeline.
How much evidence should be retained?
Keep the minimum needed to explain the transaction, authorization, patch state, customer action, and closure. Follow the merchant's retention and access policies.
When HandL WP should help
HandL WP can preserve the technical record, reconcile WooCommerce and Stripe events, support the payment team with a clean timeline, and verify the patched checkout afterward.
If this is active on a production site, investigate a WooCommerce Stripe payment case.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references