What is a Merchant Initiated Transaction?

‍

Let’s talk about Merchant Initiated Transactions (MITs). If you run subscriptions, delayed charges, usage-based billing, or anything that bills a customer when they are not actively clicking a button, you’re already living in the world of merchant-initiated transactions.

Regulatory scrutiny around merchant-initiated transactions has increased significantly under PSD2.

PSD2 tightened the rules, card networks clarified the definitions, and banks got far more opinionated about when authentication is required and when it is not. Merchant-initiated transactions now sit right at the intersection of compliance, customer experience, and operational sanity. 

Let’s make sure you understand how MITs actually work, and where automation inside a managed vault fits so that it becomes less academic and more survival skill. Because, if you’re here, you’ll probably need it. 

What is PSD2?

Quick detour: PSD2, or the Second Payment Services Directive, is a European regulation designed to make electronic payments more secure, more competitive, and more transparent. It governs how payment service providers handle authentication, access to accounts, and customer data across the EU.

For merchants, PSD2 is best known for introducing Strong Customer Authentication (SCA) requirements and clearly defining when authentication is required, when exemptions apply, and how stored credentials can be used for future payments. It places responsibility on merchants and their partners to prove customer consent, apply the correct transaction indicators, and securely manage payment credentials throughout their lifecycle.

In practice, PSD2 turned payment compliance into an operational discipline. How you store credentials, how you flag transactions, and how consistently those rules are applied now directly affect approval rates, customer experience, and regulatory exposure.

Now we have the background, let’s continue. 

‍

What is a merchant-initiated transaction?

A merchant-initiated transaction is a payment that a merchant submits using previously stored customer credentials, without the customer being present or actively authenticating at the moment of the charge.

These transactions are commonly used for subscriptions, installment payments, delayed charges, no-show fees, and usage-based billing. What matters isn’t how the billing works. It’s that the customer isn’t present when the transaction is authorized.

Under PSD2, merchant-initiated transactions get treated differently from customer-initiated transactions because they’re considered a continuation of an agreement the customer has already approved. That distinction is what allows MITs to qualify for SCA exemptions when handled correctly.

Note: The phrase “handled correctly” does a lot of work here. Let’s find out why. 

How merchant-initiated transactions fit into PSD2 compliance

MIT PSD2 guidance is clear on one thing: an MIT is only exempt from SCA if it can be linked back to an initial customer-authenticated transaction.

That initial transaction must include SCA and explicit customer consent for future charges. That means the first transaction matters more than most teams realize.

PSD2 merchant initiated transactions are allowed to bypass SCA only when all of the following are true:

1. The customer authenticated the original transaction using SCA.
2. The customer agreed to future charges as part of that initial flow.
3. Subsequent transactions are correctly flagged as merchant-initiated.
4. Stored credentials are managed securely and consistently.

If even one of those breaks down, issuers are within their rights to challenge the transaction, request step-up authentication, or decline it outright. The European Central Bank has repeatedly emphasized that poor credential management is one of the most common causes of failed SCA exemptions.

This is where the theory of MITs starts to clash with the reality of the scale of your transaction information. 

Merchant-initiated authentication is about what happened before, not during

Let’s deal with a common misconception about MITs. 

There’s no such thing as authenticating an MIT in the moment. Authentication happens earlier. The MIT inherits its legitimacy from the original, customer-initiated transaction.

That inheritance chain is fragile if you manage credentials loosely. If the link between the initial SCA-approved transaction and future charges cannot be demonstrated cleanly, issuers treat the transaction as higher risk. In 2024, European issuers increased scrutiny on stored credential transactions after finding inconsistent MIT indicators across gateways and processors.

The lesson is simple: MIT compliance isn’t just a switch you flip at authorization time. It’s a lifecycle problem.

Why automating merchant-initiated transactions changes the math

Like everything else, manually managing MITs works right up until it doesn’t. The breaking point usually shows up as a combination of soft declines, surprise authentication challenges, and support tickets asking why a perfectly valid subscription failed. It’s a drag. 

Automating MITs through a managed vault changes three things at once.

Firstly, it centralizes credential storage and lifecycle management. Payment methods stay current through automated updates, network tokenization, and expiration handling. That alone reduces issuer friction and improves approval rates.

Secondly, it enforces consistency. MIT indicators, transaction flags, and credential references are applied the same way every time, regardless of gateway or processor. Consistency is what issuers reward.

Finally, it reduces human error. Compliance failures around MITs are rarely malicious. They are usually the result of manual exceptions, one-off logic, or historical baggage that nobody remembers implementing.

A managed vault turns MITs from a brittle workflow into a repeatable system.

Where a managed vault fits in MIT compliance

A managed vault is not just a place to store card numbers. It’s an active system that governs how stored credentials are used, updated, and presented to the network.

In the context of merchant-initiated transactions, the vault becomes the source of truth for:

1. Linking initial customer authentication to future charges
2. Maintaining network tokens and updated credentials
3. Applying correct MIT indicators across processors
4. Supporting auditability for PSD2 compliance

Spreedly’s vault is PSP-independent and actively managed, which matters more than it sounds. When credentials live outside a single processor, merchants retain control over how MITs are executed even as providers change. That portability reduces compliance risk during migrations and expansions.

From a regulatory perspective, this aligns with PSD2’s emphasis on traceability and secure credential handling rather than processor-specific implementations.

Merchant-initiated vs. processor-initiated transactions

This is where confusion tends to creep in, so it is worth slowing down.

A merchant-initiated transaction is initiated by the merchant, based on an agreement with the customer, using stored credentials.

A processor-initiated transaction is initiated by a payment processor or acquirer, often as part of internal processes such as account updates, retries, or network-driven actions.

Processor initiated meaning matters because it changes who is accountable for the transaction logic. Processor-initiated transactions do not replace MITs. They complement them.

The risk appears when merchants rely on processor-initiated behavior to paper over poor MIT hygiene. Issuers can tell the difference. In 2025, both Visa and Mastercard reiterated that MIT indicators must be merchant-driven and accurate, regardless of processor automation.

Processors can lend a hand, but they can’t carry a strategy that isn’t built to hold the weight.

Why MITs break first when compliance gets sloppy

There is an old saying in payments that edge cases fail first. Merchant-initiated transactions live permanently on the edge.

Merchant-initiated transactions tend to surface problems earlier than other payment flows because customers aren’t present, authentication happened in the past, and consent has to be inferred rather than confirmed in the moment. That combination puts more weight on how credentials are stored, flagged, and reused over time, which is why issuers often focus on MITs first when regulatory expectations change under frameworks like PSD2.

Teams that treat MITs as a checkbox tend to accumulate hidden risk. Teams that treat MITs as a system invest in automation, auditability, and vault hygiene. One of those approaches scales. The other produces late-night incident calls.

Where this leaves you

Merchant-initiated transactions have become a normal part of how businesses charge customers, especially as subscriptions and flexible billing models continue to grow. Because these payments happen without the customer present, everything depends on how well credentials and consent were handled earlier.

PSD2 makes that expectation explicit. When authentication is done properly up front and repeat charges follow clear, consistent rules, merchant-initiated payments tend to run smoothly.

A managed vault helps keep that foundation solid by maintaining payment credentials over time and applying the same compliance logic every time a transaction runs. Treating the vault as core infrastructure, rather than simple storage, makes it much easier to scale merchant-initiated transactions without adding risk or manual work.

‍

Book a demo to see how a Spreedly’s open payments platform can support your business today.

Download the Payments Orchestration eBook Below