Merchant-Initiated Transactions (MIT)

A Merchant-Initiated Transaction (MIT) is a payment triggered by a merchant without the customer's active involvement at the moment of the charge, based on a prior agreement authorising the merchant to store and reuse the customer's payment credentials. MITs are the backbone of subscription billing, instalment plans, auto top-ups, and no-show charges in ecommerce.

MIT vs CIT

The counterpart is a Customer-Initiated Transaction (CIT): any payment where the cardholder is actively present and participating (e.g., checking out). The distinction between MIT and CIT governs whether Strong Customer Authentication (SCA / PSD2) applies, how decline rates behave, what interchange fees apply, and where Chargeback liability sits. (Checkout.com Blog, 2026-07-21)

Stripe notes that card networks classify transactions as MIT or CIT based on signals of cardholder participation, not solely on API parameters like off_session. (Stripe Docs — CITs and MITs, 2026-07-21)

Use cases (eight sub-types)

GR4VY identifies eight recognised MIT sub-types: (GR4VY — MIT vs CIT, 2026-07-21)

Sub-type	Description
Recurring	Fixed-frequency charge of fixed or variable amount (e.g., monthly subscription)
Instalment	Known total split into a defined number of scheduled charges (BNPL/financing)
Unscheduled card-on-file	Event-triggered charge against stored credentials (auto top-ups, automatic refills when balance drops)
Retry	Re-submission of a previously declined MIT
Incremental	Increase or extension of a prior pre-authorisation
Reauthorisation	Refreshing an authorisation after the original expires
No-show	Penalty when a customer fails to arrive (hotel, rental car); requires prior cancellation-policy agreement
Delayed charge	Post-service charge for incidentals (hotel mini-bar, car damage)

Adyen uses three processing-model labels: Subscription, CardOnFile, and UnscheduledCardOnFile; the model applied at setup governs SCA exemption eligibility and retry behaviour for all subsequent MITs. (Adyen Knowledge Hub — Card-on-File, 2026-07-21)

Technical mechanics — the stored-credential chain

The Stored Credentials Framework was introduced by Visa and Mastercard in 2017, requiring merchants to signal when payment details are stored and how they are reused. (Merchant Alternatives — Stored Credential Framework Guide, 2026-07-21)

The MIT chain works as follows:

Initial CIT — the cardholder authenticates (with 3DS2 where required), consents to future charges, and the merchant captures a network Transaction Identifier (Visa NTI or Mastercard Trace ID/TLID).
Storage — the merchant stores the credentials or token alongside the network identifier.
MIT — every subsequent merchant-initiated charge references the original CIT's network identifier, signalling to the issuer that this is an authorised recurring or off-schedule charge.

Processor implementations

Stripe: Uses the SetupIntents API to save a card and establish the MIT chain; subsequent PaymentIntents are flagged as off_session: true to trigger MIT processing. (Stripe Docs — Setup Intents, 2026-06-24)

Adyen: Uses ContAuth recurring contract type; distinguishes ONECLICK (CVV present, cardholder present) from RECURRING (no CVV, card-not-present MIT). Returns a Tokenisation|token tied to the specific shopper. (Adyen Knowledge Hub — Recurring Payments, 2026-07-21)

Checkout.com: Set merchant_initiated: true in the payment request; for SCA-in-scope regions, 3ds.enabled can be omitted on qualifying MITs. (Checkout.com Docs — Recurring payments with stored card details, 2026-07-21)

Braintree/PayPal: 3RI (3-D Secure Requestor Initiated) became mandatory from October 18, 2024, for recurring MIT use cases; authenticates server-to-server by referencing the initial 3DS2 CIT. (Braintree Docs — 3RI, 2026-07-21)

Spreedly: Requires stored_credential_initiator (CIT or MIT) and stored_credential_reason_type (recurring, instalment, unscheduled) fields; Spreedly populates the downstream gateway request. (Spreedly Docs — Stored Credentials, 2026-07-21)

PSD2 / SCA treatment

MITs are out of scope for Strong Customer Authentication (SCA / PSD2) — not merely exempt. The EBA has stated that MITs "are initiated by the payee and thus, like direct debits, are not subject to the requirement for SCA." (EBA Q&A 2018_4404, 2018; EBA Q&A 2019_4792, 2019; EBA Q&A 2019_4866, 2019)

Practical implication: Ravelin distinguishes out-of-scope MITs from SCA exemptions. Out-of-scope means PSD2 does not govern the transaction at all; exemptions are in-scope but can be requested. Merchants cannot request exemptions on out-of-scope MITs. (Ravelin — SCA Transaction Optimization Guide, 2026-07-21)

The initial CIT must have SCA. Checkout.com states that "the original CIT must have been authenticated with 3DS2" and "future transactions must contain Card on File (CoF) data to show that they're authorised by the cardholder." (Checkout.com — Manage SCA Compliance, 2026-07-21)

Ravelin states that "preauthorised MIT transactions for varying amounts may fall within SCA scope" — suggesting variable-amount unscheduled CoF MITs could be in scope. Checkout.com and Akurateco describe all qualifying MITs (including variable-amount unscheduled CoF) as categorically out of scope for SCA. This likely reflects differing issuer interpretations of the EBA guidance rather than a rule conflict; Stripe also cautions that "exemptions aren't guaranteed, and subsequent payments may require authentication, as individual banks may apply exemptions differently." Merchants with variable-amount MITs should validate treatment with their acquirer. [Ravelin: https://www.ravelin.com/blog/sca-transaction-optimization-guide-exemptions] vs [Checkout.com: https://www.checkout.com/docs/payments/authenticate-payments/manage-sca-compliance] vs [Akurateco: https://akurateco.com/blog/merchant-initiated-transactions-cit-vs-mit-sca] vs [Stripe Support: https://support.stripe.com/questions/merchant-initiated-transactions-(mits)-when-to-categorize-a-transaction-as-mit]

Liability shift

A properly structured MIT chain — initial CIT with 3DS2 authentication, correct stored-credential signalling — shifts Chargeback liability to the issuing bank. If the initial mandate is weak, missing, or the initial CIT was not authenticated, the merchant bears the liability. (Checkout.com Support — Why have I lost a dispute on a recurring MIT, 2026-07-21)

GR4VY states that "properly classified MITs that follow a 3DS-authenticated CIT shift liability to the issuer." (GR4VY — MIT vs CIT, 2026-07-21)

Active scheme mandates (2025–2026)

Mastercard TLID (as-of 2026-07-21)

The Mastercard Transaction Link Identifier (TLID) is a 22-character alphanumeric identifier automatically generated for every card authorisation, linking the original CIT to all lifecycle messages and economically-related subsequent MITs. (GR4VY — Mastercard TLID, 2026-07-21; Adyen Help — TLID, 2026-07-21)

Rollout phases:

Date	Obligation
Oct 17, 2025	Acquirers must send TLID for lifecycle transactions (settlement, void, incremental)
Jun 2, 2026	Acquirers must retain and store TLIDs from CITs for economically-related MITs
Oct 23, 2026	Merchants must include stored TLID in every MIT authorisation request ← 3 months away
Jan 31, 2027	Non-compliance fees begin (per Checkout.com support article)

Adyen states that merchants using Adyen Tokenization require no action — Adyen stores and transmits the TLID automatically. Merchants using their own vault or a third-party vault must update their integration to receive and store additionalData.transactionLinkId. (Adyen Help — TLID, 2026-07-21)

Stripe documentation confirms: "Starting 23 October 2026, Mastercard requires you to send the TLID retained from the original CIT with merchant-initiated transactions (MITs)." (Stripe Docs — Mastercard TLID, 2026-07-21)

Visa NTI / Authorization Window (as-of 2026-07-21)

Effective April 13–14, 2024, Visa shortened the authorization window for online MITs from 7 days to 5 days, consolidating authorization validity and clearing into a single time frame across MIT types (instalments, recurring, advance payments, unscheduled CoF, merchandise credits). (Stripe Docs — CITs and MITs, referencing Visa April 2024 mandate; Visa PDF — Authorization Framework Update, 2024)

Merchant best practice

Stripe specifies that merchants must have a documented agreement with the customer covering: (i) the customer's consent to merchant-initiated charges; (ii) anticipated timing and frequency; (iii) how the customer will be notified of changes. (Stripe Docs — CITs and MITs, 2026-07-21)

Akurateco identifies two layers for compliance: (1) Foundation — correct CIT/MIT classification, documented cardholder consent, consistent stored-credential signalling; (2) Execution — routing, retry logic, and failover strategies that adapt to issuer behaviour. Misclassifying a transaction causes issuers to treat it as a "brand-new payment," triggering authentication requests or straight declines. (Akurateco — CIT vs MIT, SCA, 2026-07-21)

The MRC (2025) advises auditing all transaction flows and correctly tagging each as CIT or MIT as a first step, given Visa NTI and Mastercard TLID mandates requiring consistent transmission of network reference identifiers. (MRC — Card-on-File Done Right 2025)

Spreedly's 2026 standalone payment vault allows merchants to store and manage customer credentials with tokens working across 100+ payment providers without re-vaulting — directly addressing MIT chain portability across PSPs. (PYMNTS — Spreedly 2026)

SCA displacement effect

According to Signifyd's Senior Manager of Risk Intelligence, SCA's hardening of the CIT/checkout moment did not eliminate ecommerce fraud — it displaced it toward pre-purchase stages (account takeover, synthetic identity) and post-purchase stages (return abuse, refund abuse, promo abuse). The implication: a correctly structured MIT chain reduces authorisation-stage fraud, but does not reduce total fraud exposure. (Signifyd — How SCA is fueling ecommerce abuse in Europe, YouTube 2025-01-23)

PSD3 outlook

No confirmed change to MIT's out-of-scope SCA treatment under PSD3 has been published as of 2026-07-21. GR4VY's 2026 article on PSD3/PSR notes that European merchants need to track whether PSD3 will alter the MIT out-of-scope regime. (GR4VY — PSD3 and PSR explained, 2026)

Key terms

Term	Meaning
MIT	Merchant-Initiated Transaction — charge triggered by merchant without cardholder present
CIT	Customer-Initiated Transaction — charge with active cardholder participation
CoF	Card-on-File — stored payment credentials enabling MIT
TLID	Transaction Link Identifier — Mastercard's 22-char chain ID linking CIT to all MITs
NTI	Network Transaction Identifier — Visa's equivalent chain ID
3RI	3-D Secure Requestor Initiated — 3DS2 authentication path for MITs (server-to-server)
ContAuth	Adyen's recurring contract type for MIT; distinct from ONECLICK (cardholder present)