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.
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.
| Characteristic | Customer-initiated transaction (CIT) | Merchant-initiated transaction (MIT) |
|---|---|---|
| Who starts the payment? | The customer actively initiates the payment, often during checkout. | The merchant initiates the later payment. |
| Customer involvement | The customer is present or actively interacting with the payment flow. | The customer is not actively initiating that payment. |
| Typical examples | Online purchase, in-app checkout or point-of-sale payment. | Subscription renewal, delayed charge or installment collection. |
| Relationship to an earlier payment | May establish the original customer–merchant relationship. | Must generally be linked to the original payment or agreement. |
| Authentication | Authentication may occur during checkout, depending on risk and applicable requirements. | The merchant cannot authenticate the customer at the moment it initiates the payment in the same way as a customer-present 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.
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:
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.
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.
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.
Incorrectly labeling a payment can create problems across the payment chain:
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.
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:
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.
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.
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.
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.
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.
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.
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.