Merchant-Initiated Transactions and SCA: When Does SCA Apply?

Merchant-Initiated Transactions, usually shortened to MITs, are an important part of modern subscription billing, utilities, insurance, mobility services, hospitality and other payment relationships where a merchant may need to collect a later payment without the customer actively initiating that specific transaction at the time it is processed.

They also create one of the most misunderstood areas of Strong Customer Authentication (SCA). A common question is whether every merchant-initiated payment must go through SCA, whether MITs are an SCA exemption, and when the customer's authentication is actually required.

Short answer: under the EU PSD2 framework, a genuine payment initiated by the payee without interaction or involvement of the payer is not subject to SCA for that later transaction. However, when the customer gives the merchant a remote mandate authorising future merchant-initiated payments, the setting up of that mandate is subject to Strong Customer Authentication.

This distinction matters because an MIT is not simply any payment made using a card stored on file. The deciding question is who actually initiates the individual transaction and whether the merchant is acting under a valid prior mandate from the customer.

What Is a Merchant-Initiated Transaction (MIT)?

A Merchant-Initiated Transaction is a payment initiated by the merchant, or payee, on the basis of a prior agreement and mandate from the customer. For a transaction to be treated as genuinely merchant-initiated in the PSD2/SCA context, the later payment must be triggered by the merchant without a specific action from the customer to initiate that individual payment.

The European Banking Authority's Q&A 2018_4031 explains that later payments can qualify as payee-initiated where the payer has given a mandate authorising the payee to initiate a transaction or series of transactions through a particular payment instrument, the mandate is based on an agreement for products or services, and the later payments do not need to be preceded by a specific action from the payer.

Utility or telecommunications billing collected under an established agreement.
Insurance premium payments collected under an agreed mandate.
Digital service or subscription charges that occur automatically under the customer's prior agreement.
Certain mobility or usage-based services where the merchant calculates and initiates a later charge.
Certain hospitality charges where a customer has previously agreed to clearly disclosed future payments.

MIT vs CIT: What Is the Difference?

Area	Customer-initiated transaction (CIT)	Merchant-initiated transaction (MIT)
Who triggers it?	Customer initiates or actively triggers the payment	Merchant initiates under prior customer permission
Customer present?	Usually on-session	Usually off-session
SCA under PSD2?	Generally in scope unless an exemption or out-of-scope rule applies	A genuine MIT is generally outside SCA when no payer interaction triggers it
Typical role in MIT setup	Often establishes the mandate and the future-use credential	Subsequent charge under the mandate
Examples	Checkout purchase, first subscription payment	Later subscription billing, agreed variable recurring charge

The relationship between the two is the whole point: the CIT is normally where the customer is authenticated and where the mandate is born. Every later MIT inherits its legitimacy from that moment - which is why a badly set-up CIT undermines everything that follows.

The Core SCA Rule for Merchant-Initiated Transactions

PSD2 requires Strong Customer Authentication when the payer accesses a payment account online, initiates an electronic payment transaction, or carries out a remote action that may imply a risk of payment fraud or other abuse. A qualifying MIT is different because the later payment is initiated by the payee rather than by the payer.

The EBA therefore distinguishes genuine payee-initiated transactions from ordinary card payments initiated by the customer through a merchant. When the customer is not involved in triggering the later payment, the individual MIT can fall outside the SCA requirement. But if the mandate authorising those future payments is created remotely, SCA applies when that mandate is established.

The arrangements that legitimately qualify are broad but specific: fixed recurring subscriptions; variable subscriptions where pricing follows agreed terms; instalment plans after the customer authorised the series; usage-based or metered billing under an agreed contract; certain delayed charges or adjustments permitted under the original agreement; and certain no-show or service-related charges the customer previously accepted, where network rules are satisfied.

Why the Initial Mandate Matters

The mandate is the customer's prior authorisation allowing the merchant to initiate later payments in accordance with the underlying agreement. It is not merely the fact that a merchant possesses card details or has stored a payment method.

For remotely created mandates, the EBA has stated that Strong Customer Authentication is required when the mandate is provided because creating that authority may itself imply a risk of payment fraud or other abuse.

In practical terms, the customer should understand and agree to the payment relationship before later merchant-initiated charges occur. A clear mandate should identify the payment relationship and the merchant or payee involved rather than relying on vague or hidden consent.

Permission is not a checkbox. Providers commonly require the agreement to cover, at minimum: the customer's permission to initiate future payments at all; whether the arrangement is one-time, recurring, scheduled or unscheduled; how the amount will be calculated or determined; cancellation and termination terms; and any further disclosures the payment network, processor or local law requires.

Original Transaction Identifiers and the CIT-to-MIT Link

Card-network processing increasingly depends on data that ties the original customer-initiated transaction to the later merchant-initiated ones. Without that link, the issuer sees a string of unexplained charges rather than a recognised payment relationship.

Visa has highlighted the Original Transaction Identifier (OTID) as the mechanism for establishing exactly that relationship. Correct linkage helps the issuer recognise the arrangement, validate that consent existed, and avoid unnecessary declines.

Practically: preserve the identifier from the initial setup and pass it with each subsequent MIT. Breaking the link is the single most common reason a legitimate recurring charge gets declined as suspected fraud.

When Does SCA Apply to an MIT Relationship?

Strong Customer Authentication is most relevant at the point where the customer establishes or actively participates in the payment relationship.

When a remote mandate is created. If a customer authorises a merchant through a remote channel to initiate future payments, the mandate setup is subject to SCA under the EBA's interpretation of PSD2.
When the customer initiates a payment. A payment does not become an MIT merely because a card is saved. If the customer actively clicks, taps, confirms or otherwise triggers the individual purchase, that transaction is payer-initiated through the merchant and is subject to the normal SCA rules unless another valid exemption applies.
When the payment relationship is changed in a way that requires new customer authorisation. Material changes should be assessed by the relevant payment service providers and merchant against the applicable mandate and SCA rules rather than being assumed to remain covered automatically.
When the transaction is not genuinely merchant-initiated. A merchant cannot simply relabel a customer-initiated transaction as an MIT to avoid authentication. Classification depends on how the transaction is actually initiated and on the prior mandate.

Are Merchant-Initiated Transactions an SCA Exemption?

The phrase “MIT exemption” is common in payment-industry discussions, but it can be misleading from a regulatory perspective.

The SCA technical standards contain formal exemptions such as certain low-value transactions, trusted beneficiaries, recurring transactions of the same amount to the same payee, secure corporate payment processes and transaction-risk analysis. Genuine payee-initiated MITs are different: EBA guidance treats them as outside the SCA requirement for the later merchant-initiated payment because the payer is not initiating that transaction.

The EBA's fraud-reporting guidance also separates merchant-initiated transactions from the regulatory SCA exemptions in Articles 11 to 18. This is why it is more accurate to describe qualifying MITs as out of scope for SCA on the later payment rather than simply calling them another exemption.

The distinction is not pedantry. Low-value payments, transaction-risk-analysis payments and trusted beneficiaries are genuine exemptions under the regulatory framework. A qualifying MIT is different in kind: Stripe describes it as technically outside the scope of SCA, and EBA guidance similarly treats payee-initiated payments without payer interaction as not subject to SCA, separating MITs from the formal exemption list in Articles 11 to 18.

How 3-D Secure Fits Into MITs

EMV 3-D Secure is normally used at the initial, customer-present step - to satisfy SCA and to establish the credential that later off-session charges will lean on. Visa's European EMV 3DS implementation guidance specifically notes that an SCA challenge should be applied when a merchant or acquirer requests it, including when setting up an MIT agreement.

The later MIT is different in kind. If it is a genuine merchant-initiated transaction under an established mandate, the customer does not normally have to return to the checkout just to complete a fresh challenge. The authentication work was already done at setup; the MIT executes under it.

MIT vs Card-on-File Payments

A stored card, token or card-on-file relationship does not automatically create a Merchant-Initiated Transaction.

If the customer returns to a website or app, selects a product and presses a purchase button, the customer has triggered that individual payment. The fact that the merchant already holds a saved payment method does not change who initiated the transaction.

The EBA specifically distinguishes these customer-triggered card-on-file payments from payee-only merchant-initiated payments. A customer-triggered card-on-file payment remains subject to the normal SCA framework.

MIT vs Recurring Payments

Merchant-Initiated Transactions and recurring-payment exemptions are related concepts, but they are not identical.

Article 14 of the EU SCA technical standards provides an exemption for subsequent recurring transactions with the same amount and the same payee after SCA has been applied when the series is created, amended or initiated for the first time.

An MIT, by contrast, is defined primarily by who initiates the later transaction and by the existence of the customer's prior mandate. Some subscription arrangements may involve merchant-initiated transactions, while other recurring arrangements may be analysed under the recurring-transaction exemption. Merchants should avoid assuming that every repeating charge belongs to the same regulatory category.

Does Every Off-Session Payment Automatically Qualify as an MIT?

No. "Off-session" describes whether the customer is present; MIT describes who initiated the payment and under what authorisation. The two are not the same axis.

A payment can be off-session and still be misconfigured, or lack a valid mandate entirely.
A customer action that directly triggers the payment can make it customer-initiated even if the final authorisation settles later.
The transaction should be flagged correctly and linked to the original customer-initiated setup wherever network rules require that relationship.
Use the processor's CIT and MIT fields and its stored-credential framework rather than inferring MIT status from timing alone.

Can the Amount of a Merchant-Initiated Transaction Vary?

A merchant-initiated payment relationship may involve fixed or variable amounts depending on the underlying agreement and the nature of the service. For example, usage-based services may not produce the same amount each billing period.

The important issue is not simply whether the amount changes. The merchant must be acting within the prior mandate and agreement, and the later payment must genuinely be initiated by the payee without a specific customer action that triggers that payment. The applicable payment service providers and card scheme rules may impose additional operational requirements.

Merchant-Initiated Transactions in Hospitality

Hospitality is one of the areas where MIT questions frequently arise because the final amount or timing of a charge may not always be known at the moment a reservation is made.

EBA Q&As addressing hotel transactions explain that when card details are taken as a guarantee and potential later payments are intended to qualify as payee-initiated transactions, SCA must be applied when the remote mandate is provided and the other conditions for a genuine payee-initiated transaction must be satisfied.

The EBA has also clarified that a mandate can, in appropriate circumstances, be provided through an intermediary acting on behalf of the merchant, provided the merchant or payee is specified and the customer understands the intermediary is acting on that payee's behalf.

Why MIT Classification Matters for Payment Security

Correctly identifying merchant-initiated and customer-initiated payments is not only a compliance issue. It also supports better payment security, clearer customer expectations and more accurate fraud monitoring.

Customers should know when a merchant has authority to collect a future payment.
Merchants should preserve clear evidence of the customer's agreement and mandate.
Payment service providers need accurate transaction context to apply authentication and risk controls correctly.
A transaction should not be classified as merchant-initiated simply because authentication would otherwise create friction.
Clear cancellation and mandate-management processes can reduce disputes and unexpected-payment complaints.

Does an MIT Get 3-D Secure Liability Shift?

Do not assume it does. The fraud-liability benefit attached to a successfully authenticated 3-D Secure customer-initiated payment does not automatically carry over to later MITs.

Stripe's current documentation is explicit that merchant-initiated transactions do not receive the 3DS liability shift in the same way as authenticated customer-initiated transactions. Merchants planning a recurring model should check their exposure per transaction flow, not assume the setup-phase authentication covers the whole series.

How Common Are MITs in Remote Card Payments?

Merchant-initiated payments are not a niche use case. In its 2025 payment-fraud report, the EBA and European Central Bank reported that MITs accounted for about 22% of remote card payments without SCA in 2024. The report also reiterated that MITs involve a previously existing mandate for which SCA is required when the mandate is granted.

That scale helps explain why merchants, payment service providers and consumers need a clear understanding of the difference between an authenticated mandate, a later merchant-initiated payment and an ordinary customer-initiated online purchase.

A Simple Merchant-Initiated Transaction Example

Imagine a customer signs up online for a service that bills automatically according to an agreed schedule or usage. During signup, the customer authorises the merchant to collect future payments and completes the required Strong Customer Authentication for that remote mandate.

Later, when the merchant initiates a qualifying payment under that existing mandate without the customer returning to the website or taking an action to trigger the individual payment, the later transaction can be treated as merchant-initiated.

If instead the customer returns to the service, selects a new purchase and presses “Pay now,” that new payment is customer-initiated even if the same stored card is used.

What If the Issuer Still Requests Authentication?

Out-of-scope treatment is not a guarantee of approval. An issuer can still decline for risk, account status or processing reasons, and off-session payments sometimes fail in a way that requires the customer to come back online and authenticate.

Build a recovery flow rather than assuming every saved-card charge will clear on its own:

Notify the customer that the payment could not be completed.
Bring the customer back on-session through a secure payment flow.
Perform authentication when required.
Update or re-establish the stored payment method where needed.
Retry only through the processor's supported workflow.

What Merchants Should Focus On

For legitimate payment operations, the safest approach is to focus on the substance of the customer relationship rather than trying to fit transactions into a preferred authentication category.

Use clear terms that explain when future charges may occur.
Obtain a genuine customer mandate for merchant-initiated payments.
Apply SCA when a remote mandate is established where required.
Keep customer-triggered purchases separate from genuine merchant-initiated charges.
Maintain accurate records of the customer's consent and the payment relationship.
Provide clear cancellation, billing and dispute-handling information.
Work with the acquiring bank or payment service provider on jurisdiction-specific and scheme-specific requirements.

Common Mistakes Merchants Make

Saving a card without clear permission for future merchant-initiated charges.
Treating every saved-card payment as an MIT even when the customer actively triggers it.
Failing to authenticate the initial remote setup when SCA requires it.
Submitting later off-session payments without the correct stored-credential or MIT indicators.
Failing to preserve the link between the original CIT and the subsequent MITs.
Assuming "out of scope" means the issuer must approve the payment.
Providing no recovery path when an off-session transaction needs authentication.

What Consumers Should Know About MITs

From the customer's perspective, an MIT should be connected to a payment relationship that was previously agreed. A consumer may not be present when the later charge is initiated, but that does not mean the merchant has unlimited authority to charge the payment method.

Consumers should review subscription and booking terms, monitor account statements and contact the merchant or payment provider if they see an unexpected charge. They should also be cautious about approving authentication prompts they did not initiate or do not understand.

Merchant-Initiated Transactions and SCA in the EU and UK

The explanation in this article is primarily based on the EU PSD2 framework, Commission Delegated Regulation (EU) 2018/389 and related EBA Q&As.

The United Kingdom also applies Strong Customer Authentication requirements under its own payment-services framework. Although the UK regime is closely related to the earlier EU framework, businesses should verify current UK-specific requirements with their payment service provider and the Financial Conduct Authority rather than assuming every EU interpretation applies identically.

Frequently Asked Questions

Does SCA apply to Merchant-Initiated Transactions?

A genuine later transaction initiated by the merchant without interaction or involvement from the payer is not subject to SCA under the EBA's PSD2 interpretation. However, if the customer creates the mandate remotely, SCA applies when that mandate is established.

Is an MIT the same as an SCA exemption?

Not technically. Formal SCA exemptions are contained in the regulatory technical standards. Qualifying payee-initiated MITs are generally treated as outside the SCA requirement for the later payment because the payer is not initiating that transaction.

Does the first merchant-initiated payment need SCA?

The key requirement is the remote setup of the mandate. Depending on the payment flow, SCA may be performed when the customer gives the mandate or during an associated customer-initiated transaction. Merchants should follow the exact process required by their payment service provider.

Is every card-on-file payment an MIT?

No. If the customer takes an action that triggers the specific purchase, such as pressing a purchase button, the payment is customer-initiated even if the card was already stored.

Are subscriptions Merchant-Initiated Transactions?

Some automatic subscription charges can be merchant-initiated where they occur under a prior mandate without a specific customer action for each payment. Other recurring-payment structures may be analysed under the separate recurring-transactions exemption.

Can an MIT have a variable amount?

Potentially, depending on the underlying mandate and service. The critical points are that the payment remains within the agreed mandate and is genuinely initiated by the payee without a specific payer action triggering that individual transaction.

Can a merchant classify a normal online purchase as MIT to avoid SCA?

No. The classification depends on how the transaction is actually initiated and on the prior mandate. A customer-triggered purchase does not become merchant-initiated merely because a merchant prefers not to request authentication.

What is the difference between an MIT and a recurring-payment exemption?

MIT status focuses on who initiates the later payment. The recurring-payment exemption in Article 14 concerns a series of same-amount payments to the same payee after SCA has been applied at the required point.

Final Thoughts

Merchant-Initiated Transactions are best understood as a payment-initiation concept, not as a shortcut around Strong Customer Authentication.

Where the customer gives a merchant a remote mandate to initiate future payments, Strong Customer Authentication is required when that mandate is established. Later qualifying payments can fall outside the SCA requirement when they are genuinely initiated by the merchant without a specific action from the customer and remain within the prior mandate.

The most important distinction is therefore not whether a card is stored, whether the payment repeats, or whether authentication would add friction. It is whether the customer or the merchant actually initiates the individual transaction and whether the merchant has valid prior authority to do so.

Authoritative References

Editorial note: This article is educational and should not be treated as legal advice. Payment rules can vary by jurisdiction and provider.

Additional sources on MIT treatment and off-session recovery:

European Banking Authority - Q&A 2019_4776: More than one transaction from a single consumer-initiated transaction
Stripe - Setup Intents API: future off-session use and MIT agreements
Stripe - Strong Customer Authentication exemptions: merchant-initiated transactions
Stripe - Strong Customer Authentication readiness and off-session payments
Visa - European EMV 3DS 2.2.0 Implementation Guide
Visa - Merchant Business News Digest: original transaction identifiers and MIT linkage