Time for a Level Playing Field for Regulated UK Gambling Payments
Download Whitepaper
Transaction Processing

Merchant-Initiated Transaction

What Is a Merchant-Initiated Transaction (MIT)? Definition and How It Works

Definition

A Merchant-Initiated Transaction (MIT) is a payment charged by a merchant against a stored credential without the cardholder being present to authenticate, covering subscriptions, instalments, and unscheduled charges such as usage fees or account top-ups.

How it works

Card scheme rules divide transactions into two categories based on who initiates the charge: Customer-Initiated Transactions (CITs) where the cardholder is present and participates in the checkout, and Merchant-Initiated Transactions (MITs) where the merchant triggers the charge using a stored credential agreed to by the cardholder in a previous CIT. The CIT/MIT framework governs how authorisation messages must be constructed and what authentication requirements apply.

An MIT is only permitted after the cardholder has given explicit consent during an initial CIT, typically at subscription signup, account creation, or trial initiation. This initial CIT establishes the stored credential and the cardholder's agreement to future MIT charges. The scheme rules require the merchant to include specific data fields in the authorisation message for each MIT: the transaction type indicator (recurring, instalment, or unscheduled), a reference to the original CIT transaction, and confirmation that no SCA challenge is being presented.

There are three MIT subcategories with distinct rules. Recurring MITs are fixed-amount charges on a fixed schedule (monthly subscription). Instalment MITs are a fixed total split into a predetermined number of charges. Unscheduled MITs are variable-amount charges triggered by a specific event rather than a calendar schedule, examples include usage-based billing, account top-ups when balance falls below a threshold, and no-show or cancellation fees charged after the fact.

SCA under PSD2 does not apply to MITs, SCA is a cardholder authentication requirement and the cardholder is not present during an MIT. However the initial CIT that sets up the stored credential must be SCA-compliant in regulated markets. If the initial authentication is not SCA-compliant, subsequent MITs on those credentials may be declined by the issuer.

Why it matters

Correctly flagged MITs with valid stored credentials and original transaction references achieve higher authorisation rates than unformatted recurring charges. The initial CIT that sets up the stored credential must include SCA authentication; failure to authenticate the original CIT creates a weak credential that issuers may decline on subsequent MITs. MIT declines for insufficient funds or expired credentials should trigger specific retry logic per scheme rules; unscheduled retries outside permitted windows can result in scheme violations. MIT authorisation messages must include the correct transaction type indicator and original transaction reference; missing or incorrect fields lead to interchange downgrade and higher decline rates. No-show fees, cancellation charges, and usage top-ups are unscheduled MITs requiring specific authorisation message construction distinct from recurring or instalment MITs.

With PXP

PXP supports full MIT transaction flows including recurring, instalment, and unscheduled MIT types, with correct scheme data field population and SCA-compliant CIT setup to maximise authorisation rates on stored credential charges.

Talk to a payments specialist

Frequently asked questions

What is the difference between a recurring MIT and an unscheduled MIT?

A recurring MIT is a fixed amount charged on a fixed calendar schedule, a monthly SaaS subscription for 49 GBP on the 1st of each month. The amount and timing are predetermined and disclosed to the cardholder. An unscheduled MIT is triggered by an event rather than a calendar schedule and may be for a variable amount, a top-up charge when a prepaid account balance falls below 10 GBP, or a no-show fee of 150 GBP charged the day after a missed hotel reservation. Unscheduled MITs require specific authorisation message fields distinct from recurring MITs.

Do MITs require SCA authentication?

MITs themselves do not require SCA because the cardholder is not present. SCA is required at the initial CIT that establishes the stored credential. The cardholder authenticates once (via 3DS at sign-up) and subsequent MITs are exempt from SCA as they are merchant-initiated off-session charges. If the initial CIT was not properly SCA-authenticated in a regulated market, issuers may decline subsequent MITs citing the weak credential. Merchants in SCA-regulated markets (EU, UK) must ensure strong authentication at the CIT stage.

What retry rules apply when an MIT is declined?

Card scheme rules govern MIT retry behaviour. Visa and Mastercard both restrict how many times a declined MIT can be retried and within what time window. Retrying beyond the permitted frequency or outside allowed windows can result in scheme violations and fines. For soft declines (insufficient funds, try again), specific retry windows apply. For hard declines (do not honour, stolen card), retries are not permitted. Merchants must implement scheme-compliant retry logic in their recurring billing infrastructure.

How should merchants document cardholder consent for MITs?

Consent for future MITs should be clearly disclosed at the initial CIT stage: the amount or amount range, billing frequency or trigger event, and how to cancel future charges. This disclosure should be visible at checkout and stored with the transaction record. In the event of a chargeback for an MIT (cardholder claims they did not authorise the recurring charge), the merchant's primary evidence is the consent documentation from the original CIT and any subsequent communications confirming the billing arrangement.

Revolutionize your business with PXP

Take complete control of your commerce and payments with one platform.

Get Started