Merchant-Initiated Transactions
Merchant-Initiated Transactions Explained: How Recurring Subscription Charges Work When the Customer Is Not Present Two backend requests can look almost identical. Both charge the same customer's stored card. Both contain: One can be a correctly structured merchant-initiated recu
Merchant-Initiated Transactions Explained: How Recurring Subscription Charges Work When the Customer Is Not Present
Two backend requests can look almost identical.
Both charge the same customer's stored card.
Both contain:
the merchant account;
the amount;
the currency;
a reusable payment credential;
no browser session;
no customer waiting at checkout.
One can be a correctly structured merchant-initiated recurring payment.
The other may simply be an incorrectly labeled card-on-file transaction.
The difference does not begin in the API request.
It begins earlier—when the customer originally agreed to the payment relationship, when the credential was stored, what the merchant told the customer about future use, how the first transaction or setup event was represented, and whether later payments actually belong to that established sequence.
That is why merchant-initiated transaction, or MIT, should not be understood as shorthand for:
“The merchant charged the card while the customer was offline.”
A more accurate operational definition is:
An MIT is a subsequent transaction initiated by the merchant under a previously established arrangement with the customer, without the customer actively initiating that specific payment, and represented according to the applicable stored-credential and network/payment-provider rules.
For subscription businesses, this distinction matters because the renewal payment does not really begin on the renewal date.
Its processing context was established when the subscription relationship began.
The renewal starts at subscription signup
A monthly subscription might look operationally simple:
Customer signs up
→ card is saved
→ month passes
→ merchant charges card
But that hides several separate payment concepts.
A more useful sequence is:
Customer actively enters payment flow
↓
Customer agrees to subscription/payment terms
↓
Initial transaction or account-verification/setup event
↓
Credential is stored under applicable rules
↓
Merchant retains evidence of the arrangement
↓
Subscription is created
↓
Billing date arrives
↓
Merchant creates a subsequent payment instruction
↓
Transaction is submitted using the appropriate
stored-credential / recurring / MIT context
That sequence is the foundation of the later recurring payment.
The cluster brief requires recurring billing to be modeled this way: initial customer setup and payment come before stored-credential use and later merchant-initiated charging.
If the initial setup was incomplete, later renewal failures are not necessarily a retry problem.
They can be a transaction-classification problem created months earlier.
What is a Customer-Initiated Transaction?
A Customer-Initiated Transaction, or CIT, is a transaction initiated while the customer is actively participating in the payment flow.
For example, a customer:
selects a subscription;
enters or chooses a payment credential;
sees the amount and relevant payment terms;
actively submits the payment.
That is conceptually different from a later renewal charge that the merchant initiates automatically.
A CIT can also use a credential that was already stored.
This is an important distinction:
Stored credential does not automatically mean MIT.
Suppose a returning customer logs in, selects their saved card, and clicks Buy now.
The credential was stored.
The customer is still actively initiating that payment.
That can therefore remain a customer-initiated transaction using a stored credential, rather than becoming an MIT merely because no PAN was re-entered.
The current Mastercard Transaction Processing Rules similarly treat credential-on-file status and CIT/MIT classification as separate dimensions: a transaction using stored account data must carry credential-on-file context in addition to the applicable CIT or MIT indicator.
That separation is fundamental.
What is a Merchant-Initiated Transaction?
A Merchant-Initiated Transaction is a later payment initiated by the merchant under a previously established arrangement, without the customer actively initiating that specific transaction.
Recurring subscription renewals are one common example.
The sequence is usually:
Customer establishes subscription
↓
Customer authorizes storage/future use
↓
Initial customer-participating payment/setup occurs
↓
Merchant stores payment credential
↓
Later billing date occurs
↓
Merchant initiates recurring payment
Mastercard's current public brand guidance describes recurring stored-credential payment as a payment where the merchant initiates a transaction using a credential the consumer previously stored and authorized for ongoing future use.
Visa's current public rules likewise impose explicit processing requirements for stored-credential arrangements, including customer agreement before storage and transaction indicators for recurring, installment, and unscheduled credential-on-file transactions.
So MIT status is not established merely because:
customer absent = true
or:
backend request = true.
The later transaction has to belong to the payment relationship that was established earlier.
Customer absence is necessary context, not sufficient classification
Consider these three card-on-file scenarios.
Scenario 1 — Monthly subscription renewal
The customer signed up for a $20 monthly subscription and authorized ongoing recurring charges.
The merchant bills the next renewal automatically.
The customer is not actively participating in that specific payment.
This may be a recurring merchant-initiated transaction when all applicable conditions and network/provider requirements have been established.
Scenario 2 — Customer presses “Buy again”
The customer previously stored a card.
They return six weeks later and actively click Buy again.
The customer is participating.
Even though the credential is on file, this is not automatically an MIT.
Scenario 3 — Merchant charges an old stored card without a qualifying agreement
The customer previously made a one-time purchase and allowed the merchant to store the credential for future convenience.
The merchant later decides to charge it for a service that the customer never authorized the merchant to initiate automatically.
The customer is absent.
That absence does not create a valid MIT relationship.
This is the central classification principle:
The question is not merely who sent the API request. The question is who initiated the payment under the established customer-payment relationship.
Stored credential and MIT are different concepts
Subscription architectures become much easier to reason about when these terms are separated.
Stored credential
A reusable payment credential has been retained for later use according to the applicable framework.
That credential might be:
a PAN stored through an appropriate secure environment
a PSP or merchant vault token
or:
another eligible credential representation.
The token architecture itself is separate from the transaction classification.
CIT using a stored credential
Customer actively initiates the payment but chooses the previously saved payment method.
Example:
“Use my saved Visa ending 1234.”
MIT using a stored credential
Merchant initiates a later payment under an established arrangement.
Example:
Monthly automatic subscription renewal.
Therefore:
STORED CREDENTIAL
|
+---- Customer actively participates
| ↓
| CIT
|
+---- Merchant initiates under qualifying
prior arrangement
↓
MIT
Do not encode:
if token_exists:
transaction_type = MIT
That is a conceptual bug.
The agreement is part of the payment architecture
Developers tend to think of subscription payment state in technical terms:
customer_id
token
subscription_id
amount
billing_date.
But the recurring transaction also depends on a commercial relationship.
The merchant needs appropriate evidence of what the customer agreed to.
Depending on applicable network rules, payment method, jurisdiction, and business model, relevant evidence may include:
merchant identity;
payment credential being stored;
reason for future charges;
frequency or triggering basis;
amount or method for determining it;
cancellation or termination terms;
duration where relevant;
other required stored-credential or recurring-payment disclosures.
Visa's current public stored-credential requirements state that cardholder agreement must be completed before storing the credential and before the first transaction, with recurring or other subsequent use represented through appropriate indicators.
Mastercard's current processing rules likewise define credential-on-file transactions around explicit cardholder authorization for the merchant to store account data and subsequently use it for later transactions.
The precise required terms should be verified against the merchant's current acquirer/PSP/network implementation.
The architectural principle is broader:
Consent is not metadata added after the payment. It is part of what makes the later payment relationship valid.
The initial transaction matters to later renewals
Subscription teams often focus heavily on renewal performance:
Was the renewal approved?
Can we retry it?
Should we use another PSP?
But the later renewal can depend on the initial transaction being structured correctly.
The original customer interaction can establish:
customer participation;
credential storage;
recurring agreement;
payment credentials;
initial authentication where applicable;
references or linkage needed by the provider/network for subsequent transactions;
evidence the merchant may later need for disputes or support.
The current Mastercard gateway documentation provides a useful implementation example in the European PSD2 context: it describes merchant-initiated transactions as subsequent transactions based on an agreement with the payer and states that the payer must be authenticated during the first transaction establishing that agreement.
European Banking Authority guidance similarly says payment transactions initiated by the payee without payer involvement can be outside the SCA requirement when they are genuinely based on a standing agreement authorizing the merchant to initiate subsequent payments.
So the later charge cannot always be “fixed” by changing one field in a renewal request.
If the required relationship was not established earlier, the merchant may need customer participation to repair the payment setup.
A transaction sequence is more useful than a transaction label
A strong subscription architecture should preserve the relationship between the initial setup and later payments.
Conceptually:
SUBSCRIPTION AGREEMENT
|
v
INITIAL CUSTOMER-PARTICIPATING EVENT
transaction_ref = TXN_001
relationship = INITIAL
customer_present = YES
|
v
STORED CREDENTIAL RELATIONSHIP
credential_ref = CRED_123
agreement_ref = AGR_456
|
+--------------------------+
| |
v v
RENEWAL 1 RENEWAL 2
transaction_ref = TXN_101 transaction_ref = TXN_102
relationship = SUBSEQUENT relationship = SUBSEQUENT
customer_present = NO customer_present = NO
agreement_ref = AGR_456 agreement_ref = AGR_456
The exact network/provider fields will differ.
Do not invent a universal agreement_ref field.
The useful design principle is:
A merchant should be able to explain why a later payment belongs to the earlier customer-authorized relationship.
That is more robust than storing only:
is_mit = true.
Recurring MIT and unscheduled merchant-initiated use are not identical
MIT is a broader concept than a conventional fixed monthly subscription.
Different merchant-initiated uses can have different network classifications or indicators.
At a high level, distinguish:
Recurring transaction
Merchant charges according to an established recurring arrangement.
Examples might include:
monthly membership
annual SaaS renewal
or another periodic subscription.
Installment transaction
A defined purchase is paid in several agreed installments.
That is economically different from an indefinite recurring subscription.
Unscheduled credential-on-file / other merchant-initiated transaction
Merchant initiates a later transaction under a qualifying agreement, but the amount or timing is not simply the fixed recurring schedule.
Depending on the network and use case, examples can include certain usage-based charges, delayed charges, or other specific merchant-initiated categories.
Do not assume every variable subscription charge should use the same technical indicator as a fixed recurring renewal.
Mastercard's current gateway documentation, for example, distinguishes a RECURRING_PAYMENT SCA treatment for certain fixed recurring payment scenarios from MERCHANT_INITIATED_TRANSACTION for varying amounts in the implementation documented by that gateway.
Exact production classification must be verified with the merchant's current PSP/acquirer and applicable network rules.
Recurring and unscheduled does not mean “predictable” versus “unpredictable” in ordinary English
This is an easy engineering error.
A merchant might say:
“We know roughly when the customer will incur the usage charge, so it's recurring.”
That ordinary-language description does not necessarily determine the payment-network classification.
Likewise:
“The amount changes every month, so it's unscheduled.”
may also be wrong in a given implementation.
Network payment terminology is not always identical to product-team vocabulary.
That is why the article brief requires merchants to separate:
network rules
from:
provider terminology.
Build one merchant semantic model, but preserve the exact provider/network transaction classification that gets transmitted.
Transaction indicators matter because the payment is being explained to other participants
A payment request is not simply:
Charge this card $29.
It also communicates context.
For recurring stored-credential transactions, relevant network/provider fields can convey facts such as:
credential stored
initial versus subsequent transaction
customer-initiated versus merchant-initiated
recurring relationship
transaction subtype
and potentially:
reference/linkage to the original transaction
depending on the network/provider implementation.
Why does this matter?
Because the acquirer, network, and issuer do not see the merchant's subscription database.
They see payment messages.
The merchant might know internally:
“This customer has been subscribed since 2024.”
That knowledge does not automatically reach the issuer.
The transaction has to be represented correctly through the payment stack.
Visa's rules explicitly require applicable stored-credential indicators for recurring and related credential-on-file transactions.
Mastercard similarly requires credential-on-file context alongside the appropriate CIT or MIT indicator where stored account data is used.
The indicator is how merchant business state becomes payment-network context.
Provider terminology can hide network distinctions
A PSP API may expose one high-level field such as:
recurring = true
Another may expose:
initiator = merchant
Another may expose:
storedCredential.sequence = subsequent
Another may derive parts of the transaction context automatically from a subscription object.
Do not assume those APIs mean exactly the same thing.
The merchant needs to understand:
what business event it is creating;
what the applicable network classification is;
how its PSP/acquirer expects that classification to be represented;
which provider fields are derived automatically;
which ones the merchant must supply;
whether linkage to the original transaction/setup is required.
That mapping should be documented and versioned.
A good internal record might include:
Merchant concept
Provider/network representation
Customer actively initiated
Provider-specific CIT indicator
Merchant initiated
Provider-specific MIT indicator
Credential stored
Stored-credential flag/context
Initial setup
Initial sequence indicator
Subsequent use
Subsequent sequence
Recurring relationship
Provider/network recurring subtype
Initial transaction reference
Provider/network reference where applicable
Never publish this as one universal field-name table.
PSP and network interfaces differ.
MIT does not mean “authentication never applies”
This is one of the most important distinctions in subscription billing.
Avoid:
“MITs bypass authentication.”
That language is both technically imprecise and likely to mislead merchants.
The better sequence is:
Authentication obligations depend on jurisdiction, customer participation, transaction classification, payment method, and how the payment relationship was originally established.
In the EEA PSD2 context, the EBA says payment transactions not initiated by the payer but by the payee, and initiated without payer interaction, are not subject to SCA in the same way as payer-initiated electronic transactions. But the existence of the required mandate/standing agreement matters, and establishing that mandate remotely can itself require SCA.
This is better described as:
transaction outside the relevant SCA scope because of how it is initiated
rather than casually calling MIT an “exemption.”
The exact legal and network implementation should be verified for the current geography.
Initial authentication still matters
For recurring subscriptions, an EEA-oriented flow may conceptually look like:
CUSTOMER PRESENT
|
v
Subscription setup / initial transaction
|
+--> customer consent
+--> credential storage
+--> authentication where required
|
v
Recurring relationship established
|
v
CUSTOMER NOT PRESENT
|
v
Subsequent merchant-initiated payment
The dedicated Recurring Payment Authentication article should own SCA, challenge flows, exemptions/out-of-scope treatment, and reauthentication in depth.
The MIT article needs only one firm rule:
Do not decide authentication treatment by looking only at whether the current request came from backend code.
MIT is not itself an SCA exemption
This wording deserves a separate callout because many implementations get it wrong.
In provider APIs, merchants may encounter fields named:
exemption
with a value such as:
MERCHANT_INITIATED_TRANSACTION.
That API design can lead teams to conclude:
“MIT is an exemption.”
But under PSD2 analysis, genuinely payee-initiated transactions without payer involvement are generally treated as outside the payer-initiated SCA requirement rather than as a conventional SCA exemption under Articles 11–18 of the RTS. The EBA's guidance explicitly describes payee-initiated transactions as not subject to SCA where the payer is not involved in initiation.
A gateway field name is therefore not necessarily the best legal description of the regulatory mechanism.
This illustrates a larger principle:
Provider API terminology is an implementation interface. It is not automatically the governing network or regulatory definition.
A customer returning to fix a failed MIT can change the transaction context
Suppose the monthly renewal was a valid MIT.
It fails.
The merchant sends a dunning message:
Update your payment method.
The customer clicks the link, enters a new card, and submits payment.
That recovery payment now involves active customer participation.
It should not automatically inherit the transaction classification of the failed merchant-initiated renewal.
Conceptually:
RECURRING RENEWAL
customer absent
→ MIT attempt fails
CUSTOMER RETURNS
actively updates card / submits payment
→ customer-participating payment context
FUTURE RENEWALS
merchant initiates under newly established/updated relationship
→ subsequent merchant-initiated context where valid
The exact provider/network handling must be verified.
The important architectural lesson is:
Transaction classification belongs to the event, not permanently to the subscription.
Do not store:
subscription.is_mit = true
and blindly apply it to every payment touching that subscription.
Classify the payment attempt, not the customer
Likewise, do not say:
“This customer is MIT.”
A customer can generate:
CIT
and later:
MIT
and later:
another CIT
within the same subscription relationship.
A better model attaches classification to each payment attempt.
For example:
payment_attempt
id
subscription_id
billing_cycle_id
customer_participating
stored_credential_used
initiator_class
credential_sequence
recurring_relationship
provider_transaction_id
original_transaction_reference
Field names are illustrative.
The design principle is:
Payment classification should be reconstructable per attempt.
That becomes especially important when investigating:
renewal failures
authentication
disputes
PSP migrations
and:
multi-provider retry behavior.
Keep the initial transaction reference
Where applicable to the network/provider implementation, later stored-credential transactions may need to maintain linkage to an initial credential-storage transaction or previously established relationship.
Do not treat the original transaction ID as disposable historical data once the first payment settles.
A merchant may need to preserve:
merchant subscription ID
billing-cycle ID
credential ID
initial PSP transaction ID
network/provider reference
subsequent payment attempt IDs
CIT/MIT classification
and:
provider used.
This becomes particularly important when the merchant changes PSPs.
Multi-PSP subscription billing exposes classification dependencies
A one-time payment can often be routed relatively independently.
Recurring MITs are harder.
Suppose the initial customer setup occurred through PSP A.
Six months later, the merchant wants to send the renewal through PSP B.
Questions immediately appear:
Does PSP B have a usable credential?
What credential type is it?
Can the stored-credential relationship be represented correctly through PSP B?
Does the network/provider require original transaction information?
Can the merchant preserve the relevant MIT sequence?
Was the customer agreement broad enough for the intended billing setup?
Can PSP B correctly transmit the applicable network indicators?
The cluster explicitly warns against assuming a recurring decline can simply be retried through another PSP because credentials, transaction history, stored-credential state, and MIT indicators may not transfer automatically.
That deeper architecture belongs in Subscription Billing Across PSPs.
For MIT design, the takeaway is:
Transaction classification state must not disappear inside one PSP if the merchant expects recurring billing to be portable.
Customer agreement and transaction history also matter for disputes
MIT classification is primarily a payment-processing issue.
But the original relationship can later become relevant operational evidence.
If a customer disputes a renewal, the merchant may need to establish:
what the customer purchased
what recurring terms were presented
whether the customer agreed
which credential was used
when renewals were scheduled
what cancellation state existed
and:
which payment was the initial versus subsequent transaction.
The dedicated Subscription Chargeback Prevention article should own prevention and evidence strategy.
The MIT article's narrower point is:
A clean transaction sequence improves both processing correctness and the merchant's ability to explain what happened later.
The CIT vs MIT Decision Map
A useful classification process begins before the API request.
Is the customer actively participating in this specific payment?
Yes
Start from CIT analysis.
The fact that the merchant uses a saved credential does not turn it into MIT.
No
Continue.
Customer absence alone does not prove MIT eligibility.
Is a credential being stored or reused?
No
The transaction may not belong to a stored-credential MIT framework at all.
Re-evaluate the actual payment method and transaction type.
Yes
Continue.
Is there a prior qualifying agreement authorizing the merchant to initiate this type of subsequent payment?
No
Do not simply mark it MIT.
Customer participation or a properly established payment arrangement may be required.
Yes
Continue.
Is the later charge genuinely merchant initiated under that agreement?
Consider whether it is:
recurring
installment
unscheduled/other permitted MIT category
or another applicable provider/network-defined type.
Do not choose the subtype based solely on product-team vocabulary.
Which transaction relationship and indicators does the current PSP/acquirer/network implementation require?
Verify:
CIT/MIT
stored credential
initial/subsequent sequence
recurring/other MIT subtype
original transaction/reference linkage
and any other applicable current requirements.
Is customer interaction required before proceeding?
This can occur because:
the original setup was insufficient
the customer is changing credentials
authentication is required
the agreement changed materially
or:
the payment cannot validly proceed as the intended MIT.
If customer participation resumes, classify that new payment interaction accordingly.
Decision Map summary
Is customer actively participating?
|
+----+----+
| |
YES NO
| |
CIT Stored credential?
|
+----+----+
| |
NO YES
| |
Re-evaluate Prior qualifying
transaction agreement?
|
+----+----+
| |
NO YES
| |
Customer/setup Merchant genuinely
action needed initiates later charge?
|
+----+----+
| |
NO YES
| |
Reclassify Identify MIT
subtype/relationship
|
v
Apply current provider/
network indicators
|
v
Customer action required?
| |
Exact final classification must be verified against current network, acquirer, PSP, payment-method, geography, and transaction-specific rules, as the editorial brief requires.
Common implementation error: customer_present = false means MIT
This is the most obvious misclassification.
Why it fails:
Customer absence describes what is happening now.
MIT classification also depends on what happened before.
A backend job running without the customer can represent:
valid recurring MIT
valid other merchant-initiated use
invalid use of an old credential
technical recovery operation
or another transaction type.
Fix:
Store and evaluate the relationship, not only the channel.
Common implementation error: every stored-card transaction is MIT
Why it fails:
A customer can actively initiate a payment using a stored credential.
Fix:
Represent at least:
credential stored?
and:
who initiated this payment?
as different dimensions.
Common implementation error: MIT is a subscription-level flag
Why it fails:
One subscription can contain multiple payment contexts.
Example:
signup CIT
→ renewal MIT
→ failed renewal
→ customer payment-update CIT
→ later renewal MIT.
Fix:
Classify each payment attempt.
Common implementation error: renewals lose the original transaction relationship
Why it fails:
Provider migrations, storage design, or data retention can separate the later payment from information needed to represent the original relationship correctly.
Fix:
Preserve durable merchant-side linkage between:
subscription
credential
initial setup
and:
subsequent attempts.
Common implementation error: copy transaction indicators from one PSP to another
Why it fails:
Provider APIs expose network concepts differently.
recurring=true
at PSP A does not prove:
merchantInitiated=true
at PSP B is semantically identical.
Fix:
Create a merchant canonical model and maintain provider-specific mappings.
Common implementation error: treat MIT as an authentication shortcut
Why it fails:
Classification should describe the real transaction relationship.
It should not be selected because the merchant wants to avoid customer friction.
In the EEA, EBA guidance ties payee-initiated treatment to the genuine absence of payer involvement and the existence of the underlying mandate/standing agreement.
Fix:
Determine the transaction structure first.
Apply the correct authentication treatment second.
Common implementation error: retry a failed renewal using a different classification
Suppose the original renewal is correctly submitted as an MIT but declines.
A merchant should not casually send the same transaction again as a CIT solely to change how it is processed when the customer has not actually returned.
Likewise, if the customer has returned and actively participates in the recovery payment, the new interaction should not automatically remain MIT just because the original renewal was MIT.
Fix:
Let actual customer participation determine the transaction context.
Common implementation error: assume successful authorization proves classification was correct
A payment can authorize even when the merchant's stored-credential architecture is poorly modeled.
Authorization is not a compliance audit of the merchant's subscription design.
A successful payment therefore does not prove:
the original agreement was sufficient
the network indicators were optimal
the transaction sequence was correctly stored
or:
future payments will behave correctly.
Fix:
Validate the architecture independently against current PSP/acquirer/network requirements.
Merchant-initiated transaction data model
A scalable merchant system should retain enough information to distinguish the relevant states without storing payment-network logic only inside scattered application code.
A conceptual payment-attempt model could include:
subscription_id
billing_cycle_id
payment_attempt_id
customer_participating
credential_id
credential_type
stored_credential_used
credential_sequence
merchant_initiated
merchant_initiated_category
initial_transaction_id
provider_transaction_id
provider
payment_method
authentication_status
raw_provider_transaction_type
canonical_transaction_type
agreement_version
agreement_timestamp
Not every field belongs in every database.
The important principle is that the merchant should be able to reconstruct:
who initiated the payment
why the credential could be reused
which earlier arrangement supported it
where the payment sits in the sequence
and:
what the provider/network was told.
The cluster's broader recommended subscription data model likewise calls for payment-attempt IDs, provider/acquirer context, credential identifiers, CIT/MIT indicators, authentication state, and raw provider responses where relevant.
Separate merchant meaning from provider fields
A useful architecture has three layers.
Merchant subscription state
Examples:
subscription active
billing cycle due
customer agreement current
cancellation state.
Merchant payment classification
Examples:
customer actively participating
stored credential used
initial/subsequent
merchant initiated
recurring relationship.
PSP/network implementation
Examples:
provider-specific stored-credential flag
provider-specific MIT indicator
provider-specific recurring field
network reference/linkage.
This prevents a vendor migration from changing the merchant's understanding of its own payment relationship.
Its older Digital Goods API documentation likewise describes support for recurring memberships and subscription products.
Those public sources support the restrained statement that:
current Visa MIT field mapping;
current Mastercard MIT field mapping;
original-transaction-reference handling;
current CIT/MIT indicators exposed to merchants;
automatic stored-credential framework handling;
universal SCA/MIT treatment;
cross-PSP MIT portability;
Those details should be verified internally before publication.
The final recommendation
The most important MIT decision does not happen when the renewal job runs.
It happens when the subscription is created.
That is when the merchant establishes:
customer participation
commercial agreement
credential storage
initial payment context
authentication where required
and:
the relationship that later payments will depend on.
The renewal request months later is simply the next event in that sequence.
So do not design merchant-initiated transactions as:
if customer_not_present:
mit = true
Design them as a lifecycle:
Customer establishes relationship → credential is stored correctly → initial transaction/setup is represented correctly → subsequent payment belongs to that relationship → merchant initiates it without customer participation → applicable network/provider indicators preserve the sequence.
That approach also makes renewal failures easier to diagnose.
If a subsequent charge fails, the merchant can ask:
Was the credential valid?
Was this actually an MIT?
Was the original relationship established correctly?
Did the PSP receive the correct subsequent-transaction context?
Does the customer now need to participate?
Is authentication required for the next interaction?
Can this payment still use the same stored-credential relationship?
Those are much better questions than:
“What MIT flag makes the card go through?”
The flag is not the relationship.
It is the payment-system representation of a relationship the merchant should already have created correctly.
This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, or commercial advice. Subscription merchants should verify current recurring-payment rules, stored-credential requirements, authentication requirements, network rules, customer-consent obligations, cancellation requirements, payment-provider terms, and applicable laws with qualified advisers, acquirers, payment providers, card networks, and relevant authorities.
🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
END OF ARTICLE
A. Brief interpretation
This is Subscription Operations — Article 8: Merchant-Initiated Transactions. It owns the mechanics of CIT versus MIT classification, stored credentials, the original customer agreement, the transaction sequence, recurring versus other merchant-initiated use, indicators, and the relationship between MIT classification and authentication.
The merchant problem is not simply “how do we charge a stored card?” It is that engineering teams often treat MIT as a property of the API call being made today, when the validity and processing context of that later payment depend on what happened when the customer first established the payment relationship.
The article's central thesis is:
A merchant-initiated transaction is not just a backend card-on-file charge. It is a transaction classification built on an earlier customer relationship, stored-credential setup, consent, and correctly represented transaction sequence.
The core assumption to challenge is therefore:
“Any card-on-file transaction sent while the customer is offline is an MIT.”
That is too broad. The controlling brief explicitly requires the article to distinguish customer absence from valid MIT classification and to distinguish stored credential status from MIT status.
Lifecycle stage: The article begins at subscription setup, not renewal. It follows the initial customer-participating payment/setup event into storage of the credential and then into subsequent recurring merchant-initiated charges.
Primary participants: Customer/cardholder, merchant, PSP/acquirer, card network, and issuer. The merchant determines the business event and passes the appropriate transaction context through its PSP/acquirer; network and issuer systems receive that context according to applicable rules.
Authentication context: MIT classification is not itself an “authentication exemption” that merchants can apply loosely. In the EEA, current European Banking Authority guidance distinguishes payment transactions initiated by the payee without payer involvement from payer-initiated transactions for SCA purposes; the standing agreement and initial customer interaction matter.
Merchant decision: Was this subsequent charge actually created under a qualifying prior customer arrangement and encoded using the transaction relationship required by the applicable network/provider implementation?
Selected format: Transaction classification journey, culminating in a CIT vs MIT Decision Map.
Everything below is SEO, editorial, sourcing, architecture, verification, and production guidance and is not publication copy.
Original practical asset — CIT vs MIT Decision Map
Use this as the main visual and potentially as a downloadable engineering checklist.
Decision
If yes
If no
Is the customer actively participating in this payment?
Start with CIT
Continue classification
Is a stored credential being used?
Record stored-credential context separately
MIT stored-credential framework may not apply
Was a qualifying prior customer agreement/setup established?
Continue
Customer/setup action may be required
Did the merchant genuinely initiate this later payment under that agreement?
Potential MIT
Reclassify transaction
What type of later payment is it?
Recurring/installment/other applicable category
Do not guess from product terminology
Which network/provider indicators apply?
Apply current verified mapping
Integration must be corrected
Does the customer need to participate now?
Enter a customer-participating payment/authentication flow
Proceed under verified MIT treatment
Asset footer
Customer absence is a condition of the payment. A qualifying prior relationship is what gives that absence transaction meaning.
Proposed architecture
SUBSCRIPTION / BILLING SYSTEM
|
+-- subscription_id
+-- billing_cycle
+-- amount
+-- cancellation state
|
v
MERCHANT PAYMENT CLASSIFICATION LAYER
|
+-- customer participating?
+-- stored credential?
+-- initial / subsequent?
+-- CIT / MIT?
+-- recurring / other MIT category?
+-- agreement reference
+-- initial transaction reference
|
v
PSP / ACQUIRER ADAPTER
|
+-- provider-specific transaction type
+-- provider-specific stored credential field
+-- network indicator
+-- original transaction/reference where required
+-- authentication context
|
v
CARD NETWORK / ISSUER
The merchant classification layer should remain stable even when PSP field names change.
SEO package
Merchant-Initiated Transactions: CIT vs MIT Explained
H1:
Merchant-Initiated Transactions Explained: How Recurring Subscription Charges Work When the Customer Is Not Present
Meta description:
Learn how merchant-initiated transactions work, how CIT and MIT differ, how stored credentials and initial customer consent affect recurring payments, and why MIT classification must begin at subscription setup.
Suggested URL:
/solve/payment-operations-dont-scale/subscription-operations/merchant-initiated-transactions/
merchant initiated transactions
Secondary keywords:
MIT payments
merchant initiated transaction recurring
recurring MIT
CIT vs MIT
stored credential transactions
merchant initiated recurring payment
recurring card transaction
card on file MIT
subscription MIT payments
These are the article-specific search targets.
Related entities: Merchant-initiated transaction, customer-initiated transaction, MIT, CIT, recurring transaction, stored credential, card on file, subscription billing, recurring payment, credential-on-file, PSP, acquirer, card network, issuer, SCA, PSD2, authentication, recurring agreement, network transaction indicator.
Article excerpt:
A merchant-initiated transaction is not simply a backend charge made while the customer is absent. In recurring billing, the later payment depends on the customer agreement, credential-storage setup, initial customer-participating transaction, transaction sequence, and network/provider indicators established earlier. Correct CIT-versus-MIT classification therefore begins at subscription setup—not when a renewal fails.
Featured-answer candidate:
A merchant-initiated transaction (MIT) is a payment the merchant initiates without the customer actively participating in that specific payment, under a previously established customer agreement. Recurring subscription renewals can qualify as MITs when the stored credential relationship and initial setup were established correctly. A stored card alone does not make a transaction an MIT.
Internal-link strategy
Use the four links assigned by the editorial brief.
Recommended anchor
Destination
Boundary
recurring payment authentication
Recurring Payment Authentication
Owns SCA/authentication treatment
why subscription payments fail
Why Subscription Payments Fail
Owns classification failures as one renewal-failure cause
subscription billing across PSPs
Subscription Billing Across PSPs
Owns credential and transaction-state portability
failed payment recovery
Failed Payment Recovery
Owns what happens after a renewal attempt fails
Natural secondary links:
Network Tokens for Subscriptions where credential types are introduced.
Subscription Chargeback Prevention where agreement/history become dispute evidence.
Avoid turning the MIT article into either of those topics.
Authoritative external-source recommendations
Visa
Use current Visa rules or the merchant's acquirer-provided current Visa implementation guidance for:
stored-credential agreement requirements;
initial/subsequent transaction representation;
recurring/unscheduled transaction indicators;
MIT processing requirements;
original-transaction references where applicable.
Current public Visa Interlink rules confirm that stored-credential transactions require prior cardholder agreement and appropriate recurring/installment/unscheduled indicators.
Mastercard
Use current Mastercard Transaction Processing Rules for:
credential-on-file requirements;
CIT/MIT distinction;
stored-credential indicators;
MIT categories;
transaction references;
recurring transaction requirements.
Current Mastercard rules explicitly distinguish credential-on-file status from CIT/MIT classification.
Mastercard also warns that public rule documents may not always be absolutely current and that official rules control in the event of discrepancies, which is another reason publication and implementation should be validated through current acquirer/provider guidance.
EBA / European Commission
For EEA SCA claims, prioritize current EU law and EBA/Commission interpretation.
The EBA's final Q&A states that payment transactions initiated solely by the payee without payer involvement are not subject to SCA under the payer-initiated transaction requirement, provided the merchant has the necessary standing arrangement; it also distinguishes remote establishment of that mandate.
Because EBA Q&A pages warn that old answers are not systematically updated after legislative amendments, confirm the legislation remains current before publication.
Supporting visual
Title
CIT vs MIT Across the Subscription Lifecycle
CUSTOMER PRESENT
|
v
Subscription signup
|
+--> agrees to recurring relationship
+--> payment credential supplied/stored
+--> authentication where required
|
v
INITIAL PAYMENT / SETUP
|
| CIT / initial stored-credential context
|
v
RECURRING RELATIONSHIP ESTABLISHED
|
v
Billing date
|
v
CUSTOMER NOT PRESENT
|
v
MERCHANT INITIATES RENEWAL
|
| subsequent stored-credential / MIT context
|
v
Payment processed
|
+--> succeeds
|
+--> fails
|
v
Alt text
Diagram showing a customer-initiated subscription signup establishing consent and a stored credential, followed by subsequent merchant-initiated recurring subscription payments when the customer is not actively participating.
Proposed author and reviewers
Recommended author: Payments architect with direct stored-credential and recurring-payment implementation experience.
Network/acquiring reviewer: Acquiring or card-network specialist who can verify current CIT/MIT indicators and stored-credential sequence requirements.
Compliance reviewer: Payments compliance specialist familiar with recurring transaction classification and jurisdiction-specific authentication.
These are the reviewer roles specified by the editorial brief.
The strongest first-hand contribution would be an approved architecture example showing:
subscription signup
→ initial customer-participating payment/setup
→ stored-credential relationship
→ later recurring MIT
→ customer-assisted recovery CIT
→ future MIT relationship.
Do not invent merchant approval improvements or failure reductions.
Technical fact-check checklist
Before implementation or publication, verify:
Current initial stored-credential flow.
Current subsequent stored-credential flow.
How active customer participation is represented.
How merchant initiation is represented.
Initial-versus-subsequent sequence.
Recurring transaction indicator.
Unscheduled MIT indicator where relevant.
Installment indicator where relevant.
Original transaction/reference requirements.
Required agreement evidence.
PSP field mappings.
Acquirer field mappings.
Token/credential type.
Merchant payment-attempt data model.
Trial/signup versus first paid charge.
Renewal-payment classification.
Recovery-payment classification.
Cancellation-state propagation.
Multi-PSP handling.
Reporting and raw provider data retention.
Network-rule fact checks
For each supported card network, verify the current applicable rules covering:
stored credential
cardholder agreement
credential storage
initial transaction
subsequent transaction
CIT
MIT
recurring MIT
installment
unscheduled MIT
transaction sequence
transaction identifier/linkage
authorization response handling
and:
decline-related restrictions where relevant.
Do not assume Visa terminology and Mastercard terminology are identical.
Do not copy one network's indicators into another network implementation.
Authentication / MIT fact checks
Where SCA or other authentication is mentioned, verify:
jurisdiction
customer participation
initial payment or setup event
whether a mandate/agreement is being created or changed
whether current payment is payer/customer initiated
whether current payment is genuinely merchant/payee initiated
network classification
PSP/acquirer implementation
and:
current effective regulation/rule.
Do not state:
“MITs are exempt from SCA.”
For EEA material, more precise wording is generally needed because genuine payee-initiated transactions without payer involvement are treated outside the payer-initiated SCA requirement under the cited EBA interpretation, rather than simply as a generic exemption.
Credential and token fact checks
MIT status should remain distinct from credential type.
Verify whether the merchant uses:
raw PAN in an eligible PCI-controlled environment
merchant vault token
PSP token
network token
or another representation.
Then separately verify whether the credential relationship can support the intended subsequent transaction.
Do not write:
“network token = MIT token.”
or:
“PSP token proves the payment qualifies as MIT.”
Credential representation and transaction classification are different dimensions.
Multi-PSP fact checks
Before moving recurring MITs between providers, verify:
credential ownership
credential portability
token type
original transaction/reference portability
stored-credential relationship data
MIT indicator support
network requirements
PSP B's ability to use the credential
authentication implications
duplicate-charge controls
and:
canonical attempt history.
The source brief explicitly prohibits treating PSP B as a trivial failover route for recurring payments.
Merchant-model assumptions
Before defining the MIT implementation, document:
subscription type
billing cadence
fixed versus variable amount
customer markets
merchant entity
payment method
PSP/acquirer
credential type
initial payment behavior
free trial versus paid signup
customer agreement
authentication regime
renewal behavior
customer-assisted recovery behavior
PSP migration plan
and:
cancellation semantics.
An annual membership with a one-year gap between payments can expose different operational problems from a monthly subscription, even if both produce recurring MITs.
Regulatory boundary
The article should distinguish:
network transaction classification
from:
regulatory authentication treatment
from:
provider API terminology
from:
merchant contractual/customer-consent obligations.
Do not turn card-network MIT classification into a universal legal definition for every payment method.
MIT terminology is particularly card-oriented.
Recurring direct debit, bank mandates, and other payment methods can use different legal and scheme constructs.
Amber-flag claims
Do not publish without current, scoped verification:
“Any card-on-file payment without the customer is an MIT.”
“Every recurring payment is an MIT.”
“Every MIT uses a stored credential.”
“Stored credential means MIT.”
“MITs bypass SCA.”
“MITs are always exempt from SCA.”
“The initial transaction must always be charged rather than verified.”
“All recurring payments use the same MIT indicator.”
“Variable subscription payments use the same indicator as fixed recurring charges.”
“PSP A's MIT field is equivalent to PSP B's.”
“A successful authorization proves the MIT was classified correctly.”
“A customer returning to update a card should still be charged as MIT.”
“MIT classification can be fixed by changing the renewal API request.”
MIT eligibility, SCA treatment, network rules, and provider implementations are explicitly identified as amber-flag areas by the source brief.
Current public documentation verifies recurring subscription functionality, but not enough MIT implementation detail for stronger claims.
Before publication, verify internally:
Which products support provider-managed subscriptions.
Which support merchant-managed recurring charging.
Current Visa stored-credential implementation.
Current Mastercard stored-credential implementation.
Current CIT field/indicator support.
Current MIT field/indicator support.
Initial transaction sequence handling.
Subsequent transaction sequence handling.
Recurring indicator mapping.
Unscheduled MIT mapping.
Installment mapping if applicable.
Original transaction/reference handling.
Credential-on-file indicator handling.
Which fields merchants must supply.
Customer-agreement requirements exposed to merchants.
Trial/signup setup behavior.
Account verification versus first-payment behavior.
Current permanent-token relationship to recurring/MIT flows.
Network-token support in MIT flows.
PSP token behavior.
Current 3DS/SCA treatment.
Current initial SCA behavior in EEA.
Subsequent MIT treatment.
Customer-assisted payment recovery after a failed MIT.
Reauthentication behavior.
Merchant-requested one-off card-on-file CIT behavior.
Multi-PSP MIT support.
Credential portability.
Original transaction reference portability.
Subscription migration.
Reporting fields exposing CIT/MIT.
Payment-status reporting.
Raw network/acquirer indicators available to merchant/support teams.
Decline-response behavior for MITs.
Network advice-code visibility where applicable.
Dispute evidence for recurring MITs.
Cancellation propagation.
Current recurring-method coverage beyond cards.
Which recurring flows are legacy.
Current API versions.
Internal owner of MIT/network-rule compliance.
Approved merchant MIT implementation example.
Any verified MIT authorization-performance evidence.
Any approved SCA/MIT performance claims.
Cluster sameness audit
Field
Merchant-Initiated Transactions
Cluster article
Article 8
Primary format
Transaction classification journey
Opening device
Two identical backend stored-card requests with different transaction legitimacy/context
Merchant problem
Teams believe backend customer absence alone creates MIT
Lifecycle stage
Initial subscription setup → stored credential → subsequent payment
Primary friction
Transaction relationship incorrectly established or classified
Primary mechanism
CIT/MIT + stored-credential transaction sequence
Evidence anchor
Later renewal validity/context begins at the original customer interaction
Editorial position
Design classification at signup, not after renewal failure
Assumption challenged
Any offline card-on-file charge is MIT
Primary distinction
Customer absence ≠ valid MIT classification
Supporting distinctions
CIT ≠ MIT; stored credential ≠ MIT; recurring ≠ unscheduled MIT; MIT ≠ authentication exemption; provider terminology ≠ network rule
Merchant decision
Does this payment genuinely belong to a qualifying prior merchant-initiated relationship?
Original framework
CIT vs MIT Decision Map
Primary data object
Payment attempt + original transaction/relationship context
Primary architectural control
Merchant canonical transaction-classification layer
Authentication boundary
Explains relationship only; Recurring Payment Authentication owns SCA implementation
Failure boundary
Classification can cause failures; Why Subscription Payments Fail owns diagnosis taxonomy
Recovery boundary
Customer return can change transaction context; Failed Payment Recovery owns recovery sequence
Multi-PSP boundary
Identifies sequence/reference portability needs; Subscription Billing Across PSPs owns full architecture
Token boundary
Distinguishes credential from classification; Network Tokens article owns token lifecycle
Conclusion
MIT is the payment representation of a relationship established earlier
Does not own
Retry timing, dunning, full SCA implementation, network-token mechanics, full multi-PSP architecture, chargeback prevention
That keeps the article precisely within the ownership assigned by the brief: merchant-initiated recurring transaction mechanics and classification.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗