Merchant-initiated transactions (MIT)

A merchant-initiated transaction (MIT) is a card payment that a merchant starts without the cardholder actively initiating that individual payment. It is linked to an earlier customer-initiated transaction (CIT) or a payment agreement that established the relationship between the customer and the merchant.

Common examples include subscription renewals, installment payments, delayed charges, hotel no-show charges and usage-based bills. MITs make digital commerce convenient, but they also require accurate classification, evidence of customer consent and payment data that gives issuers enough context to make informed authorization decisions.

What is a merchant-initiated transaction?

A merchant-initiated transaction is a payment request submitted by a merchant after the customer has previously agreed to a product, service or billing arrangement. The customer is not actively present or taking part in the initiation of that later payment.

Visa describes an MIT as a transaction related to a previous cardholder-initiated transaction but conducted without the cardholder present and without additional cardholder validation. The later payment must refer back to the customer’s original interaction or agreement. Visa’s card-on-file guidance distinguishes MITs from customer-initiated transactions, in which the customer actively presents or uses the payment credential.

The distinction matters because an MIT is not simply a normal card payment with the customer missing from the screen. Its authorization data, authentication treatment, dispute context and processing requirements can be different.

MIT vs. customer-initiated transaction

A recurring payment is therefore one type of MIT, but the terms are not interchangeable. “Recurring” describes a payment pattern or schedule. “Merchant initiated” describes who starts the individual transaction.

Common types of merchant-initiated transactions

Card schemes and payment providers use transaction indicators to distinguish different MIT use cases. The exact categories and required data depend on the payment network, region and processing setup, but common examples include:

• Recurring payments: scheduled charges for subscriptions, memberships, insurance or other continuing services.
• Installment payments: later scheduled payments that form part of an agreed series.
• Unscheduled credential-on-file payments: charges that are not made on a fixed schedule but are authorized under an ongoing arrangement, such as usage-based billing.
• Delayed charges: a later charge for an amount that could not be finalized during the original customer interaction, such as additional hotel or rental-car charges.
• Incremental authorizations: additional authorization requests when the final amount increases during a service period.
• Reauthorization or resubmission: a further attempt connected to an earlier transaction, where permitted by the relevant scheme rules.
• No-show transactions: charges under a booking or reservation agreement when the customer does not attend or cancel within the permitted terms.

Visa’s published MIT examples include reauthorization, resubmission, delayed charges, incremental authorization, no-show, installment, recurring, account top-up and unscheduled stored-credential transactions. A merchant should confirm the permitted category and message requirements with its acquirer and payment processor.

How does an MIT work?

1. The customer establishes the relationship. The customer buys a product, starts a service or agrees to a payment arrangement. This is normally the customer-initiated transaction or the initial payment event.
2. The merchant records consent and payment details. The merchant retains the relevant agreement, billing terms, credential-on-file information and evidence of the original interaction.
3. The merchant triggers a later payment. A renewal date, installment schedule, usage event, reservation condition or other agreed trigger causes the merchant to submit the payment.
4. The merchant identifies the transaction correctly. The authorization message should indicate that the payment is merchant initiated and connect it to the original transaction or agreement where required.
5. The issuer assesses the request. The issuer uses the transaction indicators, original transaction reference, account status, payment history and other available risk data to decide whether to approve, decline or request additional action.

Visa’s MIT framework requires the acquirer or acquirer processor to provide evidence of the preceding transaction by sending the relevant original transaction identifier. Maintaining this link is important for authorization, dispute handling and reliable issuer decisioning.

Do merchant-initiated transactions require authentication?

There is no single answer for every market or payment flow. The initial customer-initiated transaction and later MITs are treated differently because the customer is involved in the first payment but not in the later merchant-triggered payment.

In the European Union, the European Banking Authority has stated that card payments initiated by the payee only, such as certain recurring card payments, are outside the scope of the Strong Customer Authentication requirements in the relevant regulatory technical standards because the payer does not initiate each payment. The EBA guidance also emphasizes the importance of distinguishing payee-initiated payments from payments initiated by the payer through the payee.

That does not mean MITs are automatically low risk or that they should bypass all fraud controls. Payment networks, regulators, issuers and acquirers may apply different requirements. A merchant may also need to authenticate the customer when establishing the original agreement, when a material change is made or when a later payment is handled through a customer-present flow.

EMV 3-D Secure includes features that support recurring and installment payment use cases and can help payment participants communicate more information about the initial setup and subsequent payments. EMVCo’s guidance explains how the standard supports recurring and installment transactions while enabling risk-based, frictionless or challenged authentication where appropriate.

Why accurate MIT classification matters

Incorrectly labeling a payment can create problems across the payment chain:

• Unnecessary declines: The issuer may see a payment that lacks the expected relationship to the original transaction or agreement.
• Higher fraud exposure: A fraudster may exploit weak controls around stored credentials, account takeover or changes to subscription details.
• Disputes and chargebacks: The merchant may struggle to demonstrate consent, the original agreement or the connection between the initial and later payments.
• Regulatory and scheme risk: Inaccurate indicators or missing data can cause non-compliance with network or local requirements.
• Customer frustration: Failed renewals, repeated payment attempts and unexpected challenges can damage trust and increase support demand.

Classification should reflect what actually happened. A payment should not be marked as merchant initiated merely to avoid an authentication step, and a customer-initiated payment should not be presented as an MIT.

MITs and fraud prevention

A valid payment mandate proves that a customer agreed to an arrangement. It does not prove that every later transaction is legitimate. Accounts can be taken over, payment credentials can be stolen, subscription terms can be manipulated and a customer’s circumstances can change.

Effective controls should combine the original agreement with current risk context. Relevant signals may include:

• device and browser context;
• customer and transaction behavior;
• changes to the payment credential, amount or billing pattern;
• merchant, payee and transaction history;
• location, velocity and unusual timing; and
• links between payment activity and suspicious digital-account events.

For financial institutions, the strongest approach is not to treat the initial authentication as permanent proof of trust. Risk can change after the first payment. Cross-channel intelligence helps an issuer decide when a later payment can proceed normally, when additional assurance is appropriate and when the activity should be investigated.

Entersekt’s payment and digital banking capabilities are designed around this principle: use richer context and adaptive decisioning to protect high-risk interactions without adding unnecessary friction to legitimate customers. Relevant applications include 3-D Secure issuer authentication, card-not-present payments and high-risk digital banking actions.

Implementation checklist for merchants and payment providers

• Define the agreement: Record who authorized the payment, what service or product is covered, the payment terms and the conditions that trigger later charges.
• Authenticate the initial setup where required: Apply the relevant customer authentication, consent and risk controls when the relationship is created.
• Store the original transaction reference: Maintain the identifier needed to link later MITs to the original customer interaction.
• Use the correct MIT category: Distinguish recurring, installment, unscheduled, delayed-charge, no-show and other use cases.
• Send complete payment data: Provide issuers and payment systems with the context required for authorization decisions.
• Protect changes: Reassess the customer when the amount, schedule, merchant, credential or terms change materially.
• Monitor the full lifecycle: Track failed renewals, repeated attempts, unusual amounts, account changes and customer disputes.
• Confirm local requirements: Check current card-scheme rules, regulatory obligations and processor guidance before launch.

Frequently asked questions

➡️ What is the difference between an MIT and a recurring payment?

A recurring payment is a scheduled or repeating payment. An MIT is any payment initiated by the merchant after a prior customer agreement or interaction. Recurring payments are one common category of MIT.

➡️ Is an MIT the same as a card-on-file transaction?

Not always. A card-on-file transaction uses payment credentials stored by a merchant or service provider. If the merchant initiates the payment without the customer actively initiating it, the transaction may be an MIT. The correct classification depends on the actual payment flow and applicable scheme rules.

➡️ Do customers need to authenticate every subscription payment?

Not necessarily. The treatment of the initial payment and later merchant-initiated payments can differ, and requirements vary by jurisdiction, network and transaction flow. Organizations should confirm the applicable rules with their acquirer, payment processor and legal or compliance advisers.

➡️ Can an MIT be fraudulent?

Yes. A payment agreement can be abused after account takeover, credential theft, unauthorized changes or social engineering. A mandate is evidence of an arrangement, not a guarantee that the current payment is safe.

➡️ Why does the original transaction identifier matter?

The original transaction identifier links the later merchant-initiated payment to the customer’s earlier interaction. This gives the issuer and other payment participants important context for authorization, risk assessment and dispute handling.

Sources and related articles

• Visa: Card-On-File Data Inquiry
• Visa: Introduction of the Visa Network Merchant-Initiated Transaction Service
• EMVCo: Supporting recurring and installment transactions with EMV 3-D Secure
• European Banking Authority: Applicability of SCA to card payments initiated by the payee only
• Entersekt: Simplified, secure payment authentication

Payment rules and scheme requirements vary by market and may change. Always confirm current requirements with the relevant payment network, acquirer, processor, regulator and legal advisers.