Only card issuers and card networks are permitted to store the card data of an India-issued card for transactions processed through payment service providers licenced by the Reserve Bank of India (RBI). The RBI requires payment aggregators (like Stripe India) to use network tokens for payment processing instead of the actual credit/debit card number.

These regulations mainly affect businesses based in India. Card networks have launched card-on-file (CoF) tokenisation services to comply with these requirements and Stripe has developed solutions for our customers to take advantage of. For more information on India regulations, please see our article on Background on Indian government regulations affecting card payments.

FAQ

What exactly do the Reserve Bank of India guidelines say on card credential storage?

No entity in the card transaction chain can store customer card related information (other than the card issuers and card networks) - this restriction extends to Merchants, Payment Aggregators (PAs), Payment Gateways (PGs) and Acquiring Banks. It also confirms that network tokenisation and issuer tokenisation is the only applicable way forward for the industry.

There are also additional requirements around the implementation of tokenisation that need to be adhered to:

• A token must be scoped to a Merchant, Customer Card and token requestor (such as Stripe India)
• Explicit customer consent and Additional Factor Authentication must be taken before generating a token
• A merchant should give the customer an option to delete the tokenised card from the merchant platform
• Only the last 4 digits of the customer card, along with Issuer Bank name and card network can be available to a merchant during transactions (i.e. visible on the Stripe Dashboard for payments).

This applies only to India domestic merchants for domestic transactions. If you are an international merchant on Stripe, you are not contracted with Stripe India, this regulation should not apply and cards will not be tokenised.

Can I now store Tokens instead of Cards?

No, as with the case of Card on File (CoF) storage, only PCI DSS compliant Merchants can store Tokens themselves. For the remaining Merchants who currently use a third party service to store their cards, they will have to continue doing the same for their Tokens as well.

Stripe is a certified Token Requestor who can not only store Tokens and facilitate token based transactions, but also enable the generation of Tokens via the card networks.

Nothing will changes in your Stripe integration. Stripe will seamlessly handle fetching and using network tokens on behalf of your customers under the hood. You will not have to manage that process.

Will a token created for a customer card be the same for my customers and other merchants?

A token will always be unique to a merchant, a customer ID, a token requestor and a card network. A token generated on one merchant’s platform will not be valid on another merchant’s platform for usage.

Essentially, one cardholder’s card will have multiple Tokens based on the number of Merchant-CustomerID combinations they have.

This map will be maintained by the Token Requestor (Stripe). However we cannot guarantee that a Merchant on-boarded to the card networks will have the same merchant ID provided by other Token Requestors (i.e. duplication may occur). Therefore we cannot guarantee that a token provided by Stripe will work for the same merchant-customer combination if used through other Payment Aggregators / Payment Gateways.

How will my customer checkout experience be impacted?

For the end customer, the impact of Tokenisation will be minimal. To convert their cards into a token, a customer will have to give you consent to do so, as they proceed to pay for an ongoing transaction. This will be the case for new card flow as well as the saved card flow.

To make life easier for you, Stripe is launching, Stripe Managed Tokenisation Consent (SMTC), an intercepted form view as part of the checkout flow, to collect customer consent on your behalf, without you building out any new UX flow or having to make integration changes.

You have the option to opt-out of Stripe Managed Tokenisation Consent (please see opt-out below), if you want to build or integrate your own custom consent flow that you want to seamlessly use in your checkout experience.

For users who have already tokenised their customers’ cards, their saved cards would now be further masked such that only the last 4 digits will be visible to them.

For cardholders who choose not to tokenise their cards, they will have to enter their 16-digit card number, expiry and CVV for all card transactions going forward.

How can I opt out of Stripe Managed Tokenisation Consent?

If you want to opt out of Stripe Managed Tokenisation Consent, because you want to create your own custom consent flow, then please navigate to the compliance section in the Stripe Dashboard settings page to Card Storage Consent.

Inside Card Storage Consent, please toggle the consent collection acknowledgement.

Once you opt out, it is then your obligation to collect customer consent and only save card details for future use on the Stripe Customer object if the cardholder has given consent in your checkout consent flow.

What are the flows that will potentially break for me?

For users who do not use Stripe Billing, Stripe Checkout or Stripe Elements, any flows that rely on the card number for your customer will be impacted. You will have to opt out using the dashboard mechanism and collect consent from your customers to allow us to tokenise and store the information on Stripe systems.