1. Separate the schedule from execution
A retry counter can look like evidence that a customer was charged again. Stripe documents a narrower meaning after a hard decline: retries remain scheduled and attempt_count continues to increase, but execution requires detection of a new payment method. Unexecuted retries do not create a new Charge.[1]
Editorial recommendation: treat scheduling, execution, and successful collection as separate observations. A future timestamp describes a plan; a higher counter alone does not establish a new charge. Customer-facing messages should describe the evidence available, rather than translating every retry update into another attempted debit.
2. Identify the hard-decline gate
The documented hard-decline list includes incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level, and transaction_not_allowed. Stripe says these failures prevent automatic retry execution until a new payment method is obtained.[1]
Editorial recommendation: capture the exact decline code and assign a replacement-method follow-up instead of merely shortening the retry interval. Do not describe a method update as payment success. The documentation states an execution prerequisite, not a promise that the replacement will be accepted. Keep the invoice unresolved until payment evidence supports a different conclusion.
3. Correct the field that actually takes priority
Stripe selects the first available method in this order: subscription.default_payment_method; subscription.default_source; the customer default payment method; and the legacy customer.default_source. For Customer objects, the third entry is customer.invoice_settings.default_payment_method; for customer-configured Account objects, it is configuration.customer.billing.default_payment_method.[1]
Stripe explicitly warns that updating only customer.invoice_settings.default_payment_method leaves a populated subscription.default_payment_method in control. Its instruction is to update the field where the previous payment failed.[1]
Editorial recommendation: record the selected level before editing anything. Inspect higher-priority fields rather than assuming a newly saved customer default will take precedence. A successful field update and a corrected retry target are different acceptance conditions.
4. Fictional drill: the new card is in the wrong place
This is a fictional, offline operational drill, not an observed customer incident. A subscription points to method A. An invoice fails with lost_card. Support records replacement B only as the customer invoice default. A later fixture increases attempt_count, while showing no additional Charge. The agent initially labels the case 'retried with the new card.'
That label conflicts with both documented rules: a hard-decline schedule can advance without execution, and the subscription default still outranks the customer default.[1] Editorial recommendation: correct the case note, identify the subscription-level field as the repair target, and model its change to B in the fixture. Do not run a live charge or claim that this simulated repair collected money.
5. Use a field-and-evidence checklist
Editorial checklist: identify the invoice, subscription, and customer or customer-configured account; preserve the failure code; inspect the four precedence levels; record the old selected method and intended replacement; update the applicable field through an approved workflow; then verify the resulting selection. Keep these identifiers in access-controlled operational records rather than public case notes.
For monitoring, Stripe describes invoice.payment_failed as carrying failure and retry-attempt updates. With automations, next_payment_attempt is set in invoice.updated rather than invoice.payment_failed.[1] Editorial recommendation: record the event type alongside the timestamp, and distinguish a missing field in one event from a verified absence of any future schedule.
6. Keep the operational boundaries explicit
Stripe also lists unavailable payment methods, India-issued cards, and disconnected Connect accounts as reasons it does not retry payments. Local payment methods have separate retry settings and are not automatically retried by default.[1]
Editorial recommendation: route those cases for their own checks instead of treating every failure as a default-method mismatch. This article does not establish processor-independent rules, prescribe legal authorization, or claim PayIn implements Stripe's retry machinery. Use offline fixtures for this exercise; a production correction needs its own authorized workflow and observed result. Neither a revised schedule nor a replacement method guarantees recovery.
7. Accept the repair only on matching evidence
Editorial acceptance criteria: the drill must show an increasing counter without inventing a Charge; a customer-only update must leave the subscription method selected; correcting the subscription field must change the modeled selection. A separate automations fixture must read scheduling information from invoice.updated. Mark collection as unverified unless actual payment evidence exists; this offline exercise produces none.
Sources and dates
Official Stripe documentation in English. No publication or update date is stated; retrieved and checked on 2026-09-21. The retrieval date is not a source publication date. This is editorial research, not a PayIn feature claim, account eligibility check, or legal advice.
- [1] Automate payment retries · Checked 2026-09-21; source date not stated.