Retry With 3DS: What It Means and How to Recover the Payment

"Retry with 3DS" is not an error. It is the issuer telling you it will consider approving the card once authentication is attached. Here is how to act on that instruction, including the recurring rebill case where a challenge cannot be served at all.

Most decline documentation treats "retry with 3DS" as a technical footnote in a guide to 3D Secure (3DS), the authentication check a cardholder's bank runs. It is not a footnote. It is one of the few responses in card payments where the issuer tells you exactly what it wants. The issuer agrees to look again if you supply it. The standard advice, re-attempt the payment with authentication, assumes a cardholder is sitting in front of a checkout page. On a subscription rebill, nobody is there. That single fact turns a 3DS question into a decline-recovery sequencing question. Almost every page on this topic stops right there.

What does 'retry with 3DS' actually mean when your gateway or acquirer returns it?

Retry with 3DS means the issuer refused the authorization only because authentication was missing. This is a soft decline, not a refusal of the card. The issuer signals that it will consider the same card, the same amount and the same customer again. You have to re-present the transaction with 3D Secure data attached.

The distinction matters because the two outcomes look identical in most reporting. A card refusal ends the payment. An authentication instruction leaves the payment recoverable if you supply the missing element. Adyen documents this literally: refusal reason 38, "Authentication required", means the issuer rejected your exemption request. The issuer wants the transaction resubmitted with 3D Secure attached. If your dashboards roll both into one bucket, start with the difference between a soft decline and a hard decline. Settle that before you touch retry logic.

Visa goes further. Visa requires acquirers to surface the 1A code to merchants rather than rolling it up into generic responses such as Do Not Honour. If you only ever see generic declines on European rebills, that points to a reporting fidelity problem rather than an authentication problem. No amount of retry tuning will fix that. Our primer on 3D Secure authentication covers what the protocol does when you re-present.

A second wrinkle hides the size of this cohort. On some platforms the retry has already happened before you see anything. Adyen automatically re-runs the transaction through 3DS where the integration supports it, unless the merchant explicitly passed executeThreeD=false. Stripe reattempts with authentication when a transaction it treated as exempt comes back soft-declined. Merchants on those stacks can run one 3DS retry that never appears in their own logs.

Which decline responses are instructions to re-attempt with authentication, and which mean the issuer will not approve?

Treat the raw code as an instruction only after you map it to the scheme that sent it. Visa uses 1A, Mastercard 65, American Express 130, Diners 103 and Dankort 132 for the same authentication-required message. Platform codes differ again: Checkout.com returns 20154, Solidgate 2.15, Braintree 2099 and Stripe authentication_required.

Note: platform codes and scheme codes are different layers. Map both, and store the raw acquirer response, or your recovery rules will be built on your gateway's normalisation rather than the issuer's actual instruction.

The three buckets that decide whether a retry is even permitted

Visa's four-category framework is the scheme-level version of "should I retry". Visa introduced it in April 2020 and realigned it effective 17 April 2021. Category 1 covers declines the issuer has said it will not approve, and you cannot reattempt them at all. Category 2 means "cannot approve at this time". Category 3 means "data quality, revalidate payment information". Visa places 1A in Category 3 rather than treating it as a refusal.

That placement has a cost consequence most merchants miss. Because 1A sits in the data-quality bucket, the reattempt cap on authentication declines carries two fee risks. Exceeding it can trigger excessive-retry fees and data-quality fees together, not one or the other. Visa's own guidance also tells merchants to suppress retries where the issuer sent a do-not-try-again instruction. Visa tells merchants to default to no retry when no category code comes back at all.

The machine-readable version of this decision is the advice code that travels alongside the decline reason. Stripe exposes advice_code with values such as do_not_try_again, try_again_later and confirm_card_data. Mastercard's Merchant Advice Codes split the same way: 03 means do not try again, 21 means payment cancellation, and 24 through 30 carry explicit retry timing. Read that field to split retryable from non-retryable instead of guessing from the decline text. Our guide to reading an issuer decline covers the same discipline.

Cohort one case separately before you force another authentication. Stripe reports that issuers sometimes return authentication_required on payments that already completed 3DS. Stripe also reports that on some Mastercard cards the code has appeared where the issuer actually meant a withdrawal count limit. In that population the fix is a different payment method or a different day, not another challenge.

How do you re-run a declined authorization through 3DS without double-charging or losing the original attempt?

Re-running the payment is a two-step sequence, not a resend. You authenticate first through EMV 3DS (the current 3D Secure standard) with challenge indicator 04. You then submit a fresh authorization carrying the resulting ECI (electronic commerce indicator) and CAVV (cardholder authentication verification value). An idempotency key on the authorization call keeps a network timeout from turning one recovery into two charges.

1. Treat the soft decline as a closed attempt. An SCA soft decline is a refusal, so there is normally no approved authorization sitting open to void, but store the original attempt reference so the recovered charge can be reconciled back to it.
2. Send the re-attempt under an idempotency key. Stripe stores the first response per key and replays it, prunes keys after roughly 24 hours, and returns an error if the replayed parameters differ, which is the mechanism that prevents a duplicate charge.
3. Re-attempt through EMV 3DS with challenge indicator 04 (SCA mandated) rather than resending the same authorization message. Checkout.com's documented sequence is soft decline, authenticate with indicator 04, then a new authorization carrying the 3DS data.
4. Do not design a 3DS1 fallback. Stripe's documentation now cautions that the major card brands no longer support 3D Secure 1, and EMV 3DS 2.1.0 was sunset across the networks in September 2024, so current retries run on 2.2.0 or later.
5. Carry ECI and CAVV/AAV into the new authorization. Dropping them is a common integration error: without them you cannot demonstrate that authentication occurred, and liability reverts to the merchant.
6. Authorize inside the authentication window. A CAVV carries fraud liability protection for 90 days from creation, and an ECI 05/06 authorization submitted without the CAVV is reclassified to ECI 07, where liability shift does not apply.
7. Watch for the issuer's own duplicate detection. There is a distinct decline code for a near-identical amount and card submitted very recently, and the prescribed action is to look for an existing payment rather than retry again.

Two settings shape the outcome before you send anything. Stripe's request_three_d_secure parameter lets you bias toward a frictionless flow or force a challenge. The issuer determines the final flow, so "attempt frictionless first" is a preference rather than a fixed behaviour. If you are still reasoning about protocol versions, our comparison of 3DS1 vs 3DS2 explains why the old fallback path is gone. For the wider sequencing context, see our overview of payment retry strategies.

Why can't you retry a recurring rebill with 3DS, and how do you convert it into a customer-initiated re-authentication?

You cannot serve a challenge to a cardholder who is not there. On a merchant-initiated rebill the Directory Server forbids the issuer from returning a challenge. Off-session payments do not support 3DS. Recovery means converting the rebill into a customer-initiated re-authentication.

The mechanics are unambiguous. Merchant-initiated 3DS is flagged with deviceChannel 03. That flag tells the ACS (the access control server, the issuer's authentication service) there is no interactive challenge surface. If an issuer attempts a challenge anyway, the Directory Server converts the result into a failed authentication (transStatus N with transStatusReason 87). Visa's own guidance for that outcome is a sequencing decision, not a 3DS fix. Go straight to authorization, or bring the cardholder back and resend the transaction with them present.

A sanctioned out-of-session path exists, and its limits matter. 3DS Requestor-Initiated authentication (3RI) is available from EMV 3DS v2.2 onward. It lets you generate authentication data without the customer being involved. You must carry the DS (directory server) and/or ACS Transaction ID from the original authenticated sign-up and set 3RI Indicator 01 for recurring. 3RI is asynchronous by design: authentication completes first, authorization follows. When the ACS decides it needs the cardholder anyway, its only route is decoupled, out-of-band authentication. 3RI support depends on the card and issuer country, so it cannot be your only plan.

Cost sits on the other side of that ledger. The U.S. Payments Forum names two costs. Out-of-band authentication lengthens overall transaction time and requires complex, costly changes to payment systems. Cardholders who see an authentication prompt for a payment they did not initiate can read it as fraud on their card. The offsetting benefit is real but partial: a successful 3RI authentication typically shifts fraud-chargeback liability to the issuer for some reason codes, not for all of them.

The root cause is usually upstream of the decline

Under EU law, merchant-initiated rebills sit outside the scope of SCA (strong customer authentication). Payee-initiated transactions under a standing mandate fall outside SCA where no specific payer action triggers them. The EBA (European Banking Authority) is equally clear that the exclusion fails without a genuine mandate. Visa anchors the out-of-scope status to an authenticated initial CIT (customer-initiated transaction), which can be a zero-value transaction. An authentication demand on an established rebill therefore signals that the mandate chain broke somewhere.

• The sign-up was never authenticated, so the MIT claim was not defensible. The Banque de France recommended French issuers decline merchant-initiated transactions set up without strong authentication.
• The transaction is not being flagged as an MIT. Visa's rules say issuers should not return an SCA decline code on an out-of-scope transaction, so a 1A on a rebill often means the credential-on-file data is wrong.
• The mandate changed. A new card or a plan upgrade triggers SCA again, which is a common hidden cause of an authentication demand on a subscription that had been billing cleanly.
• Chaining references are missing. In France, MITs without a proper chaining reference hit velocity limits and trigger authentication requirements.
• The stack cannot see the code. Recurly's 3DS-specific dunning works only where the gateway returns a 3DS-specific decline message, and it names Adyen, Worldpay and Stripe.

These declines also fall out of your normal dunning cohort. Stripe lists authentication_required among the codes Smart Retries will not automatically retry. Scheduled retries keep incrementing but do not execute until a new payment method arrives. A subscription that failed on 3DS sits waiting for authentication rather than failing outright. Chargebee likewise treats a 3DS authentication failure as requiring customer intervention and does not retry it. A default schedule of eight tries over two weeks can burn its entire ladder without sending a single authorization.

The working recovery is a dunning conversion. Mark the renewal invoice past due and fire a 3DS-specific email. Land the cardholder on a hosted page whose only job is to put them back in session, so the issuer's challenge can render. Recurly productises exactly this. Chargebee's dunning emails carry a Pay Now button to a hosted page, where the 3DS window appears after the customer selects the invoice. Adyen states the step plainly for the recurring case: bring the cardholder back to authenticate, using Pay By Link over email. Visa's own definition explains why this works. A transaction can only be an MIT (merchant-initiated transaction) if the cardholder is unavailable to initiate or authenticate. The moment you get the cardholder back, the payment is a customer-initiated transaction and a challenge is available again.

How do SCA exemptions (TRA, low value, trusted beneficiary, delegated authentication) change whether you should challenge at all?

Exemptions change the order of your attempts, not the outcome you can count on. TRA (transaction risk analysis) and low value are requests the issuer can refuse. A granted exemption costs you the liability shift. Trusted beneficiary and delegated authentication reduce future challenges. Neither is something a merchant can simply apply at authorization time.

The ladder itself is fixed by the SCA-RTS, the EU technical standards that bind each payment service provider (PSP). TRA thresholds are gated on the PSP's own fraud rate: EUR 500 requires 0.01%, EUR 250 requires 0.06%, and EUR 100 requires 0.13%. Above EUR 500 there is no TRA exemption. Low value caps at EUR 30 per transaction. It also requires cumulative value since the last SCA under EUR 100, or no more than five consecutive remote transactions. Eligibility is recalculated on a rolling 90-day basis. A PSP must stop using TRA in a band once its fraud rate exceeds the reference rate for two consecutive quarters.

• Sequence TRA ahead of low value on most traffic. Visa advises that PSPs generally claim TRA rather than low value, because an acquirer claiming low value is blind to the issuer's cumulative counters and the transaction will simply have to be resubmitted via 3DS if a limit is breached.
• Treat exemption choice as a single bet per attempt. You can claim one exemption per request, and whatever you claim in authentication must be mirrored in authorization, so exemptions do not stack.
• Remember that only the claiming PSP needs to be inside the reference fraud rate, which is why the same rebill can be exempted by one issuer and soft-declined by another.
• Price the liability you keep. An exempted authorization carries ECI 07, and under Visa Rules fraud liability protection does not apply. A CAVV with ECI 05 or 06 is what carries protection.
• Do not try to solve a soft-declined rebill by re-sending it with an exemption flag. Visa states exemptions can only be applied to customer-initiated transactions.
• Ask for trusted-beneficiary listing during the re-authentication you already brought the customer into, by setting threeDSRequestorChallengeInd 09. The issuer can still step up later if it suspects fraud, but this is the one lever that reduces future challenges structurally.

Two structural notes stop teams over-rotating on exemptions. First, the schemes disagree. Mastercard treats recurring and MIT as an exemption you can signal. Visa treats the same scenario as out of scope of PSD2 (the EU's second Payment Services Directive) and provides no recurring indicator. The correct flag for the same rebill therefore differs by brand. Second, exemption claiming is now mainstream and getting harder. Ravelin's 2026 data has 78% of merchants requesting exemptions while issuers reject them more often. That combination is precisely how authentication-required responses are generated.

There is a measurable price to choosing exemptions over authentication. In 2024, EEA (European Economic Area) card transactions without SCA carried fraud rates twice as high as SCA-authenticated ones in both value and volume. Fraud rates for remote card payments without SCA ranged from 0.01% to 0.17% of value, against an overall card fraud rate of 0.033%. Delegated authentication is the emerging middle path. The merchant or acquirer executes SCA before the ACS sees it, and Stripe cites 7% higher conversion and 4x faster authentication in one deployment. Under the agreed PSR (Payment Services Regulation), delegating SCA is formally outsourcing and the delegating PSP retains liability.

What should retry timing, scheme limits and the customer message look like after a 3DS-triggered decline?

The issuer and the schemes dictate retry cadence after a 3DS decline, not your dunning calendar. Mastercard publishes timed advice codes running from one hour to ten days. Visa caps reattempts inside a 30-day window. The customer message has to explain a bank verification step rather than a failed card.

Note: acquirer guidance is that these fees are avoidable by reading the response message before re-attempting, which is the whole argument for treating the decline text as an instruction.

Depth matters as much as timing. Stripe recommends a maximum of eight retries on a charge that permits them. Stripe warns that extra attempts can look like fraud to issuers and depress approval rates on legitimate charges. Repeated failed attempts on non-retryable declines also raise your fraud score and change how issuers score future transactions. That is the mechanism by which an aggressive retry policy damages traffic it was not aimed at.

What to say to the customer

The message is not a dunning email about a failed card. The cardholder's bank asked for a verification step. If you say "payment failed", you invite a cancellation instead of a click. The Forum's warning is specific: customers are not accustomed to unprompted issuer prompts. They can read those prompts as fraud on their card. They can also end up confused about the outcome, because processing takes time. Name the bank, name the action, and land them somewhere that renders the challenge.

• Split authentication-required declines out of the generic failed-payment cohort before you write any retry rule.
• Read the advice code, not just the decline code: do_not_try_again means stop for that transaction, try_again_later means the authorization can be re-presented.
• Follow Mastercard's timed advice codes (1 hour through 10 days) rather than a fixed internal cadence.
• Cap retry depth. Stripe recommends a maximum of eight attempts and notes that more can depress approval odds on legitimate charges.
• Exclude wallet payments from 3DS retry logic, since Stripe names wallets among the transaction types that do not support 3DS.
• Send a 3DS-specific email that names the bank verification step, and hold the hosted re-authentication link open long enough for a challenge: SCA rules allow at least five minutes for completion.
• Set a decoupled max time you can live with. The spec permits up to 10080 minutes (seven days), which is usually longer than a rebill should sit unresolved.
• Log every attempt with scheme, raw code, advice code and whether authentication data was attached, so the cohort is reconstructable later.

How do you measure whether your 3DS retries are recovering revenue or quietly destroying it?

Measure a 3DS retry as a net figure. Start with recovered rebill revenue plus avoided fraud liability. Subtract challenge abandonment, per-authentication fees, and the subscribers who cancel after an unexpected bank prompt. Cohort recovered rebills against abandoned ones by issuer and corridor, because the base rates differ enormously.

The cost side is quantifiable. Frictionless rates commonly run 80% to 85% for merchants sending complete 3DS data. Abandonment among customers who are actually challenged typically runs 10% to 15%. Other vendor estimates stretch to 30%, depending on implementation quality, bank familiarity and device. Authentication itself is not free. Visa and Mastercard each charge per 3D Secure authentication request as non-transactional scheme fees in Europe and GB. Clover publishes a merchant price of 4 cents per transaction.

The base rate is also moving in the wrong direction. Ravelin's 2026 report puts frictionless authentication at 54% in North America, 62% in Europe and 58% globally. Rates are declining or plateauing in 28 of the 37 countries tracked. More exemption denials plus fewer frictionless outcomes push more of your retries into a challenge that an out-of-session rebill customer cannot see.

Two measurement traps are worth naming. First, the denominator. Baremetrics argues the honest metric is attempted recovery rate: recovered divided by recovery attempts. A naive recovery rate contaminates the denominator with failures the system never tried to recover. Across 119 US B2B SaaS companies in May 2026, the median attempted recovery rate was 12.7%. That sits against about 9% of MRR (monthly recurring revenue) lost to failed payments. Second, attempt-level metrics mislead. After Japan's April 2025 3DS mandate, gross per-attempt success fell about 1.6 percentage points. Net success across the whole purchase order fell only about 0.8 points, because shoppers retried and succeeded.

On the benefit side, count what you can actually attribute. A successful 3RI authentication typically shifts fraud-chargeback liability to the issuer for some reason codes. Stripe's own measurement in SCA regions reported a 1.20% conversion uplift alongside a 7.67% reduction in fraud. There is also a floor you cannot fall below without consequence. Under Mastercard's Excessive Fraud Merchant program, EU merchants are non-compliant below 50% of transactions authenticated with 3DS. US and Canada merchants are non-compliant below 10%. Switching authentication off to protect conversion is not a free option.

One reconciliation detail matters. Some gateways block retries on your behalf specifically to avoid network penalty fees, so your internal attempt counts and your acquirer's can diverge. If your retry budget looks healthy in your own logs and your acquirer's fee line says otherwise, check that gap first.

Frequently Asked Questions

What does 'retry with 3DS' mean on a declined payment?

It means the issuer declined the authorization only because authentication was missing, and it will consider the payment again if you re-present it with 3D Secure data attached. Adyen documents the equivalent refusal reason as an instruction to resubmit with 3DS rather than as a refusal of the card itself.

Is a 3DS-required decline a soft decline or a hard decline?

It is a soft decline. Adyen classifies the authentication-required response as a soft decline caused by the issuer mandating SCA, and Visa places code 1A in its data-quality category rather than in the bucket it will not approve. The card is usable; the submission is incomplete.

Which decline codes mean I should retry with 3D Secure?

Visa 1A, Mastercard 65, Amex 130, Diners 103 and Dankort 132 all carry the authentication-required instruction. On platform codes, look for Checkout.com 20154, Solidgate 2.15, Braintree 2099 and Stripe's authentication_required. Map by scheme, because 65 on Visa means exceeds withdrawal frequency instead.

How many times can I retry a soft-declined transaction before schemes fine me?

Under the Visa Core Rules edition dated 18 April 2026, Category 2, 3 and 4 declines allow up to 20 attempts in 30 days, and Category 1 permits none. Mastercard charges a compliance integrity fee once ten unsuccessful attempts hit the same card within 24 hours. Stripe separately recommends capping at eight.

Can you retry a recurring or merchant-initiated payment with 3DS?

Not directly, because no cardholder is in session to answer a challenge. The Directory Server does not permit an issuer to challenge a merchant-initiated authentication, and off-session payments do not support 3DS. Your options are a 3RI authentication where supported, or converting the rebill into a customer-initiated re-authentication through dunning.

Do SCA exemptions let me avoid retrying with 3D Secure?

Sometimes, but exemptions are requests the issuer can refuse, and a rejected exemption is what produces the soft decline in the first place. A granted exemption also carries ECI 07, so fraud liability protection does not apply. Exemptions typically reduce challenge volume rather than removing the need for a recovery path.