Home/Research library/Compliance Slows Launches

Guide · Authentication and payment regulation

Merchant-Initiated Transactions and SCA

Merchant-Initiated Transactions and SCA: What Merchants Need to Know A customer being absent from checkout does not automatically make a payment merchant-initiated. That distinction is the starting point for understanding merchant-initiated transactions and SCA. A genuine merchan

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Merchant-Initiated Transactions and SCA: What Merchants Need to Know

A customer being absent from checkout does not automatically make a payment merchant-initiated.

That distinction is the starting point for understanding merchant-initiated transactions and SCA.

A genuine merchant-initiated transaction, commonly shortened to MIT, is a later payment initiated by the merchant under a pre-existing agreement or mandate from the customer, without the customer taking a specific action to trigger that individual payment. The important question is therefore who initiates the payment, not merely whether a saved card is used or whether the customer happens to be offline.

Under the current European Economic Area PSD2 framework, that distinction has a major Strong Customer Authentication consequence:

A qualifying payment initiated solely by the merchant under an appropriate prior mandate can fall outside the payer-initiated SCA requirement. That is different from an SCA exemption.

The initial act that establishes the mandate can still require Strong Customer Authentication, particularly when the customer establishes it remotely. And the later transaction must actually be merchant-initiated: if the customer returns, clicks “buy,” confirms an order, or otherwise triggers the individual payment, it is generally a customer-initiated transaction rather than an MIT.

That distinction matters for subscriptions, SaaS billing, usage-based services, marketplaces, mobility services, travel businesses, stored credentials, and any payment flow in which a merchant may need to charge a customer after the original checkout.

What is a merchant-initiated transaction?

A merchant-initiated transaction is a payment initiated by the merchant using a payment credential or payment instrument under authority previously provided by the customer.

For the EEA SCA analysis, three characteristics are especially important:

The customer previously authorized the merchant to initiate later payments.

The mandate is connected to an agreement for goods or services.

The individual later payment does not depend on a new action by the customer to trigger it.

European Banking Authority Q&A guidance explains that later card payments can qualify as payee-initiated transactions where the payer has given the merchant a mandate to initiate transactions and the merchant subsequently initiates them without specific payer involvement.

The practical flow looks like this:

CUSTOMER

Establishes payment relationship

and authorizes future charges

INITIAL SETUP / PAYMENT

SCA where required

MANDATE + STORED CREDENTIAL

RELATIONSHIP

MERCHANT LATER DETERMINES

THAT AN AGREED CHARGE IS DUE

MERCHANT INITIATES PAYMENT

WITHOUT NEW CUSTOMER ACTION

QUALIFYING MIT

The fact that the card is stored is not enough.

The fact that the customer is “off-session” is not enough.

The merchant must be able to connect the later payment to the earlier agreement and customer authorization.

MIT versus customer-initiated transaction

The cleanest distinction is who causes the individual payment to start.

Scenario

Typical classification

Customer enters card details and clicks Pay

Customer-initiated transaction

Customer returns with a stored card and clicks Buy now

Customer-initiated transaction

Merchant automatically charges an agreed monthly subscription under a prior mandate

Potential MIT

Merchant bills measured usage under a prior standing agreement without customer action

Potential MIT

Merchant charges an agreed no-show amount under a properly established mandate

Potential MIT

Customer receives a payment request and actively confirms the charge

Customer-initiated

Customer must log in and trigger every stored-card payment

Customer-initiated

This distinction is particularly important for card-on-file payments.

EBA guidance explicitly says that a card-on-file transaction remains payer-initiated where the payer triggers each individual payment, such as by returning to an ecommerce website and clicking the purchase button. A credential being saved at the merchant does not transform subsequent customer purchases into merchant-initiated transactions.

So:

Stored credential ≠ MIT

and:

off-session ≠ MIT

The real test is initiation.

Does Strong Customer Authentication apply to MITs?

Under the current EEA PSD2 framework, SCA is required in specified circumstances including when the payer initiates an electronic payment transaction.

A genuine MIT is different because the later transaction is initiated by the payee—the merchant—without interaction or involvement by the payer.

European Commission interpretations published through the EBA therefore state that transactions initiated only by the payee are not subject to the payer-initiated SCA requirement where the customer does not participate in triggering the individual payment.

That gives merchants an important terminology rule:

Do not call MIT an “SCA exemption.”

An exemption means a transaction is otherwise within the SCA framework but qualifies for a regulatory provision allowing SCA not to be applied.

A genuine MIT is treated differently because the later transaction is outside the payer-initiated SCA trigger.

The distinction can be summarized as:

Treatment

Regulatory logic

SCA performed

Payer-initiated transaction requires authentication

SCA exemption

Transaction is in scope, but a defined exemption may apply

MIT / payee initiated

Later payment is initiated solely by merchant under prior mandate and can fall outside payer-initiated SCA requirement

That difference may produce the same visible customer experience—no authentication challenge—but for completely different reasons.

Establishing the MIT relationship can require SCA

MIT treatment does not mean that a merchant can simply collect a card number once and then charge it indefinitely without an appropriately established agreement.

The initial mandate matters.

EBA guidance states that where the payer provides the mandate to the merchant through a remote channel, establishing that mandate is subject to SCA because the remote action itself may imply a risk of payment fraud or other abuse under PSD2 Article 97.

A simplified lifecycle is:

CUSTOMER PRESENT / ONLINE

AGREES TO FUTURE

MERCHANT-INITIATED CHARGES

SCA AT REMOTE SETUP

WHERE REQUIRED

MANDATE ESTABLISHED

LATER MERCHANT-INITIATED

CHARGES UNDER THAT MANDATE

This is why payment teams need to think of MIT as a relationship between transactions, not an isolated authorization flag.

What should the mandate establish?

PSD2's SCA analysis and card-network processing rules are separate layers.

The regulatory framework determines whether the payment can qualify as payee initiated.

Card networks and acquirers define additional requirements for how stored credentials and later transactions should be agreed, identified, and submitted.

For example, Visa's current April 2026 public rules require express informed consent before a merchant stores a payment credential for future use. Depending on the transaction type, the agreement can need to describe matters such as:

what goods or services are involved;

how the credential will be used;

the transaction amount or how the amount will be determined;

currency;

timing or frequency;

for unscheduled credential-on-file payments, the event that triggers the payment;

relevant cancellation and refund terms;

changes to the agreement.

Those are network requirements, not a restatement of the PSD2 legal definition of an MIT.

But operationally they point in the same direction:

The customer should understand what future charges they are authorizing, and the merchant should be able to demonstrate the relationship between that authority and later payments.

Can the MIT amount be variable?

Yes, potentially.

A merchant-initiated payment does not necessarily need to have the same amount every time.

European guidance specifically recognizes standing agreements under which later payee-initiated payments can have variable amounts or irregular timing, provided the merchant initiates them according to the prior agreement and the individual payments do not depend on a specific customer action.

Examples identified in EBA materials include:

utility bills;

mobile or internet services containing usage-based charges;

car or bike sharing;

digital services;

other arrangements in which consumption determines the later charge.

So this can be a valid model:

CUSTOMER AUTHORIZES:

"Charge my stored payment method

for my actual monthly usage."

MONTH 1 = €42

MONTH 2 = €57

MONTH 3 = €39

MERCHANT INITIATES EACH PAYMENT

WITHOUT CUSTOMER ACTION

Variable amount does not, by itself, prevent MIT treatment.

The merchant still needs an appropriate mandate explaining the basis on which future amounts can be determined.

Visa's current stored-credential rules, for example, require the agreement to state either the transaction amount or a description of how it will be calculated, and for unscheduled credential-on-file transactions to identify the event that prompts the charge.

Recurring payments and MITs are related—but not identical

“Recurring payment” is often used as though it means MIT.

That is too simple.

A recurring payment describes a commercial pattern:

payment happens repeatedly.

An MIT describes who initiates the individual transaction and under what authority.

A recurring card series can qualify as merchant initiated when:

the customer gave the merchant the required mandate;

the merchant initiates subsequent payments;

no new customer action is necessary for each payment.

EBA guidance confirms that subsequent recurring card transactions can qualify as payee initiated when those conditions are met.

But PSD2's SCA Regulatory Technical Standards also contain a distinct recurring-transactions exemption for a series with the same amount and same payee. SCA applies when the payer creates, amends, or initiates that series for the first time, while subsequent transactions within that qualifying series may proceed without SCA under the exemption.

These are therefore separate concepts:

Genuine MIT

Reason no SCA applies to later payment:

Transaction is payee initiated and outside the relevant payer-initiated SCA trigger.

Recurring-payment exemption

Reason SCA may not be applied:

Transaction falls within a defined SCA exemption for a qualifying same-amount, same-payee series.

Do not describe both as:

“subscription exemption.”

What about unscheduled merchant-initiated payments?

Many merchant relationships are not monthly subscriptions.

A customer may authorize a merchant to initiate a payment when a defined event occurs.

Examples can include:

an account balance falling below an agreed level;

usage reaching a billing point;

a rental ending;

a service being consumed;

another contractually agreed charging event.

These are often described in card-processing terminology as unscheduled credential-on-file transactions.

The exact card-network category and indicator is a processing-rule matter, not the legal definition of MIT under PSD2.

The important regulatory question remains:

Did the customer previously authorize the merchant to initiate the payment when the defined event occurs, and does the merchant initiate it without another customer action?

If yes, the payment can potentially fit the payee-initiated model described by the EBA.

Hotel, travel, and delayed-charge scenarios require particular care

Travel businesses illustrate why “customer not present” cannot be the entire test.

Hotels may need to charge:

no-show fees;

late cancellation charges;

amounts discovered after checkout;

payment_initiator

customer | merchant

stored_credential

true | false

agreement_type

recurring | unscheduled | other

original_payment_reference

customer_action_required

true | false

mandate_reference

Then map these fields to the PSP's current MIT/stored-credential implementation.

Why the original transaction reference matters

A later MIT should generally remain connected to the transaction or setup event that established the stored-credential relationship.

Visa's December 2025 merchant guidance emphasizes use of the Original Transaction ID (OTID) to link the original cardholder-initiated transaction with later recurring or other merchant-initiated transactions. Visa says this connection helps issuers identify the relevant subscription or service and validate customer consent.

Mastercard's current public transaction-processing rules similarly contain identifiers distinguishing cardholder-initiated and merchant-initiated stored-credential transactions and require or recommend references linking later recurring/installment activity back to the original authorization in specified circumstances.

The exact fields differ between networks.

The architecture principle does not:

Do not treat every MIT as a completely unrelated payment. Preserve the chain back to the customer-authorized origin.

What information should merchants retain?

There are two different reasons to preserve information.

Regulatory and contractual evidence

The merchant should be able to establish the basis on which it initiated the later payment.

Network and processing continuity

The PSP/acquirer may need identifiers connecting later MITs to the original credential relationship or transaction.

Depending on the model and applicable rules, useful records can include:

evidence of customer consent;

date and method of consent;

agreed goods or services;

amount or method for calculating future amounts;

frequency or triggering event;

currency;

cancellation terms;

agreement changes;

mandate/agreement identifier;

PSP token or stored-credential reference;

original transaction or network reference;

transaction type used for subsequent charges;

cancellation or withdrawal of consent.

Visa's current rules require merchants to retain specified stored-credential agreement information for the duration of the agreement and make it available to the cardholder or issuer on request.

That does not mean merchants should unnecessarily store raw card numbers.

Sensitive payment credentials should be handled according to the merchant's payment architecture, PSP arrangement, applicable PCI requirements, and data-security policies. Often the more scalable design is to retain provider tokens and transaction references rather than reproduce card-storage infrastructure internally.

The customer mandate and the network reference solve different problems

It is useful to keep these concepts separate.

Mandate

Answers:

Why is the merchant entitled to initiate this later charge?

Original transaction reference

Answers:

Which established payment relationship does this later transaction belong to?

MIT indicator

Answers:

How should this particular payment be represented to the payment-processing ecosystem?

A robust implementation needs all three concepts even if the PSP abstracts some of them behind its API.

Common MIT implementation mistakes

Mistake 1: Treating every off-session payment as an MIT

The customer being offline says nothing by itself about who initiated the payment.

Fix: determine whether a prior mandate exists and whether a new customer action triggers the individual payment.

Mistake 2: Treating every stored-card purchase as an MIT

A returning shopper clicking Buy is initiating that payment.

Fix: classify payment initiation separately from credential storage.

Mistake 3: Calling MIT an SCA exemption

This obscures the regulatory reason SCA does not apply to qualifying later transactions.

Fix: distinguish out of scope because payee initiated from in-scope transaction using an exemption.

Mistake 4: Skipping SCA when establishing a remote mandate

The later MIT treatment does not necessarily remove the authentication requirement from the original remote setup.

Fix: support SCA where required when establishing the mandate.

Mistake 5: Assuming variable amounts cannot be MITs

Variable and irregular charges can potentially qualify when the mandate properly authorizes merchant initiation and the individual payment does not depend on payer action.

Fix: document how the amount or trigger is determined.

Mistake 6: Reusing MIT classification after the customer returns

A failed MIT can lead to a new customer-initiated recovery payment.

Fix: re-evaluate the initiator for each transaction rather than inheriting the previous classification.

Mistake 7: Failing to send the right stored-credential/MIT information to the PSP

The transaction may be commercially valid but technically misidentified.

Fix: implement the PSP's current recurring, stored-credential, MIT, and original-transaction-reference parameters.

Mistake 8: Losing the original transaction reference

That can weaken the link between the original CIT and later MIT sequence.

Fix: persist durable provider/network references through migrations, token updates, retries, and subscription lifecycle changes.

Mistake 9: Assuming “subscription” automatically answers the SCA question

Subscription is a business model, not a regulatory transaction classification.

Fix: identify whether the actual payment is customer initiated, genuine MIT, or relying on another relevant regulatory treatment.

A practical MIT decision framework

Before submitting a stored-credential payment as an MIT, ask:

IS THERE A PRIOR CUSTOMER AGREEMENT?

+--+--+

| |

NO YES

| |

v v

NOT MIT DID THE CUSTOMER AUTHORIZE

MERCHANT-INITIATED CHARGES?

+--+--+

| |

NO YES

| |

v v

NOT MIT DOES THIS PAYMENT FALL

WITHIN THAT AGREEMENT?

+--+--+

| |

NO YES

| |

v v

NOT MIT DID THE CUSTOMER

TAKE A SPECIFIC ACTION

TO TRIGGER THIS PAYMENT?

+--+--+

| |

YES NO

| |

v v

CIT POTENTIAL

MIT

Then add the implementation questions:

Was the remote mandate authenticated where required?

Is the credential stored correctly?

Do we have the original transaction/reference information?

Are we submitting the correct MIT/stored-credential indicators?

Can we reconstruct the customer's authorization if questioned?

That is a far safer approach than setting:

off_session = true

and assuming the classification follows.

How should MITs be designed into a subscription or SaaS payment system?

The payment model should track at least four states independently:

Credential state

Do we have a valid stored credential or token?

Mandate state

Do we have a valid customer agreement authorizing the relevant later merchant-initiated charges?

Initiator state

Who triggered this particular payment?

Customer or merchant?

Authentication state

Was SCA performed when required during setup or for the current customer-initiated payment?

These states should not be compressed into:

recurring_customer = true.

A better lifecycle is:

CUSTOMER SETUP

MANDATE + CREDENTIAL

SCA WHERE REQUIRED

INITIAL TRANSACTION REFERENCE

MERCHANT-INITIATED BILLING

+--> successful MIT

+--> declined MIT

customer intervention?

+---+---+

| |

NO YES

| |

v v

retry / new CIT

other with SCA

process where required

This architecture also makes declines, retries, dunning, and subscription recovery easier to reason about.

Merchant-initiated transactions are a lifecycle classification

The most important thing to remember about merchant-initiated transactions and SCA is that MIT is not shorthand for:

stored card

subscription

customer absent

or:

authentication exemption.

A qualifying MIT depends on a relationship:

customer mandate

→ appropriately established credential/payment relationship

→ merchant initiates a later agreed payment

→ no new customer action triggers that individual transaction

→ transaction is correctly identified to the payment ecosystem.

Under the current EEA PSD2 interpretation, those later genuine payee-initiated payments can fall outside the payer-initiated SCA requirement. The remote establishment of the mandate can itself require SCA, however, and a later payment becomes customer initiated again if the customer actively triggers it.

Recurring transactions add another reason to be precise: the regulatory recurring-payment exemption and genuine MIT treatment are related payment concepts but are not interchangeable.

The processing layer matters too. Current card-network rules expect stored-credential and merchant-initiated transactions to be identified appropriately and can use references linking later MITs to the original customer-initiated relationship.

For merchants, the practical rule is therefore:

Classify the transaction by who actually initiates it, preserve the customer's mandate and original payment relationship, and let the PSP/acquirer submit the correct current network indicators.

Do that before launch, rather than trying to reconstruct the distinction after recurring payments start failing authentication or authorization.

As of August 2026, PSD2 remains the operative EU framework relevant to the analysis above. The PSD3/Payment Services Regulation replacement package is close to adoption but had not yet been formally adopted in the latest official EU status material reviewed; merchants should therefore revalidate the framework as those reforms are finalized and eventually take effect.

This article provides general information and does not constitute legal, regulatory, or payment-network advice. SCA treatment and stored-credential processing can depend on jurisdiction, transaction characteristics, the customer mandate, card-network rules, issuer/acquirer behavior, and the merchant's PSP implementation. Merchants should confirm the current requirements that apply to their payment flows with qualified advisers and their payment providers.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

For Merchant-Initiated Transactions and SCA, the strongest SEO/editorial opportunity is to make one distinction impossible to miss:

A transaction is not an MIT merely because the customer is absent. A genuine merchant-initiated transaction is initiated by the merchant under a previously established customer mandate or agreement.

That is the article’s real competitive advantage, and the brief explicitly says MIT treatment should not be described simply as an SCA exemption.

SEO recommendations

Element

Recommendation

Merchant-Initiated Transactions and SCA: MIT Guide for Merchants

Alternative SEO title

What Is a Merchant-Initiated Transaction? MIT & SCA Explained

Merchant-Initiated Transactions and SCA: What Merchants Need to Know

Meta description

Learn what qualifies as a merchant-initiated transaction, how MITs differ from customer-initiated payments, when SCA applies, how mandates are established, and how merchants should identify and submit MIT payments.

Slug

/merchant-initiated-transactions-sca/

merchant-initiated transactions SCA

Secondary terms

MIT SCA, merchant initiated transaction PSD2, MIT payments, SCA merchant initiated transactions, stored credentials SCA

Schema

Article + BreadcrumbList

FAQ schema

Optional only if there is a genuine visible FAQ

For broad search demand, “What Is a Merchant-Initiated Transaction? MIT & SCA Explained” is probably strongest. For cluster consistency and commercial readers, the supplied title is better.

Featured-answer block

Place this very early:

A merchant-initiated transaction (MIT) is a payment initiated by the merchant under a prior agreement or mandate from the customer, without the customer actively initiating that specific payment. Qualifying MITs are generally treated differently from customer-initiated payments for Strong Customer Authentication purposes. MIT treatment is not simply an SCA exemption: the transaction must genuinely qualify as merchant initiated under the applicable payment and regulatory framework.

That directly addresses the primary search intent and protects against the most common simplification.

High-value long-tail SEO opportunities

The page should naturally cover:

what is a merchant initiated transaction

merchant initiated transactions SCA

does SCA apply to MIT payments

MIT vs CIT payment

merchant initiated transaction PSD2

customer initiated vs merchant initiated transaction

how to set up a merchant initiated transaction

merchant initiated transaction mandate

stored credential MIT payments

recurring payments vs MIT

unscheduled merchant initiated transaction

variable amount MIT

MIT payment flag

how to identify merchant initiated transactions

MIT initial transaction SCA

does the first MIT require SCA

off-session payment vs MIT

MIT transaction reference

why was an MIT declined

merchant initiated transaction 3D Secure

I would not turn each of these into an H2. The brief specifically calls for semantic completeness rather than keyword repetition.

Editorial recommendations

Make “off-session ≠ MIT” the primary correction

This deserves a prominent callout:

Off-session does not automatically mean merchant initiated.

The key question is who initiated the specific payment and whether the merchant is acting under a previously established customer mandate.

This will distinguish the article from a lot of generic subscription-payment content.

Use CIT vs MIT as the main organizing framework

A simple comparison table should appear near the top:

Customer-Initiated Transaction (CIT)

Merchant-Initiated Transaction (MIT)

Who starts the specific payment?

Customer

Merchant

Customer actively participating?

Usually yes

Prior mandate/agreement needed?

Not inherently

Yes, for genuine MIT treatment

SCA treatment

Assess SCA requirement/exemptions

Qualifying MIT can be treated outside payer-initiated SCA scope

Stored credential may be used?

Yes

Often

Can “off-session” alone determine classification?

This is probably the single most useful table for readers.

Distinguish three concepts that frequently get collapsed

I would add this box:

Do not confuse:

Stored credential

A payment credential has been saved for later use.

Off-session payment

The customer is not actively participating at the time of payment.

Merchant-initiated transaction

The merchant initiates the payment under an appropriate prior customer agreement.

They overlap, but they are not synonyms.

That is a strong AI-search/excerptable passage.

Make the original mandate a lifecycle, not paperwork

A mandate should not be presented as merely:

“customer agreed to terms.”

Editorially, make readers think about:

initial customer interaction

→ appropriate authentication where required

→ agreement for subsequent merchant-initiated charges

→ stored credential/reference linkage

→ later MIT

→ correct transaction identification

This gives developers and product teams something operational to implement.

Add a “classification before processing” rule

A useful principle:

Do not decide whether a payment is an MIT after an authentication problem occurs. The transaction type should be known before submission because the customer agreement, credential history, transaction indicators, and payment references need to support that classification.

This is a strong practical takeaway.

Be especially careful with variable amounts

The article should explain that:

variable amount ≠ automatically not MIT.

But it also should not claim every variable off-session payment qualifies.

The stronger editorial approach is to ask:

Does the original customer agreement authorize later merchant initiation?

Does it define how later charges can arise?

Is the current charge consistent with that agreement?

Is the PSP/network transaction type being submitted correctly?

Does the transaction need linkage to an initial credential/mandate event?

That is more useful than a blanket rule.

Internal-link strategy

The brief gives four priority destinations.

Suggested anchor

Destination

how authentication works across the subscription lifecycle

Recurring Payments and SCA

the foundational rules behind Strong Customer Authentication

Strong Customer Authentication Explained

payments that are in scope but may qualify for an exemption

SCA Exemptions

how card authentication is implemented through 3-D Secure

3D Secure Compliance

One important editorial rule: when explaining MIT, link to SCA Exemptions precisely to clarify that MIT is different from an exemption, rather than implying it belongs inside the exemption category.

Visual asset 1 — CIT vs MIT Decision Tree

This should be the hero asset.

PAYMENT IS ABOUT TO OCCUR

WHO INITIATES THIS SPECIFIC PAYMENT?

/ \

CUSTOMER MERCHANT

| |

v v

CIT IS THERE A VALID

PRIOR AGREEMENT /

MANDATE?

/ \

NO YES

| |

v v

NOT A POTENTIAL

VALID MIT MIT

IS TRANSACTION

CONSISTENT WITH

THE AGREEMENT?

/ \

NO YES

| |

v v

REASSESS SUBMIT AS

PAYMENT MIT USING

TYPE CORRECT DATA

Headline:

Customer absent is not the test. Who initiated the payment is.

Alt text:

Decision tree distinguishing customer-initiated transactions from merchant-initiated transactions based on who initiates the payment, whether a prior mandate exists, and whether the later charge is consistent with that agreement.

Visual asset 2 — CIT vs MIT vs Off-Session vs Stored Credential

A highly reusable matrix:

Concept

What it tells you

CIT

Customer initiated this payment

MIT

Merchant initiated this payment under a prior agreement

Off-session

Customer is not currently interacting with checkout

Stored credential

Payment credential is being reused

Recurring

Payments occur under a recurring relationship

Unscheduled MIT

Merchant initiates later payment without a fixed recurring schedule

Headline:

These labels describe different dimensions of a payment.

This is likely the best social/shareable visual.

Visual asset 3 — MIT Lifecycle

CUSTOMER-PRESENT SETUP

AGREEMENT / MANDATE

SCA WHERE REQUIRED

CREDENTIAL STORED /

RELATIONSHIP ESTABLISHED

INITIAL PAYMENT REFERENCE

RETAINED WHERE REQUIRED

LATER BUSINESS EVENT

Subscription / usage /

no-show / delayed charge

MERCHANT INITIATES PAYMENT

MIT IDENTIFIERS +

REFERENCE / LINKAGE

AUTHORIZATION

Headline:

MIT is a payment lifecycle, not simply a flag on a later transaction.

This visual is especially useful for developers.

Visual asset 4 — SCA Exemption vs MIT

This distinction deserves a dedicated graphic.

SCA EXEMPTION

Payer-initiated payment

SCA is in scope

Defined exemption may apply

Issuer may still require SCA

versus:

QUALIFYING MIT

Prior customer mandate exists

Merchant initiates later payment

Payer is not initiating

that specific transaction

Different SCA scope analysis

Headline:

An MIT is not simply another SCA exemption.

That directly satisfies the most important accuracy instruction in the brief.

Visual asset 5 — Recurring vs Unscheduled MIT

Type

Example

Amount/timing pattern

Fixed recurring

Monthly fixed subscription

Scheduled, often same amount

Variable recurring

Usage-based subscription

Scheduled relationship, variable amount

Unscheduled MIT

Later charge permitted by prior agreement

No fixed recurring schedule

Customer return/CIT

Customer comes back and clicks Pay

Customer initiates new payment

Headline:

Recurring and MIT overlap—but they are not identical classifications.

This is an excellent bridge to Recurring Payments and SCA.

Visual asset 6 — Merchant Implementation Data Model

For developers/payment operations:

PAYMENT RELATIONSHIP

|-- customer_agreement_id

|-- stored_credential_status

|-- initial_transaction_reference

|-- initial_authentication_status

LATER PAYMENT

|-- initiator

| customer / merchant

|-- transaction_type

| CIT / MIT

|-- MIT subtype

| recurring / unscheduled / other

|-- mandate_reference

|-- original_transaction_reference

|-- amount

|-- authorization_result

Headline:

Correct MIT treatment depends on preserving the relationship between setup and later payment.

I would add a note beneath it:

Exact fields and network indicators depend on the PSP, acquirer, payment method, and card-network implementation.

Visual asset 7 — Common MIT Misclassification Errors

COMMON ASSUMPTION ACTUAL QUESTION

"Customer isn't here" → Who initiated the payment?

"We stored the card" → Was later merchant initiation agreed?

"It's a subscription" → Is this payment CIT, recurring, or MIT?

"Amount is variable" → Does the mandate permit this charge?

"We sent MIT=true" → Does the underlying relationship qualify?

"Initial payment succeeded" → Was setup/authentication/reference

captured correctly?

Headline:

A transaction flag cannot fix an incorrectly designed payment relationship.

This is probably the most useful practical troubleshooting graphic.

Suggested callout boxes

I would use four throughout the article:

Key distinction: A merchant-initiated transaction is defined by who initiates the later payment under the existing agreement—not merely by whether the customer is currently online.

SCA distinction: Qualifying MIT treatment should not be described simply as an SCA exemption. The regulatory reasoning is different.

Implementation principle: Merchant-initiated status should be established from the customer agreement and transaction lifecycle before the payment is submitted.

Data principle: Preserve the relationship among the original customer interaction, stored credential, mandate, and subsequent merchant-initiated payment.

Suggested FAQ section

A genuine FAQ could help here because the queries are quite specific:

Does SCA apply to merchant-initiated transactions?

Qualifying MITs are generally treated differently from payer-initiated transactions for SCA purposes because the merchant, rather than the customer, initiates the later payment under an existing agreement. The original setup or mandate can itself require authentication depending on the circumstances.

Is every off-session payment an MIT?

No. “Off-session” describes customer presence, not necessarily who initiated the payment or whether a valid MIT relationship exists.

Is every subscription payment an MIT?

No. Subscription payments can involve several payment classifications. The initial setup is commonly customer initiated, while qualifying later charges can have different treatment depending on the recurring arrangement and transaction mechanics.

Can an MIT have a variable amount?

Potentially. Variable amount alone does not determine whether a transaction is an MIT. The payment must be consistent with the underlying customer agreement and submitted correctly through the applicable PSP/network framework.

Is MIT an SCA exemption?

It should not generally be described that way. A qualifying MIT can be outside the relevant payer-initiated SCA requirement rather than being an otherwise in-scope transaction using an exemption.

Does storing a customer's card make future payments MITs?

No. Stored credential status and transaction initiation are separate concepts.

Downloadable reader asset

The best downloadable resource would be an MIT Implementation Checklist.

Suggested fields:

Check

Status

Customer agreement permits later merchant-initiated charges

☐

Initial customer interaction documented

☐

SCA/authentication performed where required at setup

☐

Credential stored under appropriate framework

☐

Initial transaction/reference retained where needed

☐

Later payment initiator clearly classified

☐

MIT subtype identified

☐

Amount consistent with customer agreement

☐

Required PSP/network indicators supplied

☐

Original payment/mandate reference linked

☐

Authorization response retained

☐

Failed MIT recovery path defined

☐

Customer-present fallback flow available if needed

☐

Reporting distinguishes CIT, MIT, authentication and authorization

☐

This has real operational value for product, engineering, compliance, and payments teams.

Editorial CTA recommendation

Keep the CTA practical rather than promotional:

Before launching stored-credential or off-session payments, document exactly how the customer authorizes later merchant initiation, how the initial transaction is authenticated where required, how subsequent transactions are classified, and which references and indicators your PSP expects. Fixing those relationships before launch is much easier than trying to relabel failed payments as MITs afterward.

That directly supports the cluster's larger Compliance slows launches theme without making regulation sound like arbitrary friction.

The three assets I would prioritize

If design capacity is limited, build these first:

CIT vs MIT Decision Tree — resolves the primary question.

SCA Exemption vs MIT — protects the article's most important regulatory distinction.

MIT Lifecycle — gives developers and payment teams an implementation model.

Together, those assets make the page much more useful than a generic definition of merchant-initiated payments, while leaving the deeper recurring-payment, SCA exemption, and 3D Secure material to their dedicated cluster pages.

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗