Subscriptions and Recurring Billing
- Renewal failed? Open the invoice and payment history
- Check who schedules retries before changing anything
- Test the customer's payment link and failed-payment email
- Choose what happens to access when recovery ends
- Cancellation, dispute or frozen membership? Use its own path
Your renewal failed, and you're trying to keep a customer. Start with the failed invoice and check its payment history before you retry or send another message. If they've cancelled or disputed, take that path first.
Your renewal failed. What now?
Open the failed invoice and its payment history, then match the subscription, amount and customer's message. Keep the decline detail beside the current subscription state.
More attempts than you configured? Compare the policy with actual payment records, checking your app, manual retries and any other scheduler. Ask support: "Who started each attempt? Which ones created a charge?"
In Stripe, a retry counter isn't a charge count. After certain hard declines, scheduled attempts can increase attempt_count without creating a Charge. Check the executed payment records before deciding you've charged again. Stripe retry guide.
| What happened | Start here |
|---|---|
| Renewal failed, and the customer wants to stay | Check recovery setup |
| Customer updated their card, but payment still fails | Check which saved card the subscription uses |
| Customer asked to cancel | Find the request and effective date. Use Recurring Billing Requirements |
| There's an open dispute | Read the case before another money action |
| Cards are failing across the account | Use Fix Declining Auth Rates |
Set up recovery before you buy another tool
First, find which product bills this customer, then find who schedules the retries. They're two checks, even if one product does both.
Check signup and cancellation records against Recurring Billing Requirements. This recovery setup doesn't establish permission to bill. Test the update link, message and ending state before comparing tools.
Stripe Billing
For automatically collected card renewals, open Billing > Revenue recovery > Retries. For failed-card emails, open Revenue recovery > Emails. Confirm what's enabled in your own account. Stripe retries, customer emails.
Stripe's no-code portal guide has an Activate link action. It's on the customer portal configuration page. The portal has payment-method and cancellation settings. Check the right customer record and the actual journey, since a listed option doesn't prove your flow works. Portal activation, portal settings.
WooCommerce Subscriptions
Open WooCommerce > Settings > Subscriptions. Find Payment recovery and the automatic retry checkbox. Check pending retries under Edit Subscription > Schedule. For a failed renewal order, find Automatic Failed Payment Retries on Edit Order. WooCommerce retry guide.
Check your installed version and gateway before using this path, which needs automatic recurring payments. The gateway can't control the billing schedule itself. The guide excludes SEPA payments from this retry system.
Another billing product
Ask support: "Where's this invoice's next attempt? Who schedules it? Which customer link changes the payment method?"
Get the answer for your product and version, since another app doesn't inherit Stripe's or WooCommerce's menus.
Is the saved card being updated?
Ask: "Did an update arrive? Is this subscription using it?"
Stripe attempts automatic updates when networks supply replacement details. Issuer participation matters, support varies by country, and Stripe can't identify supported cards in advance. An updater isn't a coverage guarantee. Stripe automatic card updates.
The subscription's default payment method takes priority over the customer's default in Stripe's retry order. If the new card isn't being used, ask your developer to trace which field changed. Stripe retry guide.
What should the failed-payment email say?
Confirm the failed invoice and the customer's address first. Stripe separates failed-card emails from unpaid recurring-invoice reminders for send_invoice. Check which one you're setting up. Stripe customer emails.
Here's a first message you can adapt:
Your [product] payment didn't go through. Update your payment method at [secure link]. Want to cancel instead? Use [manage subscription link].
Fill those links from the customer's account, then test the sender, branding and destination before sending. If you've named an access change, check that its date matches what you've actually configured.
For Stripe sandbox email tests, use a confirmed active team member's address with sandbox access. Connected-account tests have their own documented recipient option, so follow the current email test instructions.
What happens after recovery ends?
Write down the final state before recovery starts. Stripe documents canceled, unpaid, past-due and eligible paused outcomes, with the available path depending on your settings and eligibility. Stripe retry guide.
Keep invoice state, subscription state and access separate. Stripe's provisioning example pairs invoice.paid with an active subscription, which doesn't verify your app's access handling. Stripe subscription webhooks.
Ask your developer: "What can the customer still use? What stops the recovery messages? What happens if payment arrives later?"
Test cancellation during recovery and a later payment, then check an older event arriving afterward. Confirm it hasn't restored access against your recorded policy.
Still an unpaid balance? Use Failed Payment Collection before choosing a collection step.
They forgot to cancel and disputed. What now?
Open the case and save its reason and deadline, matching the notice to the invoice and cancellation request. In Stripe, the dispute details identify the claim you're answering. Stripe dispute response guide.
Check the refund state before another money action. Was it requested, submitted, completed or blocked? Use the case-state guide before sending money.
"They forgot" is an explanation to record. It isn't your substitute for the notice's claim. If they say they cancelled, find the request and save its date, confirmation and billing timeline.
Keep enrollment terms, customer messages and payment history together, matching any usage evidence to the actual claim. Stripe separates evidence by dispute category. Used visits alone aren't a decision to contest. This checklist doesn't choose accept or contest. Stripe dispute categories.
Already lost? Use After a Lost Dispute. For a cancellation-law question, use Recurring Billing Requirements.
A gym, salon membership or meal plan
Start with the member's record and accepted plan, checking what they've asked you to change. Is the renewal unpaid, the membership frozen, or a visit missing?
They asked to pause or freeze. Find the request and effective dates, then check the next charge and their remaining visits or meals. Write down whether billing, access and credits should stop, then check each record against that decision.
Ask your membership provider: "Does this freeze stop billing, access or both? What happens to unused credits? When does the next charge run?"
You're checking your own plan and provider here. Keep cancellation duties with Recurring Billing Requirements. A recovery pause isn't your answer to a member's cancellation request.
The card failed at the front desk. Find the attempted payment before trying again. Is it a renewal or today's separate purchase? For a renewal, check its invoice. For a counter sale, use the counter-payment guide. Check the membership record before changing entry or visit credits.
They disputed after using visits. Save the accepted plan, visit dates and cancellation record, matching those records to the disputed period and claim. Then open the dispute path. You're assembling evidence, not assuming those visits decide the case.
No-show fee, booking deposit or part-used appointment package? Start with Appointment Fees.
How do I measure recovery without counting attempts as customers?
Use one row per failed invoice, with the observation window chosen before you compare results. Keep original amounts and currencies beside the outcomes, counting invoices, customers and executed attempts separately.
Record the invoice ID, executed charge IDs and recovery source, then add the customer's request, subscription state and actual access. Include support time and any tool costs.
Count each paid invoice once within your chosen window. Keep open, cancelled, disputed and final unpaid outcomes separate. Record cancellation requests even when money later arrives. This worksheet is a method you can use. It isn't a promised recovery rate.
Compare tools after you've defined that cohort and its costs. Keep cohort size beside any claimed uplift, with unresolved invoices visible when you report the result.
Recovery by setup
| Setup | Start with |
|---|---|
| You're running this yourself | Check native settings, test the customer link and record the final state |
| You've got a support team | Name a recovery owner and use one shared queue |
| You've got custom code or several billing products | Ask your developer to trace payment, messages and access together |
For a meal plan or subscription box, check fulfilment separately and record which unpaid orders should stop before release.
Where recovery breaks
Use these as checks in your own setup:
- Two schedulers try the same renewal
- A new card lands at the wrong default
- The customer link opens the wrong record
- Messages continue after a cancellation
- A later event restores access against your policy
- Payment needs customer authentication
- The gateway owns its own billing schedule
- A freeze leaves billing or visit credits running
Test your recovery flow
Use an authorized isolated test account. Keep real subscribers out of the test. In WooCommerce, Test Mode can make real renewals fail. Staging also disables renewals and emails by default. Follow the product's retry test guide.
Create a failed renewal and follow your chosen path, then receive the test message and check both links. Then check the ending invoice, subscription and access state.
Add a card update and an authentication case, plus an ineligible retry and cancellation during recovery. Include a later payment and an older event. For memberships, add a freeze and a used-visit dispute.
Pass when the records match your written policy, saving redacted results for each case you've checked. Leave any unresolved behavior visible before you launch.
If you bill on a recurring basis, you're bound by network rules for consent, notification and cancellation. See Recurring Billing Rules and Failed Payment Collection.
- Worked example: assume billing success is measured by dollars collected. Moving from 90% to 95% on $100K billed monthly means $5K more collected before recovery costs, refunds and disputes. That's arithmetic, not a promised dunning result
- Account Updater (Visa and Mastercard card-on-file update service) can update expired and replaced cards when participating issuers supply replacement details. Turn it on before you build retry logic you don't need
- MIT (Merchant-Initiated Transaction) flagging on retries improves approval rates and is required by network rules for subsequent recurring charges after the initial CIT
- Send pre-charge notifications 3-5 days before billing. Customers who know it's coming dispute less, and they cancel through you instead of their bank
Subscription payments fail differently than one-time payments. In the dollar-based worked example above, the move from 90% to 95% is five percentage points, or $5K more collected on $100K billed monthly. Measure your own failed invoices and recovery costs.
Most subscription businesses accept their decline rate as fixed. It isn't.
What Matters
- Card-on-file consent is non-negotiable. Save the consent record and match it to the dispute's claim. See compelling evidence.
- Check account updater (CAU) coverage. Confirm that updates arrive and are applied before billing. Compare expired-card failures on matched cohorts before and after. See increase auth rates playbook.
- Dunning sequence design separates amateurs from pros. When you retry, how you communicate, and when you stop all affect recovery.
- Hard vs. soft decline logic. Retry the wrong decline code and you burn issuer goodwill.
- Keep cancellation records together. If a customer says they cancelled, the request, effective date, confirmation and billing history are what you'll answer with. See compelling evidence.
Card-on-File Requirements
Storing cards for future billing requires explicit consent. This isn't optional.
What Consent Must Include
- Clear disclosure that you're storing the card
- Explanation of what you'll charge and when
- Cancellation terms
- Customer acknowledgment (checkbox, signature, click-through)
What to Save
| Data Point | Why |
|---|---|
| Consent timestamp | Proves when they agreed |
| IP address | Links consent to a device |
| Consent language version | Shows what they agreed to |
| Transaction ID of first charge | Ties consent to billing relationship |
Issuer View
When we see a dispute on a recurring charge, the first thing we check is whether the merchant can prove consent. A timestamped signup flow with clear billing terms usually wins. A vague "I think they signed up" loses.
Card Account Updater (CAU)
CAU can update stored cards when participating issuers supply replacement details. Visa calls theirs VAU (Visa Account Updater). Mastercard calls theirs ABU (Automatic Billing Updater).
What CAU Fixes
- Expired cards
- Reissued cards (new number, same account)
- Changed expiration dates
What CAU Does Not Fix
- Closed accounts
- Fraud blocks
- Customer-initiated cancellations
- Cards the customer doesn't want you to charge
When to Enable
If you bill recurring, check CAU availability, coverage and fees. Compare the result on your own eligible cards before calling it a saving.
How to Check If You Have It
"Is Card Account Updater enabled on our merchant account? Are we receiving and applying updates before billing?"
Most processors support CAU, but it may not be enabled by default. Some charge per update (typically $0.25-$0.50 per hit). Others include it.
Measuring CAU Lift
Compare involuntary churn before and after enabling:
- Pull 3 months of data before CAU
- Enable CAU
- Pull 3 months after
- Compare expired-card failure rates on the same card, customer and billing mix; keep cohort sizes beside the rates
Check updates received and applied, recovered invoices and fees. A before-and-after change alone doesn't establish that CAU caused it; record other billing changes too.
Dunning Sequences
Dunning is what happens after a payment fails. Your sequence determines how much revenue you recover.
Anatomy of a Dunning Sequence
| Step | Timing | Action |
|---|---|---|
| 1 | On failure | Check the decline and configured retry policy before another attempt |
| 2 | Day 1 | Email: "Payment failed, update card" |
| 3 | Day 3 | Retry payment |
| 4 | Day 3 | Email: "Still having trouble" |
| 5 | Day 7 | Retry payment |
| 6 | Day 7 | Email: "Service at risk" |
| 7 | Day 14 | Final retry |
| 8 | Day 14 | Email: "Last chance before cancellation" |
| 9 | Day 21 | Cancel or pause |
Retry Timing That Works
Don't retry immediately after failure. Wait.
- Soft decline (insufficient funds): Retry in 3-5 days. Paydays matter.
- Issuer unavailable: Retry in 4-24 hours.
- Card expired without CAU update: Don't retry. Email for new card.
Email Timing That Works
- Day 1: Factual. "Your payment failed. Here's how to update."
- Day 3-7: Helpful. "Want to keep access? Update here."
- Day 14+: Urgent but not aggressive. "We'll pause your account in 3 days."
What Kills Recovery
- Too many emails (3-4 total is enough)
- Aggressive tone ("PAY NOW OR ELSE")
- No clear update link
- Retrying hard declines repeatedly
Hard vs. Soft Decline Logic
Not all declines are equal. Retry logic should match decline type.
Soft Declines: Retry-Eligible
| Code | Meaning | Retry Strategy |
|---|---|---|
| Insufficient funds | Account low | Retry in 3-5 days (around payday) |
| Issuer unavailable | Technical issue | Retry in 4-24 hours |
| Card not activated | New card | Retry in 1-2 days |
| Exceeds limit | Over spending limit | Retry in a few days |
Hard Declines: Do Not Retry
| Code | Meaning | Action |
|---|---|---|
| Card stolen/lost | Fraud flag | Stop. Request new card. |
| Invalid card number | Card doesn't exist | Stop. Request new card. |
| Card expired | The updater may not have covered it | Request updated card details. |
| Do not honor | Issuer says no | Try once more, then stop. |
| Restricted card | Blocked category | Stop. Different card needed. |
Why This Matters
Issuers track retry behavior. Hammer declined cards and you'll get worse auth rates on everything, not just the retries. That's a reputation you can't easily undo.
"What's our retry logic for soft declines vs. hard declines? Are we distinguishing between them?"
The Dunning End Game
When do you stop trying?
When to Stop Retrying
| Model | Stop After |
|---|---|
| SaaS / digital service | 14-21 days of failure |
| Physical subscription (box) | 7-14 days (you have fulfillment costs) |
| High-ticket service | 30 days (worth the chase) |
Cancel vs. Pause
| Action | When to Use |
|---|---|
| Cancel | Low LTV customers, free trial churners, abuse patterns |
| Pause (unpaid hold) | High LTV customers, long tenure, seasonal businesses |
Pausing preserves the relationship. Cancelling ends it. Choose based on customer value.
Grace Period Strategy
- Free trials: No grace. Card fails = trial ends.
- Paid subscriptions: 7-14 day grace is standard.
- Enterprise/annual: 30+ days. These are worth saving.
After the Last Retry Fails
"What happens after our last retry fails? Does the subscription cancel, pause, or just sit there?"
"Sits there" is the wrong answer. Define the end state.
Stop Using $0/$1 Auth to Save Cards
If you're still using $0 or $1 authorizations to validate cards before saving them, stop.
The Old Pattern
- Customer enters card
- Authorize $0 or $1 to "validate"
- Void the auth
- Save the card for future billing
Why This Fails
- Higher decline rates. Issuers are suspicious of $0/$1 auth patterns.
- Customer confusion. "Why is there a $1 charge?"
- Worse issuer acceptance. You look like a card tester.
The Modern Approach
Use SetupIntent-style flows (Stripe calls it SetupIntent, others have equivalents).
- Validates the card without a charge
- Designed for card-on-file use cases
- Better issuer acceptance
- No customer-facing charge
"Are we still using $0/$1 auth to save cards? Can we switch to SetupIntent or equivalent?"
Subscription Fraud Typologies
Recurring billing attracts specific fraud patterns.
Trial Abuse
Pattern: Sign up for free trial, cancel before charge, repeat with new email/card.
Signals:
- Device fingerprint matches previous trial user
- Disposable email domain
- Card BIN cycling (same first 6 digits, different cards)
- VPN or proxy use
Response:
- Limit trials to one per device fingerprint
- Block disposable email domains
- Require payment method at trial start (not $0 auth, use SetupIntent)
Promo Stacking
Pattern: Abuse referral codes, coupons, or first-month discounts.
Signals:
- Same billing address, different names
- Referrer and referee from same IP
- Multiple accounts created rapidly
Response:
- Limit referral rewards per payment method
- Velocity checks on promo code use
- Link detection across accounts
Credential Sharing/Reselling
Pattern: One paid account shared among many users, or resold access.
Signals:
- Logins from many IPs/locations simultaneously
- Usage patterns that don't match single-user behavior
- Account credentials appearing on resale sites
Response:
- Concurrent session limits
- Device registration caps
- Usage-based lockouts
Related: Fraud Prevention
Subscription Dispute Patterns
Recurring billing has unique dispute characteristics.
Common Dispute Reasons
| Reason | Cause | Prevention |
|---|---|---|
| "I cancelled" | They didn't, or you didn't process it | Clear cancellation flow, confirmation emails |
| "I didn't authorize this" | They forgot, or genuine fraud | Pre-renewal reminders, clear descriptors |
| "I didn't recognize the charge" | Bad descriptor | Include brand name in descriptor |
| "I was charged after cancelling" | Billing/cancellation timing mismatch | Stop billing immediately on cancel |
Cancellation Proof Basics
When a customer disputes saying they cancelled, you need:
- Cancellation policy they agreed to at signup
- Usage logs showing activity after alleged cancellation
- Communication history (did they contact support?)
- Account status timeline (when did they actually cancel?)
Answer that claim with your cancellation records. Without them, there's little to send.
Pre-Renewal Reminders
For annual subscriptions, send a reminder 7-14 days before renewal:
"Your subscription renews on [date] for [amount]. If you want to cancel, [click here]."
This feels scary but reduces disputes. A customer who cancels is better than a customer who disputes.
Involuntary vs. Voluntary Churn
Churn has two causes. Fix the right one.
Involuntary Churn (Payment Failure)
- Card expired
- Insufficient funds
- Card replaced
- Issuer decline
Fix with: CAU, dunning optimization, retry logic, payment method diversity.
Voluntary Churn (Customer Choice)
- Didn't need the product
- Found alternative
- Price objection
- Bad experience
Fix with: Product, pricing, onboarding, support. Not payments.
Measuring the Split
Track churn by cause:
- What percentage of churned customers had a failed payment as their last event?
- What percentage voluntarily cancelled with a working card?
Compare payment-related churn with your own prior cohorts. Check decline reasons, customer requests and recovery outcomes before deciding which part of the payment flow to change.
Test to Run
4-week CAU and dunning audit:
Week 1: Baseline your current metrics.
- Involuntary churn rate
- Retry success rate by attempt number
- CAU hit rate (if enabled)
Week 2-3: Implement changes.
- Enable CAU if not active
- Adjust retry timing based on decline codes
- Update dunning emails
Week 4: Measure.
- Compare involuntary churn to baseline
- Track recovery rate by dunning step
Success criteria: Recovery and involuntary churn improve on the same billing and customer mix after fees and support costs. Use a fixed observation window and keep unresolved invoices visible. Extend the test if a monthly cycle or thin sample makes 30 days inconclusive.
Scale Callout
| Volume | Focus |
|---|---|
| Under $100k MRR | Enable CAU, set up basic dunning (3-4 emails), don't overthink it. |
| $100k-$1M MRR | Optimize retry timing by decline code, A/B test dunning emails, track recovery by step. |
| Over $1M MRR | Dedicated retention ops, predictive churn models, custom dunning by customer segment and LTV. |
Where This Breaks
-
Prepaid cards. No CAU. Can't retry. Just fails. Consider requiring non-prepaid for subscriptions.
-
Corporate cards with frequent reissuance. B2B subscriptions on company cards churn hard. Get backup payment methods or invoice them.
-
Customers who want to cancel but dispute instead. If disputing is easier than cancelling, that's what they'll do. Make cancelling brain-dead simple.
Analyst Layer: Metrics to Track
| Metric | What It Tells You | Target |
|---|---|---|
| Involuntary churn rate | Payment-driven churn | Compare the same billing and customer mix over a fixed window |
| Retry success rate | Dunning effectiveness | Track recovered invoices and amounts by eligible decline type |
| CAU hit rate | Updater coverage | Track updates received and applied; check eligibility with your processor |
| Dunning email open rate | Message effectiveness | Compare the same audience; check payment completion too |
| Recovery by attempt | Optimal retry count | Track actual recovery and costs at each attempt |
| Churn by decline code | Where to focus | Track the mix and reason for each failure |
Recurring Churn Analytics Framework
Track these dimensions to understand where you're losing subscribers:
| Dimension | Metrics to Track | Why It Matters |
|---|---|---|
| Churn type | Voluntary vs involuntary | Different fixes for each |
| Churn timing | Days since signup when churn occurs | Identifies risk periods |
| Decline reason | Distribution of decline codes | Tells you what's fixable |
| Recovery rate | % recovered by dunning step | Shows where dunning works |
| LTV at churn | Revenue lost per churned sub | Prioritizes retention effort |
Monthly churn decomposition:
Total churn = Voluntary + Involuntary
Involuntary = Declined + Expired + Blocked + Other
Declined = Hard decline (unfixable) + Soft decline (retry-able)
Key ratios, compared on the same cohort and window:
- Involuntary / Total churn
- Soft decline / Total declined
- Recovered / Soft declined
CAU Lift Measurement
Quantify your Card Account Updater ROI:
| Metric | How to Calculate | What to check |
|---|---|---|
| CAU coverage | Subscribers with updatable cards / Total subscribers | Confirm supported cards with your processor; don't assume eligibility |
| Update rate | CAU updates received / Billing attempts | Track received and applied updates separately |
| Prevented churn | Estimate the difference in matched cohorts' expired-card failures | Record other billing changes and unresolved invoices |
| CAU ROI | Estimated extra contribution from recovery - updater and implementation costs | Use your observed results and costs; don't assume an update prevented churn |
Before/after analysis:
- Baseline 3 months of expired card failures before CAU
- Enable CAU for 3 months
- Compare expired card failure rate
- Calculate LTV of saved subscribers
Measured result: Compare expired-card failures, recovered invoices and costs on matched cohorts. Record the observation window and other billing changes. An update by itself doesn't prove that a payment or subscriber would have been lost.
Cohort Analysis
Track cohorts by:
- Signup month
- Payment method type
- Pricing tier
Identify which cohorts have highest involuntary churn and fix those first.
Next Steps
Just starting with subscriptions?
- Audit your consent capture → Do you have documented proof of recurring authorization?
- Check Card Account Updater (CAU) → Confirm coverage and fees, then measure billing results
- Set up basic dunning → Email on first failure, retry in 3 days
Improving billing success?
- Segment declines by type → Soft vs. hard, expired vs. insufficient funds
- Optimize retry timing → Match to payday cycles for B2C
- Review auth optimization → Decline patterns affect recurring
Fighting subscription chargebacks?
- Check compliance requirements → Network rules for recurring
- Improve cancellation flow → Easy cancellation = fewer disputes
- Pre-billing notifications → Remind before charging, not after
Related Pages
- Compliance: Subscription Rules - Network requirements
- Failed Payment Collection - When to stop collecting, charge-off decisions
- Payment Tokenization - Network tokens for higher auth rates
- Chargeback Prevention - Dispute reduction
- Refund Strategy - When to refund
- Fraud Prevention - Fraud patterns
- Descriptors and Communication - Billing clarity
- Buying Payments - Token portability
- Auth Optimization - Decline patterns
- Increase Auth Rates - Retry optimization
- Decline Codes - Soft vs. hard declines
- Compelling Evidence - Proving consent
- Promo Abuse - Trial abuse patterns
- Device Fingerprinting - Multi-account detection
Sources
| Source | Supports | Opened |
|---|---|---|
| Stripe retries | VENDOR Retry settings, scheduled versus executed attempts, payment-method priority and recovery end states in Your renewal failed, Set up recovery and What happens after recovery ends | 21 October 2026 |
| Stripe customer emails | VENDOR Failed-card emails, separate send_invoice reminders, customer links and sandbox recipient instructions | 21 October 2026 |
| Stripe portal activation | VENDOR Activate link and customer-record checks in Set up recovery | 21 October 2026 |
| Stripe portal settings | VENDOR Configurable payment-method updates and cancellation options | 21 October 2026 |
| Stripe automatic card updates | VENDOR Update attempts, issuer participation and coverage limits in Is the saved card being updated | 21 October 2026 |
| Stripe subscription webhooks | VENDOR Separate invoice/subscription state and the paid-invoice/active-subscription provisioning example | 21 October 2026 |
| WooCommerce retry guide | VENDOR WooCommerce Subscriptions paths and gateway eligibility in Set up recovery | 21 October 2026 |
| WooCommerce retry test guide | VENDOR Test Mode and staging constraints in Test to Run (subscription-recovery-test) | 21 October 2026 |
| Stripe dispute response guide | VENDOR Case reason, notice and deadline in They forgot to cancel and disputed | 21 October 2026 |
| Stripe dispute categories | VENDOR Claim-specific evidence in the renewal and membership dispute branches | 21 October 2026 |