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

If you run subscriptions, a marketplace, or another repeat billing model, you have probably seen it happen. A payment that should be routine fails unexpectedly. The customer hasn’t canceled the subscription and the card is still valid, yet the issuer declines the charge or asks for authentication that shouldn’t be needed.

In many cases, it has nothing to do with fraud activity. 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 let merchants charge customers without requiring them to be present every time, while still giving issuers enough context to recognize the payment as expected. Otherwise, the issuer sees an ambiguous payment, and approvals drop.

Below, we look at what an MIT is, how it differs from a CIT, which compliance and scheme rules apply, and how to raise MIT approval rates.

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.

An MIT always builds on an earlier interaction. The customer signs up for a subscription or makes the first payment on an installment plan. In this customer-initiated transaction (CIT), the customer:

• shares their payment details, which are often stored as a card on file;
• gives explicit consent to future charges;
• completes authentication where required.

Without this context, 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 simply as whether the customer is present. In practice, it also decides how the issuer reads 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 separate guide covers how 3D Secure authentication works.

On the other hand, a transaction initiated by a merchant depends completely on the context that has already been established. The issuer has to trust that the payment is part of an agreed process and not a new or unexpected charge.

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.

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

Merchant-initiated transactions are often called “low risk”. That doesn’t make them safer by default. An MIT counts as lower risk only when it is set up correctly and flagged clearly.

Strong customer authentication under PSD2 rules covers most transactions initiated by the customer. However, qualifying merchant-initiated transactions can be treated as out of scope for SCA, because the payer does not initiate them, as long as they follow a properly authenticated initial transaction. This removes friction at the moment of payment.

As for card schemes, under the stored credential framework, merchants have to signal clearly when they store payment details and how they reuse them. Those signals tell the issuer the charge is expected.

The payments themselves often follow a predictable pattern. Many recur, and all of them come from a merchant the customer already has a relationship with, so they are 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 take different forms, and each one needs its own setup.

Recurring payments are the most straightforward example. These include subscription renewals and other recurring billing with fixed intervals. They are predictable and generally perform well when set up correctly, but even small inconsistencies like a missing MIT flag or a missing link to the original transaction can still get them declined.

Unscheduled payments are more complicated since they involve charges without a set timetable, for example, usage-based billing. The amount in such cases may be fixed or variable, and clear consent together with accurate signaling is essential, as the issuer cannot depend on a regular pattern.

In travel and hospitality, delayed charges and no-show fees can arrive long after the booking. The further the payment is from the original interaction, the more critical it is that the agreement was transparent and clearly documented.

Reattempts and resubmissions count as MITs when they are linked to a prior agreement, and they need careful handling. A retry that repeats the original mistake gets declined again and adds another negative signal for the issuer. Too many of them can also trigger scheme fees.

Card schemes define a few more MIT types. Installments split one purchase into a set number of charges over an agreed period. Visa also lists incremental authorizations, used when the final amount grows beyond the original authorization, for example during a hotel stay or car rental. Its reauthorizations cover orders or services that run past the validity of the first authorization. Mastercard handles a similar case with partial shipments, when one order ships in several parts.

In 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 put their effort into optimization, such as routing, retries, and cascading. Proper setup gets far less attention, even though every other improvement depends on it.

Beyond compliance, the stored credential framework 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 (with authentication where required), consistent signaling of credential storage and subsequent use, a reference to the original transaction in each subsequent charge, and a clear customer mandate.

Inconsistent implementation, particularly when it comes to different providers, is a common cause of falling approval rates. The same payment logic results in different transaction footprints, and issuers react to this inconsistency. So compliance also decides how many of these payments get approved.

Akurateco keeps stored-credential data in one internal model, covering who initiated the payment, whether it is one-off, initial, or subsequent, which credential is used, and whether the payer is present. For each connector that supports card on file, the platform maps this model to the connector’s own format and accounts for its specifics.

Performance playbook: improving MIT approval rates in practice

Once the setup is right, 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 other merchant-initiated flows, where the issuer has no customer to authenticate and relies entirely on the transaction data. 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 a declined payment to move to another route when the problem lies with the provider.

Finally, track approval rates by transaction type, route, and issuer: a drop in one of these segments can point to misclassification.

Common mistakes that reduce MIT performance

Most problems with transactions initiated by merchants arise from small setup choices that gradually alter the way the issuer interprets the payment.

CIT and MIT mix-ups. For the issuer, the CIT or MIT flag decides whether the customer should be present and authenticated. If a subscription renewal arrives flagged as a CIT, an issuer in the EEA expects SCA. The customer isn’t there to complete it, so the payment is soft-declined or declined outright.

The first payment is not properly authenticated, or the agreement behind it is unclear. Later charges may then no longer count as merchant-initiated, and issuers can ask for SCA on them, bringing back the friction MIT was supposed to remove.

Same payment, different flags. In a multi-PSP setup, one acquirer may receive a renewal as an MIT with a link to the original transaction, while another receives it as a plain card-not-present payment. The indicators are there, but not applied the same way on every route. Issuers see mixed signals and decline more often.

Retrying instead of fixing. When a payment fails, the first instinct is to try again, and in some cases this does work. However, if the actual problem is misclassification or bad routing, then a retry will simply repeat the same error.

When customers don’t know what they signed up for. If the terms leave them unsure when they’ll be charged, how to cancel, or what to expect, a charge they don’t recognize turns into a dispute. A rising dispute rate makes issuers more cautious with the merchant’s next payments.

Conclusion

Merchant-initiated transactions shape how issuers read repeat payments and whether they approve them. When MIT is set up properly, later charges can stay out of scope for SCA, and issuers get enough context to approve them with confidence. However, an inconsistent setup has the opposite effect, causing even legitimate payments to lose that context and be declined or stopped because the customer is not there to complete the authentication request.

The foundation is correct classification, an authenticated first transaction, clear consent, and consistent signaling under the stored credential framework. On top of it sit routing, retries, and failover strategies that adjust to how each issuer actually behaves. Combined, these approaches directly affect MIT approval rates. The clearer and more consistent each charge is, the better its chance of approval. A single optimization rarely gets there on its own.

FAQ

What is a merchant-initiated transaction?

A merchant-initiated transaction (MIT) is a payment started by the merchant without the customer actively participating at the moment of the charge, based on a prior agreement and, usually, stored payment details. The customer has already agreed to future charges and, where required, 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. This difference ultimately affects how the issuer interprets intent and whether it introduces friction.

Are MIT and CIT the same?

No. In a customer-initiated transaction (CIT), the customer starts the payment and confirms it in real time, with SCA where required. A merchant-initiated transaction (MIT) comes later. The merchant charges the customer without them being present, based on an earlier agreement. The two are connected: every MIT relies on an earlier CIT that set up the agreement, but issuers review and approve them differently.

What is an example of a CIT?

A single online purchase is the most straightforward case. To complete the transaction, the customer enters their card details at checkout and, where necessary, authenticates the payment with 3D Secure. The initial payment for a subscription also counts as a CIT. The customer agrees to save the card for further charges, after which the subsequent renewals are handled as MITs.

Are MITs really out of scope for SCA under PSD2?

Yes, as long as they follow a properly authenticated initial transaction. The payer doesn’t start them, so they fall outside the scope of SCA. Authentication doesn’t disappear. Instead, it is moved to the setup stage. If the first step is omitted or poorly executed, issuers may still request authentication or decline the payment. A lot depends on how well the initial agreement is set up and flagged.

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, specifying the type where relevant and, for later merchant-initiated charges, referencing the original transaction. 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, retries, and cascading can raise MIT approval rates because each handles a different problem. With routing, every payment goes to the acquirer that performs best for its issuer or region. A retry can recover a payment that failed for a temporary reason, as long as the number of attempts stays under control. When the provider or its infrastructure is at fault, cascading moves the payment to another route.