Recurring Payments and SCA

Recurring Payments and SCA: Authentication Requirements for Subscriptions

A subscription should not require the customer to authenticate every time the merchant collects a renewal.

But that does not mean recurring payments are automatically exempt from Strong Customer Authentication (SCA).

The critical distinction is how the recurring relationship is established and who initiates each later payment. Under the EU PSD2 framework, the customer may need to complete SCA when setting up the subscription or payment mandate. Later charges can receive different treatment depending on whether they form part of a qualifying fixed recurring series or are genuinely merchant-initiated transactions made under a prior mandate.

For subscription merchants, that distinction affects much more than compliance terminology. It influences checkout design, free trials, stored credentials, upgrades, usage-based billing, payment retries, and what happens when an issuer needs the customer to return and authenticate.

The practical model is:

Customer establishes payment relationship → SCA where required → merchant stores the payment relationship correctly → later qualifying charges are submitted using the correct recurring or MIT treatment

Getting that sequence right is what allows recurring payments and SCA to coexist without forcing unnecessary authentication into every renewal.

How does SCA apply to recurring payments?

There are two concepts that subscription merchants frequently collapse into one.

The recurring-transaction exemption

Article 14 of the EU Strong Customer Authentication Regulatory Technical Standards provides an exemption for a series of recurring transactions with the same amount and the same payee.

Payment service providers must apply SCA when the customer creates, amends, or initiates the series for the first time. They may then refrain from applying SCA to subsequent transactions within that qualifying series.

This is a specific SCA exemption.

Merchant-initiated transactions

A Merchant-Initiated Transaction, or MIT, is different.

Where the customer has given the merchant a valid mandate to initiate future payments, and a later payment is initiated solely by the merchant without customer interaction, European regulatory guidance allows that subsequent payment to be treated as a payee-initiated transaction.

Because Article 97 of PSD2 requires SCA when the payer initiates an electronic payment transaction, genuinely payee-initiated transactions are not subject to that SCA requirement. The EBA has expressly stated that transactions initiated solely by the payee under a qualifying mandate can fall outside SCA, provided no specific customer action triggers the individual payment.

That difference is fundamental:

Payment treatment

Why later SCA may not apply

Typical use

Recurring-payment exemption

Explicit SCA exemption for subsequent same-amount, same-payee transactions

Fixed-price recurring series

Merchant-Initiated Transaction

Later payment is initiated by the merchant rather than the payer

Subscriptions, usage billing and other off-session charges under a mandate

A subscription merchant should therefore not simply mark every renewal as “recurring = SCA exempt.”

It should understand which treatment actually applies.

[Internal link opportunity: Strong Customer Authentication Explained]

Does the first subscription payment require SCA?

For an in-scope remote subscription setup, merchants should generally design the initial customer interaction so SCA can be completed.

There are two related reasons.

First, if the customer is actively initiating an electronic payment, Article 97 of PSD2 brings that payer-initiated transaction within the SCA requirement unless an applicable exemption can legitimately be used.

Second, if the customer is setting up a mandate authorizing the merchant to make later merchant-initiated charges, European regulatory guidance states that setting up that mandate remotely is itself subject to SCA because it can create a risk of payment fraud or abuse.

For many subscription checkouts, these events happen together:

•The customer selects a subscription.

•The merchant explains the future billing arrangement.

•The customer provides a payment credential and authorizes future charges.

•SCA is performed.

•The first payment is authorized.

•The credential and payment relationship are established for future use.

This initial authenticated interaction becomes the foundation for subsequent off-session charging.

What about a free trial with no initial charge?

A zero-cost trial can still create an authentication issue if the customer is simultaneously authorizing future merchant-initiated payments.

The absence of an immediate subscription charge does not, by itself, remove the significance of establishing the remote payment mandate.

The implementation method depends on the PSP, card network, and payment integration. A provider may support authentication or card-verification flows that establish the credential and mandate before the first monetary charge.

The merchant should therefore ask its PSP a precise question:

How do we authenticate and establish the recurring payment mandate when no payment is collected at signup?

Waiting until the free trial expires to discover that the original payment relationship was not established correctly can turn a conversion strategy into a payment-recovery problem.

What happens to subsequent recurring charges?

Later charges depend on the payment model established at signup.

Fixed same-amount recurring series

Suppose a streaming service charges the same customer €15 every month.

Where this is structured as the recurring series described in Article 14, SCA applies when the payer first creates or initiates the series. Subsequent payments with the same amount and same payee can qualify for the recurring-transaction exemption.

The important limits are contained in the rule itself:

same amount + same payee + subsequent payment in the established series

The existence of a subscription label is not enough.

Merchant-initiated renewals

Alternatively, later charges may be merchant initiated.

The EBA has clarified that recurring card transactions made after an initial mandate can qualify as payee-initiated transactions where:

•the payer authorised the merchant to initiate the future payments;

•the mandate relates to an agreement for goods or services;

•the merchant—not the customer—initiates the individual later payment; and

•the later payment does not depend on a specific action by the payer to trigger it.

Under this model, the important regulatory concept is not an exemption from SCA.

It is that the subsequent payment is outside the payer-initiated SCA trigger.

That is why describing MITs as an “SCA exemption” can be misleading.

[Internal link opportunity: Merchant-Initiated Transactions and SCA]

Recurring payments and merchant-initiated transactions are not synonymous

This is probably the most important distinction for subscription-payment teams.

A transaction can occur regularly without automatically being an MIT.

And an MIT does not necessarily need to occur at perfectly regular intervals.

Consider three models.

Monthly fixed subscription

A customer agrees to pay €20 on the first of every month.

This may fit the same-amount recurring framework, and it may also be implemented through card-scheme stored-credential and merchant-initiated processing depending on the merchant's payment architecture.

Usage-based SaaS billing

A customer authorizes a SaaS provider to charge the card monthly based on usage.

The amount could be:

•€100 in January;

•€137 in February;

•€89 in March.

That does not satisfy Article 14's “same amount” condition.

But the variable amounts do not necessarily mean the customer must authenticate every month.

The EBA has clarified that subsequent payments with irregular periods or variable amounts can be treated as payee-initiated where they arise under an appropriate standing agreement and the merchant initiates them without an individual action by the payer.

Customer manually confirms every renewal

Suppose a merchant emails the customer each month and requires them to click Pay now before the payment starts.

That customer action may make the payment payer initiated rather than a genuine MIT.

The fact that the customer previously stored the card does not by itself transform a new customer-initiated purchase into a merchant-initiated transaction.

The practical test is:

Who actually triggers this individual payment?

Fixed versus variable recurring amounts

The difference between fixed and variable billing affects which SCA logic can be used.

Fixed billing

The Article 14 recurring exemption is expressly designed around a series involving:

•the same payer relationship;

•the same payee; and

•the same amount.

A fixed monthly subscription is therefore the clearest example.

Variable billing

Variable subscription payments require a different analysis.

If the customer has given a suitable mandate authorizing the merchant to initiate future variable charges, subsequent transactions can potentially be treated as merchant initiated even though their amounts differ.

The EBA has specifically recognised use cases such as utility charges and services where a basic recurring fee may be supplemented by usage-dependent amounts.

The merchant should nevertheless make the commercial mandate clear.

The customer should understand what they are authorizing, including how the amount is determined. Separate consumer-protection and card-network rules can also govern disclosure and notification requirements.

From an implementation perspective:

Fixed amount ≠ automatically MIT

and

Variable amount ≠ automatically requires SCA every time

The deciding factors include how the customer mandate was created and who initiates the subsequent payment.

What happens when the subscription amount changes?

An amount change creates different consequences depending on the treatment being used.

If the merchant relies on the Article 14 recurring exemption

Article 14 requires SCA when the payer creates, amends, or initiates for the first time the qualifying recurring series.

A merchant should therefore not assume that a fixed €20 series can simply become a €25 series while continuing indefinitely under the original recurring exemption.

A material change to the established series can require the payment setup to be treated as amended, with SCA applied accordingly.

If later payments are MITs

A valid merchant-initiated arrangement can accommodate variable payments where the mandate genuinely authorizes them and the merchant initiates the payment without new customer involvement.

That makes MIT treatment particularly relevant for:

•metered SaaS;

•telecommunications;

•utilities;

•usage-based services;

•variable monthly subscriptions; and

•other arrangements where the final amount cannot be known at signup.

But “MIT” is not a way to avoid authenticating a new customer decision.

If the customer actively upgrades the subscription, purchases an add-on, changes the plan, or otherwise initiates a new payment event, that event may need to be treated as customer initiated.

The payment team should distinguish:

merchant calculates a variable charge under an existing mandate

from

customer actively makes a new purchase or changes the agreement

Those can look similar in the billing system but have different authentication implications.

How should merchants handle upgrades and downgrades?

Subscription changes are easiest to manage when product events and payment events are not treated as the same thing automatically.

Upgrade with an immediate customer payment

Suppose a customer moves from a €20 plan to a €50 plan and agrees to pay the prorated difference immediately.

The customer is actively initiating the upgrade and associated payment.

That payment should not simply be labelled as an old recurring MIT because the merchant happens to have the card stored.

If SCA applies to the payment, the checkout should be capable of authenticating the customer.

Upgrade affecting future merchant-initiated billing

A customer might instead authorize a changed subscription today, with the new recurring price charged next month.

The merchant should determine whether that change amends a fixed recurring series and therefore requires a fresh authenticated setup, or whether the existing merchant-initiated mandate legitimately covers the new billing arrangement.

The answer depends on the mandate, transaction model, PSP implementation, and applicable rules.

Downgrade

A lower future subscription price can still constitute an amendment to a fixed recurring series.

A lower amount is not automatically irrelevant simply because it creates less financial exposure.

The regulatory question is about the structure of the payment series and authorization, not merely whether the merchant is charging more money.

What happens if a recurring payment fails?

A declined renewal is not automatically an SCA failure.

The issuer may decline a recurring or merchant-initiated charge for reasons such as:

•insufficient funds;

•expired or replaced credentials;

•account restrictions;

•issuer risk controls;

•incorrect transaction indicators;

•a stored-credential problem; or

•a requirement for renewed customer interaction.

The merchant's recovery logic needs to preserve the distinction between retrying an existing merchant-initiated payment and asking the customer to initiate a new transaction.

Automated retries

If the merchant is retrying the same legitimate off-session payment under the original mandate, the retry can remain part of the merchant-initiated payment process where applicable.

But it needs to be submitted correctly.

Card networks have their own stored-credential and MIT rules on top of PSD2. Visa, for example, requires qualifying MITs to refer back to a preceding customer interaction using transaction identifiers within its MIT framework.

Mastercard payment infrastructure similarly provides network transaction identifiers so issuers can link a subsequent payment with the payer-initiated transaction that established the payment agreement.

Those requirements are card-network and processing requirements, not the text of PSD2 itself.

Merchants normally rely on their PSP or acquirer to expose and transmit the appropriate fields.

Customer recovery

Sometimes the payment cannot be recovered off-session.

The merchant may need to bring the customer back on-session to:

•authenticate;

•update an expired card;

•provide a new payment credential;

•confirm a changed subscription;

•resolve an issuer request; or

•initiate a replacement payment.

At that point the resulting transaction can be customer initiated, and SCA may be required if it falls within scope.

That is why a good dunning system needs both:

off-session retry logic and an authenticated customer-recovery path.

Can an issuer ask the customer to authenticate again?

Yes, but the exact reason matters.

For a genuine payee-initiated MIT, there is no customer present to complete SCA during that transaction. The transaction's treatment depends on the previously established mandate and correct classification.

An issuer can nevertheless decline the payment.

The merchant may then need to bring the customer back into an authenticated flow before it can establish a new or refreshed payment relationship or take a new customer-initiated payment.

For customer-initiated transactions where a merchant attempts an SCA exemption, a different principle applies: an exemption does not guarantee a frictionless outcome. Issuers and payment service providers still have roles in deciding whether authentication is required.

Do not design subscription recovery around the assumption:

“The card is stored, so the issuer can never require the customer again.”

Stored credentials remove the need to re-enter card details. They do not permanently remove authentication from the customer lifecycle.

What should be stored from the initial transaction?

Merchants need more than a card token.

The exact technical fields depend on the PSP, acquirer, and card network, but a robust recurring-payment integration should preserve enough information to establish the relationship between the original customer-authorized interaction and later merchant-initiated transactions.

That can include:

•evidence of the customer's mandate;

•the payment credential or token;

•the authentication result where relevant;

•the initial transaction's identifiers;

•the applicable stored-credential designation;

•the recurring or MIT classification;

•the merchant/payee identity;

•billing terms;

•the basis for variable charges where applicable; and

•the status of the payment agreement.

Visa's MIT framework, for example, requires a merchant-initiated payment to refer to the customer's preceding interaction, and Visa's Network MIT Service was specifically created to help merchants and acquirers manage the original transaction identifier lifecycle.

This is where subscription billing architecture and payment architecture need to meet.

The billing system may know why $79 is due today.

The payment stack also needs to know why the merchant is entitled to initiate that card transaction and how it relates to the customer's original authorization.

Where does 3D Secure fit?

Strong Customer Authentication is the regulatory concept.

3D Secure is an authentication protocol used for card payments.

For subscription merchants, EMV 3-D Secure is particularly relevant when:

•the customer signs up;

•the initial payment is authenticated;

•the recurring mandate is established;

•a customer returns to update payment details;

•an upgrade triggers a new customer-initiated payment; or

•recovery requires the customer to authenticate again.

3D Secure is not something that should ordinarily be run as an interactive challenge during every genuine off-session MIT. The customer is not present.

The important implementation work occurs earlier: establishing the authenticated customer relationship and retaining the information needed to classify later transactions correctly.

[Internal link opportunity: 3D Secure Compliance]

Where does the EU SCA framework apply?

The rules discussed here are primarily the EU PSD2/SCA framework. They should not be described as a universal global rule for subscriptions.

For relevant two-leg transactions, EU regulatory guidance focuses on the location of the payer's and payee's payment service providers—for card payments, typically the issuer and acquirer—rather than simply the physical location of the consumer or merchant.

The UK has its own SCA framework under the Payment Services Regulations 2017 and UK technical standards following Brexit. Its current technical standards retain the recurring-transaction rule requiring SCA when a same-amount, same-payee series is created, amended, or initiated for the first time.

Businesses selling subscriptions internationally should therefore avoid assuming that one European implementation can simply be applied to every country.

Authentication requirements, network behavior, and provider implementation can vary by market.

What should subscription merchants implement?

The easiest way to prevent SCA from becoming a launch blocker is to model the recurring-payment lifecycle before building the billing integration.

•Authenticate the setup correctly

Make sure the customer can complete SCA when establishing the remote subscription and payment mandate where required.

This includes free-trial flows in which the payment authorization is established before the first charge.

•Capture a meaningful mandate

The billing agreement should clearly establish what the customer has authorized.

For variable billing, define how charges can vary rather than relying on a generic statement that the merchant may charge the card whenever it chooses.

•Distinguish CIT from MIT

Your payment system should know whether each charge is:

•a Customer-Initiated Transaction (CIT); or

•a Merchant-Initiated Transaction (MIT).

Do not make that determination from whether a card happens to be stored.

•Distinguish MIT from the recurring SCA exemption

A same-amount recurring exemption and an out-of-scope merchant-initiated payment are not the same regulatory treatment.

The PSP integration should represent the correct one.

[Internal link opportunity: SCA Exemptions]

•Preserve the payment lineage

Keep the identifiers and payment-agreement information needed by the PSP and card network to link subsequent transactions to the original customer interaction.

•Model subscription changes separately

Define what should happen for:

•upgrades;

•downgrades;

•usage charges;

•one-time add-ons;

•annual renewals;

•price increases;

•plan changes; and

•reactivations after cancellation.

Not every event should inherit the treatment of the previous recurring charge.

•Build two recovery paths

Support both:

merchant-initiated retries when appropriate

and

customer-return flows with authentication when customer participation is required.

•Test with issuers, not just your own billing logic

The fact that your API accepts an MIT or recurring flag does not mean the end-to-end transaction is being submitted correctly.

Test authentication, initial storage, subsequent payments, upgrades, declines, retries, expired cards, and reauthentication across representative issuers.

Common recurring-payment SCA mistakes

Several implementation errors repeatedly create avoidable friction.

“Recurring payments do not require SCA”

Too broad.

The initial setup can require SCA, and later treatment depends on how the transaction is initiated and structured.

“Every later payment uses the recurring-payment exemption”

Not necessarily.

Article 14 specifically addresses a same-amount, same-payee series. A properly mandated MIT is conceptually different.

“Every subscription renewal is an MIT”

Also too broad.

If the customer actively triggers the individual payment, the transaction may be customer initiated.

“Variable amounts always require monthly authentication”

Not necessarily.

Variable payments may qualify as payee initiated where the mandate appropriately authorizes them and the merchant initiates them without payer involvement.

“A stored card means the payment is merchant initiated”

False.

Stored credentials can be used for both customer-initiated and merchant-initiated payments.

“If a renewal fails, just retry it as a new card payment”

This can lose the transaction lineage and correct stored-credential treatment. Retry logic should preserve the original payment relationship and follow the relevant PSP and card-network rules.

“If the customer authenticated once, they never need to authenticate again”

A later customer-initiated purchase, material change, new mandate, payment-method update, or recovery flow can require fresh authentication.

Key takeaway

The correct SCA model for subscription payments is not:

First payment = SCA

Every later payment = exempt

It is more precise:

Customer establishes the payment relationship → authenticate the customer and mandate where required → classify each later payment according to who initiates it and what agreement authorizes it

A fixed same-amount recurring series can benefit from the specific recurring-payment exemption after the authenticated setup.

A subsequent payment initiated solely by the merchant under an appropriate mandate can instead be treated as a Merchant-Initiated Transaction and, under the EU interpretation, fall outside the payer-initiated SCA requirement.

Variable billing does not automatically destroy MIT treatment. And storing a card does not automatically create it.

For subscription businesses, the implementation therefore needs to preserve three things:

the mandate, the transaction classification, and the relationship to the original authenticated customer interaction.

Build those into the payment architecture at signup, and SCA can support subscription security without forcing customers back through authentication at every renewal.

Ignore them until the billing system is already live, and the difficult part is no longer the regulation.

It is rebuilding the subscription lifecycle around it.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

SEO & editorial guidance — not part of the article

The brief correctly identifies the highest-value search distinction: “recurring payment” is a billing description, whereas the SCA outcome depends on the initial mandate and whether the subsequent transaction is payer initiated or merchant initiated. That should remain the article's differentiating thesis.

For search, I recommend keeping the current H1 but using Recurring Payments and SCA: PSD2 Rules for Subscriptions as the SEO title. The recommended URL is /recurring-payments-sca/, with the meta description: Learn when SCA applies to subscription payments, how first and subsequent recurring charges differ, and how merchants should handle MITs, variable billing and retries.

I would add a short featured-answer callout directly below the introduction:

Do recurring payments require SCA? The customer will generally need SCA when establishing an in-scope remote recurring payment arrangement. Later payments may not require SCA if they qualify for the recurring-payment exemption or are genuine merchant-initiated transactions under a previously authenticated mandate. The correct treatment depends on how the payment was authorized and who initiates each subsequent charge.

The best internal-link architecture is Strong Customer Authentication Explained from the introductory definition, Merchant-Initiated Transactions and SCA from the MIT distinction, SCA Exemptions from Article 14, and 3D Secure Compliance from the setup/authentication section. This article should avoid going deeply into TRA and low-value exemptions because they answer different search intents.

Recommended visual assets

The first visual should be “The Subscription SCA Lifecycle.” It would show:

Customer signs up

→ SCA / mandate established

→ Credential + original transaction reference stored

→ Merchant initiates renewal

→ MIT / qualifying recurring treatment

→ Authorization

→ Successful renewal

Then create a branch from Authorization declined to:

Off-session retry → or → Customer returns → SCA → payment relationship refreshed

That single diagram would explain most of the article.

The second—and probably strongest SEO/reader graphic—should be “Recurring Exemption vs Merchant-Initiated Transaction.”

Recurring SCA exemption

Merchant-Initiated Transaction

Customer present for later payment?

Usually no

No

Initial setup authenticated?

Yes, where required

Mandate setup authenticated where required

Same amount required?

Yes under Article 14

Not necessarily

Same payee?

Yes

Merchant/payee relationship defined by mandate

Why no later SCA?

Regulatory exemption

Payee initiates transaction; outside payer-initiated SCA trigger

Good example

€20 monthly membership

Variable monthly SaaS usage charge

That is an unusually valuable visual because many commercial payment explainers incorrectly use MIT and recurring exemption as synonyms.

The third visual should be a subscription-event decision tree:

What happened?

Automatic scheduled renewal

→ Merchant initiated?

→ MIT analysis

Customer clicks “Upgrade now”

→ Customer initiated

→ SCA-capable flow

Monthly amount changes automatically under usage agreement

→ Existing mandate covers variable billing?

→ MIT analysis

Customer changes subscription terms

→ Is the existing recurring series being amended?

→ Assess fresh SCA

Payment fails

→ Can the existing MIT be retried?

→ yes: correct resubmission treatment

→ no: bring customer on-session

I would also turn the article's implementation section into a downloadable “Subscription SCA Launch Checklist” for search, sales enablement, and LinkedIn reuse. The checklist should cover mandate capture, first-payment authentication, CIT/MIT tagging, network transaction identifiers, variable billing, upgrades, retries, and authenticated recovery.

One editorial maintenance note: keep the regulatory explanation centered on the current PSD2/RTS framework rather than tying it to transient PSP API syntax. Card-network and PSP fields change more frequently than the underlying SCA distinction. Where transaction identifiers are discussed, the article correctly labels them as network/processing requirements rather than PSD2 requirements; preserving that distinction will keep the page both accurate and durable.