CIT, MIT, and Stored Credentials: The Framework Behind Saved Cards
Every saved card, every subscription, and every one-click checkout runs on a rulebook most merchants have never read: the card networks’ stored credential framework, introduced by Visa and Mastercard in 2017 and since adopted across the major schemes. The framework answers a question issuers face millions of times a day: this charge arrived with no customer present, so is it a legitimate subscription renewal or a criminal replaying a stolen card? Merchants who speak the framework fluently get trusted, which shows up directly as approval rates; merchants who ignore it look like the criminals and get declined. Here is how CIT, MIT, consent, and transaction IDs fit together.
Quick answer: The stored credential framework requires merchants to obtain explicit cardholder consent before storing a credential, to flag the first transaction as establishing storage, to classify every later use as cardholder-initiated (CIT) or merchant-initiated (MIT) with the correct subtype, and to link each MIT back to the original transaction using the network’s transaction ID. Followed correctly, it raises approval rates and keeps background billing outside strong-authentication friction.
What distinguishes a CIT from an MIT?
The test is the cardholder’s active participation at the moment of the charge, not whether a credential was stored.
- Cardholder-initiated (CIT): the customer is present and acting, whether typing card details, clicking pay with a saved card, or setting up a new subscription. The first transaction in any stored-credential relationship must be a CIT.
- Merchant-initiated (MIT): the merchant charges later under a prior agreement with no customer present. The framework splits MITs into defined subtypes, and the subtype travels in the authorization:
| MIT type | Meaning | Example |
|---|---|---|
| Recurring | Fixed schedule, agreed amounts | Monthly streaming subscription |
| Installment | Defined number of scheduled payments | Pay in six monthly parts |
| Unscheduled credential-on-file | Event-triggered, no fixed schedule | Auto top-up when a balance runs low |
| Industry practice | Operational follow-ons to a CIT | Delayed charges, no-show fees, resubmissions, incremental hotel authorizations |
Why do consent and the first transaction matter so much?
Storage begins with a mandate: the cardholder must explicitly agree to the credential being kept and to the terms of future charges (what, when, how much, how to cancel). That consent is not just contract hygiene; it is your evidence in the dispute process when a customer claims they never authorized the renewals. The initial CIT then carries an indicator telling the issuer a credential is being stored for a stated purpose, and the issuer’s response returns the identifier that makes the whole chain work.
What is the network transaction ID chain?
When the initial CIT is approved, the network issues a transaction identifier (Visa’s transaction ID, Mastercard’s trace ID). The merchant must store it alongside the saved credential and send it with every subsequent MIT. That reference is the issuer’s proof that today’s unattended charge descends from a genuine, authenticated enrollment rather than from a stolen number, and network mandates through 2026 have only tightened the requirement to carry these references on related transactions. The practical payoffs:
- Approval rates rise, because properly chained MITs score as low risk instead of anomalous.
- In strong-authentication regions, correctly flagged MITs sit outside SCA scope: the customer authenticated once at enrollment (the CIT, where 3-D Secure applies), and renewals then proceed without challenges. Mis-flag the renewal as a CIT and it gets challenged with nobody present to answer, a guaranteed decline.
- Card updater services and network tokens keep the chain alive across reissued cards, which is why pairing the framework with network tokenization is the current best practice for subscription businesses.
One common implementation gap: merchants assume their processor stores and forwards these IDs automatically. Many do; some only if you pass the right fields. Verify where the chain lives, especially before migrating processors, because losing the original IDs mid-migration orphans every subscription on file.
How does this intersect with security and compliance?
- What you store: the framework governs how stored credentials are used; PCI DSS governs how they are kept. Best practice is storing a token (provider or network token) rather than a PAN, and never the security code, which is prohibited after authorization under the rules in our guide to permitted card data storage. CVV is neither needed nor allowed for MITs.
- Fraud surface: saved-card accounts concentrate value, making them prime targets for the credential-stuffing attacks in our account takeover guide. One-click convenience deserves step-up authentication on risk signals.
- Honest billing: the same flags that help approvals also discipline billing practice: clear consent, accurate subtypes, and easy cancellation shrink the friendly-fraud and policy-abuse exposure that subscription models attract, and regulators increasingly watch negative-option billing closely.
An implementation checklist
- Capture explicit consent at enrollment with terms, amount logic, and cancellation path, and archive it per customer.
- Flag the initial CIT as establishing storage, authenticate it (3DS where applicable), and persist the returned network transaction ID with the credential.
- Classify every subsequent charge correctly: CIT when the customer acts on a saved card, MIT subtype otherwise, with the stored ID attached.
- Use network tokens or provider tokens, never raw PANs, and enroll in account updater services.
- Test the decline paths: expired cards, closed accounts, and issuer soft declines should trigger retry logic that respects network retry rules rather than hammering the issuer.
- Audit annually: sample authorizations and confirm the flags, subtypes, and IDs your systems actually send match what this framework expects.
Frequently asked questions
Does the framework apply if my processor stores the cards?
Yes. The flags describe the business relationship between you and the cardholder; they apply whether the credential sits in your vault or your provider’s. Good providers surface the fields and defaults, but the classification choices remain yours.
Is a free-trial setup a CIT or an MIT?
The enrollment (even at zero or token value) is the CIT establishing storage; the first paid charge after the trial is an MIT under the agreed terms. Networks discourage bare account verifications as the anchor; a real initial authorization makes a stronger chain.
Why are my subscription renewals suddenly getting declined?
Frequent causes: missing or wrong network transaction IDs, renewals mis-flagged as CITs (triggering unanswered authentication), expired credentials without updater coverage, or issuer risk rules reacting to sloppy flagging history. Pull the authorization messages and check the stored-credential fields first.
Do these rules cover wallets and network tokens?
Yes. The framework is credential-agnostic: a stored network token follows the same CIT/MIT classification and ID chaining as a stored PAN, with the token adding its own cryptographic protections.
What happens if we just ignore the framework?
Nothing dramatic on day one, then a slow tax: lower approval rates, SCA challenges killing renewals in regulated markets, weaker dispute evidence, and scheme non-compliance exposure through your acquirer. The framework is effectively the price of admission to card-on-file billing.
Saved-card commerce runs on borrowed trust: the issuer approving today’s unattended charge is trusting the authenticated moment when the customer first said yes. The stored credential framework is simply the bookkeeping that keeps that trust auditable; do the bookkeeping and the approvals follow.