Merchant-Initiated Transactions: The SCA Exemption, Reason Codes, and Auth Rate Impact Most Subscription Operators Miss

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.

Subtype	Visa Code	Use Case	Key Characteristic
Recurring	R	Fixed-amount subscription billing	Known amount and schedule at setup
Instalment	I	Split-payment plans	Fixed total, known number of charges
Unscheduled COF	U	Variable-amount or trigger-based charges	Amount or timing not fixed at setup
Resubmission	RS	Retry of a previously declined transaction	References the original declined transaction
Delayed Charge	DC	Final charge after service delivery	Hotel minibar, car rental extras
No-Show	NS	Penalty for reservation not honoured	Hotel no-show, appointment cancellation

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.

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. Auth rate improvement of 8–15% versus the same charge sent without MIT flags has been reported across PSP case studies. The improvement is most pronounced in EEA markets where SCA rules are strictly enforced.

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 auth rate impact compounds across a subscription base. On 100,000 monthly renewals with a correctly implemented MIT chain versus a broken one, an 8% auth rate improvement is 8,000 additional successful charges per month. At $30 average subscription value, that is $240,000 in monthly recurring revenue that correct MIT flagging recovers — or that incorrect flagging quietly bleeds.

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.

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? The most common cause of MIT failure 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.

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.