Skip to main content
Commerce Security Authority
Category: Transaction Processing

Merchant-Initiated Transaction

Also known as: MIT, Merchant Initiated Transaction, MIT transaction
Simply put

A merchant-initiated transaction is a card payment that a merchant triggers without the customer being actively present or involved at the moment of the charge, based on an agreement the customer previously consented to. These are commonly used for recurring billing such as subscriptions, where the merchant charges a stored payment method under the terms of that prior agreement.

Formal definition

A Merchant-Initiated Transaction (MIT) is a card payment initiated by the merchant on behalf of a customer, pursuant to a prior agreement between them, without active customer participation at the time of the charge. When properly flagged, an MIT signals to the issuer that a prior consent record exists and that the merchant is authorized to charge the customer's stored credential under the agreed terms. MITs are frequently used for recurring or subscription billing to simplify repeat charges. Note that specific categorization rules, flagging requirements, and credential-on-file handling are governed by card brand and network rules, which vary by region and change over time; practitioners should confirm current requirements against the applicable network specifications and processor documentation.

Why it matters

Merchant-initiated transactions underpin much of the recurring economy: subscriptions, installment plans, and other repeat charges depend on a merchant's ability to charge a stored credential without the customer being present at the moment of each payment. Because the customer is not actively participating, issuers rely on the MIT flag and the underlying prior consent record to distinguish a legitimate, agreed-upon charge from an unauthorized one. Proper categorization and flagging are therefore central to whether these transactions are approved smoothly or declined, and they influence how disputes are evaluated.

Misclassifying transactions—labeling a customer-initiated payment as an MIT, or vice versa—can lead to authorization problems, higher decline rates, and weaker standing in dispute scenarios. Conversely, a properly flagged MIT signals to the issuer that a prior consent record exists and that the merchant is authorized to charge the stored credential under the agreed terms, which helps support the legitimacy of the charge. The strength of that signal depends on the merchant maintaining an accurate record of the customer's original agreement.

Because categorization rules, flagging requirements, and credential-on-file handling are governed by card brand and network rules that vary by region and change over time, practitioners cannot treat MIT handling as static. Teams should confirm current requirements against the applicable network specifications and processor documentation rather than relying on assumptions, since incorrect handling can affect both transaction success and how customer consent is demonstrated when challenged.

Who it's relevant to

Subscription and recurring-billing merchants
Businesses that charge stored payment methods on an ongoing basis rely on MITs to simplify repeat billing. They need to obtain and retain a proper customer consent record and flag transactions correctly so charges are recognized as authorized under the prior agreement.
Payment processors and gateways
Processors and gateways implement the categorization and flagging logic that distinguishes merchant-initiated from customer-initiated transactions. They must align their handling of credentials on file with the applicable card brand and network rules and expose the correct flags to issuers.
Issuers
Issuers evaluate MIT flags to determine that a prior consent record exists and that the merchant is authorized to charge the stored credential under the agreed terms. Accurate flagging informs their authorization decisions for transactions where the customer is not actively present.
Fraud and risk analysts
Because MITs occur without active customer participation, risk teams need to distinguish legitimate merchant-initiated charges from unauthorized use of stored credentials. Understanding how MITs are flagged and how prior consent is recorded supports the assessment of disputes and anomalous charge patterns.
Compliance and product teams
Teams responsible for network rule adherence must track that MIT categorization, flagging requirements, and credential-on-file handling follow current card brand and network rules, which vary by region and change over time, and confirm implementations against applicable network specifications and processor documentation.

Inside MIT

Merchant-Initiated Transaction (MIT)
A transaction initiated by the merchant, rather than the cardholder actively participating at the moment of the charge, under a prior agreement with the cardholder. MITs typically follow an initial cardholder-initiated transaction (CIT) that establishes consent and captures credentials.
Prior cardholder agreement
The mandate or consent established during a cardholder-initiated transaction that authorizes the merchant to charge the stored credential for subsequent MITs. The terms of that agreement (amount, timing, purpose) shape which MIT category applies.
MIT categories
MITs are commonly classified by network rules into types such as recurring payments, installments, unscheduled credential-on-file charges, incremental authorizations, reauthorizations, delayed charges, resubmissions, and no-show charges. Specific definitions and required indicators are defined by each card brand and vary by region.
Stored credential-on-file (COF)
Cardholder data retained by or on behalf of the merchant to enable future transactions. Under PCI DSS, any stored PAN must be protected by defined controls (for example rendered unreadable), and sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs must not be stored after authorization even if encrypted.
Transaction indicators and identifiers
Data elements sent in authorization messages to flag a transaction as merchant-initiated and to reference the original transaction that established the mandate (for example a transaction identifier returned on the initial CIT). Exact field names, values, and requirements are set by card brand and network rules.
Relationship to authentication controls
Because the cardholder is not present to authenticate at the time of an MIT, controls such as 3-D Secure or strong customer authentication are generally applied to the initial CIT that establishes the agreement rather than to each subsequent MIT. How exemptions or out-of-scope treatment apply is governed by applicable network and regulatory rules, which vary by region.

Common questions

Answers to the questions practitioners most commonly ask about MIT.

Does classifying a transaction as an MIT mean strong customer authentication and cardholder verification never apply?
No. An MIT is a transaction the merchant initiates based on prior agreement with the cardholder, without the cardholder actively participating at that moment. The initial transaction or agreement setup that establishes the mandate typically involves the cardholder and may itself require cardholder authentication such as 3-D Secure or applicable strong customer authentication under regional rules. The MIT designation applies to subsequent merchant-initiated charges, not to the original consent event. Whether authentication is required, and which exemptions or out-of-scope conditions apply, is governed by card brand and network rules and regional regulations that vary and change, so confirm against current requirements rather than assuming the label alone removes all authentication obligations.
Is an MIT just another name for a recurring or subscription payment?
Not exactly. Recurring or subscription billing is one category of MIT, but the term is broader. MITs also include use cases such as unscheduled charges against stored credentials, incremental charges, delayed or partial charges, reauthorizations, and no-show or account top-up scenarios, depending on how card brands and networks define and classify them. Treating MIT and recurring payment as synonyms can lead to incorrect transaction indicators being submitted. The specific MIT category and its associated data fields and indicators are defined by card brand and network rules, which vary by region and change over time.
How is an MIT distinguished from a customer-initiated transaction (CIT) in message data?
MITs and CITs are generally differentiated using transaction-type indicators and related data elements carried in the authorization message, along with references linking a stored-credential MIT back to the original cardholder-authenticated transaction. The exact fields, indicators, and linkage values are specified by card brand and network rules and by acquirer and processor implementation guides. Because these formats and values differ by network and region and are updated periodically, confirm the current field definitions with your acquirer or processor rather than relying on fixed values.
What data may I store to support future MITs, and how does that affect PCI DSS scope?
Supporting future MITs typically requires retaining a stored credential or a reference to it plus certain cardholder data such as the primary account number and expiration date under defined controls. Sensitive authentication data, including full track data, card verification codes such as CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be retained after authorization, even when encrypted. Storing the underlying account data keeps those systems in PCI DSS scope. Using tokenization to replace the PAN with a token can reduce scope, but the actual scope impact depends on the implementation and validation, not on the label; verify against the current published PCI DSS.
How should I handle the initial transaction that establishes the credential for later MITs?
The initial or setup transaction is generally treated as a customer-initiated transaction where the cardholder is present and can be authenticated, for example through 3-D Secure or applicable strong customer authentication where required by regional rules. This initial event commonly produces the reference or credential linkage used to associate subsequent MITs with the original authenticated transaction. The specific indicators, whether a zero-value or account-verification message is used for setup, and how the linkage is carried forward are defined by card brand and network rules and your processor's implementation guidance, which vary by region and change over time.
How do MITs interact with liability and chargeback outcomes for disputed charges?
Liability shift, dispute rights, and chargeback handling for MITs are governed by card brand and network rules, which vary by region and are updated periodically. Correctly flagging a transaction as an MIT with the appropriate stored-credential linkage and category indicators may affect how a dispute is evaluated, but it does not by itself determine the outcome or eliminate chargeback risk. Disputes may still arise from cardholder claims, cancellation-of-agreement scenarios, or first-party or friendly fraud. Consult your acquirer and the applicable network dispute rules for the current, region-specific treatment rather than assuming a fixed result.

Common misconceptions

An MIT is just any card-not-present transaction where the cardholder is not typing in their card.
Not all card-not-present activity qualifies as an MIT. An MIT depends on a prior cardholder agreement and correct classification and flagging under card brand and network rules. A transaction where the cardholder is actively completing a checkout using stored details may still be a cardholder-initiated transaction rather than an MIT.
Storing a credential on file for MITs means the merchant can keep whatever card data it captured, as long as it is encrypted.
Storing a credential on file does not permit retaining sensitive authentication data. Full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks must not be stored after authorization even when encrypted. Cardholder data such as the PAN may be stored only under defined PCI DSS controls, and requirement wording and numbering should be confirmed against the current published standard.
Because MITs skip cardholder authentication at charge time, the merchant carries no chargeback or fraud risk once the mandate is set.
Correctly flagging a transaction as an MIT does not eliminate fraud or chargeback exposure. Liability shift, chargeback rights, and dispute rules are governed by card brand and network rules that change and vary by region, and MITs remain exposed to disputes such as friendly or first-party fraud.

Best practices

Establish and document the cardholder agreement during the initial cardholder-initiated transaction, capturing the scope and purpose of future charges, and retain evidence of that consent to support later MITs and dispute handling.
Apply the correct MIT category and required transaction indicators and identifiers per each applicable card brand's rules, and confirm current field definitions rather than assuming values carry over unchanged between versions or regions.
Ensure stored credentials meet PCI DSS controls for cardholder data and confirm that sensitive authentication data is not retained after authorization; validate this against the current published standard rather than a fixed requirement number.
Distinguish tokenization, encryption, truncation, masking, and hashing when protecting stored PANs, and validate the chosen method's effect on scope through implementation and assessment rather than relying on the label.
Use appropriate authentication on the initial CIT that establishes the mandate, and confirm how 3-D Secure or strong customer authentication exemptions apply to subsequent MITs under the relevant network and regional rules.
Monitor MIT activity for fraud and dispute trends, recognizing that detection controls involve false-positive and false-negative trade-offs and that no single control eliminates fraud or chargeback exposure.