Customer-initiated transaction
What is customer-initiated transaction?
Customer-initiated transaction (CIT) is a card payment that the cardholder actively starts and authenticates, such as entering card details at checkout or confirming a charge inside a banking app. The cardholder is present and takes a direct role in authorizing the payment.
A CIT covers any transaction the customer triggers in the moment – a one-off purchase, a bill payment, or saving a card on file for later use. It's the counterpart to a (MIT), where the merchant charges a stored card on the customer's behalf without them being present.
Card networks created the CIT/MIT distinction as part of their stored-credential rules. When a customer saves a card during a CIT, the transaction is flagged so any later merchant-initiated charges can be traced back to that original consent. The flag tells the whether a charge was authenticated by the cardholder or run automatically, which shapes how it assesses risk and applies authentication requirements. This is why the same card can behave differently depending on context: a payment the customer authenticates at checkout and an automatic renewal billed weeks later are treated as separate transaction types, even though the underlying credential is identical.
Key facts
- Also known as: cardholder-initiated transaction
- Applies to: card payments where the cardholder is present and authenticating in real time
- Authentication: secure login, multi-factor or , or biometric verification
- Common examples: a one-time checkout, the first payment of a subscription, or manually topping up an account balance
- Counterpart: merchant-initiated transaction (MIT), run against a stored card without the cardholder present
How it works
A CIT follows the same authorization path as any card payment, but it's defined by the cardholder's active role at the start. The flow runs in four stages:
- Initiation: The cardholder enters or selects their card details and submits the payment.
- Authentication: The cardholder confirms their identity through a password, one-time code, biometric check, or a 3-D Secure challenge where strong customer authentication applies.
- Authorization: The request routes through the to the issuing bank, which either approves the payment or returns a .
- Completion: Once approved, the payment becomes an and is captured for settlement.
Because the cardholder is present and authenticated, a CIT generally carries lower and chargeback liability than a charge made without live authentication. When a CIT is authenticated with 3-D Secure, fraud-related chargeback liability typically shifts from the merchant to the issuing bank. The same card can then be reused for merchant-initiated charges, as long as the customer agreed to store it during the initial CIT. Card networks expect the first transaction that stores a credential to be a CIT, since that initial cardholder authentication establishes the consent every later MIT relies on.
Customer-initiated vs merchant-initiated transactions
The defining difference between the two is who triggers the charge and whether the cardholder is present to authenticate it.
| Aspect | Customer-initiated (CIT) | Merchant-initiated (MIT) |
| Who starts it | Cardholder | Merchant, using a stored card |
| Cardholder present | Yes | No |
| Authentication | Cardholder authenticates (3-D Secure, SCA in the EEA) | Relies on prior consent; often qualifies for an SCA exemption in the EEA |
| Typical use | Checkout, first subscription payment, manual top-up | Recurring billing, automatic renewals, delayed charges |
Whether a payment is flagged as a CIT or an MIT affects how the issuer handles it at authorization. Issuers apply different authentication and decline logic to customer-present payments, so a genuine CIT mislabeled as an MIT can lead to unnecessary declines or authentication failures. A single card can move between both types: the customer authenticates it once in a CIT, then the merchant reuses the stored credential for charges.
