Saved cards and guest checkout: consent, CVV and credential-on-file rules

A returning customer who has to find their wallet and type sixteen digits on a phone is one distraction away from leaving. Saved cards remove that step. They also bring obligations: you have to ask properly, store properly and confirm who is paying. Guest checkout pulls in the other direction, asking for nothing and remembering nothing. A good checkout does both.

This article covers when to offer saved cards, the customer consent rules, the CVV on a saved card, credential-on-file rules and how guest checkout fits in. It is about one-off purchases that the customer starts, not scheduled charges. For how cards are stored, see our articles on network tokens and PSP tokens and card token portability.

When should you offer saved cards?

Offer them where repeat purchases are likely and the customer has a reason to sign in. A store that sells consumables or sees frequent reorders has more to gain than one selling a product bought once in several years.

Keep the offer optional. Baymard’s list of checkout abandonment reasons, based on its latest study of US online shoppers, puts “the site wanted me to create an account” at 18% and not trusting the site with card information at 19%, excluding shoppers who were just browsing. Those two findings explain the balance. Push accounts too hard and you lose the first group. Push saved cards too hard and you may unsettle the second. Baymard’s figures describe US shoppers, and trust varies by market, so test before rolling out worldwide.

Some placement choices follow from this:

• Show the choice at the payment step. The customer is typing the card at that moment and can see the benefit.
• Explain it in one line. Say what you are saving, what for, and how to remove it.
• Default to not saving. A pre-ticked box fails the EDPB’s test, as the next section shows.
• Show saved cards first to returning customers, with an option to add a new one.

Do not treat a saved card as a substitute for wallets. Apple Pay and Google Pay give a similar speed without your storing the card, and on a phone they can be the faster option.

What consent do you need to save a card?

Two sets of rules overlap: the card schemes and data protection law.

Visa’s rules, in the October 2026 edition, say that before a merchant stores a payment credential for a future transaction, it must obtain the cardholder’s express informed consent to an agreement. That agreement must be displayed separately from the general purchase terms. The rules list what it contains, including:

• The goods or services and the total price, with cancellation and refund policies.
• The merchant’s location and contact details.
• The last four digits of the card that will be used.
• How the customer will be told about changes.
• How the stored credential will be used.
• The amount, or how it will be determined, and the currency.
• The expiry date of the agreement, if there is one.

You must keep this information for the length of the agreement and provide it to the customer or issuer on written request. Visa’s rules also say a merchant must use a stored credential only as agreed with the cardholder, which rules out quietly reusing it for something else.

In Europe, the European Data Protection Board adopted recommendations in May 2021 on storing card data to make further purchases easier. It concluded that consent appears to be the sole appropriate legal basis. It says this consent cannot be presumed from a purchase, must be given by a clear affirmative action, and should be requested in a user-friendly way, such as a checkbox that is not pre-ticked, on the same form. It must be separate from consent to terms of service, and must not be a condition of completing the purchase. The recommendations do not cover payment institutions operating in online stores, or storage to set up recurring payments.

Stripe’s documentation gives a practical version for merchants: add terms stating how you plan to save payment details, use a saved method only for the stated purpose, collect explicit consent, and keep a record of the customer’s agreement. It also says compliance remains your responsibility, and that is true whichever provider you use.

What must happen on the first payment?

The first payment does more than collect money. It sets up the stored credential.

1. Show the agreement and collect consent before the payment is submitted.
2. Authorise the amount. Visa’s rules say the merchant must submit an authorisation request for the transaction amount, or an account verification if no payment is due.
3. Check the result. If that authorisation or verification is not approved, Visa’s rules say you must not store the credential.
4. Store a token, not the card number, with a PCI DSS compliant provider or vault.
5. Record the consent: what was shown, when, and to which customer account.

For customers in the European Economic Area, strong customer authentication applies to this first payment in the usual way, and our article on 3-D Secure exemptions explains the options.

One rule surprises teams who built their own saved card screen. Visa’s rules say a merchant that retains stored credentials must display the last four digits and the Visa brand mark, or the name “Visa”, next to the Visa option on the payment screen and on any screen that shows payment credentials. That lets the customer see which card they are about to use.

What does a repeat purchase with a saved card need?

When a returning customer picks a saved card and presses pay, the payment is customer-initiated. Three things apply.

Identity. Visa’s rules say that before processing a cardholder-initiated transaction with a stored credential, the merchant must validate the cardholder’s identity, for example with a login ID and password. A saved card shown to someone who merely typed an email address would not meet that.

Correct flagging. Visa’s rules say a stored credential transaction must use POS Entry Mode code 10, and the authorised amount must not exceed the transaction amount. Your provider sets these fields, but ask how it labels a customer-initiated repeat purchase, because the flags are how an issuer tells a saved card payment from a new card typed in. Our credential on file entry explains the terms.

Authentication. Stripe’s guide says SCA applies to customer-initiated payments unless an exemption applies or the payment is out of scope. Saving a card does not change that. The customer is present, so be ready for a challenge on a repeat purchase.

Tokens are also a rule in some markets. Visa’s rules require acquirers and merchants in listed countries to use a Visa token for stored credential transactions, including Kazakhstan, Saudi Arabia, the United Arab Emirates, Colombia and, from 25 July 2026, Mexico. Ask your provider how this applies to your acquiring set-up in those countries.

Do you need the CVV on a saved card?

You may ask for it. You may not keep it. The PCI Security Standards Council is explicit on the second point: card verification codes cannot be retained once a transaction is authorised, they are not needed for card-on-file transactions, a customer’s approval to retain them has no validity for PCI DSS, and encryption does not change this. A separate PCI SSC answer confirms that merchants can request codes, naming Requirement 3.3.1.2 as the ban on storing them after authorisation.

Scheme rules do not always ask for it. Visa’s rules for Europe and for Canada require the CVV2 in card-absent transactions but exempt transactions using a stored credential. They also say an issuer must not decline based solely on a missing CVV2 for a transaction initiated with a token. In Australia, Hong Kong and New Zealand, the requirement to capture the CVV2 for e-commerce has an exception for token-initiated transactions, not for stored credentials in general, which is one more reason to use tokens.

Option	Good for	Cost
Never ask on saved cards	Low-value, frequent purchases from signed-in customers	No extra check if an account is taken over
Ask only on higher-risk purchases	A middle ground: new device, new address, high amount	Needs rules to decide when
Ask every time	High-value goods or markets with more fraud	More friction on a flow meant to be short

Stripe offers CVC recollection as an optional setting, which shows it is a choice, not a default. Our article on fraud screening and approval rates covers how to weigh friction against losses. If you do collect the CVV, send it for that authorisation only and make sure no log or analytics tool keeps it.

How does guest checkout fit with saved cards?

Guest checkout and saved cards serve different customers. Neither replaces the other.

	Guest checkout	Saved card with an account
Who it suits	First-time and occasional buyers	Repeat buyers
What you store	Order details only	Token, consent record, account
Login before paying	Not needed	Required by Visa’s stored credential rule
Time at next purchase	Customer types the card again	Customer picks a card
Main risk	Slower return visits	Account takeover

Our article on checkout form design covers how to make guest checkout prominent. The saved card question then comes down to one moment: consent has to be collected on the form where the card is entered, before you store it. So if a guest creates an account on the confirmation page, you can link their order to it, but you cannot go back and keep the card unless they agreed when they paid.

A workable pattern:

1. Offer guest checkout first and clearly.
2. On the payment form, signed-in customers see an unticked option to save the card.
3. Guests who want to save it are asked to create an account or sign in first.
4. After the order, offer an account for faster tracking, and let them save a card on their next purchase.

Take care with one-time links and email-only sign-in. If you use them as your identity check, ask your acquirer whether they meet Visa’s requirement to validate the cardholder’s identity. Its rule gives a login ID and password only as an example.

Which local rules change the picture?

Most of the differences are about who may hold the card.

India. The Reserve Bank of India’s September 2021 circular says that no entity in the card payment chain other than card issuers and card networks may store actual card data, and that tokenisation needs explicit customer consent with an additional factor of authentication validated by the issuer. The RBI has issued later circulars on card-on-file tokenisation, so check the current position with your provider, including how it applies to cross-border sales.

European Economic Area. Consent under the EDPB recommendations and SCA both apply, as above. Treat them as separate tests: one is about keeping the data, the other about authorising the payment.

Everywhere else. Assume local data protection law has something to say about storing payment data, and ask your provider or adviser. Our article on data localisation in the CIS shows how much this can vary.

How does Omno handle saved cards?

Omno’s hosted checkout offers saved cards and accounts, so returning customers do not retype their details. It is PCI DSS compliant, and card data never touches your servers in the hosted checkout. The consent wording and your terms remain your responsibility, so review them against the rules above. The tokenization and saved cards page explains how this works.