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 licensed by the Reserve Bank of India (RBI). The RBI requires payment aggregators (such as 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 about regulations in India, please see our article on Background on Indian government regulations affecting card payments.

FAQ

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

No entity in the card transaction chain can store information relating to customer cards (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 are the only applicable ways forward for the industry.

There are also additional requirements surrounding 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 obtained before generating a token

• A merchant should give the customer an option to delete the tokenised card from the merchant platform

• Only the last four digits of the customer card, along with the issuer bank name and the card network, may be available to a merchant during transactions (i.e. visible on the Stripe Dashboard for payments).

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

Can I now store tokens instead of cards?

No, as is the case for 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 need to continue doing the same for their tokens as well.

Stripe is a certified token requestor which cannot only store tokens and facilitate token-based transactions, but can also enable the generation of tokens via the card networks. 

Nothing will change in your Stripe integration. Stripe will seamlessly handle fetching and using network tokens on behalf of your customers in the background. You will not have to manage this 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 for use on another merchant's platform.

Essentially, one cardholder's card will have multiple tokens based on the number of merchant-customerID combinations that they have. 

This map will be maintained by the token requestor (Stripe). However, we cannot guarantee that a merchant onboarded to the card networks will have the same merchant ID as 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 it is used through other payment aggregators/payment gateways. 

How will my customer checkout experience be affected?

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

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

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

For users who have already tokenised their customers' cards, their saved cards would now be further masked so that they would only be able to see the last four digits.

For cardholders who choose not to tokenise their cards, they will need to enter their 16-digit card number, expiry date and CVV for all card transactions in future.

How can I opt out of Stripe Managed Tokenisation Consent?

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

Once you are in Card Storage Consent, please toggle the consent collection acknowledgement.

Once you opt out, it is then your obligation to obtain 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.

Which flows could 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 affected. You will need to opt out using the Dashboard mechanism and obtain consent from your customers to allow us to tokenise and store the information on Stripe systems.

Where can I find out more information?

Please contact us securely at support.stripe.com, where our team will be happy to assist you with any questions that you may have and help you gain a deeper understanding of how to comply with these regulations.