The Model 2 involves only zero code change and this section describes the general workflow.
To use tokenisation, you need to get the Token Requestor onboarding to be done. Contact your PayU Key Account Manager (KAM) to get the onboarding done.
To create the token, only a zero code change is required. However, to process the transactions using the tokens, you need to integrate an extra API.
PayU onboards the merchant on the PayU token hub.
Merchant will pass the consent value and user id in the _payment API.
Here, consent is taken from customer on the merchant’s website (similar to the step 2 of Model 1 - PayU Hosted Checkout Integration before passing the consent value.
- If the merchant is already using the PayU vault, only consent parameter needs to be passed.
- If the merchant is newly onboarded on the PayU vault, consent and user ID parameters need to be passed.
- PayU will first process the transaction and then create the network and issuer token.
- PayU will store the tokens on its own servers on the merchant’s behalf.
The following flow diagram illustrates the workflow for first-time payment workflow.
- Merchant takes the customer card details and consent, and then initiates transaction and sends the payment details to PayU.
- PayU initiates the transaction with the Payment Gateway.
- Payment Gateway passes the transaction status to PayU.
- PayU initiates the token provision with PayU vault .
- PayU then creates token with networks and issuers.
- PayU passes the token to the merchant.
- 0 – Consent was not provided by customer
- 1 – Consent was provided by customer
If the consent is provided by the customer, the value is passed as 1.
- Only the fields needed for this operation are mentioned here. For the complete API details for the _payment API, refer to Merchant Hosted Checkout.
- After taking the consent, merchant will have to call PayU for doing the transaction and creating token. This is needed as PayU will ensure the additional factor authentication (AFA) requirements are taken care of.
- The subsequent transactions (using the token) can be done through PayU or any other payment processor.
For sample request and response, refer to Model 2-Zero Code Change.
The repeat transaction flow involves the following steps:
- Get the saved card details (as described in the Get User Cards API section)
- Process the transaction with a saved card
The following figure illustrates the workflow for the repeat transaction workflow:
The steps involved in creating token after processing payment workflow:
- Merchant calls PayU with get cards API by passing the user credential
- Customer selects the card on which they want to do transaction with
- Merchant Initiates transaction and sends the request to PayU
- PayU processes the transaction and sends the transaction status to the merchant
If you have not received a response from PayU with First-Time Payment Workflow, use the get_user_card API as described in Get User Cards API
|varchar It contains the merchant ID and a unique customer identifier. In this example, the user credentials that you submitted with the var1 parameter using the save_user_cards API.||a:b|
|store_card_token||varchar It is the card token for a card that is returned by PayU when you store a card. When you store a card using the save_user_cards API, the response from PayU contains the card token value in the cardToken parameter.||57cb996f2eaeee525765a|
optional for PayU token flow
|integer This parameter can be posted with the value as 0 as you are using PayU token hub.||0|
Only the fields needed for this operation are mentioned here. For the complete API details of the _payment API, refer to Collect Payments using Merchant Hosted Checkout.
PayU will return the response (unformatted) similar to the following on the surl specified using _payment API:
Updated 1 day ago