What is Cardholder-initiated transaction?
Also: CIT
A transaction initiated by the cardholder in real time, typically the first charge that establishes credential-on-file.
A Cardholder-Initiated Transaction (CIT) is a payment authorised in real-time by the cardholder, who is actively present in the Checkout flow.
This is the most common type of transaction, covering standard online purchases where a customer enters their card details or uses a saved card to complete a payment.
In the context of recurring billing and subscriptions, the initial CIT plays a crucial role beyond simply processing the first payment. It serves to establish a formal agreement, or mandate, between the cardholder and the merchant, authorising future charges against the stored credential.
Under regulations like PSD2 in the European Economic Area and the UK, this initial CIT is typically subject to Strong Customer Authentication (SCA). The cardholder must verify their identity using a method like 3D Secure, which involves two-factor authentication.
During this authenticated transaction, the merchant must send specific data flags to the acquirer indicating that the card is being stored for future use. Upon successful authorisation, the scheme provides a unique transaction identifier.
The merchant is required to store this identifier and use it to link all subsequent Merchant-Initiated Transactions (MITs) back to this original, authenticated event.
A common misunderstanding is thinking any use of a saved card is an MIT; if the cardholder logs in and actively confirms a purchase with a stored card, it is still a CIT.
Worked example
A customer in the UK signs up for a £25 per month subscription box. They enter their card details on the Checkout page and click 'Subscribe'.
This action initiates a Cardholder-Initiated Transaction (CIT). Because the merchant and customer are in an SCA-regulated region, the merchant's gateway triggers 3D Secure.
The customer is redirected to their banking app to approve the £25 payment. Once approved, the payment is authorised successfully.
In the background, the merchant's payment provider flags this transaction to the scheme as a CIT that is establishing credentials for future use.
The response from the acquirer includes a scheme transaction ID, which the merchant stores securely in their vault, linked to the customer's new subscription record. This properly executed CIT now permits the merchant to charge the card automatically via MITs each month.
Scheme notes
Visa and Mastercard have closely aligned their rules for CITs, especially for flagging credential-on-file agreements. Both schemes require merchants to include specific indicators during the first CIT to signal that a card is being stored and that consent for future charges is being obtained.
If these flags are not sent, an issuer may decline future MITs because no valid mandate was established. The schemes also mandate that this initial CIT must be authenticated using SCA (where applicable).
Failure to perform SCA on the initiating CIT invalidates the SCA exemption for all subsequent MITs, leading to widespread declines.
While Amex and Discover follow the same principles, the technical flagging requirements can differ slightly, making it important to use a gateway that normalises these requests.
Why it matters for merchants
Correctly processing the initial CIT is the foundational step for any recurring revenue business. It is the moment of compliance where the merchant secures the cardholder's authenticated consent for future billing.
Getting this wrong can cripple a subscription model, as subsequent automated payments (MITs) will be declined without it, leading to massive Involuntary churn. For merchants operating in SCA regions, a failure to properly authenticate the CIT essentially makes automated recurring billing impossible.
Using a modern payment gateway or orchestration provider like Cardflo is critical, as the platform manages the complex flagging and data submission requirements for CITs across different schemes and acquirers, ensuring a valid mandate is established from day one.
Frequently asked
Why is the transaction ID from a CIT important for recurring billing?
The transaction ID proves to the issuer that a cardholder-initiated authentication occurred previously.
Merchants must include this original ID in future Merchant-initiated transaction (MIT) requests to indicate the payment is part of an established chain, which helps maintain higher authorisation rates and ensures compliance with scheme rules.
Can a CIT be exempt from Strong Customer Authentication (SCA)?
While CITs are the primary target for SCA, certain exemptions may apply depending on the transaction value or the acquirer’s fraud rates.
Low-value transactions under thirty Euros or those deemed low risk through Transaction Risk Analysis (TRA) might bypass Step-up authentication, though the issuer ultimately retains the right to demand a challenge.
Does every CIT require Strong Customer Authentication (SCA)?
In SCA-regulated regions like the UK and EEA, most CITs do require SCA. However, there are exemptions.
For example, low-value transactions (under €30, up to a cumulative limit of €100 or five transactions), or transactions identified as low-risk via a Transaction Risk Analysis (TRA) exemption, may not require it.
However, when a CIT's purpose is to set up a subscription or recurring mandate, it is best practice to always perform SCA to ensure subsequent MITs are approved without issue.
What data must be stored from the initial CIT?
The most critical piece of data to store from a successful CIT is the unique transaction identifier provided by the card scheme (sometimes called Scheme Transaction ID, DS Transaction ID, or similar). This identifier is the cryptographic proof of the original authenticated transaction.
You must store this ID and include it in the authorisation request for every subsequent MIT. Storing this link is a core requirement of the Visa and Mastercard Stored Credential Transaction framework.
If a customer uses a saved card, is it a CIT or an MIT?
It depends on who initiates the charge. If a customer is logged into their account, adds an item to their basket, proceeds to Checkout, and actively clicks a 'Pay Now' button using their saved card details, it is a CIT.
The cardholder is present and initiating the payment. An MIT only occurs when the merchant initiates the charge without the cardholder's active involvement in that specific transaction, such as for an automated monthly subscription renewal.
Can a £0 or €0 authorisation be used as the initial CIT?
Yes, a zero-value authorisation can be used to validate a card and establish a mandate. This is a common practice during sign-ups for free trials.
The transaction is still processed as a CIT, must undergo SCA where required, and will return a scheme transaction ID that can be stored for future use.
However, some issuing banks have lower approval rates for zero-value authorisations compared to small-value transactions (e. g. , £1), so testing is advised.
What happens if the initial CIT is declined?
If the initial CIT is declined, the payment fails, and no mandate is created. The customer cannot complete their purchase or sign-up, and no credentials can be stored for future use.
The merchant should display the decline reason to the customer if possible and ask them to try again or use a different payment method. No MITs can be attempted until a CIT is successfully authorised and authenticated.
See how Cardholder-initiated transaction plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Related terms
A charge initiated by the merchant against a previously stored credential, without the cardholder present.
PSD2 requirement that customer-initiated electronic payments in the EEA and UK be authenticated with two of: knowledge, possession, inherence.
A card-network authentication protocol that shifts fraud liability from the merchant to the issuer when a cardholder is verified.
A PCI DSS compliant store of tokenised card credentials that lets a merchant charge a card again without holding the PAN.
Related guides.
From the blog
The subscription model provides predictable revenue through recurring fees for SaaS and streaming services. While it fosters long-term customer loyalty, businesses must manage higher acquisition costs and potential churn. This approach offers stability for companies providing ongoing value through continuous access to products. It is designed to generate a steady income stream and build relationships.
Read articleSubscription payments are a specific subset of recurring billing where customers pay at the start of each cycle. These automated payments occur at weekly, monthly, or annual intervals until the service is terminated. This model helps businesses reduce churn and secure predictable revenue while helping customers budget effectively. It is an ideal system for strengthening long term loyalty.
Read articleA recurring payment is an automated billing system where a customer authorises a business to charge their card or bank account at regular intervals. This model is common for gym memberships, insurance premiums, and streaming services. It provides convenience for consumers while ensuring consistent revenue for service providers. Payments occur at fixed or variable amounts without manual customer input.
Read articleReady to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.