Payment Orchestration Retry Logic

Skip key takeaways

Updated October 8, 2026

• Classify declines by the scheme's own categories Visa sorts decline codes into four categories, one of which may never be resubmitted for the same card, so store the raw network response code for every attempt and classify on it, together with any Mastercard merchant advice code.
• Map every decline class to a routing decision A single table of decline class, retry permission and route turns scheme rules into executable policy and makes cascade decisions reviewable.
• Never resubmit a Category 1 decline on any route The Category 1 rule is written against the payment credential, not the acquirer, so forwarding a stolen-card or closed-account decline to a backup PSP breaks it just as a same-route retry would.
• Treat an authentication soft decline as a step-up Visa code 1A in the Europe and CEMEA regions means additional customer authentication is required, so the next move is a 3-D Secure challenge on the same acquirer, not another blind attempt.
• Resolve unknown outcomes before the next attempt One client idempotency key per payment intent, a separate attempt ID and downstream key for every attempt and a settled outcome after every timeout prevent a cascade from authorizing the same order twice.

Copy takeaways

In short: payment orchestration retry logic is the part of a payment platform that decides, after a decline or a timeout, whether to try again, when to try, on which route and with what changes to the request. The card networks answer several of those questions. Visa's rules sort decline codes into four categories, forbid any resubmission of the first category for the same card and cap reattempts on the other three. Visa also prohibits deliberately changing protected fields such as the merchant category code on a reattempt, and in Europe a soft decline for authentication calls for a 3-D Secure challenge rather than another blind attempt. Good retry logic encodes those rules as a classifier, gives every attempt its own identity and resolves an unknown outcome before it sends the next one.

What it costs to connect a PSP in the first place, and the build paths for doing it, are covered in our payment gateway integration cost guide.

What Is Payment Orchestration Retry Logic?

An orchestration layer sits between checkout or billing and one or more payment service providers (PSPs) and acquirers. It receives one payment intent, such as an order total or a subscription renewal, and turns it into one or more authorization attempts. Retry logic is the policy that governs those attempts. It has three distinct moves.

• A same-route retry sends a new authorization for the same intent through the same PSP and acquirer, usually after a delay.
• Cascading, sometimes called failover, sends the intent to a different PSP or acquirer after a decline or an error on the first.
• A step-up retry repeats the attempt after the cardholder completes additional authentication, typically a 3-D Secure challenge.

Each move needs four decision inputs: the network response code, any merchant advice the issuer attached and the authentication status of the attempt, all returned by the PSP with the decline, plus the history of earlier attempts on the same card, which the platform keeps itself. A platform that only sees a PSP's simplified declined or failed status cannot make these decisions well, so the first engineering task is to store the raw network response code for every attempt.

This guide covers card payments under the Visa rules, and Mastercard only as far as its merchant advice codes. Other card schemes and non-card rails such as SEPA Direct Debit and ACH follow their own rules for retrying a failed collection and are out of scope.

How Does Visa Classify Decline Codes?

Section 7.3.6.3 of the Visa Core Rules and Visa Product and Service Rules, edition of 18 April 2026, starts with the issuer: "An Issuer that declines an Authorization Request or an Account Verification request must send to VisaNet the Decline Response code that most accurately reflects the reason for the decline". That obligation is why a classifier can treat the code as the issuer's stated reason for the decline. What the merchant may do next is set out in Table 7-2 of the same section. Mobility and transport merchants follow separate resubmission rules in Section 7.3.6.2, which this guide does not cover.

Four categories and their reattempt limits

Table 7-2 splits decline codes into four categories. Category 1 holds the codes for which the issuer will never approve, and for these the rule in the April 2026 Visa rules is absolute: "a Merchant must never resubmit an Authorization Request or Account Verification for the same Payment Credential". A footnote closes the loophole of hoping the issuer changes its mind: "After sending a Category 1 Decline Response, Issuers must consistently send the same Decline Response code."

Category 2 covers codes where the issuer cannot approve at this time, Category 3 covers data-quality declines where the payment information has to be revalidated and Category 4 is a generic bucket for every other decline code. For all three, the April 2026 edition of the Visa rules states the merchant reattempt limit as "Reattempt permitted (up to 20 attempts in 30 days)". The limit belongs to a dated edition, so a retry policy should record which edition it was built against and be reviewed when Visa publishes the next one.

How the Category 2 and 4 budget is spent matters more than its size. Spread attempts across the 30-day window instead of bursting them in the first hours, when nothing at the issuer has had time to change. Respect any retry-after interval a Mastercard advice code states and time insufficient-funds retries for when money is likely to arrive, such as after common paydays. Stop the schedule when the dunning period agreed with the customer ends. That is engineering practice, not a scheme rule.

Category memberships that surprise

Some memberships in Table 7-2 run against intuition.

• Invalid account number (14) is Category 1. It is not a typo to be corrected and retried on the same credential.
• Suspected fraud (59) and invalid merchant (03) sit in Category 2, not Category 1.
• Expired card or expiration date missing (54) is Category 3, which means it is recoverable once the expiry date is updated, not a hard decline.
• Table 7-2 does not list 05, which places it in Category 4 by the table's rule for all other decline codes. That is an inference from the table's structure, not a listing in it.

Decline Classes Mapped to Retry and Routing Decisions

The table below turns the Visa categories, and the Mastercard merchant advice described under it, into decisions an orchestration layer can execute. Code lists in the Visa rows come from Table 7-2 in the April 2026 edition and, except for Category 1, are examples rather than the complete category membership. The last column is Pharos Production's engineering judgment about where implementations commonly go wrong, not a measured statistic.

Decline class	Example response codes	Retry allowed?	Where to route	Typical failure mode
Issuer will never approve (Visa Category 1)	04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3	No, not for the same Payment Credential, on any route	Stop. Ask the customer for a different payment method. R0, R1 and R3 are stop-payment and revocation orders, so also stop the stored-credential payments they cover. For a stored credential, also mark it unusable for future merchant-initiated payments until the customer replaces it.	Cascading a 14 or a 46 to a second acquirer, which is still a resubmission of the same credential
Issuer cannot approve at this time (Visa Category 2)	03, 51, 59, 61, 91, 96	Yes, within the Category 2 limit of the current Visa edition	51 and 61: same route, later, on a schedule. 91 (issuer or switch inoperative): a delayed retry, since a second acquirer reaches the same issuer. 96 (system malfunction): a delayed retry, and a second route only when your acquirer confirms the request never left its systems. 59 (suspected fraud): no scheduled retry; ask the customer to confirm or authenticate. 03 (invalid merchant): no retry until the merchant setup with the acquirer is checked	Immediate retries of a 51 that spend the attempt budget before any funds can arrive
Data quality, revalidate (Visa Category 3)	54, 55, 82, N7, 6P	Yes, within the limit, once the payment data has been revalidated as the category name requires	Back to the customer for checkout. For a 54 on a stored credential, an account-updater or token-lifecycle path	Retrying a 54 with the same expiry date
Authentication required (Visa Category 3, Europe and CEMEA)	1A	Yes, after the cardholder authenticates, within the Category 3 limit	Same acquirer, with a 3-D Secure challenge	Sending the unauthenticated request to a second acquirer in the hope of a different exemption outcome
Generic decline (Visa Category 4)	All codes not listed in Categories 1 to 3, including 05 by inference	Yes, within the Category 4 limit	Same route on a bounded schedule	Treating 05 as hard and losing recoverable payments, or as soft and retrying until the limit
Advice: do not retry (Mastercard)	Merchant Advice Codes 03 and 21	No	Stop retrying, as the issuer advises. Flag a 21 (payment cancellation) on the recurring agreement it belongs to	Reading the response code alone and ignoring the merchant advice code
Advice: retry later or update (Mastercard)	Merchant Advice Codes 01, 02 and 24 to 30	01: with updated account data. 02: later, on your own bounded schedule. 24 to 30: not before the interval the code states	01 to an account-updater path. Otherwise the same route, scheduled	A fixed retry schedule that ignores an interval the code states

Mastercard's developer documentation for the Mastercard Send funding API describes a Merchant Advice Code that is present when the issuer declines the transaction. Listed values include 01 for new account information available, 02 for try again later, 03 for do not try again and 21 for payment cancellation, while 24 to 30, marked for Mastercard use only, each ask for a retry after a set interval, from one hour up to ten days. Code 02 states no interval. That documentation belongs to the funding API of Mastercard Send, a money-transfer product, not to the card-acceptance rulebook, so treat the advice values as classifier input and take any Mastercard attempt limits from your acquirer agreement.

Two design rules follow from the table. Classify on the network response code and the merchant advice together, with the stricter instruction winning when they disagree. Then keep one attempt count per card across every route the platform uses. Only the Category 1 rule is written against the Payment Credential. For the other categories the public table gives a number of attempts and a window but not how they are counted, which the rules and your acquirers define, so ask each acquirer how it counts and treat a single per-card count that every route spends as the conservative engineering choice.

For stored credentials, a 54 often does not need the customer. An account updater service can return a new expiry date or card number, and where the platform charges network tokens instead of card numbers, the lifecycle updates the network sends keep the token current. Either way the retry carries the refreshed data, never the data the issuer declined. The other Category 3 codes, such as a CVV2 failure (N7), a PIN error (55) or 1A, need the cardholder.

Some attempts never pass through the orchestration layer at all. A PSP may retry a declined or timed-out authorization on its own before it reports a result, and the issuer sees those attempts on the same card, so treat them as part of the same per-card count. Ask each PSP whether it retries automatically, then either switch that off or have the PSP report its own attempt count with every result.

Resubmitting after a Category 1 decline or overrunning a Visa reattempt limit is a rule breach rather than wasted traffic. Retrying after Mastercard advice 03 or 21 is a different failure: it continues after the issuer advised the merchant to stop. The public Visa rules read here name no specific charge for excess reattempts and Visa's fee schedules are not public, so how any consequence reaches the merchant is set in the acquirer agreement.

Can You Cascade a Declined Payment to a Second Acquirer?

The Visa rule text read here neither allows nor forbids sending a declined authorization to a second acquirer. It does set two constraints that bind any cascade.

What the rules settle

First comes the Category 1 rule. It is written against the Payment Credential, not against the route, so a Category 1 decline cannot be resubmitted through a second acquirer any more than through the first. A cascade engine that routes every decline to a backup PSP violates this rule on every stolen-card, closed-account and invalid-account decline it forwards.

Second is the data-integrity rule. Rule ID# 0008752 in the Visa Core Rules binds an acquirer, a merchant, a payment facilitator or a VisaNet processor that reattempts an authorization after a decline: it "must not intentionally manipulate any data elements from the original Authorization Request". The protected elements include the acquiring identifier, the acquirer and merchant country, the merchant category code, the POS condition code, the POS environment field, the POS entry mode and the electronic commerce indicator. The same rule adds that "Merchant Outlet country data must be the same throughout the Transaction life cycle".

What the rules leave open

That leaves a genuine interpretation question. A cascade to a second acquirer necessarily carries a different acquiring identifier, and the rule text does not say whether a real second acquiring relationship, with the merchant contracted there, counts as manipulation. Treat it as a question for your acquirers and record their answer before switching cascading on. What the rule plainly excludes is the clever version of a cascade, in which the second attempt changes the merchant category code, the merchant country, the POS entry mode or the e-commerce indicator to look like a different kind of transaction. That is an approval trick, not a routing decision.

A cascade is safest when limited to failures that describe the route rather than the card or its issuer, such as a PSP or acquirer error returned before the request reached the card network, with every hop counted against the same per-card attempt budget. An issuer decline is not one of them. A 91 says the issuer or switch is inoperative, and a second acquirer reaches the same issuer, so that hop is one more Category 2 attempt on the same card rather than a fix. A timeout is not one of them either until its outcome is resolved, as the section on duplicates explains.

SCA Soft Declines: When a Retry Becomes a Step-Up

In the European Economic Area, card payments sit under the strong customer authentication (SCA) rules of PSD2. The Regulatory Technical Standards in Commission Delegated Regulation (EU) 2018/389 allow payment service providers to "exempt the application of the security requirements of strong customer authentication, subject to specified and limited conditions based on the level of risk, the amount and the recurrence of the payment transaction", per Article 1 of the consolidated text. The exemptions are permissions, not obligations, and the payer's PSP, the issuer, keeps the final say.

Exemptions that matter to retry logic

The exemptions that come up in checkout, such as low-value payments under Article 16 and transaction risk analysis under Article 18, can be requested by the acquirer and are then granted or refused by the issuer, which can also apply them on its own. A refused exemption is one route to the soft decline described next. Recurring payments with a fixed amount add a fixed point. Article 14 of the consolidated RTS states: "Payment service providers shall apply strong customer authentication when a payer creates, amends, or initiates for the first time, a series of recurring transactions with the same amount and with the same payee." Under its second paragraph only the subsequent payments in the series may skip SCA. Article 14 does not address a declined first payment, so the safe engineering reading is that its retry is still the first initiation of the series and runs with authentication rather than on a timer.

The soft decline and the step-up

When the issuer wants strong customer authentication that the authorization did not carry, for example because it refused a requested exemption or did not accept the transaction as out of scope, the decline comes back as a soft decline. Visa's Table 7-2 in the April 2026 rules lists the code for it under Category 3: "In the CEMEA Region, Europe Region: 1A (Additional customer authentication required)". The RTS itself never uses the words soft decline, and 1A is the network's code for that outcome.

The correct response is a step-up before the next reattempt: a 3-D Secure challenge on the same acquirer, then a new authorization carrying the authentication result, which the conservative reading counts as a Category 3 reattempt. Retrying the unauthenticated request on a timer spends Category 3 attempts on a request the issuer has already refused, and moving it to a second acquirer adds the cascade questions above. A step-up needs the customer present, so a soft decline on a merchant-initiated payment usually ends with a request to the customer to return and authenticate. For how authentication itself is changing, see our guides to PSD3 compliance requirements and EUDI Wallet strong customer authentication.

Which Merchant-Initiated Retries Stay Outside SCA?

Subscription renewals, retried invoices and delayed charges are merchant-initiated transactions (MITs). In Q&A 2018_4031 of the EBA's Single Rulebook Q&A tool, the answer, prepared by the European Commission, is that "Payment transactions that are not initiated by the payer but by the payee only are therefore not subject to strong customer authentication (SCA) to the extent that these transactions are initiated without any interaction or involvement of the payer." In Q&A 2018_4131 the Commission's answer ties payee initiation to a mandate the customer has given the merchant, and the answer in 2018_4031 adds that where the mandate is given through a remote channel, "the setting up of such a mandate is subject to strong customer authentication". Both answers are an unofficial opinion of the Commission's Directorate General for Financial Stability, Financial Services and Capital Markets Union (DG FISMA), which the EBA publishes on its behalf. They are not law, and only the Court of Justice of the EU can give definitive interpretations of EU legislation.

Retries under a mandate

A retry of a properly flagged MIT, made under a mandate the customer gave with SCA, stays an MIT. A retry that needs the customer to do something, such as confirm the payment or re-enter card details, is customer-initiated and back in scope of SCA, subject to any exemption the issuer grants. Visa's stored-credential guide, published in 2017 and used here only for its terminology, defines one narrow retry type, resubmission: "A merchant performs a resubmission in cases where it requested an authorization, but received a decline due to" insufficient funds when the goods or services were already delivered to the cardholder. The guide files resubmission among industry-practice MITs, next to delayed charges and no-show charges, while installment, recurring and unscheduled credential-on-file payments are standing-instruction MITs. Read against that taxonomy, a retried subscription renewal is still a recurring payment rather than a resubmission, so flagging it with the resubmission reason misdescribes it.

To keep a retry recognizable as the MIT it is, the orchestration layer should carry the stored-credential indicators and the reference to the first transaction in the series unchanged on every attempt. That is engineering practice. It sits alongside rule ID# 0008752, whose protected fields are the ones listed in the cascade section above.

How Do You Stop a Cascade From Charging Twice?

The worst failure in retry logic is a duplicated payment, and it usually starts with a timeout. Attempt one goes to PSP A and times out. The orchestration layer treats it as failed and sends attempt two to PSP B, and later PSP A turns out to have approved. The customer now holds two authorizations for one order.

Idempotency at two levels

Idempotency is the tool, applied at two levels. RFC 9110 calls a method idempotent "if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request". A payment intent should behave that way toward the client that created it: one intent, one idempotency key, however often checkout resubmits. Each attempt inside the intent gets its own attempt ID and its own downstream key, because a same-route retry and a cascade hop are different requests. An IETF HTTPAPI working-group Internet-Draft on the Idempotency-Key header, draft -07, which expired on 18 April 2026 and is citable only as work in progress, adds that "If there is an attempt to reuse an idempotency key with a different request payload, the resource SHOULD reply with a HTTP 422 status code", so one key shared across changed attempts is a bug, and a key reused on an unchanged retry only returns the stored decline instead of a new authorization.

Attempt rules that prevent duplicates

1. Persist the attempt record, with its ID, route and key, before sending the request, so a crash cannot produce an attempt the platform does not know about.
2. Treat a timeout as an unknown outcome, not a decline. Resolve it with a status query to the PSP, or by replaying the same request with the same downstream key only where the PSP documents idempotent replay and the key is still inside its retention window. Reverse the authorization if it turns out approved and is no longer wanted. If none of these settles the outcome, hold the intent for manual review rather than send a new attempt.
3. Allow at most one attempt in flight per payment intent.
4. Post every authorization, capture and reversal to the ledger under the attempt ID, so the payment reconciliation engine can match PSP records to attempts and flag a second capture as a break.

Measuring Retry Logic Without Double Counting

Retry logic inflates its own metrics when the denominator is wrong. Pharos Production counts approval per payment intent, not per attempt: an intent that succeeds on its third attempt counts once as approved, and its first-attempt result is reported separately. Recovered payments are intents approved after at least one decline, split by decline class and by move, meaning same-route retry, cascade or step-up. Attempts per card over the 30-day window, counted the way your acquirers define it, are tracked as a compliance measure next to these, alongside the share of Category 1 declines that were followed by any further attempt on the same card, which should be zero. Each figure is read against the platform's own trend, not against external benchmarks.

How Pharos Production Helps

Retry logic is a small amount of code wrapped around a large number of rules, and most of the risk sits in classification, attempt identity and ledger posting rather than in the scheduler. Our payment solutions development team builds orchestration layers that store raw network responses, classify declines against the current scheme editions, keep every attempt idempotent and reconcile each one to the ledger. For the wider platform around it, see our FinTech software development work.

Sources: Visa, Visa Core Rules and Visa Product and Service Rules, edition of 18 April 2026, section 7.3.6.3 and Table 7-2, and rule ID# 0008752; Visa, Improving Authorization Management for Transactions with Stored Credentials (2017); Commission Delegated Regulation (EU) 2018/389, consolidated text of 25 July 2023; European Commission answers published in the EBA Single Rulebook Q&A tool, 2018_4031 and 2018_4131; IETF, RFC 9110 HTTP Semantics and The Idempotency-Key HTTP Header Field (Internet-Draft -07, expired); Mastercard developer documentation for the Mastercard Send funding API, paraphrased. Engineering guidance, not legal advice.

FAQ

Last updated: October 8, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• How many times can a declined Visa transaction be retried?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  It depends on the decline category. Under the April 2026 edition of the Visa rules, a Category 1 decline, where the issuer will never approve, may not be resubmitted at all for the same card.

  Categories 2, 3 and 4 allow up to 20 attempts in 30 days, and Category 3, the data-quality category, signals that the payment data must be revalidated before the next attempt. Spread those attempts across the window rather than bursting them early, which is engineering practice rather than a scheme rule.

• Is it allowed to send a declined payment to a second acquirer?

  Copy link Copies a direct link to this answer to your clipboard.

  The Visa rule text read here does not say that cascading to a second acquirer is allowed, and it does not say that it is forbidden. It does prohibit a reattempt that deliberately changes protected data such as the merchant category code, merchant country, POS entry mode or e-commerce indicator.

  Confirm the position with your acquirers before enabling cascades, and limit them to failures on the route itself, such as a PSP or acquirer error before the request reached the network, because a second acquirer reaches the same issuer.

• What should retry logic do with a soft decline for authentication?

  Copy link Copies a direct link to this answer to your clipboard.

  Start a step-up before the next attempt. In the Europe and CEMEA regions, the issuer returns Visa code 1A when additional customer authentication is required, for example after the issuer refuses an SCA exemption.

  The orchestration layer should run a 3-D Secure challenge on the same acquirer and send a new authorization with the authentication result.

• Do merchant-initiated retries need strong customer authentication?

  Copy link Copies a direct link to this answer to your clipboard.

  Not if they are genuinely merchant-initiated. Q&A answers prepared by the European Commission and published by the EBA treat payments initiated by the payee alone, under a mandate the customer gave, as outside SCA, while a mandate given through a remote channel needs SCA when it is set up.

  A retry that requires the customer to act, such as confirming the payment, becomes customer-initiated and back in scope of SCA, subject to any exemption the issuer grants.

• Do a PSP's own automatic retries count against the limit?

  Copy link Copies a direct link to this answer to your clipboard.

  The issuer sees every attempt on the card, including retries a PSP makes on its own before it reports a result, so in engineering practice they belong in the same per-card count. Ask each PSP whether it retries automatically, then either switch that off or have the PSP report its attempt count with every result.

• What should happen when a PSP call times out?

  Copy link Copies a direct link to this answer to your clipboard.

  Treat the timeout as an unknown outcome, not a decline. Resolve it with a status query to the PSP, or by replaying the same request with the same downstream key where the PSP documents idempotent replay and the key has not expired, and reverse the authorization if it was approved and is no longer wanted.

  If the outcome still cannot be settled, hold the payment intent for manual review rather than send a new attempt. Allowing only one attempt in flight per intent and giving every attempt its own ID and downstream idempotency key stops a cascade from charging the customer twice.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.