The next payment attempt has its own P&L

The next payment attempt is a small investment decision. Its return is not “recovered revenue.” It is the probability that this attempt produces a valid, retained payment, multiplied by the contribution that payment creates, minus the attempt’s incremental fees, fraud loss, service work and risk of losing the customer.

That frame changes the retry question from “How many times should we try?” to “Is this particular attempt worth making now?” Prior attempts are sunk. A retry policy should send the next request only when its expected contribution is positive—and when the payment rules and the customer’s consent permit it.

Price the attempt at the margin

A compact decision rule is:

EV(next attempt) = p(good collection) × contribution if collected − rail cost − expected fraud loss − expected service cost − expected customer loss

“Good collection” matters. An authorization is not necessarily durable revenue: a cardholder can dispute a transaction, and a successful chargeback reverses the payment from the merchant’s account.6 The value term should therefore use the probability of a payment that settles and remains valid, not a dashboard’s authorization rate.

Contribution is also not the face value of the payment. For a physical order that has not shipped, it may be revenue less fulfilment and variable product cost. For an already delivered service, the marginal contribution of collection may be much closer to the amount owed. For a subscription, retaining access may create future margin—but only if the customer would otherwise leave and the retry does not itself push them away. The model must match the business event.

Everything already spent belongs outside this decision. The first attempt’s fee, last week’s support conversation and the original acquisition cost cannot make the next attempt better. They explain the account’s history; they do not alter the next attempt’s marginal return.

The decline changes the probability

The approval probability does not live at “merchant average.” It is conditional on the issuer response, attempt number, elapsed time, credential state, authentication state, amount, route and whether the customer has intervened.

Public network guidance makes the point sharply. Visa classifies response code 14 as “Issuer Will Never Approve” and says merchants must not reattempt it; for its Category 2 and Category 4 responses, Visa permits up to 15 retries in 30 days.1 A processor can expose the same distinction as advice: Stripe documents do_not_try_again, try_again_later and confirm_card_data, each requiring a different next action.2 Mastercard’s June 2025 rules say issuers should provide a Merchant Advice Code when declining a recurring payment and that acquirers and merchants should be able to act on it.3

Those are constraints and signals, not forecasts. Fifteen permitted retries do not imply that retry fifteen has positive value. Conversely, a generic decline is not evidence that every future attempt is worthless; many issuer declines arrive without a specific reason.2

Attempt number still carries information. If the same credential, amount, route and context have failed repeatedly, another unchanged request has less reason to produce a different outcome. A policy should estimate p(good collection) for the exact state before the next attempt, not inherit the success rate of first attempts or of the whole recovery sequence.

One retry creates four cost ledgers

The first ledger is the rail. Depending on the merchant’s commercial arrangement, a request can carry gateway, processor, network or authorization cost. It can also cross a retry-control boundary: Stripe’s public optimization documentation describes blocking attempts that would incur network retry penalties and blocking requests unlikely to succeed to avoid additional scheme fees.4 The correct input is the merchant’s contracted marginal cost for this attempt, including any threshold effects—not a blended processing rate for successful sales.

The second is loss. Repeated low-value attempts can be a fraud mechanism, not merely enthusiastic recovery. The PCI Security Standards Council describes account testing as using payment requests to validate full or partially known card data for later fraud.5 Visa lists multiple transactions on one card in a short period and multiple cards from one IP address among card-not-present warning signs.7 A retry engine therefore needs fraud controls at the sequence level. Its expected-loss term should include the value at risk, the probability of fraud or dispute after approval, dispute fees where applicable, and unrecoverable fulfilment.

The third ledger is service work. A decline email may produce a contact; a duplicate hold may produce two; a confusing sequence can involve payments operations as well as support. Price that path from observed contact rates and handling costs for the relevant decline and channel. A flat “support cost per failed payment” hides the product behaviour causing the work.

The fourth is customer loss. A retry can recover today’s invoice while reducing the chance of tomorrow’s renewal. Estimate that cost from customer cohorts exposed to the same cadence, messages and payment state. Keep it separate from support: silence, repeated notifications and an ill-timed authentication challenge can damage a relationship without opening a ticket.

A better attempt changes the state

Waiting is valuable only when time can change the cause, as with an insufficient-funds response.2 Asking the customer is valuable when they can correct data or provide another method. Updating the credential is valuable when the stored account has changed: Mastercard’s Automatic Billing Updater returns issuer-reported account changes to merchants, and its public guide recommends checking for an update before retrying a declined transaction.8

Authentication changes a different variable. EMV 3-D Secure exchanges transaction, payment-method and device data between merchant and issuer to authenticate card-not-present payments.9 In the EU’s regulatory framework, a transaction-risk-analysis exemption depends on real-time analysis and specified fraud-rate conditions; when the payment cannot be classified as low risk, the provider should revert to strong customer authentication.10 Authentication may improve the good-collection probability or satisfy a regulatory requirement, but a customer challenge also has completion friction. Both belong in the P&L.

This produces state-specific actions. Correct bad data before resubmitting. Wait for a temporary condition. Seek a new method after a terminal response. Apply authentication when the risk and regulatory state requires it. Do not spend another authorization merely because a scheduler woke up.

Do not mistake an unknown outcome for a decline

A timeout needs a different ledger. After a network error, the caller may not know whether the server received the request; Stripe advises repeating the same parameters with the same idempotency key until a definitive result is returned.11 Its API saves the first result for an idempotency key and returns that result on subsequent matching requests.12

That is a transmission retry of the original operation, not a new collection attempt. Creating a fresh payment can produce a duplicate, which idempotency is designed to prevent.12 The duplicate can convert an uncertain outcome into refund work, support demand and customer distrust. Before evaluating the P&L of “another attempt,” establish whether another economic attempt actually exists.

Measure incrementality, not retry theatre

A recovery dashboard can flatter a weak policy. Raw acceptance counts every attempt; deduplicated acceptance groups retries for the same payment and uses the final outcome.13 Neither alone proves that the last retry caused recovery. Some payments would have succeeded later without that attempt, after a customer update, or on the next normal billing event. Stripe’s own optimization reporting accounts for the likelihood that an optimized payment would otherwise have been approved.4

The clean measurement is a controlled holdout at the decision boundary. For eligible payments with comparable state, send the candidate attempt for one group and withhold or replace it for another. Observe retained collections, fees, fraud and disputes, support contacts, cancellations and later customer contribution over an appropriate window. Then estimate the incremental terms in the equation, not just the attempted group’s success rate.

The decision record should preserve the features and forecast used before sending: decline and advice codes, credential and authentication state, attempt index, time since failure, predicted good-collection probability, value, each expected cost and the policy version. That makes a retry explainable after the outcome and allows estimates to be recalibrated.

The result is a smaller, stricter recovery system. It stops because another request is uneconomic, not because an arbitrary counter expired. It waits when time can create new information, asks the customer when only the customer can change the state, and reconciles when the outcome is unknown. Every attempt must earn its place on its own P&L.

Sources

Authorization Response Code Update, Alignment and Reminders (opens in a new tab) — Visa Merchant Business News Digest.

Card declines (opens in a new tab) — Stripe Documentation.

Transaction Processing Rules (opens in a new tab) — Mastercard.

Payments optimization (opens in a new tab) — Stripe Documentation.

Beware of Account Testing Attacks (opens in a new tab) — PCI Security Standards Council.

Chargebacks (opens in a new tab) — Visa Acceptance Solutions.

Protect Your Business from Fraud (opens in a new tab) — Visa.

Mastercard Automatic Billing Updater: Merchant External Summary (opens in a new tab) — Mastercard.

EMV 3-D Secure (opens in a new tab) — EMVCo.

Commission Delegated Regulation (EU) 2018/389 (opens in a new tab) — EUR-Lex / European Commission.

Advanced error handling (opens in a new tab) — Stripe Documentation.

Idempotent requests (opens in a new tab) — Stripe API Reference.

Acceptance analytics (opens in a new tab) — Stripe Documentation.