Published in


13. Save Card / Card Vault

You might have noticed that many merchants give option to ‘save card for future purchases’. Card vault is important for a merchant because,

  • Success rate of transaction done with saved cards is higher than regular transactions
  • Ease of completing transaction (as involves less steps)
  • If a customer has saved card that means the customer will come again to purchase (indicates loyalty, repeat purchase possibility, higher LTV)

Having said that, it is important for a merchant to understand processes and challenges of saving customer’s card.

Do you want users to save their cards?

A merchant may want to save user’s card if,

  • Frequency of purchase is high or repeat purchases

A term insurance merchant has repeat payments but that is one time in a year so it really doesn’t make sense to save user’s card but it is important for an online fashion apparel merchant

  • Mobile is important sales channel

Entering 16 digits card number every time on a mobile is cumbersome so allow user to save card for faster checkout experience

So a merchant has to think whether they really need to save card and then decide on strategy as card vault involved cost, risks and may create dependencies. Let’s understand these aspects in detail.

Who can save the card?

Any entity that is PCI-DSS (L1) certified can save the card. So card can be vaulted by,

a. Merchant

Card saved with merchant (E.g. Flipkart)

A merchant can save the card if it is PCI Certified


  • No lock in with any aggregator or bank or TSP
  • Better control on routing
  • Use same card vault across multiple Live Ids of same aggregator


  • Huge costs related to audits, insurance, resources (if you want to have an elephant as a pet then be ready to buy a farm to feed it)
  • Risk of saving card (remember, everything in payments is associated with risk)

b. Payment Aggregators

All payment aggregators are PCI Certified entities and can provide card vault service to merchants.


  • No additional cost to merchant as aggregator bears costs and risks


  • Saved cards are locked in the aggregator (Saved cards always have to be processed with that aggregator only and merchant cannot use other aggregator to process it)
  • Merchant may think that I will vault card with aggregator A and then move to aggregator B when the time comes. But such migrations are next to impossible. Although technically it is allowed but aggregators won’t do it giving various reasons of compliance, risk etc. but main reason is that the existing aggregator would hate to lose exclusivity with merchant
Aggregator saving card

c. Technical Solution provider (TSP)

TSP Vaulting the card (E.g. Swiggy)

FinTech companies that provide aggregator agnostic card vault (E.g. JusPay)


  • Cards are not locked in with any aggregator or aggregator’s Live Id so merchant can use any aggregator/acquiring bank of its choice to process cards
  • Merchant can enjoy benefits of card vault but TSP will do PCI heavy lifting


  • TSPs may charge additional fees to merchant

Another type of card storage:

Some of the aggregators and payment containers provide allow users to store card and can be accessed (with login credentials) where they are enabled.

Example 1: Aggregator’s Checkout Solution

CC Avenue’s Checkout allows user to vault card and can be accessed where CC Avenue Checkout is enabled (remember, not just CC Avenue as aggregator but specifically the checkout should be enabled.

Example 2:

AmazonPay, PhonePe allows users to store card and customer can make payment on merchant if those containers are enabled.

Pros: Customer doesn’t have to store cards with every other merchant


  • Cards are linked to particular account that user created with these payment providers
  • To make payment the payment providers should be available with merchant.

Conclusion: Understand the cost, dependencies, scalability and risks involved in each method and then decide on your card vault strategy

Further information on Saving the Card:

Consent to save: There are no particular guidelines on customer’s consent and this purely merchant’s business decision. A merchant may seek consent from user to save card (little checkbox is shown with ‘save card’) and some merchant save card without explicit consent from customer

How to Save Card: Card is saved against unique user id (mobile number, mail id or unique customer id) and user can store more than 1 card. So every time the user comes to purchase, then all saved card (s) stored against that user id is shown.

Note: As card vault is connected to unique id that is why ‘save card’ option is not shown when you login as ‘guest’ because ‘guest’ doesn’t have unique Id.

When to save: Typically, card is saved only when transaction is successful.

I have seen cases where merchant has vaulted card even for unsuccessful transaction. This is wrong method as a card with wrong credentials might get saved and transaction done with that card will always fail.

What is saved: Only card number and expiry date is saved.

A repeat user has to enter the CVV to complete the transaction.

Note: Some aggregators allow transaction without CVV but that is an exception

Transaction flow of Saved Card

Ownership: The merchant owns the card data. So usually aggregators do not cross expose one merchant’s card vault to others.

Live Id & Card vault: Card vault is linked to merchant’s Live Id. If a merchant has two Live Ids (e.g. A1234 & B6789) then saved card at Live Id A1234 will not be shown LB6789. If merchant has multiple Live Ids but require single card vault then merge card vaults

Example: Ola has multiple Live Ids (depending on business line) but has one combined single vault. This is done to provide uniform user experience because customer is storing card on Ola App and she doesn’t care underlying Live IDs or business line.

Card Migration: Saved cards can be migrated from one PCI compliant entity to other PCI compliant entity based on merchant’s instruction (remember… saved cards are merchant’s property).

Let us assume aggregator who has saved cards has to migrate cards to another PCI entity then below are the scenarios in decreasing order of friction

  • Readily migrate cards to PCI Compliant merchant
  • Will migrate cards to TSP with great resistance (higher chance)
  • Will not migrate cards to another aggregator (1 in a million chance)

Deletion of saved card: Based on merchant’s request the aggregator/TSP can delete the card

Here is little section on capturing card details

Cards details (card number, expiry, CVV) can be entered only on pages of PCI compliant entities.

  • If merchant is using non-seamless (redirection) page or iFrame page of aggregator/TSP then anyway cards are entered on aggregator/TSP’s pages
  • If merchant is PCI compliant then it can capture card details

If merchant is non-PCI compliant and using seamless flow then card details shouldn’t hit merchant’s website or App. So in this case, aggregator /TSP provide iFrame elements to that can be embedded in merchant’s page to capture card details.

Checks done on card details

  • Do not allow non-numbers in card number, expiry, CVV field
  • Check on card number length depending on card type (MasterCard: 16, Visa: 13, 16, Amex: 15, Rupay:16 etc.)
  • Expiry date checks (months should be 1 to 12 and card should not be older than present)
  • Length of CVV/CVC (3 for Visa, MasterCard, RuPay and 4 for Amex)
  • Mod10 check (to highlight the wrong card)

How to use ‘Saved Cards’ in marketing/Promotion campaigns

What does it mean when customer saves card? Ans: Customer has intention to come back again (and again) to make additional purchases and that means the life time value of that customer is higher compared to customer who didn’t save card.

So merchant and banks can create tailor promotions for transactions done with saved cards or give extra incentive for users who save cards.

Next Topic: Transaction Routing




Everything about digital payments, products/platforms, processes and players in dynamic and evolving India’s payment eco-system. You can order a book on <>

Recommended from Medium

Block 11: Coverage is Coming 🐲

ProximaX Tech — November 2018

The Steemit adventure

Celebrating $1B Astar TVL!

How to decentralize with DAppNode

Moeda Weekly Ship | 10/7 to 10/13

ARK Core: Path And Vision To V3

Biconomy Integrates Chainlink Price Feeds to Enable Gas Payments in Various Cryptocurrencies

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aditya Kulkarni

Aditya Kulkarni

Trying to follow Richard Feynman’s words “do what you can, learn what you can, improve the solutions, and pass them on”.

More from Medium

Designing Payment Cards Made Simple: Here’s What You Need to Know

65. Payments Digest — VI

The Origin & Evolution of NACH Mandates & Recurring Payments