Every card transaction is classified by the card networks as either customer-initiated (CIT) or merchant-initiated (MIT). The distinction sounds technical, but it determines how the issuing bank treats the transaction, whether Strong Customer Authentication is required, how decline rates behave, what fees apply, and whether the merchant is exposed to chargeback liability. Misclassified transactions decline more often, trigger unnecessary authentication friction, and increase compliance risk. Correctly classified transactions process cleanly and benefit from rules designed specifically for their category.
For subscription businesses, marketplaces, and any merchant running card-on-file or recurring billing, the CIT-MIT framework is the single most important set of rules to get right. It governs everything from when 3D Secure is required to how the new Mastercard Transaction Link Identifier propagates across renewals.
This guide explains what CITs and MITs are, the eight MIT use cases the card networks formally recognize, the indicators that must accompany each one, how SCA exemptions work, and what merchants need to do to keep their transactions correctly classified across multiple PSPs and acquirers.
A customer-initiated transaction (CIT) is a payment where the cardholder is actively present and participating in the transaction at the moment it happens, providing card details, authorizing the charge, or completing authentication in real time.
A merchant-initiated transaction (MIT) is a payment that the merchant triggers without the customer’s active involvement at the moment of the charge, based on a prior agreement with the cardholder that authorized the merchant to do so.
The distinction comes down to who initiates the authorization at the moment it occurs, regardless of who benefits from the transaction. Both transaction types flow through the same card networks, but the networks apply different rules to each.
| Dimension | Customer-Initiated Transaction (CIT) | Merchant-Initiated Transaction (MIT) |
|---|---|---|
| Customer presence at authorization | Yes, actively involved | No, processed without participation |
| Strong Customer Authentication required | Yes (in SCA-regulated regions) | No, exempt when properly flagged |
| 3D Secure | Applied at the time of transaction | Performed once on initial CIT, then carried forward |
| Decision authority | Customer authorizes each transaction | Customer authorized in advance |
| Common examples | Online checkout, one-click repeat purchase, manual recurring confirmation | Subscription renewal, installment payment, account top-up, no-show fee |
| Risk profile | Higher fraud risk per transaction | Lower risk, governed by prior consent |
| Chargeback liability | Standard rules apply | Specific MIT chargeback codes |
| Authorization rates | Variable, dependent on 3DS, fraud, AVS | Often higher when properly classified |
| Required indicators | Standard CIT flag | MIT type indicator plus original transaction reference |
| Network transaction ID propagation | Generated at CIT | Must be passed forward from CIT |
The defining mechanic across all these differences is the same: a CIT establishes the consent and the credential relationship, and every subsequent MIT references that original CIT to inherit its authorization context. Get the link right and the chain works. Get it wrong and the chain breaks, with every MIT in the broken chain treated as a fresh, suspicious, fully-authenticatable transaction.
Visa formalized the modern MIT framework in 2017. Mastercard updated theirs in late 2021 to include eight specific use cases, broadly aligned with Visa’s framework. Every MIT must be classified as one of these eight types, and the classification affects how the transaction is processed:
Scheduled, fixed-frequency payments of a fixed or variable amount, agreed to in advance. The classic example is a monthly subscription. Visa’s indicator for recurring CIT storage is R (credential stored for subsequent recurring MITs).
Scheduled payments of a known total amount, split into a defined number of installments. Common in BNPL and large-purchase financing. Visa’s indicator is I (credential stored for subsequent installment MITs).
Payments triggered by an event rather than a schedule, against a stored credential. Examples include account top-ups, automatic refills, and one-tap repeat purchases initiated by the merchant based on a stored agreement. Visa’s indicator is C (credential stored for unscheduled subsequent MITs or for subsequent CITs).
A merchant-initiated retry of a transaction that previously declined for specific reasons (typically insufficient funds), submitted under the original authorization context. Must reference the original CIT’s network transaction ID.
A charge submitted after the original CIT, typically for incremental services or additional costs that were authorized as part of the original agreement. Common in hospitality (minibar charges added after checkout) and rental services (additional usage fees).
A charge applied when a customer fails to honor a reservation, with prior authorization from the original booking CIT. Standard in hotels, restaurants, car rentals, and any reservation-based business.
A new authorization request for a transaction whose original authorization has expired or whose amount needs adjustment, against the same stored agreement. Common in travel and hospitality for extended stays.
An additional authorization on top of an existing one, to increase the authorized amount as services accumulate. Common in fuel pumps, hotels (incidentals), and any transaction with growing or uncertain final amounts.
Each of these eight types has a specific transaction indicator that must be sent with the authorization request. Sending the wrong indicator (or no indicator) can cause the issuer to decline the transaction, treat it as a fresh CIT requiring authentication, or flag it for fraud review.
Every MIT depends on a prior CIT that established the consent and the credential storage. The chain works in three phases:
The customer reaches the merchant’s checkout, enters card details, and explicitly agrees to terms that authorize the merchant to use the stored credential for future transactions. In SCA-regulated regions, the merchant must perform Strong Customer Authentication on this CIT (typically through 3D Secure 2 with a challenge if the issuer requires it).
The merchant must:
The card is stored in a secure vault, typically with network tokenization layered on top to handle automatic credential lifecycle updates. The stored credential is linked to:
This metadata is what makes future MITs work. Without it, every renewal looks like a fresh, suspicious card-not-present transaction.
When the merchant initiates a future charge (subscription renewal, installment, top-up, etc.), the authorization request includes:
The issuer sees the chain: “this MIT is part of an installment plan authorized in CIT X, processed Y days ago, with this customer.” The issuer treats it as a low-risk transaction governed by prior consent and approves it without requiring fresh authentication.
If any link in this chain breaks (missing network transaction ID, wrong MIT indicator, lost TLID), the issuer loses the context. The transaction looks like a fresh card-not-present charge with no consent history, and gets treated accordingly: higher decline rates, fraud flags, and in SCA regions, demands for re-authentication that cannot be satisfied because the customer is not present.
For more on Mastercard’s TLID specifically and how it propagates across the chain, see Gr4vy’s guide on the Mastercard Transaction Link Identifier mandate.
Under PSD2 in Europe (and similar regulations in the UK, Japan, and a growing list of jurisdictions), most electronic payments require Strong Customer Authentication. The MIT framework provides a critical exemption: properly classified MITs are out of scope for SCA, because the authentication happens once on the original CIT and is carried forward through the MIT framework.
For an MIT to qualify for SCA exemption, two conditions must be met:
If either condition fails, the MIT loses its exemption status and the issuer is entitled to decline it or demand re-authentication.
This is why correct MIT classification is not optional for European subscription businesses. A misclassified MIT in an SCA-regulated market is a transaction that will decline more often, trigger 3DS challenges that cannot complete (the customer is not present), and create chargeback exposure that the merchant cannot defend.
The same logic applies to Japan’s SCA mandate, the upcoming PSD3/PSR rules in Europe, and the gradual rollout of SCA-equivalent requirements in other markets. Markets that do not have explicit SCA mandates still benefit from correct MIT classification because issuers in those markets use the same indicators to inform their risk decisioning.
Across both Visa and Mastercard, the network transaction ID (Visa Transaction ID, Mastercard scheme transaction ID) is the single most important field in the MIT chain. It is the value the issuer uses to confirm that the current MIT belongs to a previously-established stored credential relationship.
A few important properties:
For Mastercard transactions, the Transaction Link Identifier (TLID) introduced in 2024-2026 supplements the existing scheme transaction ID with a stronger, network-generated linkage value. From October 23, 2026, merchants must include the stored TLID in every economically-related MIT. The TLID does not replace the network transaction ID; both are required during the transition period.
Correct MIT classification requires the merchant’s authorization request to include the right combination of indicators. The exact field names vary by PSP, but the underlying network requirements are the same:
| Field | What it indicates |
|---|---|
| Initiator | Customer (CIT) or Merchant (MIT) |
| Stored Credential indicator | First storage, subsequent use, or no stored credential involved |
| Credential Type | Recurring, installment, unscheduled COF, or general subsequent CIT |
| MIT use case | One of the eight recognized types (recurring, installment, UCOF, resubmission, delayed charge, no-show, reauthorization, incremental) |
| Network Transaction ID | The value from the original CIT or prior MIT in the chain |
| Mastercard TLID | (Mastercard transactions) The Transaction Link Identifier from the original CIT |
| POS Entry Mode | Indicates the transaction was processed using stored credentials |
For most modern PSPs and orchestration platforms, these indicators are handled at the integration layer rather than being passed explicitly by the merchant’s application. The merchant configures the transaction type once (subscription, installment, etc.) and the platform translates the configuration into the correct combination of network indicators for each authorization request.
For a deeper view of how the tokenization layer interacts with MIT classification, see Gr4vy’s guide on PSP tokens vs network tokens.
For single-PSP merchants, MIT classification is operationally straightforward. The PSP captures the original CIT, returns the network transaction ID, stores it alongside the merchant’s customer reference, and submits it on every subsequent MIT.
For multi-PSP merchants, the chain becomes fragile. If an original CIT is processed through Acquirer A and a subsequent renewal is routed through Acquirer B, the network transaction ID and TLID need to be portable across the boundary. Three failure modes are common:
Failure 1: Acquirer-locked transaction ID storage. If the network transaction ID is stored inside Acquirer A’s records rather than at the merchant or orchestration layer, Acquirer B cannot reference it on the renewal. The MIT loses its CIT linkage and is treated as a fresh card-not-present transaction.
Failure 2: Inconsistent indicator application. Different PSPs implement MIT indicators slightly differently. The same logical transaction (a subscription renewal) might be flagged correctly through one PSP and incorrectly through another. The issuer sees inconsistent signals and decisions vary.
Failure 3: Lost chain during PSP migration. When a merchant migrates from one PSP to another, the stored credential relationships and their associated network transaction IDs need to migrate with them. Without explicit migration, the renewal volume on the new PSP starts as if every customer were a brand new acquisition with no consent history.
The solution to all three failure modes is to maintain the network transaction ID, TLID, COF indicator, and MIT classification at the orchestration or merchant layer rather than inside any single PSP’s records. The orchestration platform captures the metadata from whichever PSP processes the original CIT and propagates it to whichever PSP processes the subsequent MITs.
The MIT framework was designed by Visa and Mastercard with the assumption that the merchant would maintain the chain metadata, but most early implementations defaulted to letting the acquirer handle it. As multi-PSP setups have become standard for enterprise merchants, the architectural correction has become important.
The rise of agentic commerce introduces a new question into the CIT/MIT framework. When an AI agent like ChatGPT or Gemini initiates a purchase on behalf of a customer, who initiated the transaction?
The card networks have not yet published comprehensive guidance on this question, but the operational consensus is forming around two principles:
Initial agent setup is a CIT. When the customer first authorizes an AI agent to make purchases on their behalf, providing consent and going through Strong Customer Authentication, that transaction is a CIT in the classical sense. The customer is present, providing credentials, and authorizing future activity.
Subsequent agent-initiated purchases are typically classified as MITs, with the agent’s instructions treated as part of the merchant-initiated chain. The specific MIT type depends on the use case: a scheduled agent purchase resembles a recurring MIT, while an on-demand agent purchase resembles an unscheduled COF.
The protocols emerging from Mastercard, Visa, OpenAI, Stripe, and others (including the Agentic Commerce Protocol and Universal Commerce Protocol) are formalizing this classification with new transaction indicators specific to agent-initiated flows. Merchants accepting agentic commerce should plan to support agent-specific MIT indicators alongside the existing eight use cases.
For a deeper view, see Gr4vy’s guide on making your checkout AI-agent-ready.
A handful of patterns consistently produce misclassified transactions and the avoidable declines they cause:
Treating a customer-initiated repeat purchase as an MIT. A returning customer logging in and clicking “buy again” is a CIT, even though the card was stored. The transaction is initiated by the customer at the moment it happens. Flagging it as an MIT can cause the issuer to apply different rules than it should, with unpredictable approval outcomes.
Treating a delayed merchant-initiated capture as an MIT. A customer who completes a CIT at checkout but whose charge is captured the next day is still a CIT. The latter capture happens against the original authorization, which was customer-initiated. The capture timing does not change the classification.
Missing the COF indicator on the original CIT. If the original CIT does not declare that credentials are being stored for future MITs, the chain cannot be established. Every subsequent MIT will lack the proper consent reference. This is one of the most common implementation mistakes.
Sending the wrong MIT type indicator. A recurring monthly subscription submitted with an installment indicator (or vice versa) creates inconsistency between what the issuer expects and what arrives. Decline rates rise even though the customer would have approved the transaction if it had been classified correctly.
Reusing one MIT indicator across all subsequent transactions regardless of purpose. Some merchants default all MITs to “recurring” because it covers the largest share of their volume. A no-show fee classified as recurring confuses the issuer’s risk model. Each MIT should carry the indicator that matches its specific purpose.
Losing the network transaction ID during PSP migration or routing changes. The chain breaks silently. Renewal authorization rates drop, but the cause is hidden in the indicator metadata rather than in any visible error. Audit migrations specifically to confirm the chain remains intact.
Skipping SCA on the initial CIT in regulated markets. Without SCA on the CIT, subsequent MITs do not qualify for SCA exemption. Every renewal becomes subject to authentication requirements that cannot be satisfied without the customer present. The result is a slow accumulation of declines on what should be a frictionless renewal flow.
Setting up correct MIT classification requires consistent handling across the entire payment stack. A practical checklist:
1. Identify every transaction in your stack as CIT or MIT. Map every flow that creates an authorization request and document which classification applies. Renewals, top-ups, no-show fees, delayed captures, and reauthorizations all need explicit classification.
2. For each MIT, identify the specific use case (recurring, installment, UCOF, resubmission, delayed charge, no-show, reauthorization, or incremental). The classification drives the indicator that must be sent.
3. Update CIT authorization requests to declare stored credential intent. Use the appropriate COF indicator (R, I, C, or other depending on the scheme) to tell the issuer the credential is being stored.
4. Capture and store the network transaction ID from every CIT response. This is the value that links subsequent MITs back to the original consent. Store it alongside the customer’s credential reference.
5. For Mastercard transactions, also capture and store the TLID in preparation for the October 23, 2026 mandate.
6. Include the network transaction ID (and TLID for Mastercard) in every subsequent MIT. The exact field names vary by PSP, but the values are required.
7. Ensure SCA is properly applied to CITs in regulated markets. Without authentication on the CIT, MIT exemptions do not apply.
8. Validate the chain across all your PSPs and acquirers. If you operate multi-PSP, verify that the network transaction ID, TLID, and indicators flow correctly across provider boundaries.
9. Monitor authorization rates and decline reasons by transaction type. A drop in MIT approval rates often points to misclassification or a broken chain rather than fundamental issues with the underlying credentials.
10. Document the classification rules in your operations runbook. New transaction types, edge cases, and integration changes should all be reviewed against the framework.
A customer-initiated transaction (CIT) is a payment where the cardholder is actively involved at the moment of the charge, providing card details or authenticating in real time. A merchant-initiated transaction (MIT) is a payment that the merchant triggers without the cardholder’s active involvement, based on a prior agreement established during an earlier CIT. The distinction determines authentication requirements, decline behavior, chargeback handling, and SCA exemption status.
Card networks apply different rules to each category. CITs require Strong Customer Authentication in SCA-regulated regions; MITs are exempt when properly flagged. Issuers use the classification to inform their risk decisioning, which affects authorization rates. Misclassified transactions decline more often, can trigger unnecessary authentication requests, and may create chargeback liability that the merchant cannot defend.
The card networks recognize eight MIT use cases: recurring payments, installment payments, unscheduled credential-on-file (UCOF), resubmission, delayed charge, no-show, reauthorization, and incremental authorization. Each use case has a specific transaction indicator that must accompany the authorization request to properly classify the transaction.
No, MITs are exempt from SCA when properly flagged, provided the original CIT that established the stored-credential relationship underwent SCA authentication. This is one of the primary reasons subscription businesses in Europe rely on the MIT framework: it allows recurring transactions to proceed without re-authenticating the customer for every renewal.
A subscription renewal is an MIT when the merchant triggers the renewal automatically based on the subscription schedule. The original sign-up (where the customer entered card details and agreed to terms) was the CIT. Every subsequent automatic renewal is a recurring MIT that references back to that original CIT.
Credential-on-File refers to the stored card data, which is a prerequisite for MITs but is not itself a transaction classification. A stored credential can be used for both subsequent CITs (when the customer returns and clicks “use my saved card”) and MITs (when the merchant triggers a transaction against the stored credential). The COF indicator at the original CIT declares what types of future transactions the stored credential authorizes.
The Mastercard Transaction Link Identifier (TLID) is a scheme-generated identifier that links the original CIT to all subsequent MITs at the network level. It supplements the existing network transaction ID with a stronger, more consistent linkage value. From October 23, 2026, merchants must include the stored TLID on every economically-related MIT authorization request.
For Visa, you can use the network transaction ID from any prior MIT in the chain when submitting a new MIT. For other schemes, you typically need to reference the ID from the original CIT or the relationship-establishment transaction. Most modern PSPs and orchestration platforms handle this automatically based on the configured transaction type.
Misclassified transactions can decline at higher rates because the issuer’s risk model receives inconsistent signals. In SCA-regulated regions, a misclassified MIT can lose its authentication exemption and be subject to challenge requests that cannot be satisfied without the customer present. Chargeback liability can also shift because MIT-specific dispute codes do not apply to misclassified transactions.
Yes, all major card networks (Visa, Mastercard, American Express, Discover) recognize the CIT-MIT distinction, though the specific indicators, use case definitions, and technical requirements vary slightly by scheme. Visa formalized the modern framework in 2017; Mastercard updated theirs in late 2021. American Express and Discover apply similar logic through their closed-loop systems.
When an AI agent like ChatGPT initiates a purchase on behalf of a customer, the initial setup (where the customer authorizes the agent and authenticates) is treated as a CIT. Subsequent agent-initiated purchases are typically classified as MITs, with the specific MIT type depending on the use case. The agentic commerce protocols emerging from Mastercard, Visa, and major AI platforms are formalizing this classification with new indicators specific to agent-initiated flows.
Store the original CIT’s network transaction ID (and Mastercard TLID where applicable), the COF indicator declaring what types of future transactions are authorized, the credential reference (typically a network token), and the customer’s consent record. This metadata should live at the merchant or orchestration layer rather than inside any single PSP’s records, particularly for multi-PSP setups where MITs may be routed through a different acquirer than the original CIT.
The network transaction ID (sometimes called Visa Transaction ID, Mastercard scheme transaction ID, or NTID) is a value generated by the card network at the time of authorization and included in the response. It serves as the reference that links subsequent MITs back to the original CIT. The merchant does not create it; the merchant receives it and stores it for use on future transactions.
Correct MIT classification is the foundation of every successful card-on-file and subscription business. Get it right, and authorization rates on renewals stay high, SCA exemptions apply cleanly, and chargeback defenses hold up. Get it wrong, and the symptoms appear gradually: declining renewal approval rates, mysterious authentication challenges on transactions that should be exempt, and chargeback losses on transactions that should have been defensible.
For most merchants, the work falls into two categories. The classification logic and indicator application can usually be handled at the PSP or orchestration layer, which is where it belongs architecturally. The harder problem is making sure the chain metadata (network transaction IDs, TLIDs, COF indicators, consent records) is stored at the merchant or orchestration layer rather than inside any single PSP’s records, so that it remains portable across PSP boundaries.
Gr4vy’s cloud-native payment orchestration platform handles MIT classification, network transaction ID propagation, and TLID management automatically across more than 400 connected PSPs and payment methods. The chain stays intact across routing decisions, PSP migrations, and multi-acquirer setups, with no merchant-side application code required to maintain it.
If you’re evaluating your current MIT classification setup or want to understand how chain metadata could be unified across your existing PSP relationships, contact our team for a stack review and integration plan tailored to your current architecture.
3D Secure 2 (3DS2) is the authentication protocol that decides whether most of your card-not-present…
Integration gives merchants direct access to global acquiring through orchestration, with control over routing, authentication,…
Peak moments don’t break systems by accident. They expose the limits that were always there.…
Mastercard is changing how transactions are tracked across the payment lifecycle. The Transaction Link Identifier…
Last updated May 21st 2026 Around half of online merchants now use more than one…
The complexity of managing digital transactions has grown exponentially as businesses expand their reach globally.…