Impact of Tokenization

This section describes the impact of tokenization on PayU Subscription.

Suggest Edits

Existing Flow

  1. Mandate request comes to PayU with the plain card.
  2. PayU does authentication, creates a subscription with SI hub, does authorization and then updates SI hub with the details to finally activate the subscription.
  3. In this case, PayU was storing cards every time for each and every merchant.

Earlier Approach for SI Tokenization

  1. PayU will purge all the plain cards of the created subscriptions in its system and to do recurring of existing mandates, SI Hub will share with PayU the plain card number at the time of recurring and basis this, PayU will do authorization
  2. Above flow remains the same for the new Mandates set up through plain card.
  3. For new mandates where the merchant has the token and not the plain card, PayU will make changes in the registration leg to accept tokens and accordingly create subscriptions through tokens at the SI hub end as well as do authorization through tokens with the PG.

Recently, a lot of contemplation has been done in the Fintech industry and an alternative approach has come up. The earlier approach will be taken if the regulator approves the SI hub to save the plain card.

New Approach for SI Tokenization

To set up a subscription, every card has to be tokenised and shared with PayU at the time of registration. For existing mandates, migration needs to happen where the network token of the card has to be created with which subscription happened. Now, this token can be pre-generated where the merchant might have already generated a token or a fresh token has to be generated for this. The impact areas are:

  1. Existing Mandates
  2. New Mandates

Existing Mandates

 To process existing mandates, a network token needs to be there and that network token has to be shared with PayU for one-time migration of that subscription. 

  1. For cases where the token is already created by the merchant for that card number, PayU will expose an Subscription with PayU API where the merchant can pass us network tokens and PayU will basically update the token at the SI Hub end and share the result with the merchant. You can refer to Recurring Payment Transaction API.
  2. For cases where PayU will do the migration or where merchant is not using tokenization anyways, PayU will do a bulk migration activity and create tokens. Post this, PayU will update the token for migration. The result of migration will be shared via an excel format.

New Mandates Through Plain Card

  • Where PayU is the token requestor: Nothing changes in this approach. PayU will basically do tokenization post AFA and share the network token with the SI Hub to activate the subscription.
  • Where PayU is not the token requestor: Merchant will call the Recurring Update API to set up registration and PayU will share the authorization result. Now, the merchant will have to tokenise the card and then update PayU with the token so that the same can be updated at the SI Hub end. Later, the subscription will get activated. For more information, refer to Recurring Payment Transaction API

New Mandates Through Tokens

  • PayU will pass network tokens directly at the time of subscription creation to SIHub. Now, the network token can be generated by PayU or outside PayU which doesn’t affect in this leg since PayU requires network token and expiry details.

Changes Required

  1. Modify the Recurring Payments for a Card – This needs to be done for cases where merchant is doing the migration or where PayU will not be the token requestor.
  2. New mandate setup through plain card
    • Where PayU is the token requestor: No changes. Only tokenization needs to be activated
    • Where PayU is not the token requestor: Changes have to be done post the registration is initiated. Update SI API has to be called to update the subscription and final basis of that response, the subscription will get activated. For more information, refer to Update SI API.
  3. New mandate setup through token

Updated 4 months ago