---
title: "Retry Logic"
url: "https://mahouse.world/glossary/retry-logic"
type: "glossary term"
topic: "Payments performance"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# Retry Logic

Retry logic is the set of rules, or the model, that decides whether and when to resubmit a declined payment — which decline codes to retry, how many times, at what intervals and times of day, through which acquirer — within the card schemes' limits on reattempts. It is the largest lever in decline recovery for subscription businesses, and the difference between a naive engine and a good one.

**Also known as:** Smart retries, Retry strategy, Payment retries

## Key facts

- **Used at:** subscription billing, marketplaces, any merchant-initiated transaction on a stored credential; increasingly on customer-present declines through instant retries on an alternative route
- **Binding:** the schemes' reattempt rules — Visa's cap of 15 attempts in 30 days for retriable codes, its prohibition on retrying category-1 codes, and per-reattempt fees for excess; Mastercard's equivalent rules; the merchant-initiated-transaction framework for how stored credentials are used
- **Typical inputs:** the decline code and its category, the issuer's observed approval patterns by hour and day, the customer's likely payday, the card type, the previous attempts, and the availability of an alternative acquirer or a network token
- **Typical results:** a tuned engine recovers 40–60% of soft declines; a naive daily retry recovers 20–30% and pays fees; instant re-routing on issuer timeouts recovers a further share on customer-present transactions
- **Parties:** the merchant or its billing platform, the PSP or orchestrator running the engine, the issuers (whose behaviour the engine learns), and the schemes (whose rules bound it)

## How retry logic works in practice

A renewal declines with "insufficient funds" on a Tuesday. A naive engine retries every day until it succeeds or gives up. A tuned engine reads the code (soft, retriable), consults its model of this issuer — approvals on this code cluster on the 1st and 15th and on weekday mornings — and schedules attempts on Friday morning and the 1st, with a third on the 3rd, and stops at the scheme's limit; if the card is a network token, it uses the token; if the first two attempts fail with a timeout rather than a decline, it routes the third through the merchant's second acquirer. Each attempt is idempotent — the same payment, not a duplicate — and flagged as merchant-initiated so it does not trigger an SCA challenge with nobody present.

The intelligence is in the data. PSPs and billing platforms see millions of retries across merchants and issuers, and their models learn which code, issuer and hour combinations succeed; a single merchant cannot. That is what "smart retries" sells, and it is measurable: recovery rate and fees paid. The bounds are the schemes': hard declines never; retriable codes within the count; and the reattempt fees when a merchant exceeds them, which are the signal that the engine is naive.

For customer-present transactions the same idea runs in seconds: an issuer timeout or a soft decline can be retried immediately through another acquirer or with a different message format, before the customer sees "payment failed" — which is what orchestration platforms do.

## Example

A fitness-app subscription with 400,000 monthly renewals and 9% first-attempt declines runs a daily retry for seven days: recovery 26%, 18 reattempt fees per hundred declines beyond the allowance, $6,000 a month in fees. It switches to its billing platform's model-based engine: retries scheduled by issuer and code, capped at five attempts, network tokens used where enrolled, timeouts re-routed. Recovery rises to 51%, fees fall to nil, and the retries take an average of nine days rather than the previous four — customers whose funds arrived on payday are recovered instead of churned. The 25-point improvement is 9,000 renewals a month, $108,000, for a platform fee of $4,000.

## Common mistakes

- Retrying on a fixed daily schedule regardless of code, issuer or the customer's payday.
- Exceeding the schemes' reattempt limits and treating the fees as a cost of business.
- Retries not flagged as merchant-initiated, so each one hits SCA with no customer present.
- Retries that are not idempotent, so a slow response produces two charges.
- Measuring recovery without the fees, and calling a naive engine successful.

## Related terms

- [Soft Decline](https://mahouse.world/glossary/soft-decline.md)
- [Hard Decline](https://mahouse.world/glossary/hard-decline.md)
- [Decline Recovery](https://mahouse.world/glossary/decline-recovery.md)
- [Approval Rate](https://mahouse.world/glossary/approval-rate.md)
- [Payment Orchestration](https://mahouse.world/glossary/payment-orchestration.md)
- [Idempotency Key](https://mahouse.world/glossary/idempotency-key.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov