Payment Retry

What Is Payment Retry?

Payment retry refers to the automated or manual process of re-submitting a payment authorization request after the initial attempt is declined by the issuer or fails due to a processing error. When a cardholder's transaction is declined, the merchant or their payment processor may attempt the charge again, either immediately or after a delay, depending on the reason for the failure.

Not all declines are equal. The payments industry distinguishes between soft declines (temporary conditions that may resolve on their own) and hard declines (permanent failures requiring cardholder action). Understanding this distinction is critical because retrying the wrong type of decline wastes processing resources, incurs penalty fees from card networks, and can trigger fraud monitoring systems.

Payment retry is most commonly associated with card-not-present transactions (online purchases and recurring billing), where the merchant cannot ask the cardholder to swipe a different card in real time. Soft declines represent an estimated 70 to 90 percent of card-not-present failures, making smart retry logic a significant lever for improving authorization rates.

How It Works

When a payment authorization is submitted to the card network, the issuing bank evaluates the request and returns a response code. This decline code tells the merchant or processor what went wrong and, importantly, whether the transaction is worth retrying.

Soft Declines: Retryable Failures

Soft declines indicate temporary conditions on an otherwise valid card. Common causes include:

• Insufficient funds at the time of the charge
• Processor or gateway timeouts
• Issuer velocity limits (too many transactions in a short window)
• Temporary issuer system outages
• Generic "do not honor" responses without a permanent reason

These failures may resolve on their own: the cardholder deposits more money, the processor recovers, or the velocity window resets. Retrying after a delay often succeeds.

Hard Declines: Do Not Retry

Hard declines indicate permanent conditions that no amount of retrying will fix:

• Account closed or card cancelled
• Card reported stolen or lost
• Invalid card number or expired card
• Fraud-flagged transactions
• Cardholder explicitly cancelled a recurring authorization

Retrying hard declines wastes network capacity, triggers penalty fees, and can damage a merchant's reputation with processors. The correct response is to notify the customer and request an updated payment method.

Merchant Advice Codes

Card networks provide Merchant Advice Codes (MACs) alongside decline responses to guide retry behavior. Mastercard, for example, uses codes such as:

Following these codes is not optional: networks monitor compliance and penalize merchants who ignore them.

Card Network Retry Rules

Visa and Mastercard both impose limits on how many times a merchant can retry a declined transaction, with financial penalties for violations.

Visa Reattempt Rules

Visa charges per-transaction fees for excessive reattempts: $0.10 per reattempt for domestic transactions and an additional $0.05 for cross-border transactions. Processors may restrict or drop merchants with heavy retry activity. Visa categorizes decline codes into retryable and non-retryable buckets, and merchants must respect these classifications.

Mastercard Retry Limits

Mastercard counts excessive retry attempts starting from the eighth attempt in a calendar month on the same card and merchant combination. The network also caps failed attempts at 35 per card and merchant within any continuous 30-day period. Exceeding these thresholds results in penalty assessments and increased monitoring.

Why Networks Enforce Limits

These rules exist for several reasons: excessive retries burden network infrastructure, they can indicate fraud or merchant abuse, and they generate unnecessary processing costs for issuers. A merchant who retries aggressively without analyzing decline codes is essentially brute-forcing authorizations, which the networks treat as abusive behavior.

Retry Timing Strategies

When a retry is appropriate, timing matters significantly. Retrying too quickly often hits the same temporary condition; retrying too late risks losing the sale entirely.

Fixed Interval Schedules

The simplest approach uses predetermined intervals. A common pattern is retrying at 3, 7, and 14 days after the initial failure. Some processors default to retrying every 2 days for up to 5 attempts. The key principle: avoid daily retries, as repeated attempts in quick succession can resemble fraud to processors and issuers.

Decline-Aware Scheduling

More sophisticated systems adjust timing based on the decline reason:

• Insufficient funds: retry around payroll dates (typically the 1st and 15th of the month) when account balances are likely higher
• Processor timeouts: retry within minutes, as these are infrastructure issues rather than account issues
• Velocity limits: wait 24 hours for the issuer's rate window to reset
• Generic soft declines: retry after 12 to 24 hours

Machine Learning Optimization

Modern payment platforms use machine learning models to predict the optimal retry time for each individual transaction. These models analyze historical approval patterns, cardholder behavior, time of day, and decline code frequency to maximize recovery rates while staying within network limits.

Dunning Management

In recurring billing and subscription contexts, payment retry becomes part of a broader process called dunning: the systematic effort to recover failed payments before cancelling a subscription.

A dunning workflow combines automated retries with customer communication:

1. Initial payment attempt fails
2. System sends a notification email with a link to update billing details
3. First retry attempt after a configured delay (e.g., 3 days)
4. If still failing, another notification and retry (e.g., day 7)
5. Final retry attempt (e.g., day 14)
6. If all retries fail, the subscription is paused or cancelled

Dunning systems also integrate with account updater services like Visa Account Updater, which automatically refresh stored card details when an issuer re-issues a card. When a payment fails because a card was replaced, the updater can supply the new card number and expiration date, allowing the retry to succeed without any cardholder intervention.

Idempotency and Retry Safety

A critical requirement for any retry system is idempotency: the guarantee that retrying a payment request does not result in duplicate charges. If a timeout occurs after the authorization was actually approved but before the response reached the merchant, a naive retry would create a second charge.

Payment processors solve this with idempotency keys: unique identifiers attached to each payment request. When the processor receives a retry with the same key, it returns the result of the original attempt rather than processing a new one.

// Idempotent payment retry with an idempotency key
const response = await paymentGateway.charge({
  amount: 4999,
  currency: "usd",
  paymentMethod: "card_abc123",
  idempotencyKey: "order_789_attempt_1",
});

// If the request timed out, retry with the same key
// The gateway returns the original result, not a duplicate charge
const retryResponse = await paymentGateway.charge({
  amount: 4999,
  currency: "usd",
  paymentMethod: "card_abc123",
  idempotencyKey: "order_789_attempt_1",
});

Crypto Payments: No Retry Needed

Blockchain-based payments operate on a fundamentally different model. On-chain transactions either confirm (are included in a valid block) or they don't. There is no issuer to decline the transaction and no ambiguous soft-decline state.

When a user submits a Bitcoin transaction, one of two outcomes occurs:

• The transaction is broadcast, enters the mempool, and eventually confirms in a block
• The transaction is rejected at submission (invalid signature, double spend, insufficient balance) and never enters the network

There is no "insufficient funds, try again later" response. Balance checks happen at the protocol level before the transaction is accepted. If the user has the funds, the transaction will eventually confirm (assuming an adequate fee rate). If they don't, the transaction is immediately invalid.

This eliminates the entire retry infrastructure: no decline codes, no dunning workflows, no network penalty fees, and no risk of duplicate charges. The trade-off is payment finality: while card payments can be retried but also reversed (via chargebacks), confirmed blockchain transactions are irreversible. See our payment finality comparison for a deeper analysis of these trade-offs.

Layer 2 solutions like Spark extend this model with near-instant settlement. A payment through Spark either completes or fails at the protocol level: there is no soft decline, no retry window, and no ambiguity about whether the funds moved. This deterministic outcome simplifies payment infrastructure for merchants significantly.

Why It Matters

Payment retry logic directly impacts a business's bottom line. Subscription businesses can lose 5 to 10 percent of revenue to involuntary churn from failed payments that are never recovered. Smart retry strategies recover a meaningful share of these transactions without violating network rules.

For payment engineers, the complexity is real: you need to parse decline codes correctly, implement idempotent retry logic, respect per-network retry limits, time retries intelligently, and coordinate with dunning workflows. A mistake can mean duplicate charges, penalty fees, or losing processing privileges.

The contrast with crypto payment rails is stark. As stablecoin and blockchain-based payments gain adoption, the elimination of the entire retry and dunning layer represents a significant reduction in payment infrastructure complexity. Merchants processing stablecoin payments don't need to build retry schedulers, interpret decline codes, or manage dunning email sequences: the payment either works or it doesn't.

Risks and Considerations

Penalty Fees and Compliance

Merchants who retry too aggressively face penalty fees from card networks, increased monitoring, and in extreme cases, loss of processing privileges. Every retry strategy must account for Visa and Mastercard limits to stay compliant.

Duplicate Charges

Without proper idempotency, retries can create duplicate charges that lead to customer disputes, chargebacks, and reputational damage. Every retry must carry an idempotency key.

Customer Experience

Excessive retries without customer communication create a poor experience. Cardholders may see repeated pending charges on their statements, receive fraud alerts from their bank, or have their card temporarily frozen. Pairing retries with clear notifications through a dunning process keeps customers informed.

Fraud Detection Interference

Rapid, repeated authorization attempts on the same card can trigger issuer fraud detection systems, potentially causing the card to be frozen for all transactions. This creates the opposite of the intended effect: instead of recovering a payment, the retry pattern blocks the customer's card entirely.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.