A Stripe security update deserves more than one new-card purchase. Saved payment methods touch customer tokens, account ownership, subscriptions, SCA, retries, refunds, and checkout blocks, so a narrow regression can miss the workflow that produces the largest customer impact.
Use this for WooCommerce stores that allow customers to save cards, use subscriptions, offer account checkout, or rely on returning-customer payment tokens.
Quick answer
On staging, test a new card, a saved card, an expired token, SCA, guest checkout, account checkout, subscription renewal, and refund. Confirm the token belongs to the authenticated customer, Stripe and WooCommerce agree on state, and logs do not expose payment data.
What to check first
- Inventory checkout blocks, classic checkout, subscriptions, express methods, and token plugins.
- Create disposable customer accounts with known saved, expired, and missing payment methods.
- Record PaymentIntent, customer, payment method, order, and subscription IDs for each fixture.
- Compare success, decline, SCA, retry, and refund states in Stripe and WooCommerce.
- Review logs and database records for unsafe cardholder data or cross-account token access.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Update Stripe for WooCommerce and every checkout-dependent extension on staging. | Inventory checkout blocks, classic checkout, subscriptions, express methods, and token plugins. | Every successful fixture creates one intended payment and matching order state. |
| Remove stale or orphaned tokens only after customer and subscription ownership is reconciled. | Create disposable customer accounts with known saved, expired, and missing payment methods. | Denied and expired fixtures create no paid order or unauthorized token access. |
| Fix authorization so tokens are loaded and used only for the current customer. | Record PaymentIntent, customer, payment method, order, and subscription IDs for each fixture. | SCA and webhook transitions settle into the expected terminal state. |
| Align asynchronous order transitions with Stripe event handling. | Compare success, decline, SCA, retry, and refund states in Stripe and WooCommerce. | Logs and database exports contain identifiers but no prohibited card data. |
Why this usually happens
- Saved methods add a token ownership boundary that a guest new-card test does not exercise.
- Checkout blocks, classic checkout, subscriptions, and express flows can call different handlers.
- The browser can report success before webhook confirmation produces the final order state.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,customer_state,payment_method,expected_order
new-card,guest,pm_card_visa,paid
saved-card,authenticated,owned_token,paid
expired,authenticated,expired_fixture,failed
sca,authenticated,requires_action,on-hold-to-paid
cross-account,authenticated,foreign_token,rejected
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Returning customer | Authenticated account selects valid saved card | One charge and one paid order tied to correct customer |
| Expired method | Authenticated account selects expired fixture | Clear failure, no paid order, retry path available |
| SCA challenge | Saved method requiring authentication | Challenge completes and final order follows PaymentIntent |
| Cross-account attempt | Second account references another token | Method unavailable and server rejects unauthorized ownership |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Update Stripe for WooCommerce and every checkout-dependent extension on staging.
- Remove stale or orphaned tokens only after customer and subscription ownership is reconciled.
- Fix authorization so tokens are loaded and used only for the current customer.
- Align asynchronous order transitions with Stripe event handling.
- Run the complete fixture matrix before and after production deployment.
Decision rule
Stop rollout for any cross-account token exposure, duplicate charge, missing SCA path, or paid Stripe object without a matching WooCommerce order. A cosmetic saved-card label defect can follow the normal release path if payment and ownership remain correct.
Production verification checklist
- Every successful fixture creates one intended payment and matching order state.
- Denied and expired fixtures create no paid order or unauthorized token access.
- SCA and webhook transitions settle into the expected terminal state.
- Logs and database exports contain identifiers but no prohibited card data.
Field notes
- Use Stripe test data and isolated staging accounts, never a real card.
- Verify database records by token identifiers, not card numbers.
- Include a second user to prove saved methods cannot cross account boundaries.
Questions teams ask during testing
Why include a cross-account attempt?
It directly tests the authorization boundary around a saved token.
Should subscriptions be a separate run?
Include at least one renewal fixture because subscription handlers and timing differ from manual checkout.
What IDs should be retained?
Keep test customer, payment method, PaymentIntent, order, subscription, and webhook event IDs.
Mistakes to avoid
- Do not test only a guest purchase with a new card.
- Do not use a real card or production customer token.
- Do not mark browser success as final before webhook reconciliation.
- Do not delete tokens broadly to solve one account mapping defect.
What to tell the client or owner
Provide fixture name, customer state, WooCommerce order, Stripe object IDs, final state, and whether the issue occurs in blocks, classic checkout, or both.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test a WooCommerce Stripe update.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references