SCA Recurring Payments: Exemptions, Triggers, and Soft Declines

Under Strong Customer Authentication rules, recurring payments only need full two-factor verification once, when the customer first sets up the payment series. After that initial authenticated payment, subsequent charges in the series can process automatically without the customer verifying again, provided the merchant sets the mandate up correctly and flags each later charge with the right data. SCA comes from the European Union’s revised Payment Services Directive (PSD2), which applies across the European Economic Area and, in a closely mirrored form, the United Kingdom.1European Commission. Strong Customer Authentication Requirement of PSD2 Comes Into Force If you bill cardholders whose banks sit in those regions, the rules apply to you whether or not your business is based there.

What SCA Requires at the First Payment

SCA is a two-factor check. The issuing bank must confirm the customer’s identity using at least two of three categories: something the customer knows (a password or PIN), something the customer has (a phone receiving a one-time code), and something the customer is (a fingerprint or facial scan).2European Banking Authority. Independence of the Elements for SCA The two elements must come from different categories, and a breach of one cannot compromise the other.

In practice, the checkout runs through 3D Secure 2 (3DS2). The card network routes the transaction to the issuing bank’s authentication system, and the customer approves a push notification in their banking app, enters a one-time SMS code, or uses biometrics. That flow happens on the first payment of any recurring series. Whether it needs to happen again on later charges is what the rest of this article is about.

The Fixed-Amount Recurring Exemption

The regulatory technical standards carve out a specific exemption for fixed-amount recurring payments. SCA must be applied when a customer first creates or initiates a series of recurring transactions with the same amount and the same payee.3FCA. Chapter 3 Exemptions From Strong Customer Authentication After that first authenticated payment, every subsequent charge in the series can process without further customer verification.

The exemption hinges on two words: same amount. A €9.99 monthly streaming subscription qualifies cleanly because every charge is identical. A utility bill that changes month to month does not, because the amount varies. If the customer later amends the series, such as accepting a price increase, that amendment triggers a fresh SCA check, and the exemption resumes for future charges at the new amount.4European Banking Authority. 2018_4048 Applicability of Strong Customer Authentication (SCA) to Recurring Transactions

Variable Amounts and Merchant-Initiated Transactions

Charges that fluctuate — utilities, usage-based software, metered cloud services — rely on a different mechanism: classification as a merchant-initiated transaction (MIT). An MIT is a payment the merchant triggers based on a prior agreement, without the customer being actively involved at the time of the charge. Because the customer isn’t present to authenticate, MITs fall outside the scope of SCA entirely, provided the initial agreement was properly set up with full authentication.5European Banking Authority. Merchant Initiated Transactions Exemption for Hotel Transactions

The initial customer-initiated transaction that establishes the mandate must go through 3DS2 with a cardholder challenge. During that first payment, you flag the transaction as the beginning of a recurring or credential-on-file relationship. The card scheme returns a unique reference identifier that links all future charges back to that authenticated session. Every later MIT must include that reference, plus data fields marking the transaction as merchant-initiated and part of an ongoing sequence.

Getting those flags wrong is one of the most common reasons recurring charges get declined. If you send a subsequent charge without the correct credential-on-file indicators or scheme reference data, the issuing bank has no way to connect it to the original authenticated mandate. It sees an unauthenticated payment with no SCA data, and declines it.

Setting Up the First Payment Correctly

The first transaction is where the legal and technical groundwork gets laid. Several things need to happen at once during that initial checkout:

  • The customer must clearly consent to recurring billing, including the frequency, the amount or the way a variable amount will be calculated, and the duration of the arrangement.
  • The payment must go through a full 3D Secure 2 challenge so the issuing bank can verify the cardholder’s identity with two-factor authentication.
  • The authorization request must carry metadata indicating this is the first in a recurring series, not a one-off purchase.
  • The billing terms must be disclosed before the customer authenticates, not after. If the bank later determines the cardholder wasn’t properly informed, subsequent MITs can be rejected or disputed.

Once authentication succeeds, the payment gateway returns a token and the card scheme provides a reference identifier. Those two pieces of data are what make future billing possible without re-authentication. Store them securely and include them in every subsequent charge request. Lose them, or mishandle them, and the mandate has to be set up again from scratch with the customer.

When Re-Authentication Gets Triggered Again

Even with a properly established mandate, certain events push the customer back through SCA. A change to the recurring amount is the clearest one. Amending a recurring series requires fresh authentication under the technical standards, so a subscription price increase means the customer needs to authenticate again before the new amount can bill.

Card expiration and replacement create their own friction. When a cardholder’s card is reissued with a new number or expiry date, the stored credentials linking back to the original mandate may no longer match. Card networks offer account updater services that refresh stored card details behind the scenes when a replacement is issued, and in many cases the merchant’s token remains valid without the customer doing anything. If the update fails, or the card was reported stolen rather than simply expiring, you’ll need the customer to authenticate again and establish a new mandate.

Issuers can also require a challenge on any individual recurring charge if their fraud monitoring detects unusual patterns: a sudden spike in charge amounts, a change in transaction metadata, or inconsistencies in the credential-on-file data. This is uncommon on well-established recurring relationships, but worth having a contingency flow for.

Handling Soft Declines

A soft decline is the issuing bank’s way of saying the transaction needs authentication but none was provided. When you submit a charge without SCA data, or request an exemption the bank doesn’t accept, the bank returns a soft decline rather than a permanent rejection. The standard response codes for this are 65 and 1A across major card schemes.

Recovery is straightforward in concept. On receiving a soft decline, route the customer back through a 3DS2 challenge, then re-submit the transaction with the SCA data included. Only at that point does the bank run its remaining checks, such as available funds, before issuing a final approval or hard decline.

For recurring payments, soft declines most commonly hit the first charge after a mandate is set up, usually because the recurring flag wasn’t properly included or the scheme reference data is missing. They can also happen when a long gap between charges leads the issuer to question whether the mandate is still valid. Without automated soft-decline handling in your payment flow, those transactions are just lost, so most payment processors now offer retry logic that escalates to 3DS2 when a soft decline comes back.

Other Exemptions That Affect Recurring Models

Low-Value Transactions

Individual transactions below €30 can process without SCA. The exemption has built-in safety limits: the bank must require authentication after five consecutive unchallenged low-value transactions on the same card, or once the cumulative total of unchallenged transactions exceeds €100. For very small recurring charges, SCA will periodically be triggered even when every individual charge sits under the threshold.

Transaction Risk Analysis

Acquirers and issuers can request an exemption based on their real-time fraud analysis. The maximum transaction value eligible depends on the payment service provider’s overall fraud rate: up to €100 if the fraud rate is below 0.13%, up to €250 if below 0.06%, and up to €500 if below 0.01%. Any transaction above €500 always requires SCA. Payment providers must recalculate and report their fraud rates every 90 days.

Trusted Beneficiaries

Customers can add a merchant to a trusted beneficiaries list maintained by their bank. Once you’re on that list, future payments to you skip SCA. Adding a merchant to the list itself requires authentication, and the bank must use at least one new authentication element beyond what was used for the payment that triggered the whitelisting.6European Banking Authority. 2023_6827 Trusted Beneficiaries Not all banks have implemented this feature, so it isn’t a reliable primary strategy.

Merchants Outside the EEA and the UK Position

Merchants based outside the EEA who bill customers with EEA-based bank cards sit in a nuanced position. PSD2 technically applies to the parts of a transaction carried out within the EU, even when only one party is located there. For card payments where the merchant’s acquiring bank is outside the EU, the acquirer isn’t subject to PSD2, but the customer’s issuing bank still is. The issuer must decide whether to apply SCA or accept liability for any unauthorized transactions under PSD2’s consumer protection rules.7European Banking Authority. 2018_4233 Is the Scope of the RTS on Strong Customer Authentication In practice, many EEA issuers apply SCA challenges to these one-leg-out transactions anyway, especially at higher values. Non-EEA merchants who don’t support 3DS2 see higher decline rates on European cards as a result.

The UK retained SCA requirements after leaving the EU. The Financial Conduct Authority adopted its own version of the regulatory technical standards, which are substantively the same as the EU version.8FCA. PS19/26 Brexit Regulatory Technical Standards for Strong Customer Authentication If you serve both EEA and UK cardholders, you can treat the two frameworks as functionally equivalent for recurring payment purposes. The same mandate setup, MIT flagging, and exemption categories apply. The UK versions use sterling equivalents for a few thresholds, such as a £45 contactless limit against the EU’s €50, but the underlying logic is identical.