Using Machine Learning to Reduce Payment Failures on Subscription Platforms

Where machine learning can help#

Machine learning helps most when recurring-payment failures are probabilistic, not deterministic. If a charge might succeed later because timing, issuer behavior, or customer segment matters, model-driven retry timing can improve recovery. If the failure is deterministic, such as an invalid API call, a blocked payment, or a hard decline that cannot be fixed right away, rules and process fixes usually do more good.

For a subscription business, the useful question is whether a different retry time brings more failed renewals to payment. A higher success rate per attempt can still hide more retries, higher fees, or duplicate collections. Judge the model against an eligible renewal cohort and a defined recovery window.

Keep two decisions separate: whether another collection attempt is allowed, and when an allowed attempt should run. Payment rules and the collection executor decide eligibility. A model recommends timing within those limits.

Classify the failure before choosing a retry time#

The provider’s actual response matters more than a model’s predicted probability. Stripe’s decline-code guidance, for example, distinguishes authentication, duplicate transactions, and stop conditions. Translate supported codes into explicit actions rather than treating every non-success response as insufficient funds.

Use provider recovery before building a custom scheduler#

If one provider owns your recurring invoices, evaluate its recovery tooling first. Stripe Smart Retries uses changing signals to select retry times, but some failures cannot be retried without a new payment method. Its documented attempt_count can increase for scheduled hard-decline retries that do not create a charge. Count actual executions separately from the schedule.

Choose one owner for collection: provider recovery or your custom executor. Enabling both against the same invoice can create competing attempts. Build a custom timing model only when you have a concrete requirement, such as a supported policy that the provider cannot express, and enough reliable outcome data to evaluate it.

A provider outage is not permission to send an unresolved charge to another gateway. Provider keys do not deduplicate requests across providers. A different route requires a separate, authorized decision after the earlier attempt’s outcome is known.

Prepare evidence that describes real attempts#

Link each actual collection attempt to its invoice, customer, provider account, request identity, amount, currency, and timestamps. Preserve the provider’s response, payment reference, and later events. Keep scheduled retry records separate so the training data does not invent declines for attempts that never ran.

Do not use the eventual successful payment, later customer updates, or a future refund as features for an earlier decision. Those outcomes leak the answer into training. Avoid collecting raw card numbers or security codes for the model; use only the limited, permitted information needed for the task.

Define labels before training#

One practical label is whether an eligible failed renewal becomes paid within 30 days of its first confirmed failure. Treat that as a proposed evaluation window, not a universal billing rule. Decide in advance how cancellations, customer-initiated payments, partial payments, and refunds affect the label.

An unresolved attempt is not a failed payment. An invoice with no observed follow-up is not automatically proof that a retry would fail. Mark incomplete observation windows and unresolved outcomes explicitly. Otherwise the model learns from missing information as if it were a customer decision.

Historical timing was selected by the old policy. Customers retried early may differ from those retried later, so a correlation between retry time and success does not establish the best time to retry. Split evaluation chronologically and keep a customer’s related renewals together where possible. Check calibration and performance across meaningful cohorts before making a timing recommendation.

Make the executor safe independently of the model#

Store a durable obligation record for the invoice and use an atomic claim to select the worker allowed to collect it. Persist the attempt identity and provider idempotency key before the external call. A second worker, a customer payment, and a recovery webhook must all consult the same collection state.

A worker lease expiring proves only that the worker stopped reporting. It does not prove that the provider failed to execute. Move uncertain attempts into reconciliation, using the original provider reference or a supported replay of the same request within that provider’s documented scope. Do not manufacture a new key to escape uncertainty.

Stripe’s low-level error guidance treats some server errors as indeterminate. Its idempotency documentation also defines parameter matching and a finite key-retention policy. Record these limits in the executor: an expired key is not evidence that an earlier charge never happened.

Resolve the attempt through supported status lookup, verified provider events, or reconciliation. Create a new business attempt only after confirmed non-execution or a known refusal permits it under the applicable policy. An authorization or pending charge blocks duplicate collection before bank settlement; later capture, refund, or dispute events remain part of that original payment’s lifecycle.

For webhook delivery, verify the signature over the original request body and durably record the event before acknowledging it. Process duplicates safely and tolerate events arriving out of order. Commit the local processed marker, state change, and any queued follow-up together; an outbox can coordinate these local effects, but it cannot make the provider call part of your database transaction. See the provider’s webhook guidance and the transactional outbox pattern.

Measure incremental recovery, not a flattering retry rate#

Suppose 1,000 eligible failed renewals enter a hypothetical test. Assign customers consistently to two groups of 500 and observe both for the same 30-day window. The fixed-policy group pays 200 invoices; the model group pays 250. Recovery is 40% versus 50%: a 10-percentage-point difference, or 25% relative improvement.

That is 50 additional paid invoices in the model group. If each invoice is $40, the difference is $2,000 in gross collections for that group. Deduct incremental processing fees, operating costs, refunds, and disputes before describing an economic benefit. Gross collections are not automatically recognized revenue, and this invented example is not a forecast.

Keep assignment stable across a customer’s renewals and record the policy actually used. Analyze the assigned groups, including cases where no retry occurred, rather than selecting only successful model actions. Mature loss outcomes need a longer observation window than immediate authorizations.

Roll out without changing the collection boundary#

Start in shadow mode: the model records recommendations while the existing authorized policy continues to collect. Check eligibility disagreements, feature availability, and proposed timings. Shadow mode must not send a second charge.

Then run a bounded randomized trial with explicit stopping criteria for duplicate collection, complaint increases, and recovery performance. If the model is unavailable or its inputs are incomplete, fall back to an approved static schedule only for eligible attempts. Unresolved payments remain in reconciliation. Monitor changes in provider codes, billing policies, and customer mix before expanding.

Give the billing owner authority over eligibility and customer treatment, the engineering owner authority over execution and incident response, and the analyst responsibility for labels and experiment reporting. A model that predicts well but cannot be measured safely is not ready to collect.

Sources#

• Stripe Smart Retries
• Stripe decline codes
• Stripe low-level errors
• Stripe idempotent requests
• Stripe webhooks
• AWS transactional outbox