Merchant-initiated transactions explained: CIT vs MIT, SCA rules, and best practices

If you work with subscriptions, marketplaces, or any repeat billing model, you’ve likely seen this: a payment that should be routine fails unexpectedly. The customer didn’t cancel, the card is still valid, but the issuer either declines the charge or requests authentication that shouldn’t be needed.

In many cases, this isn’t about fraud. It’s about how the transaction is structured and communicated. At the center of this issue is the merchant-initiated transaction.

When implemented correctly, merchant-initiated transactions allow businesses to charge customers without requiring them to be present every time, while still providing issuers with enough context to recognize the payment as expected. When implemented poorly, the same transactions become ambiguous and ambiguity is one of the fastest ways to lose approvals.

This article explains not just what MIT is, but how it works across compliance, scheme rules, and performance and how to actually improve results.

What is a merchant-initiated transaction?

A merchant-initiated transaction is a payment initiated by the merchant without the customer actively participating at the moment of the charge, based on a prior agreement established during an earlier interaction.

The key idea is that an MIT is not an isolated payment. It is a continuation of a previous interaction, typically a customer-initiated transaction, where the customer:

• provided their payment details (creating a card on file),
• gave explicit consent to future charges,
• and, where required, completed authentication.

This context is essential. Without it, the issuer cannot distinguish between a legitimate follow-up charge and a potentially unauthorized transaction.

CIT vs MIT: why the distinction directly affects approvals

The difference between customer-initiated transactions (CIT) and merchant-initiated transactions (MIT) is often described in simple terms whether the customer is present or not. But in practice, the distinction is much more important.

It determines how the issuer interprets the payment.

A customer-initiated transaction happens in real time, with the customer actively confirming the payment. If needed, authentication such as 3D Secure can be applied immediately.

A merchant-initiated transaction, on the other hand, relies entirely on previously established context. The issuer must trust that the payment is part of an agreed process, not a new or unexpected charge.

This is where many systems fail. In multi-provider setups, the same payment flow can be classified differently depending on the PSP or acquirer. One provider sends the correct indicators, another does not. The issuer receives inconsistent signals and responds with friction or declines.

So the real difference between CIT and MIT is not just participation it is clarity of intent.

Why MIT is considered “low risk” and what that actually means

The term “low risk” is often used in connection with merchant-initiated transactions, but it needs to be understood correctly.

MIT is not inherently safer. It is considered lower risk in a specific context when it is implemented correctly and clearly communicated.

From a regulatory perspective, under PSD2, most customer-initiated transactions require strong customer authentication. However, qualifying merchant-initiated transactions can be treated as out of scope for SCA if they follow a properly authenticated initial transaction. This removes friction at the moment of payment.

From a scheme perspective, the stored credential framework requires merchants to clearly signal when payment details are stored and how they are reused. These signals help issuers understand that the transaction is expected.

From a behavioral perspective, MITs often follow predictable patterns recurring charges, known merchants, established relationships. This predictability makes them easier to evaluate.

But none of this guarantees approval. Issuers still decline transactions for insufficient funds, internal risk rules, or account status. “Low risk” simply means less friction when everything is done correctly.

MIT types and real-world use cases

Merchant-initiated transactions appear across a wide range of business models, and understanding their differences is key to implementing them correctly.

Recurring payments are the most straightforward example. These include subscription renewals with fixed intervals. They are predictable and generally perform well when set up correctly, but even small inconsistencies in signaling can lead to declines.

Unscheduled payments are more complex. These are charges where timing or amount is not fixed in advance, such as usage-based billing. In these cases, clear consent and accurate signaling are critical, because the issuer cannot rely on a predictable pattern.

Delayed charges and no-show fees are common in travel and hospitality. Here, the transaction may happen long after the initial interaction, which makes transparency and clearly documented agreement especially important.

Reattempts and resubmissions also fall into the MIT category when they are linked to a prior agreement. However, they require careful handling. Poorly designed retry strategies can create negative signals instead of improving outcomes.

Across all these scenarios, the core principle remains the same: the transaction must clearly reflect an existing agreement between the customer and the merchant.

Compliance and setup: where most approval problems actually start

Many teams focus on optimization routing, retries, cascading while overlooking the foundation: correct setup.

The stored credential framework is not just a compliance requirement. It is the mechanism that tells issuers how to interpret your transactions.

A valid setup requires explicit consent to store and reuse payment details, a properly executed initial customer-initiated transaction (often with authentication where required), consistent signaling of credential storage and subsequent use, and a clear customer mandate.

Inconsistent implementation especially across multiple providers is one of the most common reasons for declining approval rates. The same payment logic produces different transaction footprints, and issuers respond to that inconsistency.

This is why compliance should be seen not as a legal obligation, but as a performance prerequisite.

Performance playbook: improving MIT approval rates in practice

Once the setup is correct, performance becomes a matter of control and optimization.

Routing optimization allows you to direct transactions through the acquirers that perform best for specific issuers, regions, or BIN ranges. This is especially important for recurring and MIT traffic, where issuer expectations are stricter. Learn more about it here. 

Retry logic helps recover transactions that fail due to temporary or context-specific reasons. The key is to apply retries selectively, based on decline type and timing. Poorly implemented retries can harm performance. Cascading payments introduce controlled failover between providers, allowing transactions to be retried through alternative routes when appropriate.

Finally, analytics and reporting allow you to track approval rates by transaction type, route, and issuer, helping identify misclassification and optimize performance.

Common mistakes that reduce MIT performance

Most problems with merchant-initiated transactions don’t come from “bad issuers” or “tough markets.” They usually come from small decisions in setup that quietly break how the transaction is perceived.

One of the most common pitfalls is mixing up CIT and MIT. On paper, it may seem like a minor technical detail, but for the issuer it completely changes the context. When a transaction that should look like a continuation suddenly looks like a brand-new payment, the response is predictable: extra authentication requests or straight declines. It’s not that the payment is risky   it just doesn’t look the way the issuer expects.

Another issue often happens much earlier, during the initial setup. If the first transaction isn’t properly authenticated or the agreement isn’t clearly established, every future charge is built on shaky ground. This is where many teams lose the SCA advantage without realizing it. Instead of a smooth, frictionless flow, they end up reintroducing friction into every subsequent payment.

Then there’s the problem of inconsistency. Transaction indicators might be technically implemented, but not consistently across providers or flows. In a multi-PSP setup, this becomes особенно noticeable: the same type of payment behaves differently depending on the route. For issuers, that inconsistency creates uncertainty and uncertainty often leads to declines.

A different kind of mistake is trying to “fix” everything with retries. When payments fail, the instinct is to try again and sometimes that works. But if the root cause is misclassification or poor routing, retries just repeat the same mistake. In some cases, they can even make things worse by reinforcing negative signals.

And finally, there’s the human side of the process that often gets overlooked. If customers don’t clearly understand what they agreed to when they’ll be charged, how to cancel, what to expect disputes become more likely. And once disputes increase, issuer trust drops, which eventually impacts approval rates as well.

In the end, MIT performance is rarely about a single issue. It’s about how clearly and consistently the entire payment story is communicated from the first interaction to every charge that follows.

Conclusion

Merchant-initiated transactions are not just a technical nuance — they shape how every repeat payment is interpreted, approved, or declined. They determine whether a transaction appears to be a trusted continuation of a relationship or an unexpected request that warrants scrutiny.

When implemented correctly, MIT creates a smoother payment experience, aligns with PSD2 SCA expectations, and gives issuers the clarity they need to approve transactions with confidence. When implemented inconsistently, even legitimate payments lose that context, and the result is friction, declines, and lost revenue.

The real impact comes from combining two layers. First, a solid foundation: correct classification, clear consent, and consistent signaling under the stored credential framework. Second, intelligent execution: routing, retries, and failover strategies that adapt to issuer behavior and real-world performance.

In practice, MIT success is not about a single optimization. It is about building a system where every transaction is both clearly understood and optimally processed.

FAQ

What is a merchant-initiated transaction?

A merchant-initiated transaction is a payment triggered by the merchant without the customer actively participating at the moment of the charge, based on previously stored payment details and a prior agreement. It is best understood as a continuation of an existing relationship rather than a standalone payment. The customer has already agreed to future charges and often completed authentication earlier. When this context is clear and consistent, issuers are more likely to treat the payment as expected.

CIT vs MIT: what’s the difference?

A customer-initiated transaction happens when the customer is actively involved in the payment, confirming it in real time and completing authentication if required. A merchant-initiated transaction occurs later without the customer being present. Because of this, issuers rely on signals and prior agreement rather than real-time confirmation. The difference ultimately affects how the issuer interprets intent and whether friction is introduced.

Are MITs really out of scope for SCA under PSD2?

They can be out of scope, but only if they follow a properly authenticated initial transaction and meet regulatory conditions. Authentication does not disappear; it is shifted to the setup phase. If the initial step is missing or poorly implemented, issuers may still require authentication or decline the payment. Everything depends on how well the initial agreement is established and communicated.

What are the most common MIT use cases?

MITs are used in subscriptions, usage-based billing, delayed charges, and payment retries. Subscriptions are the most predictable and easiest for issuers to process when configured correctly. Unscheduled or delayed charges require clearer signaling because they lack a fixed pattern. In all cases, the payment works because it follows a prior agreement.

What indicators are required under the stored credential framework?

Merchants must signal both the initial storage of payment details and their later use in transactions. This includes identifying whether the payment is customer-initiated or merchant-initiated and specifying the type where relevant. The biggest challenge is consistency across providers and flows. Inconsistent signals create uncertainty for issuers and can reduce approval rates.

How can routing and retries improve MIT approvals?

Routing improves performance by sending transactions through acquirers that work best for specific issuers or regions. Retries help recover payments that fail due to temporary or contextual reasons, but they must be controlled and not excessive. Cascading allows rerouting when failures are caused by provider or infrastructure issues. Together, these approaches increase approval rates by aligning transactions with issuer expectations rather than forcing them through.