Page Comparison

...

Merchants will need to make the following amendments to the normal setTransaction API call in order to do Real-Time Recurring Credit Card transactions with and without tokens on the PayU platform.  

• AuthenticationType Secure3d= TOKENTRUE/FALSE
• storePaymentMethod SupportedPaymentMethods= TRUE CREDITCARD_TOKEN

• merchantUserId = Identifying value at merchant

• Customfield

  • key = processingType

  • value = REAL_TIME_RECURRING

...

<AuthenticationType>TOKEN<<Secure3d>true</AuthenticationType>Secure3d>
 
<AdditionalInformation>
  <storePaymentMethod>true</storePaymentMethod>
</AdditionalInformation><SupportedPaymentMethods>CREDITCARD_TOKEN</SupportedPaymentMethods>
 
<Customer><Customer FirstName="John"  <merchantUserId>123</merchantUserId>
  <regionalId>123456</regionalId>
  <countryCode>27</countryCode>
</Customer>
LastName="Doe" CountryCode="27" Mobile="27999220020" MerchantUserId="Merch000001"/>
 
<Customfield>
  <key>processingType</key>
  <value>REAL_TIME_RECURRING</value>
</Customfield>

Response: Token created and returned by PayU on successful transaction completion in IPN.

• pmId = This value needs to be associated with merchantUserId and used for both redirect and enterprise payments. (Back-end Real-Time recurring subscription type transactions)
• cardExpiry = Store this value to ensure recurring transactions are not requested beyond expiry date of card. (Back-end Real-Time recurring subscription type transactions)

<pmId>C113C08A96F9E1177DB441EAB08DC046</pmId>
<cardExpiry>102018</cardExpiry>
<cardNumber>403822******8021</cardNumber>

Additional payments: Tokens exist and used in setTransaction. 

• AuthenticationType = TOKEN

• merchantUserId = Identifying value at merchant

• CreditCard
  • pmId = Token representing the card. 

• Customfield

  • key = processingType

  • value = REAL_TIME_RECURRING

<AuthenticationType>TOKEN</AuthenticationType>

 
<Customer>
  <merchantUserId>123</merchantUserId>
  <regionalId>123456</regionalId>
  <countryCode>27</countryCode>
</Customer>
 
<Creditcard>
  <amountInCents>1000</amountInCents>
  <pmId>f1VnURZ/QBV6FVVpJhBgVGdVEHFFDANFFBAWNj5RZkkRekQQehJec1xke1Fl</pmId>
  <cvv></cvv>
</Creditcard>
<Customfield>
  <key>processingType</key>
  <value>REAL_TIME_RECURRING</value>
</Customfield>

Integration payment sequence/flow

When developing a solution with PayU's Enterprise API some de-risking of transactions can be done be performing a transaction.

Set-up flow with Secure 3D de-risking:

Image Removed

Real-time recurring transaction chargeback risk is with the merchant. In order to validate card holder and de-risk the recurring transaction a normal eCommerce transaction can be done prior to a recurring set-up transaction. 

• Step 1
  • Ensure a secure user profile management system is in place that can:
    • Store one or more payment tokens against the user.
    • Store the masked card number and expiry date as returned from PayU in the transaction response.
    • Able to return the stored token in follow up recurring transactions to PayU.
  • Display terms and conditions plus inform that card will be saved securely for recurring transactions.
• Step 2
  • During checkout process the merchant website needs to:
    • Retrieve all stored tokens with masked card numbers and expiry dates to allow user to select a card to transact with.
      • If no token found then display payment capture form.
      • or if tokens are present allow user to add another card to transact against. 
      • if tokens are found refer to "Transactions beyond set-up "below".
• Step 3
  • Send a eCommerce doTransaction API call to PayU as per selected criteria of step 2 for amount required.
  • Handle Secure 3D redirect if card is enrolled for Secure 3D.
• Step 4
  • On completion of eCommerce transaction leg store payment token issued by PayU against the merchant user profile.
• Step 5
  • Next perform a recurring set-up transaction for a zero amount using the token details as returned in the eCommerce leg plus CVV.
• Step 6
  • Update transaction database with the transaction lookup response from PayU. (getTransaction or IPN)
• Step 7
  • Display the transaction result to the user.

Set-up flow without any de-risk (Fraud checks can be added)

Image Removed

Real-time recurring transaction chargeback risk is with the merchant. In this flow the merchant might perform other fraud check and do not have the requirement for additional de-risking.

• Step 1
  • Ensure a secure user profile management system is in place that can:
    • Store one or more payment tokens against the user.
    • Store the masked card number and expiry date as returned from PayU in the transaction response.
    • Able to return the stored token in follow up recurring transactions to PayU.
  • Display terms and conditions plus inform that card will be saved securely for recurring transactions.
• Step 2
  • During checkout process the merchant website needs to:
    • Retrieve all stored tokens with masked card numbers and expiry dates to allow user to select a card to transact with.
      • If no token found then display payment capture form.
      • or if tokens are present allow user to add another card to transact against. 
      • if tokens are found refer to "Transactions beyond set-up "below".
• Step 3
  • Send recurring set-up transaction for the required amount using the card number, expiry date, and CVV.
• Step 4
  • On completion of recurring transaction store payment token issued by PayU against the merchant user profile.
• Step 5
  • Update transaction database with the transaction lookup response from PayU. (getTransaction or IPN)
• Step 6
  • Display the transaction result to the user.

Transaction flow for recurring transactions beyond set-up (Front end - user driven)

Image Removed

This flow allows the merchant to enable a quick checkout experience by sending a token to PayU for a recurring transaction. The user needs to provide permission for a quick checkout via recurring transaction and the merchant accepts all fraud related transaction charge backs.

• Step 1
  • Merchant user logged into Merchant user management system
• Step 2
  • User selects an existing card from options presented
  • Merchant match token to payment method selected
• Step 3
  • Merchant submits recurring doTransaction call to PayU with token and amount. (No CVV required)
• Step 4
  • Update transaction database with the transaction lookup response from PayU. (getTransaction or IPN)
• Step 5
  • Display the transaction result to the user.

Transaction flow for recurring transactions beyond set-up (Back-end - subscriptions not user driven)

 Image Removed

This flow is for an administrative process to which the card holder agreed to regular system initiated payments. For example subscriptions.

• Step 1
  • Merchant subscription system selects user token to perform transaction against
• Step 2
  • Merchant subscription system send recurring doTransaction call with token and amount to PayU
• Step 3
  • Update transaction database with the transaction response from PayU. (getTransaction or IPN)

<Customfield Key="processingType" Value="REAL_TIME_RECURRING"/>
</Customfield>

...

API call examples

Please refer to the doTransaction setTransaction API example page for more information