Merchant-initiated transactions under PSD2 are card payments a business triggers on its own after the customer has set up a mandate, and they sit outside the scope of Strong Customer Authentication rather than qualifying for an exemption from it. That distinction drives every practical decision you make: how you authenticate the first charge, how you flag the ones that follow, and how issuing banks decide whether to approve or decline them. Get the setup right and recurring billing runs quietly in the background. Get it wrong and your authorization rates on European cards collapse.
What Counts as a Merchant-Initiated Transaction
The European Banking Authority defines a merchant-initiated transaction as one the merchant sends to the acquirer without any action from the payer at the moment it’s processed.1European Banking Authority. Payee-Initiated Transactions With Irregular Period or Variable Amount The cardholder is off-session. They aren’t tapping a button, approving a push notification, or scanning a fingerprint. The payment travels from your system to the acquirer to the issuer with the customer nowhere in the loop.
The qualifying condition is a prior agreement. The cardholder must have authorized you, at an earlier moment, to collect funds later under defined terms. If any specific action by the cardholder triggers the charge, including a tap on an in-app approval screen, it isn’t an MIT. It’s a customer-initiated transaction and SCA applies normally.2European Banking Authority. 2018_4031 Applicability of SCA to Card Payments Initiated by the Payee
Typical cases: variable-amount subscriptions where the monthly bill depends on usage, utility billing after a consumption period closes, automatic top-ups when a transit balance drops below a threshold, scheduled installments, and hotel charges for no-shows, minibar, or damage after checkout. In each, the merchant decides when and how much to charge based on terms the cardholder has already agreed to.
Out of Scope, Not Exempt
This is the single most misunderstood point in PSD2 payment processing, and it changes how issuers evaluate your transactions. Merchant-initiated transactions are not exempt from SCA. They sit outside its scope entirely.
SCA requires the payer to authenticate using two independent factors drawn from knowledge, possession, and inherence. Since the cardholder isn’t present when an MIT fires, they physically can’t complete a challenge. The EBA’s position is that transactions initiated by the payee without any payer interaction are “not subject to strong customer authentication.”1European Banking Authority. Payee-Initiated Transactions With Irregular Period or Variable Amount
An exemption works differently. It applies to transactions that are in scope but excused from authentication under specific conditions: low-value payments under €30, successful risk analysis, trusted beneficiary whitelisting. The issuer can still choose to challenge an exempt transaction. With a properly flagged MIT, that choice doesn’t exist, because the transaction isn’t inside the SCA framework to begin with.3Visa. Out of Scope and Exempt Transactions
The out-of-scope treatment is conditional, though. It depends on you having built the mandate correctly in the first place and signaling the transaction correctly every time you charge.
The Authenticated Mandate at Setup
Every MIT series rests on a mandate: the agreement that authorizes you to collect funds later. The mandate should cover what the charges are for, how often you’ll bill, and how the amount is calculated. Specificity protects you when a dispute lands.
When the mandate is created through a remote channel like an online checkout or in-app signup, the first transaction has to go through Strong Customer Authentication. The EBA treats mandate setup as an action carrying fraud risk under Article 97(1)(c) of PSD2, so two-factor verification is required at that moment.2European Banking Authority. 2018_4031 Applicability of SCA to Card Payments Initiated by the Payee The customer might complete a biometric check, enter a one-time passcode, or approve a push notification from their bank.
That authenticated first transaction is what every later MIT is anchored to. The card schemes generate a reference ID during the SCA event, and your system has to carry it forward on every subsequent charge. Skip or botch this step and the later charges have no valid foundation. Issuers will treat them as unauthenticated card-not-present payments and decline.
Flagging MITs Correctly
Correct technical signaling is what separates a quietly processed MIT from a decline. When you submit the charge, your payment metadata has to tell the issuing bank three things: this is a merchant-initiated event, the cardholder’s credentials are stored on file, and the transaction links back to a previously authenticated mandate.
Each scheme defines the fields. Mastercard’s gateway expects the transaction source set as “MERCHANT,” the stored credential indicator set as “STORED,” and an agreement ID matching the one generated during the original authenticated customer-initiated transaction. That agreement ID is the thread connecting every subsequent MIT back to the SCA event. Additional fields cover amount variability, agreement expiry, and minimum days between payments, depending on whether the MIT is recurring, installment-based, or unscheduled.
Visa uses a similar structure through its MIT Framework ID, which categorizes the charge as a standing instruction, subscription, or unscheduled credential-on-file payment. The 3D Secure protocol can carry this information during initial authentication, and your gateway’s API passes it along with each later charge.
Without these flags, the issuer sees an unauthenticated card-not-present transaction with no context. It has no way to verify a valid mandate exists, and the rational response is to decline. If authorization rates on your recurring charges have slipped without an obvious reason, your MIT flagging is the first place to look. The EBA’s fraud-reporting framework gives MITs their own category, so issuers are tracking these transactions separately and expect them to arrive properly identified.4European Banking Authority. 2019_4866 Reporting of Card Transactions That Are Out-of-Scope
When a Fixed-Amount Recurring Payment Is Simpler
If you bill the same amount on the same schedule every month, you may not need to flag your transactions as MITs at all. Fixed-amount recurring payments can use the recurring transaction exemption. SCA runs on the first payment, and subsequent charges for the same amount to the same merchant can be exempted.
The practical difference between that path and the MIT path: an exemption leaves the issuer free to step up and challenge if it wants to. A properly flagged out-of-scope MIT doesn’t give the issuer that option. Variable-amount subscriptions, usage-based billing, and any scenario where the charge isn’t known upfront are the natural territory for MITs. Truly fixed pricing is usually better served by the recurring exemption.
Handling Soft Declines
Even with correct flagging, you’ll occasionally see a soft decline, often response code 1A, meaning the issuer wants additional customer authentication before approving. This tends to happen when the original mandate’s authentication has aged out, when the issuer’s risk engine flags something unusual, or when your CIT/MIT flagging is inconsistent across a customer’s history.
Do not retry the same unauthenticated request. The same request produces the same decline. Instead, bring the customer back into the flow. Send them through a 3D Secure challenge, have them approve the payment in their banking app, or re-authenticate through whatever channel the issuer supports. Once SCA completes, the transaction can be reattempted and will go through normal authorization.
Repeated 1A codes on charges that should be valid MITs are a diagnostic signal. Usually it means the gateway isn’t passing stored credential flags correctly, the agreement ID doesn’t match the original CIT, or your 3D Secure settings are misconfigured. Fixing the root cause stops the problem from spreading across the rest of your MIT volume.
Hotels, Subscriptions, and Other Typical Cases
Hotels are one of the clearest illustrations. When a guest supplies card details during an online reservation as a guarantee, that remote-channel setup must include SCA. Later charges for no-shows, minibar, or damage can then run as merchant-initiated transactions because the guest isn’t present at billing time. The EBA has confirmed this reading directly, treating mandate-stage SCA as required and the subsequent payee-initiated charges as governed by PSD2’s general provisions for such transactions.5European Banking Authority. Merchant Initiated Transactions Exemption for Hotel Transactions
Subscription services with variable pricing rely heavily on MITs. A streaming platform with tiered plans, a cloud storage provider that bills by usage, or a meal kit service where weekly costs shift with each order all need to charge different amounts without re-authenticating the customer every time. The mandate at signup covers the ongoing relationship; each variable charge flows as an MIT.
Utility companies billing after a consumption period, insurers collecting premiums that adjust annually, and transit systems topping up a card balance when it drops below a threshold round out the standard set. Each shares the same shape: a pre-agreed authorization, an off-session customer, and a charge whose timing or amount couldn’t be fully pinned down at setup.
Non-EEA Merchants Billing EEA Cards
PSD2 doesn’t stop at the edge of the EEA. The EBA has clarified that SCA requirements extend to “one-leg” transactions, meaning payments where only one of the two payment service providers is located in the EEA. The rules apply to the parts of the transaction carried out within the EEA.6European Banking Authority. 2018_4233 Scope of the RTS on Strong Customer Authentication
If the customer’s issuing bank is in the EEA but your acquirer is outside it, the issuer still has to decide whether to apply SCA, and if it can’t technically enforce authentication it carries the liability for unauthorized payments. In practice, an issuer facing that situation often just declines.6European Banking Authority. 2018_4233 Scope of the RTS on Strong Customer Authentication
For a merchant based in the United States or elsewhere outside the EEA who bills European cardholders on a recurring basis, this creates a practical compliance obligation even without a direct legal one. Flag your MITs properly, authenticate the mandate with SCA, or EEA issuers will decline your charges. Your authorization rates on European cards will drop, customers will churn, and you’ll spend resources chasing failed payments. The law may not reach you, but the payment infrastructure enforces it anyway.
Consumer Protections for Card-Based MITs
A note on refunds, because the point is frequently misstated. The unconditional refund right under PSD2 Article 76 applies to direct debits under the SEPA framework, not to card-based merchant-initiated transactions. Conflating the two leads merchants to overestimate their exposure and consumers to overestimate their protections.
For card-based MITs, the dispute path is the scheme chargeback. If a cardholder didn’t authorize a transaction, or the amount doesn’t match the mandate’s terms, they can raise a dispute, and you’ll need to produce evidence that the charge was authorized and consistent with the agreement. PSD2’s general provisions on unauthorized transactions in Articles 73 and 74 also apply, placing liability on the payment service provider for payments the payer didn’t authorize.
The practical implication: keep detailed records of the mandate, the customer’s authentication at setup, and the calculation behind each charge. A merchant who can produce a clear mandate, a record of the authenticated first transaction, and the derivation of the billed amount is in far better shape than one leaning on a generic terms-of-service page.
What PSD3 and the Payment Services Regulation Could Change
The European Commission is replacing PSD2 with a two-part framework: a revised Payment Services Directive (PSD3) covering licensing and supervision, and a new Payment Services Regulation (PSR) covering conduct rules. Because the PSR is a regulation rather than a directive, its rules will apply directly across all EU member states without national transposition. The implementation timeline currently points to late 2027.
The most consequential proposed change for MITs is an unconditional refund right for all merchant-initiated transactions, mirroring the right that currently exists only for direct debits. Under the proposal, a consumer could request a no-questions-asked refund from their payment service provider within eight weeks of any MIT. Industry groups across Europe have pushed back, arguing it would invite fraudulent refund claims for goods and services already consumed and create dual-recovery scenarios where a customer claims both a chargeback and a refund. As of early 2026, the European Parliament’s Committee on Economic and Monetary Affairs has recommended removing the provision, but the final text hasn’t been adopted.
Other PSR changes with MIT implications include mandatory risk-based transaction monitoring for payment service providers, expanded liability for technical service providers whose systems contribute to failures or fraud, and stronger internal control requirements for transaction validation. If you rely on MITs, watch the final PSR text closely. An unconditional refund right surviving into the adopted version would reshape the economics of subscription and recurring billing across Europe.