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
A merchant can save the card if it is PCI Certified
Pros:
- 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
Cons:
- 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.
Pros:
- No additional cost to merchant as aggregator bears costs and risks
Cons:
- 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
c. Technical Solution provider (TSP)
FinTech companies that provide aggregator agnostic card vault (E.g. JusPay)
Pros:
- 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
Cons:
- 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
Cons:
- 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
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
