Somewhere in your billing system right now, a charge is failing. The customer didn't cancel or even call in to complain. Their card was reissued three weeks ago, your vault still has the old number, and the decline happened silently at 2AM while your team was asleep. 

Multiply that by every subscription renewal you process in a month, and you start to wake up at the same time every night in a cold sweat, especially if you start thinking about how the subscription economy is at $492 billion and growing.

Merchant initiated transactions are the infrastructure that stops that drain. Here's how they work, what the regulations actually require, and how to build an MIT setup that earns its keep.

What is a merchant initiated transaction?

A merchant initiated transaction is a payment that a merchant triggers using stored customer credentials, without requiring the customer to be present or take any action at the time of the charge. The customer authorizes the arrangement once, during their first interaction with the merchant, and every subsequent charge runs automatically from that point forward.

If you've ever subscribed to a streaming service and watched your credit card statement absorb the charge each month without lifting a finger, you've experienced a merchant initiated transaction from the customer side. From the merchant side, it's the infrastructure that makes that experience possible, and when it's built correctly, it's almost invisible. When it's built incorrectly, it's a slow, quiet drain on revenue that most finance teams never fully account for.

Merchant initiated transactions sit within a broader category called Card on File (COF) payments, which covers any transaction where the merchant retains stored payment credentials for future use. The key distinction is who initiates the charge. In a customer initiated transaction (CIT), the cardholder actively participates, whether by clicking "pay now," completing a checkout, or tapping their card at a terminal. In a merchant initiated transaction (MIT), the cardholder has already given their consent, and the merchant acts on that consent without further input.

How do MITs differ from customer initiated transactions? 

The CIT/MIT distinction isn't just semantic. It has direct implications for authentication requirements, transaction flagging, liability, and authorization rates.

For customer initiated transactions, Strong Customer Authentication (SCA) is required under PSD2 in Europe and the UK, meaning the cardholder must verify their identity at the time of the transaction, typically through two-factor authentication. For merchant initiated transactions, PSD2 provides a specific exemption: once the initial CIT has been properly authenticated and consent has been captured, subsequent MITs are exempt from SCA requirements. This is one of the most operationally significant aspects of PSD2 merchant initiated transactions for any business running recurring billing at scale. Getting the initial consent record right is what unlocks the exemption for every charge that follows.

Beyond authentication, the CIT/MIT distinction affects how the transaction is flagged to the issuing bank. A properly flagged merchant initiated transaction tells the issuer that a prior consent record exists, that the merchant is authorized to charge this credential, and that this charge is part of an established billing relationship. That context matters enormously to the issuer's authorization decision. A transaction that arrives without the correct MIT indicators looks, to the issuer, like an unauthorized use of stored credentials, and it gets treated accordingly.

The MIT types merchants actually use

Merchant initiated transactions cover more ground than most people assume. The most familiar form is the recurring fixed charge, where the same amount is billed on a predictable schedule, as with a monthly software subscription or an annual membership renewal. Usage-based billing works differently: the amount varies based on consumption, as with a cloud storage platform that charges based on how much a customer actually used in a given month.

Installment payments are also MIT territory. A customer who buys a piece of furniture and splits the cost into six monthly payments has agreed to a series of merchant initiated transactions at the point of purchase. Unscheduled MITs cover the less predictable scenarios, including automatic account top-ups that trigger when a balance drops below a threshold, no-show penalties charged after a missed hotel reservation, and delayed charges for expenses processed after a customer has already checked out.

How merchant initiated transactions work

The mechanics of a merchant initiated transaction unfold in four stages. Each stage carries compliance and infrastructure requirements that determine whether the downstream charges succeed or fail.

1. Consent and initial authorization. The customer completes a CIT, explicitly agreeing that the merchant may store their credentials and charge them in the future. This first transaction must be authenticated under applicable regulations, and it must capture a reference transaction ID (sometimes called a Trace ID) that links every subsequent MIT back to this original consent event. Without that reference, the merchant can't demonstrate a compliant consent chain to the issuer, and the entire recurring billing arrangement sits on a legally and technically precarious foundation.
2. Tokenization of payment credentials. Sensitive card data is replaced with a secure token and stored in a payment vault. For Visa merchant initiated transactions and Mastercard recurring charges, this token is what gets transmitted to the processor on every subsequent charge. The quality of the token matters significantly: a network token issued directly by Visa or Mastercard carries more issuer trust than a generic provider token, because the issuer recognizes its own credential. According to Visa's own reporting, tokenized transaction volume surged 44% in 2024, producing a 6% improvement in authorization rates and a 30% reduction in fraud.
3. The merchant-initiated charge. The merchant sends a payment request to the processor using the stored token, flagged with the correct MIT indicator and a reference to the original CIT. The issuer sees a known credential with an established consent record and context about the transaction type, whether recurring, installment, or unscheduled, and makes its authorization decision accordingly.
4. Retry and recovery logic. When a charge fails, the payment stack needs to distinguish between a soft decline, which is retriable, and a hard decline, which requires a different approach entirely. Intelligent retry logic routes the next attempt through the most favorable available path. This is where most MIT infrastructure breaks down, and where the revenue leakage becomes real.

MITs and compliance: the regulations that govern recurring billing

Compliance is crucial to the MIT story. Get it wrong at the foundation and everything built on top of it, the recurring billing, the retry logic, the revenue projections, becomes structurally unsound. The compliance requirements for merchant initiated transactions are well-defined and well-documented. They reward merchants who take the time to understand them with higher authorization rates, cleaner consent records, and a recurring billing operation that holds up under scrutiny

SCA merchant initiated transactions and PSD2

For merchants operating in Europe or the UK, PSD2 is the primary regulatory framework governing how merchant initiated transactions must be set up. The core requirement is that the initial transaction in any recurring billing relationship must be authenticated using SCA, which requires at least two of the following factors: something the customer knows (a password or PIN), something the customer has (a phone or hardware token), or something the customer is (a biometric).

Once that first authenticated transaction is in place and the consent record is properly captured, subsequent MITs are exempt from SCA requirements under PSD2. The exemption is specific and conditional: it applies to merchant initiated transactions where a prior agreement exists, and it depends on the initial CIT being correctly authenticated and documented. SCA merchant initiated transactions are a regime that front-loads the compliance burden at the point of consent, so that the recurring billing that follows can run without friction.

For UK merchants, it's worth noting that post-Brexit, the UK's SCA framework has diverged somewhat from the EU's implementation under PSD2. The underlying principles are consistent, but specific technical standards and timelines have been set independently by the FCA. Any merchant operating across both markets should verify current requirements with a payments compliance specialist.

The Stored Credential Framework

Beyond PSD2, Visa and Mastercard both maintain their own Stored Credential Frameworks, which govern how any card-on-file payment, including merchant initiated transactions, must be structured and transmitted. The frameworks require merchants to obtain explicit cardholder consent before storing credentials, to flag each subsequent MIT with the correct transaction type indicator, and to include the reference transaction ID from the original CIT in every downstream charge, as outlined by the Merchant Risk Council.

Non-compliance with the Stored Credential Framework isn't a theoretical risk. Incorrectly flagged MITs are more likely to be declined, and merchants who can't demonstrate a compliant consent chain face escalating financial assessments from the card networks. Getting the framework right is simultaneously a compliance obligation and an authorization rate lever.

Merchant initiated vs. processor initiated: understanding the difference

One source of confusion worth clearing up is the distinction between a merchant initiated transaction and what's sometimes called a processor initiated transaction.

A processor initiated meaning, in the context of recurring payments, refers to a transaction that the payment processor or acquirer triggers on behalf of the merchant, typically as part of a retry or recovery workflow. The processor acts on instructions from the merchant's billing system, using stored credentials to attempt a charge after a previous failure. In practice, the line between merchant initiated and processor initiated can blur, because both rely on stored credentials and neither requires the cardholder to be present.

The functional difference is one of origination and authorization scope. A merchant initiated transaction is triggered by the merchant's own system, acting on an established consent record. A processor initiated transaction is triggered by the processor, typically within a defined retry window and subject to the network rules that govern how many times a declined transaction can be retried before further attempts are prohibited. Visa maintains specific rules about retry limits and required intervals for recurring transactions, and exceeding those limits can result in fines.

For merchants building automated payment infrastructure, the practical implication is this: the retry strategy must be encoded in the billing logic before a transaction ever fails, not improvised after the fact.

The advantages of automating MIT management

The case for automating merchant initiated transactions is, at its core, a revenue argument.

According to research cited by Paysafe, 50% of all subscription churn occurs due to failed card payments, and 80% of those failures have nothing to do with anything the customer did or intended. These are customers who planned to stay, expected to be charged, and lost access to a service because a card expired or a gateway had a bad moment. 

Keep credentials current automatically

The most common cause of MIT failure is stale credentials. A card gets reissued after a fraud event, expires at the end of its cycle, or is replaced when a customer switches banks. The merchant's vault still holds the old Primary Account Number (PAN), the charge goes out against a dead credential, and the decline triggers a dunning sequence the customer may never respond to.

Network tokenization solves this at the infrastructure level. Network tokens issued by Visa or Mastercard are tied to the underlying account, not to the physical card. When a card is reissued, the network updates the token automatically. The merchant never needs to chase the customer for new card details, because the vault's token never goes stale. Merchants who've implemented network tokens through Spreedly's Advanced Vault report meaningful authorization rate improvements. 

Route intelligently when retries are needed

Automating MIT management means building retry logic that reflects what the decline code is actually telling you. A soft decline for insufficient funds is a different situation from a hard decline for a stolen card, and treating them identically is how merchants fail to recover recoverable revenue while burning through retry attempts on charges that were never coming back.

Intelligent routing sends a retry through the gateway or network most likely to authorize it, based on real-time performance data rather than a static configuration that hasn't been touched since the integration went live. For merchants processing recurring billing across multiple payment service providers, this capability is the difference between a billing infrastructure that's actively managed and one that's merely operational.

McKinsey projects that over 60% of global payments will shift to automated or recurring models by 2027. The merchants who build the right MIT infrastructure now will be collecting on that shift.

Eliminate manual intervention from the billing cycle

Beyond credential management and retry logic, automation removes the operational burden that manual MIT management places on finance and payments teams. Automated account updater services refresh stored credentials before charges are attempted. Automated decline code handling routes each failed transaction through the appropriate recovery path without requiring human review. Automated compliance flagging ensures that every MIT carries the correct stored credential indicator and reference transaction ID, without relying on engineering teams to maintain that logic manually.

When the billing cycle runs without intervention, the finance team's energy goes toward analysis rather than remediation. That's a better use of everyone's time.

How Spreedly's Vault makes MIT infrastructure manageable

Building compliant, high-performing MIT infrastructure from scratch is a significant engineering undertaking. The credential storage, network tokenization, account updater services, retry routing, and compliance flagging required to run recurring billing correctly don't assemble themselves, and maintaining all of it across multiple gateways and payment service providers compounds the complexity considerably.

Spreedly's Vault is built to handle that complexity as managed infrastructure. It stores both traditional tokens and network tokens, supports automatic credential refresh through account updater services, and enables merchants to dynamically select the best available payment method for each transaction. When a customer's card is reissued, the vault's token updates without merchant intervention. When a charge fails, the routing layer has the credential quality and gateway intelligence to find the best recovery path.

For merchants running recurring billing at scale, the Vault also provides the stored credential framework compliance layer that ensures MIT indicators and reference transaction IDs are correctly applied to every outbound charge. This is infrastructure that most finance teams neither want to build nor want to own, and that's exactly the point.

The forward view is worth noting briefly. As agentic commerce, where AI agents execute purchases on behalf of consumers, moves from concept to live channel, the technical foundation it requires is exactly the MIT infrastructure described above: clean stored credentials, compliant consent records, and routing logic sophisticated enough to find authorization in a complex global payments environment. Spreedly has already made agentic commerce a live channel for merchants. The Vault is part of how that becomes possible.

Build recurring revenue that doesn't leak

Merchant initiated transactions are the operational backbone of the subscription economy. When the underlying infrastructure works, they're invisible: charges clear, revenue arrives, customers stay subscribed. When it doesn't work, the losses are quiet, distributed across thousands of failed charges, and they compound in ways that summary dashboards rarely surface until the damage is already done.

The solution isn't a novel one: clean credentials, correct compliance flagging, and intelligent retry logic. What's novel is the scale at which that problem now needs to be solved, in a $492 billion subscription economy that's on its way to $1.5 trillion.

Book a demo to see how Spreedly's Vault supports merchant initiated transactions, network tokenization, and automated credential management for subscription businesses operating at scale.

‍