Stored credential
DEFINITION
A stored credential is a customer's payment information, such as a card number, that a business keeps on file with the customer's consent so it can charge that payment method again later without asking for the details each time.
TABLE OF CONTENTS
RELATED TERMS
A stored credential is a customer's payment information, such as a card number, that a business keeps on file with the customer's consent so it can charge that payment method again later without asking for the details each time. Card networks require the business to record the customer's agreement and to flag later charges correctly.
Storing a credential is what makes recurring billing possible. When a customer first agrees to save a card, that agreement covers future charges, whether the customer triggers them or the business does. Later payments fall into two groups: cardholder-initiated transactions, where the customer is present and acts, and merchant-initiated transactions, where the business charges the saved credential on a schedule the customer already agreed to. A subscription platform such as Recurly stores the credential through its payment gateway and tags each subsequent charge with the right indicators so issuers understand the context. Recurly stores the credential as a token through its supported gateways, keeps the network transaction ID and, for Mastercard, a transaction link ID, and automatically flags renewals as merchant-initiated.
Why stored credentials matter for subscription businesses
A subscription cannot rebill a customer who has to re-enter a card every cycle. The stored credential removes that step and lets the business charge on schedule. It also affects how well those charges are approved, since issuers read the transaction indicators that come with a stored-credential charge to understand its context.
Handling stored credentials also carries compliance weight. Storing card data brings the business into scope for the Payment Card Industry Data Security Standard (PCI DSS), and most businesses reduce that burden by having the gateway or platform hold the card in a secure vault rather than keeping raw card numbers themselves. Recurly.js tokenizes card details in the browser, keeping raw card numbers off the merchant's servers, which can help qualify for a reduced PCI scope.
How stored credentials work
At the first payment, the customer enters card details and agrees that the business can store and reuse them.
The business records that consent, including when and how it was given.
The card is saved as a token in a secure vault rather than as a raw card number.
The first transaction is flagged as the one that establishes the stored credential.
Later charges reference the stored credential and are flagged as either cardholder-initiated or merchant-initiated.
When a card expires or is reissued, an update service can refresh the stored token so billing continues. Recurly's Account Updater is a proactive service that does this, integrating with Visa, Mastercard, American Express, and Discover.
How to use stored credentials
Capture and store explicit consent at the first payment, and keep a record of it.
Store the card as a token through the gateway rather than holding raw card data.
Flag the first transaction correctly so later charges can reference it.
Tag each later charge as cardholder-initiated or merchant-initiated based on who triggers it.
Keep saved credentials current with an account updater so expired cards do not cause failed payments. Recurly's Account Updater covers stored credit cards across Visa, Mastercard, American Express, and Discover, though Mastercard requires an MCC on file and American Express requires a direct account and SE number.
Benefits and examples
Repeat billing without re-entry: the customer agrees once and the business charges the saved method on schedule.
Clear transaction context: correctly flagged stored-credential charges give issuers the context they need to judge the charge.
Lower compliance burden: vaulting and tokenization keep raw card data out of the business's systems. Recurly.js handles this tokenization directly in the browser, so raw card numbers never reach the merchant's servers.
Fewer involuntary failures: an account updater refreshes cards that expire or are reissued.
For example, a streaming service asks a new subscriber to save a card and agree to monthly billing. That first charge is flagged as the transaction that sets up the stored credential. Each month after, the service charges the saved token as a merchant-initiated transaction. When the subscriber's card is reissued with a new expiry date, an account updater refreshes the stored token so the next charge still goes through.
Frequently asked questions
What is a stored credential? It is a customer's payment method, such as a card, that a business keeps on file with the customer's consent so it can charge it again later without asking for the details each time.
What is the difference between cardholder-initiated and merchant-initiated transactions? A cardholder-initiated transaction is one the customer actively triggers while present, such as a manual renewal. A merchant-initiated transaction is one the business runs against the saved credential on an agreed schedule, such as an automatic monthly charge.
Do I have to store the actual card number to bill again? No. Most businesses store a token that represents the card in a secure vault, which keeps raw card data out of their own systems. On Recurly, this token is created by Recurly.js directly in the customer's browser, so the merchant's servers never see the raw card number.
Does saving a card require the customer's consent? Yes. Card network rules require the business to obtain and record the customer's agreement before storing and reusing a credential.
