Chapter 16 — Cards, Mandates & Stored Credentials: The Infrastructure Behind “Remember My Card”

Alex Chen is signing up for MelodyBox, a music streaming service, on his phone in Singapore. He picks the S$9.99 monthly plan, types in his Visa card number, and — right before hitting "Subscribe" — notices a small checkbox: Remember my card for future payments.

He ticks it without thinking. Most of us do.

But that checkbox just triggered a remarkable chain of events. Behind the scenes, MelodyBox's payment system is recording Alex's consent, routing his card number to a secure vault, requesting a network token from Visa, flagging the transaction with specific scheme indicators that tell every system downstream this is the first charge in a recurring series, and — because Alex is in the EU-adjacent regulatory orbit — kicking off a Strong Customer Authentication flow to prove he's really him.

All of that, from a single tick.

Here's what most people don't realize: without that checkbox and the infrastructure behind it, MelodyBox would need Alex to pull out his card and re-enter his details every single month. No stored card, no subscription. The entire recurring payments industry — streaming services, SaaS platforms, subscription boxes, cloud infrastructure billing — runs on the ability to charge a customer's card (or bank account) without them being actively present.

In Chapter 15, we saw what happens when one of those recurring charges fails — the dunning cascades, the retry logic, the customer notifications. But we skipped over a more fundamental question: how did MelodyBox earn the right to charge Alex's card every month in the first place?

That's what this chapter is about.

Stored Credentials: The Permission Object

A stored credential is, at its simplest, card information — or more commonly, a token representing that card — that a merchant keeps on file to process future transactions. When you save your card with Netflix, Amazon, or MelodyBox, the merchant (or their payment processor) stores a credential that lets them charge you again later.

But "storing a card" is deceptively simple language for what's actually a layered system of permissions, classifications, and compliance requirements. The card networks — Visa and Mastercard in particular — have built an entire framework around how stored credentials can be used, and getting it wrong means declined transactions, compliance violations, or both.

The most important distinction in this framework is between two types of transactions: CIT and MIT.

CIT: The Customer Is Here

A Cardholder-Initiated Transaction (CIT) is exactly what it sounds like: the customer is actively present and choosing to make a purchase. They might be clicking "Buy Now" on a website, tapping their phone at a terminal, or selecting a saved card in an app. The key point is that the customer is driving the transaction.

When Alex first subscribes to MelodyBox and enters his card, that's a CIT. He's present, he's choosing to pay, and he's completing the checkout flow. If Alex later opens the MelodyBox app, browses the merchandise store, and clicks "Buy" using his saved card, that's also a CIT — he's using a stored credential, but he initiated the purchase.

CITs with stored credentials are sometimes called one-click or saved card transactions. They're the "I've shopped here before, just use my card on file" experience.

MIT: The Merchant Charges Without You

A Merchant-Initiated Transaction (MIT) happens when the merchant charges the customer's stored credential without the customer being actively present. The customer agreed to this arrangement upfront, but at the moment the charge happens, they're not clicking anything. The merchant's system is doing the work.

MITs come in two main flavors:

Recurring charges happen on a fixed schedule for a fixed (or predictable) amount. Alex's monthly S$9.99 MelodyBox subscription is a textbook recurring MIT. Same amount, same merchant, same card, every month. The customer set it up once and expects it to continue until they cancel.

Unscheduled card-on-file (UCOF) charges happen at irregular intervals, often for variable amounts. Think of an auto top-up: when your transit card balance drops below $5, the system automatically charges your stored card for $20. Or a cloud hosting provider that charges you based on actual usage at the end of each month — the amount changes, the timing is predictable but the amount isn't fixed. These are MITs because the merchant initiates them, but they don't follow a rigid recurring schedule.

The distinction between CIT and MIT isn't just academic — it determines how the transaction is authenticated, how it's flagged in the card network's systems, and ultimately whether it gets approved or declined.

Why the Classification Matters

Every time a transaction flows through the card network, it carries scheme indicators — flags embedded in the authorization message that tell the issuing bank what kind of transaction this is. For stored credential transactions, these indicators specify:

• Whether it's a CIT or MIT
• If MIT, whether it's recurring, unscheduled, or installment
• The original transaction ID — linking this charge back to the initial CIT where the customer first consented

Get these indicators wrong, and the issuing bank may decline the transaction because it looks like an unauthorized charge. Get them right, and approval rates go up — sometimes dramatically. Merchants who properly flag their MITs with the correct scheme indicators and reference the original transaction ID routinely see approval rate improvements of five to 15 percentage points compared to merchants who submit MITs without proper flagging.

Consent Is Not Just a Checkbox

That checkbox Alex ticked? It's not just a UX element. It's a compliance artifact.

Card network rules require that when a merchant stores a credential, the customer's consent must be explicit and must cover:

• What's being stored — the card details (or token) and for what purpose
• How it will be used — recurring charges, one-click purchases, or both
• How to cancel — a clear mechanism for the customer to revoke consent and remove their card
• Notification of changes — the merchant must inform the customer if the terms change (e.g., a price increase)

This consent record must be retained for the duration of the stored credential relationship, and the merchant must be able to produce it to the issuing bank on request. If a customer disputes a recurring charge and the issuer asks MelodyBox to prove that Alex consented, MelodyBox needs to produce that record.

In practice, this means the billing system doesn't just store a token — it stores a consent record alongside it: when the customer gave consent, what version of the terms they agreed to, and a reference to the original authenticated transaction.

Table 1: CIT vs MIT at a Glance. The distinction determines authentication requirements, network flagging, and ultimately whether your recurring charge gets approved.

If the table is the reference, here is the decision as your billing engine actually makes it, charge by charge. Follow any path and notice that every branch converges on the same final step — referencing the original transaction:

The takeaway: two questions — who initiated, and what pattern — decide the flags, and every merchant-initiated path must chain back to the original authenticated transaction. Miss that reference and the issuer sees an unauthorized stranger, not a subscription.

SCA and PSD2: When Authentication Is Required

If you're building a subscription product that serves European customers — or increasingly, customers anywhere regulators are tightening the rules — you need to understand Strong Customer Authentication (SCA).

SCA is a requirement introduced by the EU's Payment Services Directive 2 (PSD2). In plain language, it says: when a customer initiates an electronic payment in the EU or EEA, the payment must be authenticated using at least two of three factors — something the customer knows (a password or PIN), something the customer has (a phone or card), and something the customer is (a fingerprint or face).

For online card payments, SCA typically means 3-D Secure (3DS) — the flow where your banking app pops up during checkout asking you to confirm the payment with your fingerprint or a one-time code. PSD2 also requires dynamic linking: the authentication must be tied to the specific amount and payee. You can't authenticate a generic "payment" — it has to be linked to "S$9.99 to MelodyBox."

The Recurring Exemption

Here's where it gets interesting for subscription businesses. PSD2 requires SCA when setting up a recurring payment series — that first transaction where Alex subscribes to MelodyBox. But subsequent charges in the same series (same amount, same payee) can be exempt from SCA.

This makes intuitive sense. Alex already proved he's himself when he signed up. Asking him to authenticate again every month for the same S$9.99 charge would add friction without meaningfully reducing fraud.

And here's the crucial connection to what we covered earlier: properly flagged MITs are generally out of scope for SCA entirely. Why? Because SCA applies when the payer initiates an electronic payment. In an MIT, the payer isn't initiating anything — the merchant is. As long as MelodyBox correctly flags the monthly renewal as an MIT with the right scheme indicators and references the original authenticated transaction, the charge flows through without triggering an SCA challenge.

But get the flagging wrong — submit the renewal as an unclassified transaction without the MIT indicators — and the issuer may treat it as a new CIT, triggering an SCA challenge that the customer isn't present to complete. The result? A hard decline and a failed subscription charge.

Who Bears the Risk?

PSD2 also shifted liability. If the customer's bank doesn't require SCA on a transaction that should have been authenticated, and that transaction turns out to be fraudulent, the customer generally doesn't bear the loss — the bank does. Conversely, if the merchant (or their payment processor) fails to support SCA when required, they bear the liability.

The practical takeaway for MelodyBox: authenticate the initial subscription signup with 3DS, flag all subsequent renewals as MITs with the correct scheme indicators and original transaction reference, and your recurring charges flow without friction. Skip the initial authentication or misclassify the MITs, and you're looking at higher decline rates and potential liability exposure.

Tokenization and PCI Scope: What's Actually Protected

In Chapter 12, we took a deep dive into tokenization — how network tokens and gateway tokens replace your real card number with a stand-in that's useless to attackers. Everything in that chapter applies here. But when you're storing credentials for recurring billing, tokenization takes on an additional dimension: it determines how much of your infrastructure falls under PCI DSS compliance obligations.

Merchants who store and process recurring card payments face a fundamental question: where does the real card number live, and who's responsible for protecting it?

Two Tokenization Architectures

In practice, most merchants encounter two approaches to tokenizing stored credentials:

PSP vault tokens. Your payment processor (Stripe, Adyen, Braintree) captures the customer's card number through their own secure interface — typically hosted fields or a client-side SDK — and stores it in their PCI-compliant vault. They give you back a token: a reference ID that you can use to initiate future charges. The real card number never touches your servers. Your systems only see the token.

Network tokens. As we covered in Chapter 12, the card network itself (Visa, Mastercard) issues a token scoped to your merchant ID. This is an MPAN — a merchant-scoped token that survives card reissues and works across payment processors. Your PSP requests the network token on your behalf, and the card network maintains the mapping between the token and the real card number.

Both approaches keep the PAN out of your systems. The difference is who manages the token lifecycle and how portable it is. PSP vault tokens are locked to that specific processor. Network tokens are portable — you can switch processors without re-collecting every customer's card.

The PCI Scope Reality

Here's the part that catches merchants off guard: tokenization dramatically reduces your PCI scope, but it doesn't eliminate it.

The systems that capture the PAN (even briefly), store it, or de-tokenize it are still in PCI scope. When you use hosted fields, the PAN travels from the customer's browser directly to your PSP's servers — your backend never sees it. That's a huge scope reduction. But the hosted fields JavaScript running on your checkout page? PCI DSS v4.0.1 now requires you to monitor those client-side scripts for tampering.

And the tokens themselves — particularly MPANs and PSP vault tokens that can initiate real transactions — need to be treated with care. They're not PANs, but they're not worthless either. If someone steals your MPAN and can present it with your merchant credentials, they can initiate a charge. Store them with access controls, encrypt them at rest, and log access.

Think of it like a valet key for your car. It's not the master key — it can't open the glove box or the trunk. But it can still start the engine and drive away. Treat it accordingly.

Diagram 1: Tokenization architecture for stored credentials. The PAN only exists within the PSP's PCI-scoped environment (red zone). MelodyBox's backend (blue zone) only handles tokens and never touches the real card number.

Stored Credentials vs Mandates: Two Permission Systems

So far, we've focused on cards — stored credentials, CIT/MIT flagging, tokenization. But cards aren't the only way a merchant can earn the right to charge a customer later. In much of Europe and parts of Asia-Pacific, there's a parallel system called a mandate.

If you've ever set up a GIRO payment in Singapore to auto-pay your utility bill, or authorized a SEPA Direct Debit for a subscription in Germany, you've used a mandate. The concept is similar to a stored credential — you're giving someone permission to charge you later — but the underlying mechanics, rules, and dispute rights are fundamentally different.

A mandate is the payer's consent given to the payee (and indirectly to the payer's bank) to debit the payer's bank account directly. Unlike card stored credentials, which operate under card network rules, mandates operate under banking regulations and scheme rules specific to the payment system — SEPA in Europe, BECS in Australia, ACH in the US.

The biggest practical difference? Dispute rights. With card stored credentials, the cardholder has chargeback rights governed by the card network (as we covered in Chapter 13). With SEPA Direct Debit mandates, the payer has an unconditional right to a refund within eight weeks of the debit — and up to 13 months for unauthorized debits. These are different rulesets with different timelines, and your billing engine needs to handle both. We'll pull apart direct debit rails — and why merchants both love and fear them — in Chapter 20.

For MelodyBox, this means their billing system needs to accommodate both permission models. European subscribers paying by direct debit have a mandate. Card subscribers have stored credentials. The billing engine should be agnostic to the underlying payment method, but it needs to store different compliance artifacts for each.

Table 2: Stored Credentials vs Mandates. Both are "permission to charge later," but they operate under entirely different rulesets. Your billing engine needs to handle both.

Card Lifecycle: When Cards Expire, Move, or Die

Alex Chen has been a happy MelodyBox subscriber for 18 months. Then his bank sends him a new Visa card — new number, new expiry date, same account. Alex drops the old card in a drawer and starts using the new one. He doesn't think about MelodyBox at all.

But MelodyBox's billing system has a problem. Next month's S$9.99 charge is going to hit a card number that no longer exists. Without intervention, the charge will decline, and Alex will get a dunning email (the kind we covered in Chapter 15) asking him to update his payment details. Some customers do. Many don't. And MelodyBox loses a subscriber — not because Alex wanted to cancel, but because his card changed.

This is called involuntary churn, and it costs subscription businesses billions of dollars annually. The good news? The card networks built tools to fight it.

Account Updater Services

Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) are batch services that let merchants (or their PSPs) submit a list of stored card credentials and receive back any updates — new card numbers, new expiry dates, or notifications that an account has been closed.

The process is simple: MelodyBox's PSP submits a batch file of stored credentials to the card network on a regular schedule (typically monthly or weekly). The network checks each credential against its records and returns updates for any cards that have been reissued, renewed, or closed. MelodyBox's billing system then updates its stored credentials accordingly — all before the next billing cycle.

For Alex, this means MelodyBox silently receives his new card details from Visa, updates the stored credential, and the next monthly charge goes through without a hitch. Alex never knows it happened.

Network Token Lifecycle

If MelodyBox uses network tokens (MPANs) instead of raw card credentials, the lifecycle gets even smoother. As we covered in Chapter 12, network tokens automatically update their underlying PAN mapping when a card is reissued. There's no batch file, no delay — the token service provider detects the reissue event and updates the mapping in near real-time.

This is the single biggest advantage of network tokens for subscription billing: they survive card lifecycle events silently. Account updater services work well, but they're batch-based and can have gaps. Network tokens are event-driven and more reliable.

Integrating Lifecycle with Dunning

Here's the practical lesson: don't blindly retry a declined card. If a monthly charge fails with a reason code that suggests an expired or invalid card, the first step should be checking the account updater (or relying on your network token lifecycle) before entering the dunning retry cascade.

The sequence should be:

1. Monthly charge declines with "expired card" or "invalid account" reason code
2. Check account updater for new credentials (or let network token lifecycle handle it)
3. If updated credentials are available, retry with the new details
4. If no update is available, enter the dunning flow from Chapter 15

This simple integration can recover 20-40% of declines that would otherwise trigger full dunning sequences.

Diagram 2: Card lifecycle recovery flow. When Alex's card is reissued, the account updater provides new details before the dunning cascade begins. The subscriber never knows their card changed.

UX Patterns and Merchant Best Practices

The infrastructure behind stored credentials is complex, but the customer experience should be dead simple. Alex Chen doesn't need to understand CIT/MIT classifications or scheme indicators. He needs to understand three things: what's being saved, what it will be used for, and how to remove it.

The "Remember My Card" Experience

The best implementations follow a consistent pattern. At checkout, the consent toggle is clear and separate from the "Submit" button — not buried in terms and conditions. The label explains what will happen: "Save this card for future purchases and subscription renewals." After saving, the customer can find their stored payment methods in their account settings, see the card brand and last four digits ("Visa ending in 4242"), and remove the card with a single click.

That removal click should trigger real consequences in the backend. The token should be deactivated or deleted. Future MITs against that credential should be prevented. And if the customer is on an active subscription, the system should prompt them to add a new payment method or acknowledge that their subscription will lapse.

Too many merchants make removal hard to find — buried three menus deep, requiring a support ticket, or failing silently. This isn't just bad UX; it's a compliance risk. Card network rules require that customers have a clear mechanism to revoke consent for stored credentials.

What Your System Should Store

Behind the scenes, MelodyBox's billing system needs to maintain a clean data model for each stored credential. The essentials: the token ID from the PSP or network token service, the vault or provider (so the system knows where to send charges), the consent version (which terms the customer agreed to and when), the original transaction ID from the initial authenticated CIT (needed for MIT scheme indicators), the CIT/MIT classification for each subsequent charge, and customer-facing descriptors — the card brand and last four digits that appear in the UI.

This isn't just good engineering — it's compliance hygiene. When an issuer challenges a recurring charge and asks MelodyBox to prove consent, the system needs to produce the consent record, the original transaction reference, and evidence that the MIT was properly classified.

Operational Essentials

Four things separate merchants who have smooth recurring billing from those who fight fires every billing cycle. First, minimize PCI scope by capturing card details through hosted fields or client-side SDKs — never let the PAN transit your backend. Second, build SCA and exemption handling into the checkout flow so European customers authenticate once and renewals flow without friction. Third, plan for card lifecycle events by connecting to account updater services and, ideally, using network tokens that update automatically. Fourth, wire your stored credential system into your dunning workflow so that a decline triggers the right recovery sequence — updater check first, then retry, then customer notification.

Beyond Cards: Other Stored Payment Relationships

Cards dominate stored credential infrastructure, but they're not the only game. Direct carrier billing (DCB) — where charges appear on the customer's phone bill — is a meaningful payment method in markets where card penetration is low or where mobile app stores use carrier billing as a default option.

In Singapore, mobile subscribers can make purchases that are added to their monthly phone bill through services offered by operators like Singtel, StarHub, and M1. The mechanics are different from card stored credentials — the "permission" is tied to the phone account, not a card token — but the billing engine needs are remarkably similar: consent management, entitlement tracking, refund handling, and reconciliation.

The same pattern holds for bank-linked payment methods like PayNow (Singapore) or UPI (India), where a recurring authorization can be established against a bank account rather than a card. Each rail has its own permission model, its own dispute rules, and its own lifecycle — but the shape of the problem is the same.

This is the key insight: your billing engine should be payment-method agnostic. The "permission object" pattern — store consent, classify the charge type, manage lifecycle events, connect to dunning — recurs across every payment rail. Cards, mandates, carrier billing, bank transfers — the specifics change, but the architecture doesn't.

What's Next

We've now covered the full infrastructure behind "remember my card" — from stored credentials and CIT/MIT classification, through SCA compliance and tokenization, to mandates, card lifecycle management, and the principle that billing engines should be payment-method agnostic.

But knowing how to charge a customer and having permission to charge them is only half the battle. The harder question, especially as billing models grow more complex, is: what exactly do you charge?

A flat S$9.99/month subscription is straightforward. But what about a B2B customer with a base subscription, usage-based API charges, a mid-month plan upgrade, and tax calculations that vary by jurisdiction? That's where billing engines earn their keep — and that's exactly where Chapter 17 takes us.

Sources

• Visa Stored Credential Transaction Framework — CIT/MIT classification and scheme indicator requirements
• Mastercard Stored Credential Guide — recurring and unscheduled card-on-file rules
• European Commission PSD2 (Directive 2015/2366) — Article 97 on Strong Customer Authentication
• EBA Regulatory Technical Standards on SCA — recurring transaction exemption criteria
• PCI SSC Tokenization Guidelines (2011) and PCI DSS v4.0.1 — token security and scope requirements
• EMVCo Payment Tokenisation Specification — network token lifecycle management
• Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) documentation
• SEPA Direct Debit Rulebook — mandate requirements and payer refund rights