Merchant-initiated transactions (MITs): how they work and how to optimize them

Merchant-initiated transactions (MITs) support many business models. These include subscriptions with recurring payments, installment plans, hotel charges after checkout, and automatic top-ups.

Unlike customer-initiated transactions (CITs), MITs don’t require the customer to be present at the time of payment. Once the customer gives consent, merchants can automatically charge a stored payment method based on the agreed terms.

In this guide, we’ll explain merchant-initiated transactions, how they differ from other types of payments, why they sometimes fail, and how to optimize them to improve performance and protect revenue.

What is a merchant-initiated transaction?

Merchant-initiated transactions are payments that a merchant triggers without the customer's involvement at the time of payment.

Once a customer consents and authorizes the merchant to store their payment details, they can automatically initiate future payments. No further action is needed from the customer.

A common example is a monthly subscription for a streaming service.

How is a merchant-initiated transaction different from a customer-initiated transaction?

The key difference between merchant-initiated transactions and customer-initiated transactions—sometimes known as cardholder-initiated transactions—lies in who initiates the authorization and under what conditions.

• With CITs, the customer starts the payment by actively entering their card details or approving the transaction in real time, whether it’s online, in-app, or tapping their card at a terminal.
• With MITs, the merchant initiates the payment authorization at a later date without the customer's presence based on the customer's prior agreement and consent.

‍

To qualify as an MIT, the merchant must:

1. Receive explicit consent from the customer to store their payment credentials during a CIT.
2. Store those credentials securely (typically in a PCI-DSS Level 1 token vault).
3. Initiate future payments—either recurring or one-off—according to the agreed terms, without real-time customer interaction.

Important distinction

Some transactions may appear to be MITs (e.g., delayed charges), but are actually CITs depending on how authorization is handled. For example, a card is authorized for a high amount at a gas station and later adjusted. This is a CIT because the customer initiated the authorization. The latter capture doesn’t make it a merchant-initiated transaction.

Examples of merchant-initiated transactions

From subscription businesses to hospitality, MITs allow merchants to collect revenue without asking customers to re-enter payment details or manually approve each transaction.

Here are some common examples of MITs across different business models:

• One-off charges, such as when a prepaid mobile provider automatically charges a customer’s credit card to top up their account balance when it gets low.
• Prepayments, for example, a utility provider collecting advance payments for electricity or gas based on estimated usage.
• Installment payments, such as a Buy Now, Pay Later (BNPL) provider, collecting scheduled payments after splitting a purchase into multiple installments.
• Penalty charges, like a restaurant charging a no-show fee to a customer who booked a table but did not attend.
• Reauthorizations, for example, an online retailer adding additional shipping fees to an order that requires split or delayed shipments after the initial payment was authorized.

Are merchant-initiated transactions high-risk?

It depends on the lens you’re looking through and what you define as "risk".

From a fraud and security perspective, MITs are often seen as less secure than CITs. That’s because MITs don’t include CVV data or benefit from authentication using 3D Secure.

What lowers the ‘risk’ for Issuers is that MITs are linked to a prior, authenticated CIT. When a customer makes the initial CIT, the merchant stores the transaction ID. This ID is then referenced in subsequent MITs, acting as a signal to the issuer. 

From a merchant’s perspective, MITs come with operational risks:

• Higher payment decline rates, especially from insufficient funds or expired cards
• More customer disputes if the original consent wasn’t explicit or the billing descriptor is confusing

‍

From a customer perspective, MITs are usually fine, as long as:

• The merchant is transparent about what’s being charged
• There’s a clear opt-in process and an easy way to cancel

Merchant-initiated transactions and Strong Customer Authentication

Under Europe’s Payment Services Directive 2 (PSD2), most electronic payments require Strong Customer Authentication (SCA) to reduce fraud.

But MITs are treated differently. Once the customer provides consent and the initial transaction is authenticated, subsequent MITs may be exempt from further authentication.

This means merchants can initiate future payments, whether recurring or variable, without requiring the customer to authenticate each time. In fact, that’s the point: MITs exist to support seamless, friction-free billing where the customer isn’t present.

Why do merchant-initiated transactions fail? 

While MITs are typically lower risk for fraud, they can suffer from higher payment failure rates than CITs. 

The biggest culprit? Insufficient funds.

Primer’s data shows that 56% of MIT failures occur because the customer’s account lacks sufficient funds, compared to 18% for customer-initiated transactions.

Why the gap?

When customers initiate payments, they tend to use a payment method they know has enough funds or credit available. They might even move money between accounts in real time to complete the transaction.

Other common reasons for MIT payment failure are errors in the payment chain, such as processor downtime and do not honor declines. 

How to optimize merchant-initiated transactions

Here’s how to increase MIT payment success rates:

Deploy a dynamic retry strategy

For soft declines, such as insufficient funds or temporary technical issues, retrying the payment can often lead to success. But retry attempts need to be strategic.

Avoid making multiple attempts in rapid succession, which can trigger negative issuer responses, increase decline rates, or even lead to penalties. Instead, space out retries over days or weeks to allow time for customers to resolve funding issues. A typical retry schedule is days 2, 4, 8, and 16 after the initial failure.

Another option is to align retries with customer pay cycles. In Europe, customers often receive wages at the end of the month, so retrying in the first few days of a new month can be effective. While in the US, many people are paid biweekly, typically mid-month and end-of-month, so timing retries around these periods can increase success rates.

Leverage network tokenization

Instead of relying on the static primary account number (PAN), network tokens provide a secure, dynamic version of the card that stays updated automatically. This removes one of the most common points of failure in merchant-initiated transactions: expired or reissued cards.

If you’re running a recurring billing model, adopting network tokenization is one of the most effective ways to keep payments flowing without interruption.

Offer alternative payment methods (APMs)

While card payments remain dominant, offering alternative payment methods (APMs) can improve MIT success rates.

APMs that could help optimize MIT use cases include:

• Open Banking payments reduce the risk of payment declines caused by expired credentials. If a customer has an overdraft, payments can still be collected, minimizing failures due to insufficient funds.
• Buy Now Pay Later eliminates the risks of card expiration or loss, as no physical card details are used for the transaction.

How Primer helps businesses optimize MITs

Primer is a Unified Payments Infrastructure used for both CITs and MITs by merchants globally, including GetYourGuide, loveholidays, Dabble, and Conforama.

Through a single integration with Primer, you can: 

• Connect to multiple payment processors and methods, reducing reliance on a single provider and increasing redundancy.
• Use network tokenization agnostically across all processors to maintain continuity even when customers change cards or you change PSPs.
• Leverage smart routing and dynamic retry logic, automatically adjusting payment routes and retry strategies based on factors like issuer response patterns, customer pay cycles, and past retry success.
• Experiment and adapt without heavy dev work using Primer’s no-code workflows, which let you test and refine MIT optimization strategies.

‍

Whether you run a subscription business, an installment model, or handle variable recurring billing, Primer’s flexible payment stack empowers you to recover more revenue and reduce involuntary churn at scale.

Final thoughts on MITs

Merchant-initiated transactions are the engine behind subscriptions, recurring billing, and many flexible business models.

However, to get the full benefit, merchants must address the weak points: failed payments, outdated card data, and lack of visibility. That’s where optimization makes the difference.

With the right strategy, smart retries, network tokenization, and flexible payment methods, MITs can become powerful drivers of customer retention, predictable revenue, and long-term growth.

Book a demo to learn more about how Primer can help.