Posted: May 06, 2026 | Updated: May 08, 2026 at 2:41 PM
Poorly managed stored credential transactions, such as failed renewals, involuntary churn, and compliance fines, carry a huge hidden cost for your business. The subscription economy relies on seamless background payments, but failing to format these payments in accordance with card network rules directly leads to false declines and lost revenue.
Every time a card is saved and billed later, Visa and Mastercard require a specific digital paper trail. If you miss this paper trail, the transaction will be deemed suspicious by the customer’s bank.
A larger threat to SaaS and subscription businesses is involuntary churn. When a customer wants to continue paying you but their payment fails due to technical or card-related issues, it is known as involuntary churn. Data shows that involuntary churn accounts for 20% to 40% of overall churn in subscription-based SaaS businesses. Involuntary churn is a greater loss than customer churn, making payment infrastructure a critical growth lever.
The shift from simple “card-on-file” storage to strict “stored credential frameworks” means merchants must now explicitly classify whether a payment was initiated by the customer or the merchant. This blog will demystify the complex web of Merchant-Initiated Transactions (MIT), Cardholder-Initiated Transactions (CIT), and network compliance so you can maximize authorization rates for your business.
Stored credentials, also known as Card-on-File, are a merchant’s or payment gateway’s secure storage of a customer’s payment information for future use. A stored credential transaction occurs when a merchant uses previously saved payment details to process a charge, which requires explicit customer consent during the initial setup phase. Stored credential transactions are very risky and require extensive PCI-DSS compliance. They take place in two phases: the first, the “setup” phase, where card details are collected and stored, and the second, the “subsequent” transactions with the saved card. Since PCI-DSS compliance is complex, most merchants rely on payment gateways to tokenize sensitive data.
Stored credential transactions are on the radar of card networks because there is a higher risk of fraud in case of a data breach. However, explicitly tagging stored transactions increases trust by indicating the safe storage of sensitive data, and also boosts approval rates.
Cardholder-initiated transactions and merchant-initiated transactions are fundamentally different. Although the purpose of both transactions is to pay money, the triggers that trigger them differentiate them.
In a cardholder-initiated transaction, the customer selects a credit card they have previously saved on the site and clicks “Pay,” thereby proving they are active participants in the purchase. It is common in online retail stores where recurring payments are not guaranteed.
On the other hand, merchant-initiated transactions serve a different purpose. They are used to pay for subscription services and recurring payments. In a merchant-initiated transaction, the merchant’s payment software requests to pull funds from the customer’s account details provided. Merchant-initiated transactions require explicit approval when the payment method is set up, i.e., when the customer sets up their auto-pay. After that, payments are deducted automatically unless they are rejected or the card expires.
Banks treat CITs and MITs very differently. A CIT is usually required to pass checks such as 3D Secure and CVV verification; however, an MIT is generally exempt from these additional checks. MIT transactions are essentially transactions in which the customer is not readily available. This means that if a CIT is mistakenly tagged as an MIT, authentication will be triggered, eventually leading to the transaction being rejected because the customer is not readily available.
This does not mean you are allowed to tag CITs as MITs to bypass security checks. This is a serious violation and could lead to heavy fines, or in some cases, permanent revocation and a ban on the merchant account.
Now, let us understand how subscription and billing cycles work, providing an overview of the mechanics of MITs and recurring payments.
Recurring payments are regular, scheduled payments charged at fixed intervals. Recurring payments are a specific subset of merchant-initiated payments. The reason MIT is often associated with recurring payments is that it is the most common use case for MIT. In everyday life, you see recurring payments everywhere, from paying for your gym membership to your streaming service. In recurring payments, the customer explicitly pre-authorizes the merchant to charge future payments at fixed intervals.
To process payments without real-time customer authorization, the merchant must pass the “Original Transaction ID” to the payment network. The Original Transaction ID, also known as the Trace ID, is a unique digital receipt number generated during the first payment; it is required for all future transactions. Without the Trace ID, your transactions are more likely to be declined as suspicious activity.
Recurring payments are heavily affected by card expiration dates. If the stored card has expired, you will need automated workflows that gently nudge the customer to update their card information before the next payment, preventing involuntary churn. According to network rules, the first transaction must be a CIT. This is logical because the first transaction is initiated by the customer, and subsequent payments are MIT and are passed along with the Trace ID of the first payment.
MITs encompass much more than just simple, fixed transactions. To understand variable and delayed billing scenarios, you must first understand unscheduled MIT and delayed charges.
Unscheduled MIT, as the name suggests, is a charge made to a saved card whose timing and amount vary based on usage or specific events. These charges occur when the customer agrees to be billed on usage; for example, your cloud hosting bill depends on your server bandwidth.
Delayed charges refer to payments processed after a service has been rendered. It is kind of like postpaid services. Delayed charges are used heavily in the travel and hospitality industry. This allows the company to charge a saved card for services such as rented cars or minibar usage.
There are other scenarios in which MITs are charged. No-show fees are penalties charged when a customer fails to show up for an appointment. MITs can be used to charge those penalties. However, this must be explicitly agreed upon at the time of booking the appointment. Additionally, reauthorization or account “top-ups”, such as transit cards or digital wallets, use MITs to pull money from saved cards when the wallet balance drops below the set threshold.
Card networks require explicit customer consent before saving any credentials. It is a huge violation to present saved credentials as pre-ticked checkboxes or hidden terms. Consent mandates are very important. These are the explicit terms and conditions that the customer agrees to before their card is billed.
A compliant consent mandate includes all details of the MIT charge, such as the date, time, amount, and billing frequency. You should send electronic receipts immediately after the initial setup. This confirms the terms of stored credentials. If you plan to change business terms or the amount charged through MIT, you are legally required to give the customer prior notice “well before” the charge is initiated.
Businesses always face the risk of chargebacks or friendly fraud. Chargebacks refer to the forced reversal of funds from a merchant’s account to the customer’s account upon the customer’s complaint. You will need to dispute these chargebacks if they occur in the future, and MITs are very prone to chargebacks. The best defense against friendly fraud is to obtain and maintain proof of the customer’s explicit consent.
Card networks such as Visa and Mastercard have laid down specific rules and guidelines for MITs. Transaction indicators are the specific data fields included in the API payload sent to the payment gateway to describe the nature of the transaction.
Visa’s Stored Credential Framework and Mastercard’s MIT framework are mandatory to avoid payment declines. We discussed in previous sections that a bank classifies the first payment as CIT and the “subsequent” payments as MIT. Card networks mandate that businesses specify whether a transaction is “first” or “subsequent”, allowing them to process it accordingly.
Under the rules of European SCA, the “first” payment, i.e., a CIT, is subject to strict two-factor authentication. The “subsequent” MIT payments are legally outside the scope of SCA, ensuring smooth background billing.
Failure to use the correct network indicators may result in your payments being declined. But the risk is not limited to declines; constant payment declines could result in non-compliance from card networks for mis-tagged transactions. Also, using correct formatting is crucial for passing the network’s correct parameters.
It is crucial for your business to distinguish between hard declines and soft declines. Soft declines are temporary, while hard declines are permanent. The type of decline dictates the retry logic you must implement to get paid. Retrying a hard decline is a guaranteed waste of money. On the other hand, soft declines need smart retry algorithms to maximize the chances of payments being approved on the next try.
You cannot keep retrying failed payments; most card networks impose strict “velocity limits” and penalize or block merchants who aggressively retry failed payments. Smart retry strategies rely on timing; smart algorithms calculate the time when it is statistically most likely for a payment to be successfully approved. Modern algorithms analyze historical data using AI and machine learning to estimate the likelihood that a transaction will be approved.
Hard declines are countered by dunning. Dunning is the automated process of communicating with a customer to ask them to update their failed payment methods. Instead of endlessly retrying, you can implement smart dunning processes that prompt customers to update payment methods to secure payments.
Stored credential transactions are the lifeblood of the subscription and automated economy. With increasing customer expectations and high demand for convenience, stored payments are the standard baseline for every business. The shift from “saving a card” to strict CIT and MIT frameworks requires operational precision. Finally, compliance rules are not just about avoiding fines; they’re a direct communication tool. Proper tagging proves your trustworthiness, directly translating to higher approval rates and sustained business growth.
A Cardholder-Initiated Transaction (CIT) occurs when a customer actively clicks on the “Pay” button on the merchant website. On the other hand, a Merchant-Initiated Transaction (MIT) occurs when a transaction is triggered automatically from a customer’s account from the card saved by the customer.
Generally, CVV is required for the first CIT transaction when the card is verified and saved. For “subsequent” MITs, you do not require a CVV to verify payments again.
It is not recommended to retry failed recurring payments immediately. Payments must be retried based on historical data and statistics at a precise time where the probability of the transaction being approved is statistically highest.
No, MITs fall outside the scope of SCA. However, the first payment, classified as a CIT, is subject to strict verification by the SCA. You should never try to pass a CIT as an MIT to evade SCA checks, as this is a severe violation of payment terms.
If you forget to pass the Trace ID, the issuing bank will view the charge as an “orphaned” or unverified stored credential transaction. This will result in the transaction being declined.
