Stored Credential Framework (MIT vs CIT): How to Set Up Subscription Billing and Card-on-File Charges Without Getting Declines

If you run subscriptions, memberships, auto-renew services, auto top-ups, or any product that charges a saved card later, you are operating in a set of card brand rules often called the stored credential framework.

The short version: your first transaction usually has to be a cardholder-initiated transaction (CIT), and your follow-on charges usually have to be sent as merchant-initiated transactions (MIT) with the right flags and reference IDs. When your payment stack gets this wrong, issuers treat your renewal like an unknown card-not-present purchase, leading to higher declines, higher dispute risk, and sometimes network monitoring problems.

This guide explains what the stored credential framework is, what MIT and CIT mean in practice, what data you need to capture and store, and how to implement common billing patterns (recurring, installment, unscheduled, incremental) in a way that stays aligned with Visa and Mastercard expectations.

What is the stored credential framework, and why does it matter?

A stored credential is any card credential stored for later use, whether you store a token from your gateway, a network token, or vault the PAN through a PCI-compliant provider.

The stored credential framework is the set of card brand rules that tell issuers and networks why a transaction is happening and whether the cardholder is actively participating. Visa and Mastercard want a consistent way to identify the initial setup event and the later follow-on charges so issuers can approve more reliably and apply the right controls.

If you get it right, you typically see better authorization rates on renewals and fewer "do not honor" type declines because the issuer recognizes the transaction as part of an existing agreement.

If you get it wrong, you can see:

• Higher renewal declines because the issuer sees a "random" e-commerce purchase instead of a known recurring agreement
• More disputes when a customer claims they did not recognize the merchant or forgot they signed up
• More friction when issuers push an authentication step that is not possible on a true MIT

What is the difference between CIT and MIT?

CIT means cardholder-initiated transaction. The cardholder is actively participating in the purchase, such as entering their card at checkout, approving a payment in-app, or taking an action that triggers the charge.

MIT means merchant-initiated transaction. The merchant triggers the charge later under an agreement the cardholder already accepted, and the cardholder is not actively participating at the moment of authorization.

Visa frames MIT as a follow-on to an initial CIT when you are charging a stored credential after the initial setup, and it expects specific indicators to identify the transaction intent and participation state. Visa Acceptance Solutions describes MIT as a follow-on to an initial CIT under Visa's MIT framework and notes merchants may need to update integrations to support it.

The practical implementation difference is not just timing. It is how you send the transaction data.

A renewal that you send without MIT indicators can be treated as a generic e-commerce purchase. A renewal that you send as an MIT with the correct identifiers is more likely to be recognized as part of the original agreement.

Which billing patterns count as MIT?

If the customer is not actively present, assume you are in MIT territory.

Common MIT patterns include:

• Subscriptions: fixed amount and frequency renewals
• Standing orders: variable amount at a fixed schedule (utilities are a classic example)
• Installment plans: a fixed number of payments tied to a single purchase
• Unscheduled credential on file: variable amount and variable timing, such as auto top-ups or pay-per-use plans

Many payment APIs and acquirers implement these as a "recurringData" or "storedCredential" block with a type that matches subscription, standing order, installment, or unscheduled. A concrete indicator table showing subscription, standing order, installment, and unscheduled COF appears in TabaPay's CIT/MIT indicators documentation.

What data do you need to store from the initial transaction?

The initial setup transaction is where many implementations fail.

At a minimum, for any stored credential agreement you should be able to tie later charges back to the original setup event. That usually means storing:

• Customer record ID in your system
• Payment method token or network token
• The "type" of stored credential agreement (subscription, installment, unscheduled COF, etc.)
• A network reference ID returned by the acquirer or gateway, when available
• Evidence of consent and terms acceptance (timestamp, IP, terms version)

For Mastercard, the Transaction Link Identifier (TLID) is becoming a core part of linking follow-on charges. Stripe explains that starting June 2, 2026 Mastercard requires businesses to retain TLIDs from CITs that set up future card use (and from ASI requests), and starting October 23, 2026 Mastercard requires sending the retained TLID with subsequent MITs.

Worldpay similarly describes that effective October 23, 2026, Mastercard requires merchants to send the TLID from the original response in MIT authorization requests and that TLID and existing scheme reference fields may run in parallel.

The details of which identifier you will actually receive depend on your acquiring path and gateway. Some providers expose it as a network transaction reference, trace ID, scheme reference data, STID, or other field names. The key is to capture whatever the network provides in the setup response and keep it in a durable store.

How do you structure the initial CIT correctly?

The initial transaction should be treated as a setup plus authorization event.

Your goals are:

1. Get the customer's explicit permission to store and reuse the credential.
2. Authenticate the customer when required by your region or risk controls.
3. Send the correct CIT indicators so the network knows a stored credential agreement is being created.
4. Capture the response identifiers you will need later.

In practice, that means:

• Clear checkout language that the card will be stored and used for future charges
• A checkbox or equivalent affirmative action, especially if your billing terms are not obvious
• A "credential on file" or "subscription" CIT indicator on the authorization
• A payment method tokenization event that is compatible with your future MITs

If you operate in markets where strong customer authentication applies, the initial CIT is usually the place where 3DS2 happens. Later MITs are typically treated differently under those regimes, but only if you send the MIT properly and include the linkage to the original authentication.

How should you send subsequent MIT renewals?

Start with the answer: send your renewal as an MIT with the right intent flag and the right linkage to the original setup.

Then expand:

A well-formed MIT renewal usually includes:

• Stored credential usage indicator set to MIT
• A subtype like subscription, installment, or unscheduled COF
• The stored payment method token or network token
• The original transaction reference ID where required (for Mastercard, this increasingly points to TLID)
• A stable descriptor that helps cardholders recognize the charge

Stripe's documentation emphasizes that Mastercard requires retention of TLIDs (June 2, 2026) and later sending the TLID with MITs (October 23, 2026).

If your PSP supports it, treat the linkage ID as mandatory even before a formal enforcement date. You want this in place ahead of time because you do not want to retrofit storage and data model changes during a decline spike.

Subscription vs standing order vs installment: how do issuers interpret each?

The short version: pick the subtype that matches what the customer agreed to.

The TabaPay indicator table is useful as a mental model:

• Subscription: fixed amount, fixed schedule
• Standing order: variable amount, fixed schedule
• Installment: fixed schedule and fixed count tied to a single purchase
• Unscheduled COF: variable timing and potentially variable amount

Why this matters:

• Dispute handling: issuers apply different expectations to recurring services vs single-purchase installment plans.
• Customer service: your cancellation and refund workflows differ across patterns.
• Approval logic: issuers might treat an unscheduled MIT differently than a fixed monthly renewal.

If your billing can change (plan upgrades, usage charges, proration), decide whether the change is still within the original agreement terms and whether you should require a customer-present action for the change.

When should you use an unscheduled MIT (and what are the risks)?

Use unscheduled MIT when the customer authorized you to charge later, but there is no fixed schedule.

Examples:

• Auto top-up when wallet balance drops
• Usage-based charges where the amount is not fixed at signup
• Pay-per-action billing where you do not charge at predictable intervals

The biggest risk is customer surprise.

To reduce disputes:

• Put the billing trigger in plain language during signup
• Send pre-billing emails or in-app notices for larger charges
• Keep your descriptor consistent
• Make cancellation simple

On the compliance side, unscheduled MIT still needs to be linked to the original agreement and sent with the proper MIT indicators.

How do incremental authorizations fit in?

Incremental authorizations are not exactly the same thing as stored credential MITs, but they are another place where reference IDs and intent flags matter.

The short version: an incremental authorization increases the authorized amount tied to an existing authorization when the final amount is expected to exceed the original amount.

This is common in lodging, car rental, and similar scenarios.

If you are mixing incremental auth patterns with stored credentials (for example, a deposit now and a variable final charge later), treat it as a system design issue, not a last-minute switch.

Ask your acquirer:

• Which fields indicate an incremental authorization in your integration
• How to reference the original authorization
• Whether the final completion is done as a capture, a completion, or a new authorization

What happens if you get MIT vs CIT wrong?

The quick answer: declines rise and disputes get messy.

Common symptoms:

• A spike in issuer declines on renewals after a gateway or checkout change
• Customers reporting "I did not authorize this" for renewals that used to go through
• Higher fraud scores on otherwise low-risk renewals
• Higher manual review volume

The root causes are usually one of these:

1. The initial transaction was not marked as setting up a stored credential.
2. The subsequent transaction was not marked as an MIT.
3. The linking identifier from the original response was not stored or not provided later.
4. Token migration broke linkages (token changed, but reference ID did not).

Worldpay notes that Mastercard expects TLID to be stored from the original authorization response and provided later for merchant-initiated charges.

Token types: gateway token vs network token (and why portability matters)

The short version: a gateway token is usually only usable inside that gateway, while a network token is issued within the card network ecosystem.

In practice:

• Gateway tokenization is easier to implement, but can create switching costs if you move providers.
• Network tokenization can reduce lifecycle issues when cards are reissued, but requires the right token requestor setup.

Either way, token choice does not remove stored credential obligations. You still need:

• Consent
• Correct CIT/MIT indicators
• Linkage IDs when required

A quick implementation checklist for merchants

Use this as a pre-flight list before you ship stored credential billing.

• [ ] Checkout language: customer agrees to stored credential and future charges
• [ ] Consent evidence stored: timestamp, terms version, and customer identifiers
• [ ] Initial transaction sent as CIT with a stored credential setup indicator
• [ ] Store network identifiers from authorization response (for Mastercard, plan for TLID retention)
• [ ] Subsequent transactions sent as MIT with correct subtype
• [ ] Descriptor and support contact are stable and recognizable
• [ ] Cancellation and refund flows are easy and documented
• [ ] Alerts: monitor renewal decline rate and dispute rate separately from first-purchase metrics

Where does this show up in real payment stacks (Stripe, Adyen, gateways, and ISOs)?

The short answer: almost every serious PSP has a field or set of fields for stored credential and MIT/CIT.

You might see it as:

• setup_future_usage and off_session flags
• storedCredential object with initiator and reason
• recurringProcessingModel or recurringData
• networkTransactionReference, traceId, schemeReferenceData, STID, or TLID

Cielo's recurrent payments documentation notes that recurring or stored credential transactions may require additional identification fields and describes Mastercard's Transaction Link Identifier (TLID) as an identifier generated during the initial transaction that must be used to associate subsequent MITs.

If you are an ISO or a platform, do not assume your merchant knows these details. You should make the "store the network reference ID and reuse it" requirement explicit in your integration docs.

Internal links for deeper context

If you want to go deeper on adjacent topics, start here:

• 3D Secure 2 (3DS2) Merchant Guide
• Network Tokenization vs Gateway Tokenization
• Account Updater (VAU/ABU) and Card Refresher

FAQ

Is every recurring payment an MIT?

Most renewals where the cardholder is not actively participating are treated as MIT. The setup payment or initial consent event is typically a CIT, and subsequent charges are MIT.

What is Mastercard TLID and do I need it?

TLID is Mastercard's Transaction Link Identifier used to link economically related transactions. Stripe notes Mastercard requires retaining TLIDs from certain CITs starting June 2, 2026 and requires sending the TLID with MITs starting October 23, 2026.

If I use tokens, do I still need stored credential indicators?

Yes. Tokenization changes how the credential is stored and secured, but does not replace the need to label transactions as CIT or MIT and link them to the original agreement.

How can I reduce subscription chargebacks related to "I forgot" cancellations?

Make billing terms obvious, send renewal reminders for higher-ticket plans, keep descriptors consistent, and make cancellation easy. Also keep a strong paper trail of consent and terms.

What if my amount changes each month?

If the schedule is fixed but the amount varies, that is closer to a standing order. If both timing and amount vary, it is closer to unscheduled COF. Match the subtype to the agreement the customer accepted.

Closing: get your billing model approved, not just your first sale

If your revenue depends on renewals, your payment stack needs to treat stored credential billing as a first-class integration.

You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look:

• Stripe: https://merchantalternatives.com/go/stripe/
• PaymentCloud: https://merchantalternatives.com/go/paymentcloud/
• Stax: https://merchantalternatives.com/go/stax/