CIT vs MIT: Who Starts the Payment? Recurring Billing Rules (2026)

CIT vs MIT is the split between a customer-initiated transaction, where the cardholder is present in the flow and actively pays, and a merchant-initiated transaction, where the merchant charges a stored card later without the cardholder taking part, under an agreement given earlier. The flag decides authentication, liability and retry rules.

In 2026 the distinction matters more than ever for PSPs, PayFacs and platforms. Subscriptions, usage billing, installments and AI-driven purchases all rely on stored credentials. A wrong flag turns a valid renewal into a decline, an unexpected authentication request or a dispute, and schemes now charge for careless retries.

What is the difference between CIT and MIT?

A CIT is any card payment the cardholder triggers, in store or online. An MIT is a payment the merchant triggers on a stored credential, with no cardholder action at that moment, based on prior consent.

The reference text is Visa’s Stored Credential Transaction Framework, mandated globally from October 14, 2017. It requires merchants, agents and payment facilitators to obtain cardholder consent before storing a credential, to disclose how the credential will be used, and to identify the first transaction and every later one with specific indicators. Mastercard followed with its own CIT and MIT indicators, mandatory for issuers and US acquirers from June 7, 2022 and for other acquirers from October 14, 2022.

Related notions:

• Card-on-file (stored credential): a card number or token kept by a merchant, its PSP or a wallet for future payments.
• Recurring transaction: an MIT at regular intervals for a fixed or variable amount, such as a subscription.
• Installment: a single purchase paid in a known number of MITs.
• Unscheduled card-on-file: an MIT with no fixed date, such as an account top-up below a threshold.
• Industry-practice MITs: no-show fees, delayed charges, incremental authorizations, resubmissions and reauthorizations.
• Continuity billing: goods or services shipped and billed repeatedly until the customer cancels, often after a trial.

In the messages, the distinction travels as indicators. Visa uses a stored-credential entry mode and a code that marks a transaction as recurring, installment or unscheduled. Mastercard uses a dedicated field with values for a cardholder-initiated transaction, a recurring or installment MIT, and an industry-practice MIT. Merchants never see these fields. Their PSP or gateway sets them, which is why the operator’s data model matters more than the merchant’s intentions.

A CIT can also use a stored credential. A returning shopper who pays in one click with a saved card is present and initiates the payment, so the transaction is a CIT on a card-on-file. The stored credential and the initiator are two separate attributes, and both must be sent.

CIT vs MIT: how do the two transaction types compare?

The two types differ on who is present, which checks apply and who carries the risk. The list below summarizes the main points for card payments.

• Who starts it: the cardholder for a CIT, the merchant for an MIT.
• Cardholder presence: in session for a CIT, absent for an MIT.
• Credential: entered or selected by the cardholder for a CIT, always stored for an MIT.
• Authentication: 3-D Secure or another strong authentication can apply to a CIT. An MIT cannot be challenged, because nobody is there to answer.
• CVV: may be requested in a CIT, never available in an MIT because it cannot be stored.
• Consent: given at checkout for a CIT. For an MIT it comes from the agreement signed during the first CIT.
• Reference: an MIT should carry the scheme reference of the original CIT, so the issuer can link the two.
• Typical declines: insufficient funds and expired cards weigh more on MITs, which makes the difference between soft declines and hard declines central to recurring billing.

How does a CIT followed by MITs work?

A recurring agreement always starts with a CIT and continues with MITs that point back to it. The usual steps, from the merchant to the issuer, are:

1. Agreement. The merchant shows the terms: amount or how it is calculated, frequency, duration, cancellation method. The cardholder accepts.
2. First CIT. The cardholder pays or verifies the card. The merchant, through its PSP, flags the transaction as the first of a stored-credential series.
3. Authentication. In Europe the cardholder is authenticated with 3-D Secure for this first payment, as described in 3-D Secure and SCA exemptions.
4. Storage. The acquirer returns the scheme transaction identifier. The PSP stores it with the credential, ideally as a network token.
5. MIT. On each due date, the merchant sends an authorization flagged as merchant-initiated, with the reason (recurring, installment, unscheduled) and the original identifier.
6. Routing. The acquirer forwards the request through the scheme to the issuer, which sees the MIT flag and the link to the authenticated agreement.
7. Outcome. The issuer approves or declines. On a decline, the response code and any advice code tell the merchant whether and when to retry.
8. End. When the cardholder cancels, the merchant stops charging and deletes or deactivates the credential.

CIT vs MIT in numbers (2026)

The rules are dated and precise, and several carry fees. Key figures:

• October 14, 2017: date Visa’s stored credential mandates took effect worldwide.
• 20 retries in 30 days: Visa’s limit on reattempts of a declined transaction since May 19, 2025, up from 15, with separate counters for CITs and MITs, as PayPal’s guide to excessive retries explains.
• 10 in 24 hours and 35 in 30 days: Mastercard’s limits on retries of the same card and amount before fees apply, according to the same guide. A "do not try again" advice code must stop retries for 30 days.
• 7 days: minimum notice Visa requires before a trial converts to a paid plan, under its subscription rules effective April 18, 2020.
• 53%: share of failed monthly subscription payments that are eventually recovered, against about 23% for annual plans, in Recurly’s January 2026 analysis of 76 million subscribers. This is vendor data.

What are the risks and limits of merchant-initiated transactions?

MITs remove friction, and they also remove the cardholder’s chance to confirm. The main risks are regulatory, financial and reputational.

• Missing or weak consent. Without a clear agreement, an MIT is an unauthorized charge. Schemes treat it as such in disputes.
• Authentication gaps in Europe. The EBA’s answer 2018_4031 states that payee-initiated transactions made without any involvement of the payer are not subject to strong customer authentication, but that setting up the mandate through a remote channel is. An MIT without an authenticated first CIT can be declined.
• Wrong flags. A CIT sent as an MIT avoids authentication the issuer expects. An MIT sent as a CIT triggers a challenge nobody can answer. Both lower approval rates.
• Retry fees. Retrying after a "never approve" response, or beyond scheme limits, generates fees per attempt.
• Subscription rules. Mastercard’s standards for subscription merchants, effective September 22, 2022, require a confirmation after enrollment, notice before a trial ends and clear cancellation instructions.
• Local rules. Some markets add their own mandates. India, covered in our guide to payment methods in India, applies e-mandate rules with pre-debit notifications.
• Disputes. Forgotten subscriptions are a classic source of "I did not authorize this" claims. Clear descriptors, receipts for each charge and a visible way to cancel prevent most of them.
• Amount changes. An MIT is covered only for what was agreed. A price increase, a plan upgrade or a new billing frequency needs notice, and in some cases a new authenticated CIT.
• Migration. When a merchant changes PSP, stored credentials move, and so must the original scheme identifiers. Without them, the first MITs at the new provider can look like new, unauthenticated agreements.

CIT vs MIT: what changes for PSPs, PayFacs and platforms

Operators carry the flags on behalf of their merchants. Five areas need explicit product decisions.

Onboarding and consent

Merchants rarely know the framework. The operator should ask, at onboarding, which billing models the merchant runs, and provide checkout components that collect and record the agreement. Proof of consent and of the first CIT is the main evidence in a later dispute.

Flagging and data

Each transaction needs the right combination: initiator, reason, position in the series and original scheme identifier. These values differ by scheme and by acquirer. A PSP that normalizes them in one API spares its merchants from the differences. The Payments Library resource Card-on-File Done Right details the stored credential requirements.

Credential freshness

Cards expire, get lost and are reissued. Visa describes its Account Updater as a service that lets issuers, acquirers and qualified merchants exchange updated account information. Mastercard’s Automatic Billing Updater gives access to updated credentials, including new card numbers and expiry dates. Network tokens go further, because the scheme refreshes the underlying card behind a stable token.

Retries and dunning

Retry logic must read the response code, respect scheme counters and adapt timing, for instance after payday for insufficient funds. A subscription product such as the subscription engine has to keep plans, billing dates and payment attempts consistent, and a retry policies matrix lets an operator define what happens per decline reason. The blog articles on white-label subscription billing for payment operators and on recovering failed payments go deeper.

Reporting and reconciliation

Finance teams need to separate first payments from renewals, and successful retries from first-attempt approvals. Reports by initiator and by attempt number show where revenue is lost: at checkout, at renewal or in dunning. They also show the cost of retries, which appears on scheme invoices weeks after the attempts.

Alternatives to cards

Recurring payments are no longer card-only. Bank-based mandates and variable recurring payments follow a similar logic: one authenticated consent, then payments started by the payee within agreed limits. Operators should model consent once and apply it across rails.

The same question now reaches AI agents that pay for users. The #TheShot episode Agentic commerce: when an AI agent pays discusses who is considered the initiator when software places the order.

Is getting CIT vs MIT right worth the effort in 2026?

Yes. Correct flags cost little to implement and protect approval rates, authentication compliance and dispute outcomes on every stored-credential payment. The work is mostly a matter of data discipline: record the agreement, keep the original reference, send the right indicator and read the response before trying again. Merchants with a small share of recurring revenue benefit less, but they still store cards for one-click checkout and delayed charges, so the framework applies to them too. What it means by player:

• PSPs: expose initiator, reason and original reference as first-class API fields, and apply scheme retry limits by default.
• PayFacs: check each sub-merchant’s billing model at onboarding, and monitor MIT decline and dispute rates per merchant.
• ISOs: make sure terminals and gateways can run an authenticated first payment and pass the identifiers needed for later MITs.
• ISVs and platforms: build consent, reminders and cancellation into the software, and keep the evidence.

A CIT is the customer saying yes, an MIT is the merchant keeping that promise, and operators who record the first and flag the second correctly get paid more often.