Introduction

Your users save invaluable time when they use their cards that are stored on PayU Vault instead of entering the card details when they make payments safely on your website. Customers can use saved cards on all the merchant websites where they support PayU Vault.

Users can update or delete their card details on the PayU vault when required. You may need to enable this on their website.

The workflow for users with PayU Vault are:

1. Customer visit the merchant’s website, adds items to the cart, or utilize the merchant’s services, and then enter the card details.
2. Customer provides consent to the merchant and the merchant saves the card details on PayU Vault
3. Customer visits the same merchant and uses the saved card details to proceed with the transaction.
4. Customer provides his/her user credentials, the merchant retrieves the card details and the user enters the CVV or 3DBC number to complete payment.

Note: While CVV is not mandatory from the network perspective, some banks may impose the necessity of the same for doing transactions with a saved card. Also, if the bank does not mandate the CVV but the merchant captures the same, CVV will be verified. It is recommended that for the banks where CVV is not required, merchants should not ask for the same

5. User can update or delete the card details when required.

📘

Note:

You need to ensure that you have filled the “Self-Assessment Questionnaire A-EP and Attestation of Compliance” form from PCI, which is mandatory for all entities seeking to store, process, and transmit cardholder data.

What is Tokenization?

Tokenization protects sensitive data by creating an identifier that maps back to the sensitive data but does not have any intrinsic value. 

RBI Guidelines

According to the RBI circular, you must be using tokenization to save card details on your website starting 1st January 2022. For more information, refer to the Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services circular.

In a card context, it replaces the actual card number with a dummy reference ID.

PayU’s interpretation of RBI guidelines

• Only Issuers & Payment Networks are allowed to store customer card data. ​
• Limited data can be stored by non-payment entities (Bank Name,  Last 4 digits of card)​
• Every token to be stored with customer consent (AFA)​
• Customers should be able to manage their details on business and Issuing bank platforms​
• Every token is unique to a user, card, and the merchant
• Existing data migration is not possible

Who can Tokenize Cards?

As per the current RBI guidelines, tokens can be created with either the networks or the issuing bank. 

For example, Mr. John Doe has an HDFC VISA Signature credit card. This card can be tokenized by VISA (VTS or Visa Token Service) or by HDFC through its proprietary token service.  

PayU is working with both the networks and issuers to be able to provide tokenization to its merchants. 

PayU Solution

PayU will provide both network tokens and issuer tokens for its merchants along with other suites of products to maintain and manage the vault services:

• Network Tokens: Network tokens are virtual payment cards created by the payment schemes (VISA, Mastercard), and they replace the original card in the digital space. This allows for several network tokens to be created per card, and they function in the same way as the original card when storing and transacting with them. 
• Issuer Tokens: Issuer tokens are virtual payment cards created by the card-issuing bank, and they replace the original card in the digital space. However, these tokens are not understood by the network schemes

Which Model you Should Choose?

If you are using PayU Hosted Checkout, you must use Model 2, where PayU manages everything end-to-end without a single line of code change at your end. For more information on PayU Hosted Checkout integration, refer to PayU Hosted Checkout.

For seamless integration, minor changes are expected in the APIs, which is explained in the subsequent sections. 

Processing a Transaction with PayU with Token Created Outside PayU

You would need the token, expiry, and TAVV values to be passed using PayU _payment API. Apart from this, no further changes are expected. For more information, refer to Collect Payments using a Saved Card.

Choosing the Tokenzation Model

PayU offers the following models to integrate vault using PayU Hosted Checkout or Merchant Hosted Checkout integration:

• PayU Hosted Checkout Integration - Model 1
• Merchant Hosted Checkout Integration
  • Zero Code Change - Model 2
  • Simple REST APIs - Model 3

Using PayU Hosted Checkout Integration

Model 1 – Zero Code Change

If you are using the PayU Hosted Checkout integration and vault, there are no changes required from your side. PayU will manage everything from procuring, managing tokens, consent management, and displaying saved cards on the checkout page end-to-end. To enable vault with PayU Hosted Checkout integration:

• Reach your PayU Key Account Manager to enable vault.
• If you are not using the PayU vault, the only change required will be passing a user identifier.

Using Merchant Hosted Checkout Integration

PayU offers the following models to use vault with Merchant Hosted Checkout integration

Model 2-Zero Code Change

If you are using the Server-to-Server integration, you can choose to have PayU create and manage tokens on your behalf. You need to send an extra parameter in the _Payment API call, and PayU takes care of the vault.

Pros

• Zero cost of compliance at your end. PayU will take care of creating, managing, and storing the tokens.
• Minimal technical changes at you end as you will only need to pass the customer consent to create a token which is one extra parameter in the _payment API.

📘

Note:

In this model, you need to ensure that first-time payment is done with PayU Payment Gateway to create the token.

Model 3-Simple REST APIs

It provides you with complete control and flexibility in creating and managing tokens. The workflow involves:

1. PayU exposes the CRUD APIs which the merchant can call to create and manage the cards
2. The merchant calls the create token API after payments confirmation to create the token.
3. The merchant can choose to store the card tokens (including network and issuer token).

📘

Note:

You need to be PCI-DSS compliant if you want to store the network tokens at your end.

Pros

• You have complete control on the token creation and management. The token can continue to be stored at PayU and/or merchant end.
• Completely decouple tokenization from payment processing as they are independent events.

Cons

• High cost of compliance
• You need to ensure that the orchestration is in compliance with the guidelines as the create token call and create payment calls are disjointed.
• You need to be PCI-DSS compliant if you want to store the network tokens at your end.