Stored Credentials and MIT Flags: Set up Card-on-File Billing Right

On this page 8 sections

1. What the Stored Credential Framework Requires
2. Customer-Initiated vs. Merchant-Initiated Transactions
3. Recurring, Installment and Unscheduled Indicators
4. Why the Original Transaction ID Matters on Renewals
5. How Wrong Flags Trigger Declines and Downgrades
6. Storing Cards From In-Person and Phone Signups
7. Testing Your Integration's Stored Credential Data
8. Next Steps

Key takeaways

• Every stored-card charge needs the right label: customer-initiated or merchant-initiated, plus recurring, installment or unscheduled.
• Renewals should carry the original transaction ID from the first stored-credential transaction, or issuers may treat them as unexpected charges.
• Wrong flags rarely cause obvious errors. They show up as extra declines, failed SCA exemptions and weaker dispute evidence.
• Test every charge type in your billing flow, inspect the actual request data and confirm the results with your gateway or processor.

If your subscription renewals decline more often than your first-time checkouts, the cause may be how your system labels each charge. When you bill a saved card without the customer present, the card networks expect the charge to be identified as a merchant-initiated transaction and linked to the customer's original consent. This guide explains how merchant-initiated transactions differ from customer-initiated ones, which recurring and card-on-file indicators to use, why the original transaction ID matters, and how to check whether your integration sends the right data on every charge.

None of this appears on a checkout page, and your billing software can look fine while sending the wrong data. Issuers read these flags on every authorization, so mistakes tend to surface as declines rather than error messages.

What the Stored Credential Framework Requires

Visa and Mastercard each publish rules for storing and reusing card details, commonly called the stored credential framework. The exact field names and requirements vary by network and are updated over time, so confirm current specifications with your processor or gateway. The core expectations are consistent:

1. Get consent and disclose terms when you store the card. The customer should know you're saving the card, what it will be used for, how much they'll be charged (or how the amount is determined), how often, and how to cancel.
2. Flag the first transaction as a stored-credential setup. This is the transaction where you save the card. It can be a purchase or an account verification with no charge.
3. Flag every later use of the card. Each charge on a stored card should say whether the customer or the merchant started it, and why.
4. Link later charges to the first one. Merchant-initiated charges should reference the identifier the network returned on the initial transaction.
5. Keep your terms current. If the price, billing date or plan changes, the cardholder agreement changes too. Our guide to raising subscription prices with proper notice covers that process.

The card on file indicator is the field that tells the issuer "this card was stored with consent." Issuers use it, together with the other flags below, to decide whether a charge looks expected or suspicious.

Customer-Initiated vs. Merchant-Initiated Transactions

The CIT vs. MIT distinction depends on one question: is the customer actively taking part in this transaction right now?

• A customer-initiated transaction (CIT) happens when the cardholder is in the session and chooses to pay. For example, they log in and buy an add-on with their saved card.
• A merchant-initiated transaction (MIT) happens when you charge the stored card under a prior agreement and the customer isn't involved at that moment. For example, a monthly renewal runs overnight.

The gray areas cause most of the trouble. A customer who clicks "pay now" on a past-due invoice email is starting a CIT, even though you prompted them. An overage charge your system calculates at month-end is an MIT, even if the customer agreed to overage pricing at signup.

Trial conversions also have their own network disclosure rules. See our breakdown of Visa and Mastercard free trial billing rules.

How CITs and MITs Are Treated in SCA Regions

When you sell to cardholders in regions with strong customer authentication (SCA) requirements, such as Europe and the UK, the label carries more weight. The rules work differently for each type:

• CITs may require authentication, typically through 3-D Secure.
• Properly flagged MITs are generally treated as outside SCA scope, as long as they're linked to an initial transaction that was authenticated.

If you sell to those customers, authenticate the signup with 3D Secure authentication. Then make sure renewals carry the MIT flag and the link to that first transaction.

Recurring, Installment and Unscheduled Indicators

Labeling a charge as an MIT isn't enough. You also need to say what kind of MIT it is. Subscription and membership businesses typically use three types.

The recurring transaction flag belongs only on charges that actually follow a fixed schedule. A common mistake is marking every automatic charge "recurring," including variable top-ups and one-off overages. If your terms describe a predictable schedule but the charges arrive at irregular times and amounts, issuers have reason to question them.

The networks also define other MIT types, such as delayed charges, incremental authorizations, resubmissions and no-show fees. These are used mostly in hotels, rentals and travel. If your business takes deposits or charges for missed appointments, such as a fitness studio with a late-cancel fee, ask your processor which indicator applies.

Why the Original Transaction ID Matters on Renewals

When the initial stored-credential transaction is approved, the network returns an identifier. Depending on your gateway, it may be called a network transaction ID, trace ID or original transaction ID. Each later MIT should include it. That link tells the issuer the charge belongs to a known, consented agreement rather than coming from nowhere.

A few practical points:

• Store the ID with the customer's payment method, not just the order. If a customer has several saved cards, each card needs its own initial ID.
• Capture it even when the first transaction is a $0 verification. A free trial signup can still produce a valid initial ID if it's flagged correctly.
• Bring the IDs with you when you switch processors or billing platforms. Exports often include tokens but not network transaction IDs. If the IDs are lost, renewals may go out without the link, which can increase declines on your existing subscribers. Ask both providers how they handle the transfer before migrating.
• Card updates affect the ID. Check with your gateway how the link is maintained when a card is reissued through card account updater services or replaced with a network token.

Our explainer on network tokenization for fewer failed renewals covers how tokens and stored credential data work together.

How Wrong Flags Trigger Declines and Downgrades

Mislabeled transactions rarely fail with a clear error. Instead, problems show up across your decline reports, your interchange costs and your dispute outcomes.

Interchange can also suffer. Correct stored credential data can help transactions qualify for the categories they're eligible for, while incomplete data may lead to less favorable categories or network compliance fees. Specific fees and qualification rules change, so review your statements with your processor.

Declines also compound. Every failed renewal that gets retried counts toward network reattempt limits, as explained in our guide to Visa and Mastercard retry limits. Before you adjust your dunning process for failed subscription payments, make sure the first attempt is labeled correctly.

Storing Cards From In-Person and Phone Signups

Many membership businesses enroll customers at a front desk or over the phone, then bill online. The stored credential rules still apply to these signups, but the setup works differently.

Front-Desk and In-Person Enrollment

Gyms, car washes, salons with service memberships and boxing studios often sign members up at a counter. In these cases:

• Run the first charge card-present on a terminal that can store the card. It should return a token and the network transaction ID to your billing system. Not every terminal and software combination does this, so confirm it before rollout. MannyPay's POS systems and smart terminals and gateway integrations are worth discussing with a specialist for this setup.
• Don't key-enter a card that's physically present just to save it. That gives up the card-present transaction and can create a weaker record of the initial authorization.
• Get consent in writing. Use a signed agreement or a tablet acknowledgment that states the amount, frequency and cancellation method.

If your members use license plate recognition or RFID tags, our guide to car wash unlimited memberships and recurring billing covers how those systems connect to stored cards.

Phone and Mail-Order Signups

For phone enrollments, take the first transaction through a virtual terminal for phone and mail orders that supports flagging it as a stored-credential setup. Then:

• Send a written confirmation with the billing terms right away.
• Keep the call notes or recording, as permitted by applicable law.
• Make sure the renewal schedule in your billing platform matches what the customer was told.

These records also support your case if a customer later files a cancelled-recurring dispute.

Testing Your Integration's Stored Credential Data

Checking settings in a dashboard isn't enough. You need to see what your system actually sends with each authorization. Work through this checklist with your developer, billing platform or gateway:

1. Map every charge type. List each way a stored card gets charged: signup, trial conversion, renewal, upgrade, overage, reactivation, installment, late fee. Assign each one CIT or MIT and an indicator.
2. Run each scenario in a sandbox. Test with your gateway's test cards and inspect the raw request and response for each charge, not just the success message.
3. Confirm the initial transaction returns an ID and your system saves it. Check that the ID is tied to the specific payment method.
4. Confirm every MIT sends that ID back. Include renewals triggered after a card update.
5. Test customer-present flows separately. A customer paying a past-due invoice in your portal should go out as a CIT, possibly with 3-D Secure, not as a renewal.
6. Spot-check production. Pull a sample of recent renewals and confirm the fields arrived as expected.
7. Review declines by reason code. A cluster of "do not honor" or authentication-related declines on renewals but not on signups points to a flagging problem. Our guide to credit card decline codes can help you interpret them.

Questions to ask your gateway or processor:

• Which stored credential fields do you send automatically, and which must our software set?
• Do you store and resend the network transaction ID, or do we have to?
• How do you handle the ID when a card is updated or tokenized?
• If we migrate, can we export network transaction IDs along with tokens?

MannyPay supports online payment gateways including Authorize.net and NMI, plus integrations with platforms such as Shopify and WooCommerce. Field handling varies by platform, so confirm the specifics for your stack.

Next Steps

Correct stored credential data won't fix every failed renewal. But wrong flags cause avoidable declines that no amount of retrying will recover. To get started:

1. Map every charge type and assign the right CIT or MIT label and indicator.
2. Verify that original transaction IDs are captured at signup and sent on every renewal.
3. Test each scenario, then keep watching decline reasons for patterns.

If you're setting up card-on-file billing or reviewing a current integration, you can request a free quote from MannyPay. A specialist responds within one business day. Network rules and SCA requirements change, so confirm current specifications with your processor and consult a qualified professional on any legal or regulatory questions.

ME

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.