To comply with stored credential rules, you must capture verifiable cardholder consent, complete an initial authorization or account verification, and transmit the correct scheme indicators on every subsequent charge, including cof, cofscheduled, and Visa’s POS Entry Mode “10.” Get those three elements wrong and you’ll experience more declines and chargebacks. Get them right, and issuers recognize your transactions as legitimate, recurring, and low‑risk.

TL;DR:

  • Sending scheme-required indicators such as cof, cofscheduled, and POS Entry Mode “10” on each stored credential transaction is essential to avoid declines and chargebacks.
  • Proper classification of transactions as cardholder-initiated or merchant-initiated is critical, especially avoiding mislabeling subscription renewals as cardholder-initiated.
  • Storing consent records and initial authorization details in a unified system provides strong evidence for chargeback defense and compliance.
  • Using network tokens instead of raw card numbers reduces PCI scope and improves billing reliability through automatic updates.
  • A comprehensive, proactive compliance approach that includes lifecycle management, retry strategies, and accurate indicator tagging ensures revenue retention in high-risk industries.

Table of Contents

Your 7-Step Stored Credential Compliance Checklist

Most merchants discover their stored credential gaps during a chargeback dispute, which is the worst possible time. Fix that by working through this sequence over the next 30 to 90 days.

  1. Audit every payment flow and label each one as cardholder‑initiated (CIT) or merchant‑initiated (MIT).
  2. Run an initial authorization or a $0 account verification before storing any credential, and log the transaction ID.
  3. Transmit scheme‑required indicators — cof, cofscheduled, and POS Entry Mode “10” — on every stored credential transaction.
  4. Tokenize cards at capture so you shrink PCI scope and pick up automatic card updates.
  5. Record consent details: last four digits, purpose, frequency, cancellation terms, and expiration.
  6. Build lifecycle checks into your billing system, including monthly verification and token refresh triggers.
  7. Monitor decline patterns by issuer and reason code so you can adjust retry logic before revenue leaks out.

Pro Tip: Store your consent record and your initial transaction ID in the same system, tied by a single reference. When a chargeback lands eight months later, you want to produce both in one query, not stitch them together from two databases under deadline pressure.

What’s the Difference Between CIT and MIT Transactions?

A cardholder‑initiated transaction (CIT) happens when the customer actively triggers the charge: entering a card at checkout, clicking “buy,” or logging in to make a one‑time payment. A merchant‑initiated transaction (MIT) happens when you charge a stored credential without the cardholder present in that moment, whether it’s a subscription renewal, an installment payment, or an unscheduled charge under a standing instruction.

The Merchant Risk Council’s guidance is blunt about why this distinction matters: mislabeling a subscription renewal as a CIT confuses issuer risk models and drags down approval rates for transactions that should sail through.

A credential becomes “stored” the moment you complete a successful initial authorization or account verification. There’s an exception for genuine single‑use cards that never get saved.

  • Standing instruction: customer authorizes future variable charges (utility bills, usage‑based billing).
  • Recurring: fixed amount, fixed schedule (monthly SaaS subscription).
  • Installment: a single purchase split into scheduled payments.
  • Unscheduled card‑on‑file (UCOF): customer‑initiated but the card is stored for future convenience, like a rideshare app.

Get the classification wrong and issuers see a mismatch between what you’re reporting and what’s actually happening, which is exactly the pattern fraud models are built to flag.

Which Authorization Fields Do You Actually Need to Send?

Engineering teams get stuck here because the field names vary by gateway, but the underlying requirements are consistent across processors.

The cof field marks whether the stored credential belongs to the customer or the merchant: “c” for customer‑initiated, “m” for merchant‑initiated. The cofscheduled flag tells the issuer whether this specific charge is scheduled (y) or unscheduled (n), which matters for standing instructions and UCOF cases where amounts vary. The previousTransactionId field carries the transaction ID from your initial authorization forward into every subsequent MIT, letting the issuer trace the relationship back to the moment consent was established.

Visa’s stored credential framework exists specifically to help issuers recognize an established merchant‑cardholder relationship before they see the charge, which is what actually moves approval rates. Skipping the indicator doesn’t just risk a decline. It strips the transaction of the context issuers rely on to say yes.

Visa requires POS Entry Mode code “10” on every transaction using a stored credential. This single field tells the issuer’s system, “this isn’t a new card entry, this is a saved credential we already verified.”

Field Purpose Required for
cof Identifies customer vs. merchant initiated storage All stored credential transactions
cofscheduled Flags scheduled vs. unscheduled charges MIT transactions
previousTransactionId Links to the initial authorization Subsequent MITs
POS Entry Mode “10” Signals a stored credential was presented Visa transactions specifically

Gateway documentation from CardPointe shows how these map to real API parameters, and Visa’s developer docs specify the JSON structure under processingInformation.authorizationOptions.initiator. Build defensive validation that checks for field presence before submission. A gateway or middleware layer can silently strip these values, and you won’t find out until decline rates spike.

Your consent record needs to answer five questions before you ever store a credential: which card (last four digits), what you’ll use it for, how often you’ll charge it, how the customer cancels, and whether the authorization expires.

  • Disclose the card’s last four digits, the scope of use, and billing frequency in plain language at capture.
  • Use hosted payment fields with a signed, timestamped consent record you can produce later.
  • Run an account verification (typically $0) when you’re storing a credential without an immediate charge.
  • Store consent records with the same access controls you’d apply to payment data, and keep them retrievable for chargeback response windows.

If the initial authorization or verification gets declined, the credential is not considered stored under scheme rules, and Visa is explicit that you cannot use it for a subsequent MIT. Don’t build a fallback that quietly retries a failed verification as a live charge. That’s the exact pattern issuer fraud teams are trained to catch.

Pro Tip: For variable recurring amounts, bake explicit dollar caps or notification triggers into the consent record itself, timestamped and signed. When a customer disputes an unexpected charge amount, that record is your entire defense.

Why Network Tokens Beat Storing Raw Card Numbers

Storing a raw PAN puts your entire payment stack inside PCI DSS scope, with all the audit overhead that entails. Tokenization narrows that scope considerably, because the sensitive card number lives with the token provider, not your systems.

  • Network tokens auto‑update when a card is reissued, so an expired or replaced card doesn’t break your next billing cycle.
  • PCI scope shrinks because tokenized environments don’t store the actual PAN, which cuts audit complexity and cost.
  • Token lifecycle work still matters: you need a mapping strategy for token refresh and a migration plan if you switch gateways.
  • Most acquiring partners and gateways can own tokenization for you rather than requiring in‑house key management.

Mastercard’s guidance on tokenized card‑on‑file payments frames this as a reliability upgrade, not just a security one: fewer failed recurring charges because the token stays current even after the physical card changes. For subscription merchants, that single feature often does more for revenue retention than any retry logic you build on top of it.

Building a Retry and Lifecycle Playbook

Declines happen even with perfect indicators, so your operational playbook decides how much revenue you actually keep.

  1. Set a retry schedule with escalation windows, typically three attempts spaced across several days rather than same‑day hammering.
  2. Run monthly verification passes on active stored credentials to catch expirations before the billing date.
  3. Trigger update requests automatically when a card nears its expiry month.
  4. Pre‑notify customers before variable or unusually large recurring charges, per scheme guidance on standing instructions.
  5. Log every decline reason code alongside the cof/cofscheduled values you sent, so you can tell whether the issuer is rejecting the charge or your gateway silently dropped a field.
  6. Retain audit trails for consent, authorization, and every subsequent MIT for as long as your chargeback window requires.

Instrumenting that last point pays off the first time an issuer disputes your indicator usage. You want the sent values and the response code sitting in the same log line, not scattered across three systems.

How Subscription Billing and On-Demand Charges Actually Flow

Subscription merchant example:

  • Customer signs up, enters card, initial CIT runs with tokenization enabled.
  • You record the transaction ID and store the resulting network token.
  • Month two’s renewal fires as an MIT with cofscheduled=y and previousTransactionId pointing back to that first charge.
  • Every subsequent month repeats the same pattern using the current token.

Unscheduled, on-demand example (think a wallet top‑up service or a rideshare app):

  • Customer adds a card but doesn’t make an immediate purchase.
  • You run a $0 account verification to confirm the card and establish the stored credential.
  • When the customer later requests a ride, the charge runs as an MIT with cof=c and cofscheduled=n, since the amount and timing weren’t fixed in advance.
  • The previousTransactionId still traces back to that original verification.

Davincipay’s Playbook for High-Risk Stored Credential Compliance

Payment processing for regulated and high‑growth merchants means stored credential compliance isn’t optional. It’s the difference between a subscription business that retains revenue and one that bleeds it to preventable declines.

Davincipay works with subscription, telehealth, and nutraceutical merchants where recurring billing volume is the business model, not a side feature. Our onboarding checklist for these merchants covers token provisioning, account verification setup, and CIT/MIT tagging before the first transaction ever runs. Chargeback mitigation and dispute support get built into the same integration, so consent records and transaction logs are structured for defense from day one.

Pro Tip: Track decline reason codes by issuer over a full billing cycle before adjusting retry timing. Issuer feedback patterns often reveal that a specific bank is rejecting a specific cofscheduled value, which a blanket retry policy will never fix.

Davincipay's Playbook for High-Risk Stored Credential Compliance — overview diagram

What Merchants Consistently Get Wrong About Compliance

The conventional advice on stored credentials treats this as a legal checkbox: get a consent checkbox on the form, file it away, move on. That’s backwards. The scheme mandates exist because issuers use these indicators to make real‑time approval decisions, which means sloppy tagging doesn’t just create legal exposure. It actively costs you revenue every single billing cycle through declines that a correctly tagged transaction would have cleared.

What Merchants Consistently Get Wrong About Compliance — overview diagram

The biggest gap I see is merchants treating tokenization as a security nice‑to‑have rather than an operational necessity. A raw PAN sitting in your database doesn’t just expand PCI scope. It guarantees you’ll manually chase expired cards every time a batch of customers gets reissued plastic, while a merchant running network tokens sails through the same reissue cycle with zero customer‑facing disruption.

If you take one thing from this guide, prioritize the initial authorization and consent record before you touch a single line of tagging code. Everything downstream, from CIT/MIT classification to retry logic, depends on that foundation being solid. Skip it, and you’re building a compliance program on a credential that technically was never stored correctly in the first place.

— Peter

Get Production-Ready Stored Credential Support From Davincipay

Building compliant stored credential flows in-house means coordinating your gateway, acquiring bank, and tokenization provider separately, then hoping they agree on field names. Davincipay collapses that into one relationship: tokenization, recurring billing orchestration, account verification, and chargeback mitigation under a single integration built for high-risk and regulated merchants.

Davincipay

That matters most for merchants in nutraceuticals, telehealth, and subscription commerce, where decline rates and chargeback ratios directly threaten your ability to keep processing at all. Davincipay’s nutraceutical payment processing and supplement merchant services are built around exactly the CIT/MIT tagging and consent architecture this guide covers, so you’re not reverse-engineering scheme mandates on your own gateway’s documentation. If your current setup is generating declines you can’t explain or chargebacks you can’t defend, apply now to get a payments infrastructure built for the way your billing actually works.

Sources