How Merchant-Initiated Transaction (MIT) Works
A Merchant-Initiated Transaction is the technical and regulatory framework that allows merchants to charge a customer's saved card without the customer actively approving each individual payment. The process begins when the customer sets up an agreement — often at subscription signup or checkout — and ends with the merchant having the right to charge autonomously under the terms of that agreement.
Customer Completes an Initial CIT
The customer makes a purchase or explicitly agrees to future charges at checkout. This customer-initiated transaction is the foundation of all subsequent MITs. Strong Customer Authentication (SCA) is performed here, and the resulting network transaction ID is stored for future reference.
Credentials Are Stored Securely
The card details are tokenized and stored as a card-on-file record by the payment processor or vault. The merchant stores the network transaction ID from the original CIT alongside the token — this linkage is mandatory for MIT flagging.
MIT Agreement Is Established
The merchant records the type of MIT agreement: recurring fixed, recurring variable, installment, or unscheduled. Each agreement type maps to a specific set of network indicators that must accompany every subsequent charge.
Merchant Initiates the Charge
At billing time, the merchant submits an authorization or sale request to the payment network. The request includes the stored token, MIT flag, agreement type, and the original CIT's network transaction ID. No cardholder action is required.
Issuer Evaluates and Responds
The issuing bank recognizes the MIT indicators and applies appropriate rules — skipping SCA checks, evaluating funds and risk, and returning an approval or decline. A correct MIT submission significantly reduces unnecessary friction declines compared to unlabeled recurring charges.
Retry Logic Handles Declines
If declined, the merchant's system evaluates the reason code and schedules retries within network-mandated windows. Soft declines (insufficient funds) may be retried; hard declines (stolen card) should not be. Retry schedules must comply with Visa and Mastercard rules to avoid fines.
Why Merchant-Initiated Transaction (MIT) Matters
For any business running recurring payments or subscription billing, MITs are not optional infrastructure — they are the mechanism that determines whether charges succeed or fail at scale. Getting MIT implementation wrong is one of the leading causes of involuntary churn.
According to Visa's 2023 stored credential framework data, properly flagged MIT transactions see approval rates 8–12 percentage points higher than equivalent unlabeled recurring charges, because issuers can apply known-good stored-credential rules rather than treating the charge as anomalous. For a SaaS business processing $5M/month in recurring revenue, that gap can represent hundreds of thousands of dollars in recovered revenue per year.
A 2022 Mastercard analysis found that improper MIT flagging — missing network transaction IDs or incorrect agreement type codes — was responsible for approximately 30% of avoidable subscription decline events globally. Separately, industry research from CMSPI estimates that subscription businesses lose 1–2% of annual recurring revenue to preventable payment failures, of which a significant share stems from incorrect credential-on-file handling.
PSD2 and SCA Exemption
Under PSD2 in the European Economic Area, MITs are explicitly exempt from Strong Customer Authentication — but only when the original agreement transaction completed SCA. Without a valid SCA-authenticated CIT on record, issuers are within their rights to decline the MIT or demand re-authentication, creating customer friction and potential revenue loss.
Merchant-Initiated Transaction (MIT) vs. Customer-Initiated Transaction (CIT)
The MIT/CIT distinction is foundational to payment compliance, liability rules, and SCA exemptions. Confusing the two leads to incorrect authorization flows, higher declines, and misassigned chargeback liability.
| Dimension | MIT | CIT |
|---|---|---|
| Cardholder present? | No | Yes |
| SCA required (PSD2)? | No (exempt) | Yes (unless exempted) |
| Chargeback liability | Merchant | Issuer (if SCA completed) |
| Authentication method | None at transaction time | 3DS2, biometric, PIN |
| Requires prior agreement | Yes — must reference CIT | No |
| Network transaction ID | Must reference original CIT | Generated at transaction time |
| Examples | Monthly subscription, installment | In-store purchase, online checkout |
| Retry rules | Network-mandated caps apply | Customer retries at will |
Types of Merchant-Initiated Transaction (MIT)
Not all MITs are the same. Card networks define distinct categories, and each requires a specific indicator code in the authorization message. Using the wrong type flag — or omitting it — is treated the same as submitting an unlabeled recurring charge.
Recurring — Fixed Amount: The most common MIT type. The merchant charges the same amount on a predictable schedule (e.g., $49/month for a SaaS product). The amount and interval must match the terms agreed to during the original CIT. This maps directly to most subscription billing models.
Recurring — Variable Amount: Used when the charge amount changes each cycle based on usage, consumption, or variable fees. Common in utilities, metered SaaS, and telco billing. The customer must have consented to variable-amount billing explicitly during setup.
Installment: A single purchase split into multiple fixed payments over a defined schedule. The total amount and number of installments are agreed upfront. Installment MITs are common in BNPL-adjacent schemes and large-ticket retail.
Unscheduled Credential-on-File (UCOF): Charges that are triggered by a specific event rather than a calendar schedule — for example, automatically topping up a digital wallet when the balance drops below $10. The customer consented to the trigger condition, but no fixed schedule exists.
Network Flag Reference
Visa uses the storedCredential.type field with values RECURRING, INSTALLMENT, or UNSCHEDULED. Mastercard uses the storedCredentialIndicator field. American Express has its own stored credential framework. Always consult current network rules documentation — these fields change with annual mandate updates.
Best Practices
Getting MITs right requires discipline at both the business and integration layers. Sloppy implementation costs authorization rate; precise implementation compounds into meaningful revenue recovery over time.
For Merchants
- Always obtain clear billing consent during signup. The MIT framework depends on an enforceable customer agreement. Document what the customer agreed to — amount, frequency, and the right to charge without their presence — and surface it clearly at checkout.
- Store the original CIT network transaction ID. This ID links every future MIT to its authorizing CIT. Without it, MITs are submitted blind and issuers have no mandate reference to honor.
- Match your MIT type flag to the actual charge pattern. A variable usage charge flagged as a fixed recurring charge creates compliance exposure. Map each product's billing model to the correct MIT category before go-live.
- Implement smart retry logic. Not all declines are equal. Parse reason codes:
insufficient fundswarrants a retry;do not honororlost carddoes not. Respect network retry windows — typically no more than 4 attempts in 15 days for soft declines before pausing. - Use account updater services. Card expiration and reissuance silently kills stored credentials. Visa Account Updater and Mastercard Automatic Billing Updater proactively refresh card numbers, reducing MIT declines from stale credentials by 30–40%.
For Developers
- Submit
initiatedBy: MERCHANTandstoredCredential.typeon every MIT. These fields must be populated on every authorization request, not just the first one. Many integrations correctly flag the first charge and then drop the indicator on subsequent requests. - Persist the
networkTransactionIdreturned from the CIT. Store it in your payments database alongside the customer token. Build a lookup so billing jobs can retrieve and attach it to every MIT submission. - Test MIT flows in sandbox with SCA. Use your PSP's sandbox to simulate the full flow: CIT with 3DS2 → store networkTransactionId → MIT submission with stored credential indicator → decline scenarios with retry logic.
- Handle network retry rule enforcement at the infrastructure level. Don't leave retry logic to application code alone. Implement a rate limiter or job scheduler that enforces per-card, per-merchant retry caps so no individual card exceeds network thresholds regardless of how billing jobs are triggered.
- Log MIT decline reason codes with structured metadata. Aggregate declines by reason code, card network, and issuer BIN to identify systematic issues — a cluster of
do not honordeclines from a single BIN range often signals a flagging or descriptor problem, not a funds issue.
Common Mistakes
Even experienced payments teams make these errors when implementing MITs. Each one has measurable impact on authorization rates or compliance standing.
1. Omitting the stored-credential indicator entirely. Many merchants configure MITs incorrectly as generic recurring charges with no storedCredential object in the authorization request. Issuers see these as anonymous card-not-present transactions — no stored-credential rules apply, SCA exemptions don't trigger, and decline rates climb accordingly.
2. Not linking back to the original CIT network transaction ID. Submitting an MIT without the networkTransactionId from the initial CIT means the issuer cannot verify the transaction is part of an authenticated agreement. This is the single most common technical error in recurring billing integrations and one of the hardest to diagnose because it produces generic decline codes rather than specific flagging errors.
3. Retrying hard declines. Submitting retries after stolen card, pickup card, or fraudulent transaction decline codes violates network rules and increases the merchant's fraud risk score. Distinguish hard declines (permanent) from soft declines (transient) and route them to different handling paths — hard declines should trigger a customer notification flow, not an automated retry.
4. Using the wrong MIT type flag. Flagging a variable usage charge as RECURRING fixed amount creates a discrepancy between the submitted mandate type and the actual charge pattern. Issuers that perform mandate validation will decline these; those that don't create a compliance exposure if the customer disputes the charge.
5. Failing to update stored credentials after card reissuance. Banks reissue cards constantly — expiration, loss, fraud replacement. Without an account updater integration, the stored credential becomes stale and MITs fail silently. This is a primary driver of passive churn in subscription businesses and is entirely preventable.
Merchant-Initiated Transaction (MIT) and Tagada
Tagada's payment orchestration layer handles MIT flagging, credential storage, and smart retry logic as first-class features — abstracting the per-network complexity that makes correct MIT implementation difficult to maintain across Visa, Mastercard, and Amex simultaneously.
MIT Orchestration with Tagada
When routing a recurring charge through Tagada, the platform automatically attaches the correct stored-credential indicator and network transaction ID to each MIT submission — sourced from the original CIT recorded at signup. If the primary acquirer declines, Tagada's retry engine applies network-compliant retry windows and can cascade to a backup acquirer without resetting the retry count. This means merchants get both higher authorization rates and full compliance without building retry infrastructure themselves.
Tagada also integrates with Visa Account Updater and Mastercard ABU out of the box, so stored credentials are refreshed proactively before they expire. For platforms managing card-on-file records across multiple payment methods and geographies, this eliminates a significant source of involuntary churn and reduces the engineering burden of keeping network mandate compliance current as rules change annually.