What Is a Merchant-Initiated Transaction (and Why the Flag Decides the Outcome)
Two charges on the same card, for the same amount, under the same agreement can get opposite answers from the issuer. Usually the difference is not the transaction. It is how the transaction was labelled.
A merchant-initiated transaction is a charge the merchant submits against a stored credential without the cardholder being present, under an agreement the cardholder set up earlier. A cardholder-initiated transaction is one the cardholder is actively taking part in. The distinction sounds administrative. It is not: it changes what the issuer is being asked, what authentication it expects to see, and how it reads a transaction that arrives without a person behind it.
The Chain Starts With One Transaction
Every stored-credential arrangement begins with a cardholder-initiated transaction. That first transaction is where consent is captured, where the credential is stored, and where the authorization message has to say so.
What follows is a chain. Each later merchant-initiated charge has to point back to that first transaction, and the networks define how. Global Payments' developer documentation describes the mechanism plainly: subsequent transactions carry scheme reference data, a unique identifier from the network that links to the payment history between that cardholder and that merchant, along with a credential-on-file sequence marked as subsequent rather than first.
Break the chain and you have an orphan. A stored-credential charge arrives at the issuer with no link to the transaction that authorized the arrangement, no cardholder present, and nothing to connect it to a history. That is close to the exact profile of a transaction issuers are built to decline.
The Taxonomy Is Not Decoration
Merchant-initiated is not one thing, and the subtype you send changes how the issuer reads the charge. The main distinctions, as the processor documentation sets them out:
Recurring. Fixed amount, no fixed end date. The merchant keeps charging until the cardholder cancels. A subscription or a membership.
Installment. Fixed amount and fixed duration. Once the term ends, the merchant cannot charge the credential again.
Unscheduled credential on file. No schedule at all, but an agreed trigger and an agreed basis for the amount. An account top-up when a balance falls below a threshold is the standard example.
Alongside these sit the industry-practice types that exist to handle how real commerce behaves: incremental authorizations, reauthorizations, resubmissions, delayed charges and no-show charges. Mastercard's Transaction Processing Rules carry these across its credential-on-file, recurring payment and installment billing sections, with the identification requirements for cardholder-initiated and merchant-initiated transactions set out separately in its appendix on transaction identification.
The point of the taxonomy is that an issuer treats a recurring subscription charge and an unscheduled top-up differently, and it can only do that if you tell it which one it is holding.
What the Flag Actually Looks Like
This lives in specific fields, not in intent. Visa's in-app transaction identification guidance is unusually concrete about it: the POS entry mode is coded 01 when the credential is not yet stored or the consumer is asking for it to be stored, and 10 for credential-on-file once it is, with the POS environment field carrying C for credential-on-file on that first transaction and the e-commerce condition code alongside it.
Two numbers, essentially. One says the cardholder is here and we are about to store this. The other says this is the stored credential being used. Get them the wrong way round and the message you send describes a transaction that did not happen.
The Two Failure Directions
An MIT dressed as a CIT. The message claims a cardholder is present and participating, but no authentication data supports that, because nobody was there. In Europe this is worse than cosmetic: the transaction gets pushed into strong customer authentication scope that a properly flagged MIT sits outside of, and the issuer soft-declines it asking for a challenge that cannot be answered. We covered why that class of decline is an infrastructure problem rather than a risk decision in Soft Declines Are an Infrastructure Problem.
A CIT dressed as an MIT. The opposite loss. A real cardholder authenticated, and you threw that evidence away by telling the issuer nobody was there.
Both failures produce declines that look inexplicable from the merchant's side, because the transaction itself was fine.
Why This Lands on PSPs and Orchestrators
A merchant can do everything right commercially - clear consent, honest terms, a real agreement - and still have this wrong, because none of it is set by the merchant. The flags live in the authorization message, and the authorization message is constructed by the gateway, the PSP or the orchestrator. The merchant has no field to get wrong.
It gets harder at scale, in two specific places.
The first is routing. The identifier that links a merchant-initiated charge to its original cardholder-initiated transaction has to travel with that credential. When traffic moves between acquirers, or a merchant migrates providers, that identifier has to be carried across deliberately. If it is not, every subsequent charge in the chain arrives looking like a first-time stored-credential transaction with no history behind it.
The second is defaults. Integrations frequently set one flag for all traffic because it was simpler at build time, which quietly misclassifies an entire category of transactions for years. It never looks like a bug. It looks like a slightly disappointing approval rate.
Visa, for its part, tells issuers not to decline authorizations solely because they are identified as credential-not-present, specifically to limit unnecessary declines. Rules worded that way usually exist because the behaviour they prohibit is common.
What to Check
Start with the question most authorization data cannot answer: what share of your merchant-initiated volume carries a valid link back to its original cardholder-initiated transaction? If you cannot produce that number, the chain is unverified rather than intact.
Then check whether subtypes are being set at all, or whether everything stored is going out as one generic type. Then check what happens to the linking identifier when a merchant is re-routed to a different acquirer.
None of this shows up in an overall approval rate, which is why it survives so long. Splitting that rate by initiation type is the first measurement that makes the problem visible, and it depends on defining the rate consistently to begin with, which we set out in What Is a Payment Authorization Rate.
Frequently Asked Questions
What is the difference between a CIT and an MIT?
A cardholder-initiated transaction is one the cardholder is actively taking part in. A merchant-initiated transaction is one the merchant submits against a stored credential, without the cardholder present, under an agreement established in an earlier cardholder-initiated transaction.
Does a subscription payment count as a merchant-initiated transaction?
Yes. A subscription is the standard recurring case: a fixed amount with no fixed end date, charged against a stored credential until the cardholder cancels. The first sign-up charge is the cardholder-initiated transaction; everything after it is merchant-initiated.
Why would a correctly authorized recurring payment be declined?
The most common structural reason is that the charge reached the issuer without a valid link to the original cardholder-initiated transaction, or carrying a flag that describes a cardholder as present when none was. The issuer is not declining the agreement. It is declining a message that does not describe one.
Who is responsible for setting these flags?
Whoever builds the authorization message, which in practice means the gateway, PSP or orchestrator rather than the merchant. That is also why the problem persists: the party that feels the declines is not the party holding the field.
