Merchant-Initiated Transactions: SCA, Reason Codes, Auth Rate Impact

Your PSP documentation says "mark it as recurring and the SCA exemption applies." What it doesn't say: the exemption is conditional on an authentication chain that starts at the customer's first transaction — and a significant share of subscription operators have broken that chain without knowing it.

The result is a specific failure pattern: European subscription charges that worked fine for months suddenly start seeing elevated soft declines with response codes 65 or 1A. The issuer is requesting SCA. The cardholder is not at their device to complete it. The charge fails. The subscription churns. Your analytics show an unexplained European decline spike with no obvious cause.

This article covers the mechanics of Merchant-Initiated Transactions — the six subtypes, the SCA anchor requirement that most operators miss, how to implement the chain correctly, and the authorization rate impact of getting it right versus wrong.

Why the MIT/CIT Distinction Exists

Strong Customer Authentication under PSD2 requires cardholder participation in the authentication process — a second factor, typically a biometric or OTP, on top of the card credentials. This makes sense for a customer actively checking out. It makes no operational sense for a recurring billing charge on day 31 of a monthly subscription: the customer is not at their device, the charge is expected, and requiring authentication would mean every subscription renewal triggers an interruption.

The MIT framework resolves this. Regulators and card schemes recognize two distinct transaction types:

Cardholder-Initiated Transaction (CIT): The cardholder is actively present and initiating the payment. Standard e-commerce checkout, initial subscription sign-up, the first charge in any recurring relationship. CITs are subject to SCA in EEA markets.

Merchant-Initiated Transaction (MIT): The merchant initiates the charge without the cardholder taking any action at that moment — subscription renewals, instalment charges, usage-based billing against stored card details. MITs are explicitly exempt from SCA because cardholder presence is structurally impossible.

The logic is clean. The implementation is where it breaks.

The Six MIT Subtypes

Visa and Mastercard define six MIT categories. Each has a specific reason code that must be included in the authorization message. Using the wrong subtype — or no subtype — affects how issuers handle the transaction and what retry rules apply.

The distinction that trips up most SaaS operators: Recurring vs Unscheduled COF.

Recurring (R) is for charges where the amount and schedule are fixed and communicated to the cardholder at subscription setup — "$29/month on the 15th." Unscheduled credential-on-file (U) is for charges where the amount varies or the timing is triggered by an event rather than a calendar — usage-based billing that charges when a threshold is hit, or a top-up that fires when account balance drops below a limit.

Using Recurring (R) for a variable-amount usage charge is technically incorrect. More importantly, issuers apply different scrutiny: unscheduled COF is treated as higher risk because the cardholder didn't agree to a specific recurring amount, which means auth rates can differ between correctly and incorrectly coded transactions.

The CIT Anchor: What It Is and Why It Breaks

The MIT SCA exemption is not absolute. It is conditional on a prior authenticated CIT establishing the cardholder's intent to enter a recurring payment relationship. The exemption chain:

1. Customer checks out (CIT) — 3DS2 authentication is completed. The issuer validates the cardholder's identity. Authorization is approved with an authentication reference. The scheme returns a network transaction ID — a 15-digit identifier for this specific transaction.

2. Merchant stores the network transaction ID — this ID is the anchor. It proves to future issuers that this recurring relationship was established with authenticated customer consent.

3. Month 1 renewal (MIT) — the merchant sends the charge with MIT reason code R (Recurring) and the network transaction ID from the original CIT. The issuer sees the authentication chain: "this cardholder set up this subscription with 3DS2 at checkout." SCA exemption applies. Transaction approved.

4. Month 2 renewal (MIT) — references either the original CIT network TX ID or the network TX ID from the Month 1 MIT. Chain continues.

Where it breaks: If the initial CIT was not 3DS2-authenticated — common in markets outside the EEA, or in integrations that skip 3DS for the first charge to reduce friction — there is no authentication anchor. The MIT chain references a CIT that the issuer has no authentication record for. EEA issuers that follow the letter of PSD2 may return SCA-required responses on the MIT. Softer issuers accept it anyway. The result: inconsistent authorization rates across your European subscriber base, depending on which issuer is most strict.

Network Transaction ID: Storage and Implementation

The network transaction ID (sometimes called the prior transaction reference or stored credential reference) is returned in the authorization response of the initial CIT. It is the mechanical link between the CIT and all subsequent MITs.

Where to find it by PSP:

• Stripe: previous_transaction_reference field in the PaymentIntent response; also accessible on the Charge object under payment_method_details.card.network_transaction_id
• Adyen: networkTxReference in the authorization response JSON
• Braintree: networkTransactionId on the Transaction object
• Checkout.com: network_token_reference in the payment response

Critical storage requirement: Store the network transaction ID at the customer or subscription level, not at the payment level. This is a common implementation bug. If you store it on the payment record and that initial payment is later refunded, the record may be soft-deleted or inaccessible when the next billing cycle runs. The MIT then fires without a prior transaction reference, breaking the chain.

What to pass in MIT authorizations: Include the network TX ID in the appropriate field for your PSP. Most PSPs accept it as a configuration parameter in the recurring charge API call. Verify with your PSP's stored credentials documentation that the field is being populated — some integrations silently accept the call without the field and send the authorization without it.

This reference goes by a different name on each network but does the same job: on Visa it is the network transaction ID returned on the original authorization; on Mastercard it is the Trace ID. Whatever your PSP calls the field, the requirement is identical — capture it on the customer-initiated anchor and replay it on every subsequent merchant-initiated charge. If you acquire across both schemes, confirm your PSP maps each to the correct outbound field; a Visa reference sent on a Mastercard transaction, or dropped entirely, lands you back in the missing-reference failure mode.

Auth Rate Impact

Correctly implementing the MIT chain produces measurable authorization rate improvement. The mechanism is straightforward: issuers trust recurring charges from established relationships differently than they trust unfamiliar authorization requests.

Correctly flagged MIT vs unflagged recurring charge: An authorization request that arrives with MIT reason code R, a valid prior transaction reference, and a clean authentication chain signals to the issuer: this is a known customer, established relationship, already authenticated. PSP case studies consistently report higher authorization rates for correctly flagged MITs versus the same charge sent without MIT flags, though the magnitude varies by market, issuer mix, and how strictly SCA is enforced. The gain is most pronounced in EEA markets under strict SCA.

Wrong MIT subtype: Sending usage-based charges as Recurring (R) when they should be Unscheduled COF (U) can trigger issuer-side inconsistencies. Some issuers have fraud rules that flag when a "recurring" charge doesn't match the amount or cadence pattern from prior cycles. Unscheduled COF (U) is the correct code when amounts vary — it sets issuer expectations correctly.

No MIT flag at all: Sending stored-credential recurring charges as if they were fresh CITs is the worst option. The issuer treats the authorization as a new transaction requiring all the scrutiny of an unknown payment. In EEA markets, this frequently triggers a 65/1A SCA-required response. In non-EEA markets, it exposes the charge to higher fraud scoring because it lacks the stored-credential signals that reduce risk.

The leverage compounds across a subscription base. As a rough illustration — not a promised uplift — on a book of 100,000 monthly renewals at a $30 average subscription value, every one percentage point of recovered authorization rate is on the order of 1,000 charges and tens of thousands of dollars a month. The point is the multiplier, not a fixed figure: on a large recurring book, even a small authorization-rate gain from correct MIT flagging is material recovered revenue, and incorrect flagging quietly bleeds the same amount.

EEA vs Non-EEA: What Applies Where

SCA is EEA-specific regulation. The authentication anchor requirement under PSD2 applies only to issuers in the European Economic Area. US, APAC, LatAm, and MENA issuers do not enforce SCA, so a broken CIT anchor does not cause the 65/1A soft decline pattern in those markets.

However, MIT reason codes still matter globally:

• Visa retry rules restrict the number of retry attempts per decline code. Transactions correctly flagged as MITs with the appropriate reason code have clearer retry paths under scheme rules than unflagged charges.
• US issuer handling: US issuers increasingly differentiate stored-credential transactions. The MIT flag signals the billing relationship context and reduces the transaction's fraud score.
• Scheme compliance: Visa and Mastercard rules require correct MIT flagging for stored-credential transactions globally. Non-compliance is a technical violation that can affect your acquiring relationship on audit, even if the issuer-side impact is invisible day-to-day.

The practical approach: implement MIT flagging correctly globally, not just for EEA traffic. The setup cost is the same; the EEA benefit is largest, but it is not the only benefit.

Where MITs break in production

Correct flagging is necessary but not sufficient. Even a well-architected MIT chain produces declines in production, and the operator skill is telling the failure modes apart — they have different fixes, and retrying the wrong one makes things worse.

Missing or dropped MIT indicator. The issuer receives an off-session card-not-present charge with no stored-credential context, so it evaluates it like a fresh unauthenticated payment — and often soft-declines asking for authentication, or hard-declines on risk. The subtlety: the indicator may be correct in your request but dropped by the acquirer or PSP before it reaches the issuer. If your side looks correct but approvals are low, pull a network trace and confirm the flag and reference actually arrive at the issuer.

Missing or orphaned network reference. The MIT must carry the original transaction's network reference back to the issuer. Two ways it breaks: the reference was never stored (the payment-level vs customer-level storage bug), or the original customer-initiated transaction was later refunded or charged back, orphaning the reference. Either way the issuer cannot tie the MIT to a prior authenticated consent, and approval rates fall.

Stale credential — and the misdiagnosis that follows. When the card on file has expired or been reissued, the PAN no longer resolves and you get a hard decline. This is one of the most commonly misdiagnosed MIT failures: operators see the decline, assume the MIT chain is broken, and start re-flagging — when the real fix is refreshing the credential. Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) push reissued and re-expired card details to participating credential-on-file merchants; confirm Account Updater is enabled and ran before you touch anything in the flagging chain.

Issuer rejects the off-session attempt. Some issuers decline off-session merchant-initiated charges as a matter of risk policy regardless of flagging, returning a soft decline that asks for authentication. There is no off-session fix — this routes into the re-authentication path below.

Exemption requested but not honored. You can flag an MIT and request the recurring or low-value exemption, but the exemption is the issuer's to grant. When it is not honored, you get a soft decline requesting step-up — which, again, can only be resolved with the cardholder present.

Authentication-required soft decline. The clearest signal of all: a scheme-defined response code meaning the issuer wants strong customer authentication (commonly Visa 1A and Mastercard 65). This is not a retryable failure — an off-session retry returns the same code. It must go to re-authentication.

Decline recovery: the MIT retry playbook

Recovery starts with classification, not retrying. The worst operator mistake on a declined MIT is a blind retry: it burns issuer goodwill, can trip velocity and excessive-retry controls, and on a hard decline it never had a chance.

1. Hard vs soft. A hard decline — closed account, stolen card, do-not-honor, restricted — should not be retried; request a fresh credential from the customer. A soft decline — insufficient funds, issuer temporarily unavailable — is genuinely retryable. A soft decline asking for authentication is a third category that looks retryable but is not: it needs the cardholder, not a retry.

2. Retry the genuinely-soft declines with discipline. For insufficient-funds and issuer-unavailable declines, space retries rather than hammering — align attempts to account-funding patterns such as payday, and respect the schemes' excessive-retry rules, including the resubmission indicator where the network requires it for a follow-on attempt. Retry storms get you velocity-blocked and degrade your standing with the issuer.

3. Send authentication-required declines to re-authentication. When the issuer wants SCA, you cannot fix it off-session. Bring the customer back on-session — an in-app or emailed re-authentication step — and run a fresh authenticated transaction (a low-value or zero-amount authorization) that re-establishes the network reference, then resume the chain from the new anchor. The product challenge is surfacing this without churning the subscription; the payments challenge is making sure the re-auth actually produces a new stored-credential reference.

4. Fix stale credentials at the credential layer. For expired or replaced cards, the durable fixes are Account Updater (reactive — it fetches the new card details) and network tokens (structural — the token persists across card reissue, so the chain keeps working without a separate fetch). Network tokens also tend to lift authorization rates on their own; treat them as the default for any recurring book, with Account Updater as the catch for credentials that are not tokenized.

5. Know when to stop retrying and switch. When recovery is exhausted — the dunning sequence has run, re-auth was not completed — fall back to an alternative credential or method on file before you lose the customer to involuntary churn. A failed MIT chain is a billing problem; unrecovered, it becomes a retention problem.

6. Preserve the consent evidence throughout. Keep the original SCA/CIT record — the authentication timestamp, the agreement terms the cardholder accepted, and the network reference — because an MIT chargeback usually turns on whether you can show the cardholder authenticated and agreed to the arrangement at setup. Recovery activity (retries, re-auth, credential updates) should append to that record, not overwrite it.

PSP Configuration Checklist

Six checks before the next billing cycle:

1. Is the initial subscription CIT going through 3DS2? In EEA markets, yes — mandatory. In non-EEA, yes — for the auth anchor. Check your PSP's 3DS configuration and confirm that subscription setup flows are using the authentication path, not a 3DS bypass.

2. Is the network transaction ID being stored per customer? Check where in your data model the network TX ID lives. It should be on the customer or subscription record, not the payment transaction record. Query your database: can you retrieve the network TX ID for any active subscriber without looking up their original payment?

3. Are subsequent charges using the correct MIT subtype code? Log a sample of recurring authorization requests and check the MIT reason code field. If it is empty, or if it says "recurring" for charges that are actually usage-based, fix the mapping.

4. Is the prior transaction reference being passed in MIT authorizations? Confirm with your PSP that the network TX ID from the CIT is being included in the recurring charge API call. Some PSPs require explicit opt-in; it is not always the default.

5. Are failed MITs being retried with the correct codes? Check your retry logic. Retried MITs should use reason code RS (Resubmission), not the original reason code. This signals to the issuer that this is a retry, not a fresh transaction.

6. Is Account Updater enabled? A leading cause of MIT failure in production is not incorrect flagging — it is stale card credentials. Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) refresh card details automatically before the charge attempt. Enable it in your PSP settings if it is not already active.

• Network token enrollment — tokenize stored credentials so the MIT chain survives card reissue without a separate Account Updater fetch, and to capture the token's own authorization-rate uplift.

Common Mistakes

Sending all charges as CITs. The simplest integration sends every charge as a new transaction. This works until EEA issuers start returning SCA-required responses on renewal charges that the cardholder cannot complete. Identifiable by: 65/1A decline codes clustered on day-of-billing runs, concentrated in European subscriber cohorts.

MIT retries with CIT flag. When a recurring charge fails, some retry logic fires a fresh authorization without the MIT flag — treating the retry as a new transaction. This generates a CIT-type auth in the scheme records, triggering SCA soft declines in EEA. The retry should use reason code RS (Resubmission) and reference the failed transaction.

Network TX ID stored at payment level. The initial charge is refunded as part of a welcome offer or trial period adjustment. The payment record is archived. Next billing cycle, the system cannot find the network TX ID. The MIT fires without a prior transaction reference. Silent failure — auth rates drop, no error thrown.

Recurring code for usage billing. Monthly SaaS fees that include a base plus variable usage are sent as Recurring (R). Issuers see a "recurring" charge that varies month-to-month. Some flag the variance as anomalous. The correct code is Unscheduled COF (U) — it sets the expectation that the amount is not fixed.

No re-authentication path for broken chains. Once a broken chain is identified, the fix requires re-authenticating the affected subscribers — not just re-flagging future charges. Build a re-authentication flow: on the subscriber's next login or billing failure, present a 3DS2 challenge to establish a new anchor. Without this, the fix only applies to new subscribers, not the existing base with broken chains.

---

For the SCA regulatory context and what PSD3 changes for stored credentials, see PSD3/PSR Operator Checklist 2026. For the broader subscription billing rail landscape including open banking alternatives to card-on-file recurring, see Subscription Payments by Rail. For how soft declines and decline codes interact with MIT retry logic, the glossary entries cover the response code reference in full.