Stripe subscription retries: check the payment method on the failed subscription

Find the card attached to the failing subscription

If a subscriber updates a card but the next retry still fails, check which payment method the subscription is actually using. Updating the customer’s general default does not necessarily replace a payment method set directly on that subscription.

Stripe is a payments and subscription-billing provider. A customer record can hold default billing details, while an individual subscription can have its own payment method. Stripe’s retry documentation gives subscription-level settings priority over customer-level defaults. That is why a correct-looking customer screen can coexist with retries against an old card. (Stripe Smart Retries documentation ↗)

Example: the customer sees a new card, the subscription uses the old one

A member adds Card B to the customer record after Card A fails. The subscription still has its own default set to Card A. Stripe’s priority order selects that subscription-level default first, so the next attempt can still use the old card.

Resolve the failed invoice after checking the subscription’s card

Give support the failed invoice and subscription identifiers, not full card details. Ask which field in the priority table actually supplies the attempted payment method. Correct the intended subscription’s configuration rather than assuming a customer-wide change reaches every subscription.

Check the decline and whether another attempt is possible. A scheduled retry is not a collected payment; confirm the invoice outcome before recording recovered revenue. Then test the member’s access so a paid reader is not left locked out.

Keep failed-payment recovery separate from voluntary cancellation. Someone trying to repair a card needs a recovery path; someone who chose to cancel needs that choice honored.

Follow one invoice from failure to access

Select a failed invoice on a test account and write down its subscription, payment method, and current status. After updating the payment method, verify which method the next attempt will use and whether the invoice actually settles. Then check access independently on the publisher’s site. Payment recovery and restoring access are distinct operations and can fail at different points.

For a real support case, preserve the timestamps of the failure, update, retry and settlement. This gives support an answer if a reader asks why they still cannot log in after changing cards. If the invoice remains open, do not report recovery just because the next attempt was scheduled. If the invoice has settled but the article is still blocked, hand the case to whoever owns the membership integration and include the exact article and access expectation. Avoid repeating payment attempts until the invoice state is understood.

Separate the recovery rate from the reader outcome

Imagine 100 renewal invoices initially fail and 40 settle within seven days. The seven-day recovery rate is 40% for that starting group. If five of the recovered subscribers still cannot access the site, you have 40 settled invoices and 35 confirmed restored reader experiences. Those counts tell different teams what to fix. Neither count should be estimated from the number of retries alone.

When comparing changes to a recovery sequence, give both groups the same number of days after the first failed charge. A longer observation period can make the newer sequence look stronger simply because it had more time. Keep the invoice and entitlement evidence tied together so support can explain exceptions without restarting billing.

Break out manual recoveries as well if support handled them outside the automated sequence.

Compare payment recovery without losing the readers behind the invoices

Imagine two groups with 100 failed invoices each and the same seven-day follow-up. Sequence A settles 45 invoices. Sequence B settles 50. On billing results alone, B wins by five percentage points. Now suppose access is confirmed for 44 subscribers in A and 42 in B. B collected more invoices, yet fewer of its readers can be confirmed back inside the product. These are illustrative counts, with one invoice per subscriber.

Reconcile each case across three events: failed payment, paid invoice, and confirmed access. Keep a separate row for subscribers whose access was not checked. If all eight unsettled access outcomes in B are unknown, you cannot conclude that eight people were locked out. If logs and a test establish that the subscription settled while the account still failed the permission check, that is an access defect with a specific owner.

Money recovered also depends on the value of the invoices. If A collects 45 invoices at $10 and B collects 50 at $8, A brings in $450 and B brings in $400 before fees or refunds. If your test groups differ in plan mix, show the amounts and recovery rates by plan before crediting the sequence. A higher count can reflect more low-priced plans rather than a better outcome for the business.

Use the comparison to decide what to investigate next. A gap between failed and paid points toward payment method or recovery work. A gap between paid and confirmed access points toward synchronization or permissions. Give support the invoice and account state, with their timestamps, so the customer does not have to repeat the payment step to get the article they already paid for.