Recurring billing — charging a stored payment method on a defined schedule — sounds straightforward until you're implementing it. The technical plumbing is only part of the challenge. Card network rules around credential-on-file storage, Merchant Initiated Transaction (MIT) indicators, retry logic after declines, and negative option billing disclosure requirements create a compliance layer that catches many subscription businesses off guard, usually in the form of elevated chargebacks, unexpected declines, or a processor audit.
This guide covers the complete picture: how to store payment credentials correctly, how to structure recurring charges to comply with card network rules, how to handle failed payments without damaging customer relationships, and how to build the communication framework that keeps chargebacks from undermining your entire subscription model.
Credential-on-File: Storing Cards the Right Way
Storing a customer's card for future use is called credential-on-file (COF), and Visa and Mastercard have specific rules about how it must be implemented. The rules exist because stored cards that are charged without proper authorization create the bulk of "I didn't authorize this" chargebacks in subscription businesses.
The core requirements:
Explicit cardholder consent at enrollment. The customer must specifically authorize you to store their card for future charges. This means a checkbox or affirmative action at enrollment — not just a buried clause in your terms of service. The authorization language must describe what you'll charge, how often, and how to cancel. If your enrollment flow doesn't have this explicit moment of consent with clear language, you're out of compliance with card network rules regardless of what your terms say.
Store the transaction ID from the initial authorization. When a customer provides their card and you run the first charge, the response from your processor includes a transaction ID. This ID is the link between the initial cardholder authorization and all subsequent charges. Store it — your gateway needs to reference it on every MIT that follows, proving to the card network that this series of charges traces back to a legitimate cardholder authorization.
Use a token, not the raw card number. Raw card numbers must never be stored on your own servers. Use CyoGate's Customer Vault to store payment credentials as tokens — your system stores a vault token that references the payment credentials held in PCI-compliant infrastructure. When you want to charge the customer, you pass the vault token to the gateway and the gateway handles the rest. This is both a PCI compliance requirement and a practical security measure.
MIT Transactions: Flagging Recurring Charges Correctly
When you charge a stored card without the customer actively participating in the transaction — which is the definition of a subscription billing charge — that's a Merchant Initiated Transaction (MIT). Card network rules require that MITs be flagged as such in the transaction request, and that they reference the original Cardholder Initiated Transaction (CIT) that established the billing relationship.
What this means technically: when you submit a recurring charge to the gateway API, the transaction request must include indicators that identify it as a recurring MIT and include the transaction ID from the original authorization. CyoGate's gateway API supports these fields directly — the developer documentation at the developer portal covers the specific field names and values for recurring transaction flags.
Why this matters practically: transactions that are correctly flagged as MITs are processed under different rules than standard card-present or card-not-present transactions. They're less likely to trigger fraud screens that would reject a legitimate recurring charge. They're also more defensible in a chargeback — a transaction correctly documented as a recurring MIT, referencing a valid original CIT with proof of cardholder authorization, is significantly harder to dispute as "unauthorized" than an unflagged charge on a stored card.
The four MIT subcategory flags to know:
- Recurring: Fixed or variable amount charges on a defined schedule (monthly subscription, annual membership)
- Installment: A series of charges for a single purchase paid over time (buy-now-pay-later, installment plan)
- Unscheduled: A charge triggered by a customer-defined condition rather than a calendar date (account reload when balance drops below a threshold)
- Industry-specific: Certain categories (travel, hospitality) have specific MIT types for charges like no-show fees
The Customer Vault: Your Recurring Billing Infrastructure
CyoGate's Customer Vault is the practical foundation for recurring billing — it stores payment credentials, billing addresses, and customer records in PCI-compliant infrastructure and makes them available for MIT transactions through a simple vault ID reference in your API calls.
The implementation flow for a new subscriber:
- Customer enrolls and provides card details through your Collect.js integration
- Collect.js tokenizes the card data and passes a one-time token to your server
- Your server submits the first charge using the one-time token, with the customer's vault profile created simultaneously
- The gateway returns an authorization response including a transaction ID and a vault customer ID
- Your system stores the vault customer ID (not the card number) for future charges
- For each subsequent billing cycle, your system submits a charge using the vault customer ID, the recurring MIT flag, and the original transaction ID
The vault also handles account updater functionality — when a customer's card is reissued (new expiration date, new card number after loss or theft), Visa and Mastercard's account updater services push the new credentials to the vault automatically. Your billing system continues charging without interruption and without the customer needing to update their payment method. This significantly reduces involuntary churn from card expirations.
Handling Failed Payments: Retry Logic and Dunning
Not every recurring charge succeeds on the first attempt. Cards decline for a variety of reasons — insufficient funds, expired card, bank-side fraud block, temporary hold — and how you handle those declines determines both your revenue recovery rate and your customer relationship outcomes.
Understand the decline codes. Not all declines are equal. A "do not honor" (decline code 05) from the issuing bank is a soft decline — the bank is declining for reasons that may change (insufficient funds, temporary hold) and a retry after a reasonable interval often succeeds. A "pick up card" or "card reported stolen" is a hard decline — retry is inappropriate and may trigger fraud flags. Your retry logic should distinguish between soft and hard declines and respond accordingly.
Intelligent retry scheduling. For soft declines, space retries over the billing period rather than retrying immediately or daily. A pattern of one retry attempt every 3–5 days over a 2-week window captures a large proportion of recoverable declines without appearing as a payment bombardment to the cardholder. Retrying a declined card more than 15 times in 30 days violates Visa's excessive retry rules — a recent enforcement area that can result in fines passed through to merchants.
Pre-charge notification. Sending an email 3–5 days before a recurring charge gives customers the opportunity to update an expiring card, ensure sufficient funds, or cancel if they no longer want the service. This one step reduces both soft declines (customer updates expired card) and chargebacks (customer who planned to cancel can do so without resorting to a dispute). It's also required by card network rules for certain subscription types.
Dunning communication sequence. When a charge fails, the customer communication sequence that follows — the dunning process — should be sympathetic rather than accusatory, give the customer easy paths to resolve the issue (update payment method, pause subscription, cancel), and respect a reasonable timeline before access is suspended. A well-designed dunning sequence recovers a meaningful percentage of failed payments and preserves the customer relationship; an aggressive one drives customers to dispute the original charge retroactively.
Negative Option Billing Compliance
If your subscription model includes a free trial, a discounted introductory period, or any structure where ongoing billing begins after an initial period, you're operating a negative option billing model — and the FTC, Visa, and Mastercard all have specific requirements for how it must be disclosed and managed.
The minimum compliance requirements that also happen to be the most effective chargeback prevention practices:
Clear disclosure before the transaction. The recurring amount, billing frequency, and trial-to-paid conversion date must be clearly visible immediately before the customer completes enrollment — not just in the terms of service, and not below the fold. "You will be charged $49.99/month starting [specific date]" in readable text adjacent to the enrollment button is the standard.
Confirmation email with all billing terms. Immediately after enrollment, send a confirmation email that restates every billing term: the amount, frequency, next charge date, and a direct cancellation link. This email is your primary dispute defense document and your best opportunity to prevent "I didn't know I was going to be charged" disputes at the conversion point.
Simple cancellation. The FTC's Click-to-Cancel rule, which took effect in 2024, requires that cancellation be as easy as enrollment. If a customer can sign up online, they must be able to cancel online — no phone-call-only cancellation, no multi-step retention flows that customers can't exit. Non-compliance creates both regulatory exposure and, more immediately, chargebacks from customers who tried to cancel and couldn't.
Putting It Together
A recurring billing implementation that handles all of the above correctly will have: explicit enrollment consent with clear recurring billing disclosure, card credentials stored in the Customer Vault rather than on your servers, MIT transaction flags with original transaction ID references on every recurring charge, intelligent retry logic that stays within Visa's 15-attempt limit, pre-charge notification emails, a complete dunning communication sequence for failed payments, and a simple cancellation flow.
It's more moving pieces than a simple "store the card and charge it monthly" approach — but each piece exists because the alternative creates chargebacks, compliance problems, or involuntary churn. Get the plumbing right at the start and your subscription operation runs cleanly. Retrofit it after problems emerge and you're managing ratio damage while simultaneously rebuilding infrastructure.
Questions about implementing recurring billing through CyoGate's gateway? The developer portal has API documentation for the Customer Vault, MIT transaction flags, and account updater integration. Or contact us to discuss your specific implementation.