How Customer-Initiated Transaction (CIT) Works
A Customer-Initiated Transaction begins the moment a cardholder actively decides to pay. The flow covers everything from the customer entering their card details to the issuer returning an authorization decision. Understanding each step helps merchants design checkout flows that maximize approval rates and maintain compliance.
Customer presents payment credentials
The cardholder enters their card number, expiry, and CVV at an online checkout, taps their card at a physical terminal, or selects a saved card from their wallet. The transaction is flagged as customer-present in the payment request.
Merchant evaluates SCA obligation
The merchant or payment gateway determines whether Strong Customer Authentication is required. For most card-not-present CITs within the EEA, SCA is mandatory under PSD2 unless a valid exemption applies (low-value, TRA, trusted beneficiary).
3DS challenge or frictionless flow
If SCA is required, the transaction is routed through 3D Secure. The issuer either completes frictionless authentication (passive risk check) or issues a challenge requiring the customer to verify their identity via OTP, biometric, or app notification.
Authentication result is returned
A successful authentication produces an authentication value (CAVV/AAV), an ECI indicator, and a 3DS transaction ID. These values are passed to the acquirer in the authorization request to signal that SCA was performed.
Authorization request sent to issuer
The acquirer forwards the authorization request — including authentication data, transaction amount, MCC, and merchant details — to the card issuer via the card network (Visa, Mastercard, etc.).
Issuer approves or declines
The issuer validates the authentication data, checks the cardholder's account status and available balance, applies its own risk models, and returns an approval or decline with a response code. Approval confirms the transaction; the merchant can capture funds.
Card-on-file credential stored (if applicable)
For recurring billing setups, the merchant stores a card-on-file token and records the network transaction ID from this CIT. This reference is required for all subsequent Merchant-Initiated Transactions in the series.
Why Customer-Initiated Transaction (CIT) Matters
CITs are the gateway to every card-on-file relationship. Without a properly authenticated CIT at the start of a subscription or recurring billing series, every subsequent merchant-initiated charge lacks a valid mandate — increasing decline rates and exposing merchants to chargebacks.
Fraud and compliance stakes are high. According to Mastercard's published guidelines, a merchant that correctly applies 3DS on a CIT receives a liability shift: fraud-related chargebacks are transferred to the card issuer, not absorbed by the merchant. For subscription businesses with large transaction volumes, this shift can represent significant chargeback cost savings annually.
Authorization rates are directly tied to CIT authentication quality. Visa's data indicates that transactions sent with full 3DS authentication data see up to 8% higher approval rates compared to non-authenticated card-not-present transactions, because issuers treat authenticated transactions as lower risk. Incomplete or missing authentication data is one of the leading causes of soft declines on first-time customer purchases, with some studies placing avoidable soft decline rates at 10–15% of CNP volume when authentication is improperly implemented.
PSD2 Scope
SCA requirements apply to electronically initiated payment transactions within the EEA where both the merchant's acquirer and the cardholder's issuer are located in the EEA. Transactions outside this scope may still benefit from 3DS for fraud protection and liability shift, even if SCA is not legally mandated.
Customer-Initiated Transaction (CIT) vs. Merchant-Initiated Transaction (MIT)
The CIT/MIT distinction is the foundational classification that determines SCA obligations, liability allocation, and how card networks route and approve recurring charges. Confusing the two leads to compliance violations, elevated declines, and disputed chargebacks.
| Dimension | Customer-Initiated Transaction (CIT) | Merchant-Initiated Transaction (MIT) |
|---|---|---|
| Who triggers it | Cardholder, in real time | Merchant, without cardholder present |
| SCA required | Yes (with exemptions) | No — mandate set during prior CIT |
| 3DS applicability | In scope | Out of scope (MIT flag sent instead) |
| Liability for fraud chargebacks | Shifts to issuer if 3DS passed | Merchant bears liability (or issuer if mandate authenticated) |
| Examples | Checkout purchase, subscription sign-up | Monthly renewal, usage-based billing |
| Network transaction ID | Generated here | References original CIT transaction ID |
| Cardholder authentication | Required | Not applicable |
| CVV submission | Allowed | Not permitted (stored credential rules) |
Types of Customer-Initiated Transaction (CIT)
CITs are not limited to simple one-time purchases. They appear across multiple payment scenarios, each with slightly different data requirements.
One-time purchase (card-not-present): The most common CIT — a customer buying a product online, entering card details fresh, with no prior relationship. SCA is standard; no card-on-file token is stored afterward.
First payment in a recurring series: The initial charge when a customer subscribes to a SaaS product, streaming service, or membership. This CIT establishes the mandate and must include the recurring indicator so the issuer is aware future MITs will follow.
Card-present transaction: A customer tapping, dipping, or swiping their card at a physical point-of-sale terminal. SCA is fulfilled via chip-and-PIN or biometric. Liability shift applies automatically under EMV rules.
Installment payment initiation: When a customer agrees to split a purchase into fixed installments at checkout, the first installment charge is a CIT. Subsequent installments may be processed as MITs referencing this initial transaction.
Wallet-initiated payment: Payments made via Apple Pay, Google Pay, or similar wallets are CITs — the cardholder actively authenticates via device biometric, and tokenized card credentials are sent. These typically benefit from frictionless SCA treatment.
Best Practices
For Merchants
Always apply 3DS on the first transaction of any card-on-file relationship, even if SCA is not legally required. The liability shift and mandate establishment are worth the minor friction increase. Clearly disclose recurring billing terms at the point of the CIT so customers understand they are authorizing future charges — undisclosed recurring billing is the primary driver of friendly fraud chargebacks on subscription businesses. Store the network transaction ID returned from every CIT authorization; without it, downstream MITs will lack the required mandate reference and face higher decline rates from issuers.
Use SCA exemptions strategically. Low-value exemptions (under €30) are useful for micro-transactions, but applying them indiscriminately on high-value first purchases increases the risk of issuer challenge or decline. Work with your payment provider to set exemption thresholds based on your actual transaction risk profile.
For Developers
Send the correct transaction type flag in your payment request. Card networks and processors use specific fields — such as initiated_by: customer and stored_credential_usage: first — to distinguish CITs from MITs. Incorrect flagging causes misrouting and compliance failures. Store authentication results (ECI, CAVV, 3DS transaction ID) at the transaction level, not just at the customer level, so each authorization request carries the correct data.
Implement payment authentication retry logic for soft declines. When an issuer requests authentication (response code 65 or equivalent), your integration should re-submit through 3DS rather than abandoning the transaction. This recovers a meaningful portion of revenue that would otherwise be lost to SCA-related declines.
Common Mistakes
Skipping 3DS on subscription sign-ups. Some merchants exempt the first charge to reduce friction, then attempt MITs without a properly authenticated mandate. Issuers increasingly decline MITs that lack a valid CIT reference, and no liability shift exists for the original charge if fraud occurs.
Sending CVV on repeat CITs using stored cards. When a returning customer pays with a card-on-file, merchants must not transmit the CVV — card network rules prohibit storing CVV post-authorization. Sending a fabricated or blank CVV can trigger hard declines or card scheme violations.
Misclassifying installment initiation as a one-time transaction. If the recurring or installment flag is omitted on the CIT, subsequent installment charges will not have a valid mandate reference, leading to higher decline rates and potential scheme penalties.
Ignoring soft decline codes. Response code 65 (authentication required) is an issuer instruction to re-run through 3DS, not a final decline. Merchants that treat it as a hard decline lose recoverable revenue. Build handling for this code into your authorization retry logic.
Failing to pass authentication data to the acquirer. Completing 3DS but omitting the ECI indicator and authentication value from the authorization request means the issuer never sees proof of authentication. The transaction is treated as non-authenticated, liability shift does not apply, and approval rates suffer accordingly.
Customer-Initiated Transaction (CIT) and Tagada
Tagada's payment orchestration layer handles CIT classification and authentication data routing automatically across all connected processors and acquirers. When a transaction enters Tagada's flow, it is evaluated against SCA rules, exemption thresholds, and card network requirements before being dispatched — ensuring the correct authentication data is attached to every authorization request.
When setting up a new subscription product on Tagada, configure the recurring indicator at the plan level rather than per-transaction. Tagada will automatically mark the first charge as a CIT with mandate establishment and all subsequent renewals as MITs with the correct network transaction ID reference — eliminating manual flagging errors that cause decline spikes on renewal cycles.