Retry Logic: How Smart Payment Retries Work

Retry logic is the system that decides when to try a failed payment again. Simple retry logic tries again every 24 hours. Smart retry logic analyzes the failure and picks the optimal moment. The difference can mean 20-30% more recovered payments.

Why retries matter

When a payment fails, you have a window of opportunity. The customer hasn't churned yet — their card just didn't work this time. A well-timed retry can capture that payment without the customer ever knowing there was a problem.

But timing matters. Retry too soon after "insufficient funds" and you'll fail again. Retry a hard decline and you're wasting attempts. Retry at the wrong time of day and you're fighting against bank fraud systems.

Good retry logic turns a potential loss into recovered revenue. Bad retry logic wastes attempts and can actually hurt your success rate.

Simple vs smart retry logic

Simple retry logic is dumb but predictable:

• Payment fails → retry in 24 hours
• Fails again → retry in 48 hours
• Fails again → retry in 72 hours
• Give up after X attempts

This approach treats all failures the same. Expired card? Retry. Insufficient funds? Retry. Processing error? Retry. Same timing, same approach.

Smart retry logic adapts to the situation:

• Analyze the decline code
• Consider the day of week and time
• Look at historical success patterns
• Adjust timing based on failure type
• Skip retries that won't work

The difference is significant. Simple retries recover maybe 30-40% of soft declines. Smart retries can hit 50-60% on the same failures.

How smart retry logic works

Smart systems consider multiple factors:

Decline code analysis. "Insufficient funds" means wait a few days (payday). "Do not honor" might work if you retry in a few hours. "Card expired" means don't retry at all — it'll never work.

Time of day. Banks have maintenance windows. Fraud systems are more aggressive at night. Mid-morning on weekdays typically has the highest success rates.

Day of week. Monday has more failures (weekend backlogs). Tuesday through Thursday are usually best. Friday afternoon success drops off.

Day of month. Beginning of month (1st-5th) catches fresh paychecks. End of month sees more "insufficient funds." Mid-month is neutral.

Customer history. Has this customer had failures before? What time did their successful payments go through? Patterns emerge.

Amount. Larger amounts get more scrutiny from fraud systems. Sometimes splitting or slightly adjusting timing helps.

Building retry logic

If you're building your own, here's a basic framework:

On payment failure:
  1. Get decline code
  2. Classify as soft or hard decline

  If hard decline:
    → Don't retry automatically
    → Trigger dunning email immediately

  If soft decline:
    → Schedule retry based on code:
      - "insufficient_funds" → 3-5 days later, early morning
      - "processing_error" → 4-6 hours later
      - "card_declined" (generic) → 24-48 hours later
      - "try_again_later" → 2-4 hours later
    → Max 3-4 retry attempts
    → After final failure, trigger dunning sequence

This is simplified. Production systems add more nuance — machine learning models, customer segmentation, dynamic timing based on real-time success rates.

The retry attempt limit

More retries isn't always better. Each failed attempt:

• Can trigger fraud alerts at the bank
• Might get flagged by payment processors
• Adds to your decline rate metrics
• Delays the dunning process

Most experts recommend 3-4 retry attempts over 7-10 days. After that, you're better off asking the customer directly to update their card.

Some processors penalize merchants with high retry rates. Stripe, for example, monitors retry patterns and can flag accounts that retry too aggressively.

Retries vs dunning

Retry logic and dunning work together but serve different purposes:

Retries are invisible to the customer. The system tries again automatically, hoping the payment goes through without anyone noticing there was a problem.

Dunning involves the customer. You tell them the payment failed and ask them to take action.

The best approach combines both:

1. Payment fails → first retry scheduled
2. Dunning email sent in parallel
3. Retry happens → if successful, cancel remaining emails
4. Retry fails → continue dunning sequence
5. After max retries → dunning becomes the only path

This way, you're working both angles. Automatic retries might solve the problem silently. Dunning engages the customer if retries don't work.

When to skip retries entirely

Some failures shouldn't be retried:

• Expired card — Will never work. Ask for new card immediately.
• Invalid card number — Card doesn't exist. Dunning only.
• Lost/stolen card — Blocked permanently. Dunning only.
• Account closed — No account to charge. Dunning only.
• Fraud block — Bank has flagged it. Retrying makes things worse.

Retrying these wastes your attempt budget and delays the real solution: getting the customer to update their payment method.

Measuring retry effectiveness

Track these metrics:

• Retry success rate — % of retried payments that eventually succeed
• Success by attempt number — Does attempt #3 ever work? Maybe you only need 2.
• Success by decline code — Are you retrying failures that never convert?
• Time to recovery — How many days from first failure to successful payment?

Use this data to tune your logic. If "insufficient funds" retries work best on day 5, adjust your timing. If attempt #4 has a 2% success rate, maybe stop at 3.