Category: Transaction Processing

Cardholder-Initiated Transaction

Also known as: CIT, Customer-Initiated Transaction, Cardholder Initiated Transaction

Simply put

A Cardholder-Initiated Transaction (CIT) is a card payment that the cardholder actively starts and takes part in, such as entering their card details or authenticating a purchase. It contrasts with a Merchant-Initiated Transaction (MIT), which a merchant processes later without the cardholder being present. The distinction matters because card brand rules treat these transaction types differently, particularly when a card is stored for future use.

Formal definition

A Cardholder-Initiated Transaction (CIT) is a transaction within the card brand CIT/MIT framework in which the cardholder is actively present and participates in the payment flow, including providing payment credentials and, where applicable, authenticating the transaction. Under this framework, a CIT typically serves as the initial transaction that establishes cardholder consent and may create a stored credential (credential-on-file), after which subsequent follow-on transactions processed by the merchant without cardholder participation must be flagged and processed as Merchant-Initiated Transactions (MITs) according to the applicable MIT framework. The specific requirements for indicators, consent capture, and stored-credential handling are defined by individual card brand and network rules, which vary by region and change over time; practitioners should confirm current requirements against the relevant card brand specifications rather than assuming fixed rules. The CIT/MIT distinction governs transaction identification and processing and is separate from PCI DSS data-protection requirements for cardholder data and sensitive authentication data.

Why it matters

The Cardholder-Initiated Transaction (CIT) distinction is foundational to how card brands and networks want stored credentials handled. When a cardholder actively participates in a payment and consents to store their card for future use, that CIT typically establishes the consent and the credential-on-file relationship. Every follow-on transaction the merchant later processes without the cardholder present must then be identified and processed as a Merchant-Initiated Transaction (MIT) under the applicable MIT framework. Misclassifying these transactions can lead to declines, higher authorization friction, and non-compliance with card brand stored-credential requirements.

For merchants and processors, getting the CIT/MIT flagging right affects both approval rates and regulatory alignment. Correctly signaling that a transaction is cardholder-initiated—and capturing the required consent when a credential is first stored—helps issuers make better authorization decisions and supports downstream MIT processing. Because the specific indicators, consent-capture rules, and stored-credential handling requirements are defined by individual card brands and vary by region and over time, teams cannot assume a fixed rule set; they must confirm current requirements against the relevant card brand specifications.

It is important to keep the CIT/MIT framework separate from data-protection obligations. The framework governs transaction identification and processing, not how cardholder data or sensitive authentication data is stored and secured. PCI DSS data-protection requirements apply independently, and correctly flagging a transaction as a CIT does nothing to relieve a merchant of its obligations around protecting cardholder data or refraining from storing sensitive authentication data after authorization.

Who it's relevant to

Merchants storing cards on file

Any merchant that offers saved-card checkout, subscriptions, or repeat purchasing needs to identify the initial CIT correctly, capture the required cardholder consent, and ensure subsequent charges are processed as MITs. Correct handling supports the stored-credential requirements set by the card brands and can affect authorization outcomes.

Payment processors and acquirers

Processors and acquirers implement the CIT/MIT indicators in authorization messages and must map merchant transaction types to the appropriate flags. They are responsible for reflecting current card brand rules, which vary by region and change over time, and for helping merchants distinguish cardholder-initiated from merchant-initiated flows.

Fraud and risk analysts

Because CITs involve active cardholder participation while MITs do not, the distinction informs how risk teams reason about a transaction's context. Analysts should treat CIT/MIT flags as a processing signal within the card brand framework, not as a standalone fraud control, and should confirm how these flags interact with their broader detection strategy.

Compliance and product teams

Teams responsible for payment product design and compliance must align stored-credential experiences with the applicable card brand mandates for consent capture and transaction flagging. They should keep the CIT/MIT framework distinct from PCI DSS data-protection obligations, which apply independently to cardholder data and sensitive authentication data.

Inside CIT

Active Cardholder Participation

A CIT is a transaction that the cardholder actively initiates and is present for, either in a card-present setting or during a card-not-present interaction such as entering payment details on a website or in an app. This is the defining characteristic that distinguishes a CIT from a merchant-initiated transaction (MIT), where the merchant triggers a payment based on prior cardholder agreement.

Relationship to Merchant-Initiated Transactions (MIT)

The CIT/MIT distinction is used within card brand and network processing rules to classify who triggers a given transaction. A CIT is often the initial transaction that establishes cardholder consent and stored credentials, which may subsequently be used for MITs such as recurring or installment payments. The precise definitions and processing indicators are governed by card brand and network rules, which vary by region and change over time.

Authentication Context

Because the cardholder is present, a CIT can support cardholder authentication mechanisms appropriate to the channel, such as EMV chip authentication in card-present environments or 3-D Secure and strong customer authentication in card-not-present environments. These controls address different risks at different points in the transaction and no single control eliminates fraud.

Data Elements Involved

A CIT involves cardholder data such as the PAN, cardholder name, and expiration date, and during authorization may involve sensitive authentication data such as CVV2/CVC2/CID or PIN blocks. Sensitive authentication data must not be stored after authorization, even when encrypted, while some cardholder data may be stored under defined controls per the applicable PCI DSS requirements; confirm exact requirements against the current published standard.

Stored Credential Establishment

A CIT is frequently the point at which a cardholder consents to store their credentials for later use. How the stored credential is protected—through tokenization, encryption, truncation, or masking—depends on implementation and validation, and each of these transforms data differently with differing effects on PCI DSS scope.

Common questions

Answers to the questions practitioners most commonly ask about CIT.

Is a Cardholder-Initiated Transaction the same thing as a card-present transaction?

No. A CIT describes who initiates and is actively participating in the transaction at the time it occurs, namely the cardholder, regardless of channel. It can be card-present (for example, a chip or contactless purchase at a terminal) or card-not-present (for example, a cardholder actively completing an online checkout). The CIT versus MIT distinction is about the presence and active participation of the cardholder in initiating that specific transaction, not about whether the physical card is present. Confirm the applicable card brand and network definitions, which vary by region and change over time.

Does classifying a transaction as a CIT rather than a merchant-initiated transaction on its own reduce fraud or shift liability in the merchant's favor?

Not by itself. The CIT or MIT indicator is a classification used in transaction processing and, in some flows, in authentication and exemption handling; it is not a fraud control. Liability and chargeback outcomes are governed by card brand and network rules, which vary by region and change over time, and may depend on authentication performed, dispute reason codes, and other factors. Accurate CIT or MIT flagging is intended to help transactions be processed and evaluated correctly, but it does not guarantee any particular fraud reduction or liability result.

How should a merchant flag a transaction as a CIT in the authorization message?

Merchants and their processors typically populate the fields and indicators defined by the relevant card brand and network specifications to signal that the cardholder is present and actively initiating the transaction. The exact field names, values, and message formats depend on the acquirer, processor, and card brand specifications in effect, and differ by region and over time. Confirm the current requirements with your acquirer or processor and against the applicable published network specifications rather than assuming a fixed value.

When a cardholder sets up a subscription or stores their card for later, which parts are CITs and which are MITs?

Commonly, the initial transaction or credential-storage step where the cardholder actively participates is treated as a CIT, while subsequent charges made by the merchant without the cardholder present, such as recurring billing, are treated as MITs. The precise treatment, including any linking of the initial CIT to later MITs and any required indicators, is defined by card brand and network rules and by your processor's implementation. Verify the current rules with your acquirer or processor and against the applicable published specifications, as these vary by region and change over time.

How does CIT versus MIT classification interact with 3-D Secure and strong customer authentication?

Authentication such as 3-D Secure is generally applied when the cardholder is present and able to authenticate, which aligns with CIT flows; merchant-initiated transactions where the cardholder is not present are handled differently and may follow separate rules or exemptions. These are distinct mechanisms addressing different points in the transaction, and none eliminates fraud on its own. The specific requirements, exemptions, and how they map to CIT or MIT depend on the applicable card brand, network, and regional regulatory rules, which change over time; confirm against current published requirements.

Does the CIT or MIT distinction change how cardholder data and sensitive authentication data must be handled?

The classification of a transaction as a CIT or MIT does not alter the underlying data-handling obligations. Sensitive authentication data, such as full track data, card verification codes, and PINs or PIN blocks, must not be stored after authorization even when encrypted, while some cardholder data may be stored under defined controls. These data-protection expectations are governed by PCI DSS and related requirements, not by the CIT or MIT indicator. Confirm the specific applicable requirements against the current published standard.

Common misconceptions

A CIT is simply any card-present transaction, and card-not-present transactions are always merchant-initiated.

The CIT classification is about who initiates the transaction and whether the cardholder is actively participating, not about the physical channel. A cardholder entering payment details on a website performs a CIT even though it is card-not-present, while a recurring charge processed without the cardholder present is typically an MIT.

Because the cardholder is present and may authenticate, a CIT is effectively immune to fraud.

Cardholder presence and authentication controls such as EMV chip authentication, 3-D Secure, or strong customer authentication are intended to reduce specific fraud risks, but no single control eliminates fraud. CITs can still be exposed to risks such as account takeover, friendly or first-party fraud, and other schemes; liability outcomes are governed by card brand and network rules that vary by region and change over time.

Since the cardholder initiates the transaction, storing the full data captured during a CIT for later reuse is acceptable as long as it is encrypted.

Sensitive authentication data such as CVV2/CVC2/CID and PIN blocks must not be stored after authorization even when encrypted. Only certain cardholder data may be retained, and only under the controls defined in the applicable PCI DSS requirements; the classification as a CIT does not by itself permit storing sensitive authentication data.

Best practices

Correctly classify transactions as CIT or MIT using the current card brand and network processing rules for your region, and confirm the applicable transaction indicators against the current published rules rather than assumptions.

Apply channel-appropriate authentication during a CIT, such as EMV chip authentication in card-present environments and 3-D Secure or strong customer authentication in card-not-present environments, recognizing these address different risks and do not by themselves eliminate fraud.

Ensure sensitive authentication data captured during authorization of a CIT is not stored afterward, even in encrypted form, and validate retention practices against the current PCI DSS requirements.

When a CIT establishes a stored credential for later MITs, protect that credential using appropriate techniques such as tokenization or encryption, and validate the actual scope impact rather than relying on the label of the technique used.

Document and retain evidence of cardholder consent obtained during the initial CIT to support the legitimacy of subsequent merchant-initiated transactions and to help address disputes under applicable network rules.

Layer fraud detection appropriate to the CIT channel while accounting for false-positive and false-negative trade-offs, and monitor for risks such as account takeover and first-party fraud that cardholder participation alone does not mitigate.