What is Merchant-initiated transaction?
Also: MIT
A charge initiated by the merchant against a previously stored credential, without the cardholder present.
A Merchant-Initiated Transaction (MIT) is a payment processed by a merchant using a cardholder's stored payment credentials without the cardholder being actively present in the transaction flow.
These transactions are fundamental to business models like subscriptions, automatic top-ups, or metered billing, where payments are collected on a recurring or unscheduled basis.
To comply with payment regulations like PSD2 in Europe and card scheme rules globally, an MIT must always be preceded by a Cardholder-Initiated Transaction (CIT). This initial CIT establishes the cardholder's consent and, where required, performs Strong Customer Authentication (SCA).
Mechanically, when a merchant submits an MIT, they must include a specific transaction identifier from the original CIT in the authorisation request. This identifier acts as proof to the issuer that a valid, authenticated mandate exists for the charge.
The merchant must also correctly flag the transaction as an MIT and specify the reason, such as 'Recurring' or 'Unscheduled Card on File'.
A common point of confusion is that not all subsequent payments are MITs; if a returning customer actively uses their saved card to make a new one-off purchase, that is still a CIT.
Correctly distinguishing between and flagging MITs and CITs is crucial, as mis-flagging can lead to higher decline rates, increased interchange fees, and compliance issues.
Worked example
A streaming service signs up a new user in Germany for a €12.99 monthly subscription. The initial sign-up payment is a Cardholder-Initiated Transaction (CIT).
The user enters their card details and completes 3D Secure authentication. The acquirer returns a successful authorisation, along with a unique scheme transaction ID.
The merchant stores this ID alongside the vaulted card details, establishing the link to the authenticated mandate.
One month later, the merchant initiates the first renewal payment. They submit a new authorisation request for €12.99 to their acquirer.
This request is flagged as a Merchant-Initiated Transaction for a 'Recurring' payment. Crucially, it includes the scheme transaction ID from the original CIT.
The customer's issuer receives the request, recognises the MIT flag and the linked ID, and applies the SCA exemption. The payment is approved without requiring any action from the cardholder, and the service continues uninterrupted.
Scheme notes
Both Visa and Mastercard have comprehensive rules governing MITs, largely harmonised under the PSD2 framework in Europe.
They require merchants to use specific flags in the authorisation message to identify the transaction as an MIT and link it to the original CIT using a scheme transaction identifier.
Failure to provide this linkage can cause issuers to soft-decline the transaction with a request for SCA. The schemes define several MIT categories, including 'Recurring' for fixed-schedule payments, 'Instalments', and 'Unscheduled Credential on File' (UCOF) for variable payments like auto top-ups.
American Express and Discover have similar concepts, requiring merchants to clearly indicate when a charge is subsequent to an initial agreement. Correctly flagging the MIT reason code is vital for interchange qualification and approval rates.
Why it matters for merchants
Correctly implementing MITs is non-negotiable for any merchant operating a subscription, recurring billing, or card-on-file business model. It is the technical foundation for automated revenue collection.
A proper setup ensures a frictionless payment experience for subscribers, leading to higher retention and predictable cash flow. Conversely, incorrect flagging of MITs results in higher Soft decline rates, as issuers will request SCA for unauthenticated transactions.
This breaks the automated process, forcing manual customer intervention and leading directly to Involuntary churn and lost revenue. Cardflo's orchestration platform and smart routing logic ensure that MITs are correctly structured and flagged according to each acquirer's and scheme's specific requirements, maximising approval rates.
Frequently asked
How does an MIT differ from a card-on-file transaction?
While both involve stored credentials, a card-on-file transaction is a CIT where the customer is present and actively triggers the payment. An MIT is specifically initiated by the merchant according to a pre-defined agreement, meaning the customer is absent during the individual charge event.
Why do MITs require a reference to a previous transaction ID?
Schemes and issuers require the original transaction ID (trace ID) to link the MIT back to the initial SCA-authenticated session.
This audit trail verifies that the customer authorised the merchant to store the credentials and allows the issuer to process the payment under the appropriate regulatory exemptions.
What is the difference between a 'Recurring' MIT and an 'Unscheduled' MIT?
A 'Recurring' MIT is a payment taken at a fixed, regular interval for a fixed amount, such as a monthly subscription of £20. An 'Unscheduled Credential on File' (UCOF) MIT is used when the payment amount or timing is variable.
Examples include automatic wallet top-ups triggered when a balance falls below a threshold, or metered billing where the amount charged depends on usage. Both require an initial CIT to establish consent, but they must be flagged differently in the transaction data.
Can I change the amount of a recurring MIT without a new CIT?
It depends on the card scheme rules and the initial agreement with the cardholder. Generally, minor changes might be acceptable, but significant increases in amount or changes in frequency may require a new CIT with SCA to re-establish the mandate.
For example, upgrading a subscription from a £10/month plan to a £50/month plan should ideally be processed as a CIT where the user confirms the new price. Failure to do so increases the risk of declines and chargebacks for 'Amount Differs'.
What happens if I forget to include the original CIT transaction ID in my MIT request?
If the original CIT transaction ID is missing, the customer's issuer has no verifiable proof of a prior authentication or mandate.
In regions like the EEA and UK where SCA is enforced, the issuer is highly likely to soft-decline the transaction and request authentication from the cardholder. This defeats the purpose of an automated MIT, requires customer intervention, and can lead to failed payments and churn.
Even outside SCA-mandated regions, the absence of the ID can lead to lower approval rates.
Are MITs exempt from Strong Customer Authentication (SCA)?
Yes, MITs are explicitly defined as out of scope for SCA under PSD2, meaning the cardholder does not need to perform 2-factor authentication for each payment. However, this exemption is predicated on the condition that the payment relationship was initiated with a properly authenticated CIT.
The merchant must prove this linkage by including the original transaction identifier in all subsequent MIT requests. Without this proof, the exemption may not be applied by the issuer.
How long is the CIT-to-MIT link valid?
The link between the initial Cardholder-Initiated Transaction (CIT) and subsequent Merchant-Initiated Transactions (MITs) does not have a fixed expiry date imposed by the schemes.
The mandate is considered valid as long as the subscription or card-on-file agreement is active according to the terms agreed upon by the cardholder.
However, if a card is updated via a service like Account Updater or the cardholder provides a new card, a new CIT with SCA is often recommended to establish a fresh, authenticated mandate for the new credential.
See how Merchant-initiated transaction plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Related terms
A transaction initiated by the cardholder in real time, typically the first charge that establishes credential-on-file.
PSD2 requirement that customer-initiated electronic payments in the EEA and UK be authenticated with two of: knowledge, possession, inherence.
A scheme-issued token that replaces the PAN end-to-end and is automatically updated when the underlying card is reissued.
Related guides.
From the blog
The subscription model provides predictable revenue through recurring fees for SaaS and streaming services. While it fosters long-term customer loyalty, businesses must manage higher acquisition costs and potential churn. This approach offers stability for companies providing ongoing value through continuous access to products. It is designed to generate a steady income stream and build relationships.
Read articleSubscription payments are a specific subset of recurring billing where customers pay at the start of each cycle. These automated payments occur at weekly, monthly, or annual intervals until the service is terminated. This model helps businesses reduce churn and secure predictable revenue while helping customers budget effectively. It is an ideal system for strengthening long term loyalty.
Read articleA recurring payment is an automated billing system where a customer authorises a business to charge their card or bank account at regular intervals. This model is common for gym memberships, insurance premiums, and streaming services. It provides convenience for consumers while ensuring consistent revenue for service providers. Payments occur at fixed or variable amounts without manual customer input.
Read articleReady to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.