Real-Time Recurring Credit Card (Enterprise API)

This page serves as a supplementary guide for integrating Real-Time Recurring Credit Card transaction payment into the payment flow and is to be read in conjunction with the PayU Enterprise API integration documentation.

Overview

PayU Real-Time Recurring (RTR) transaction processing is a card processing solution where the merchant is allowed to deduct specified amounts from a card holder's account as agreed between card holder and merchant without the card holder initiating the actual transaction. Real-Time Recurring (RTR) Credit Card transaction solution is available on the PayU payment system via both the API and responsive channel through tokenised enterprise API integration. API channel due for release last quarter of 2015 with redirect following shortly during first quarter 2016. Please consult with PayU Sales for more information.

Real-Time recurring transactions are set-up by providing full card data (Card holder provide during agreement process) for transaction authorisation initially and on subsequent transactions only the card number is required to authorise payment to the merchant. To assist Enterprise merchants in reducing PCI exposure with API integrations PayU offers RTR as a tokenised payment solution. The card details will be encrypted by PayU and stored in a token which should be stored against a merchant user profile for future recurring transactions. Future transactions can happen via administrative process or on-line transactions where card holder launch payment process.

Merchants using Real-Time Recurring transactions are always liability for charge-backs from issuers. For some chargeback risk reduction Real-Time Recurring transactions can be paired with eCommerce transactions with Secure 3D during the setup transaction. More details below on the flows. Enterprise merchants needs to manage the flow, for redirect merchants PayU will ensure correct flow is applied based on transaction perimeters.

Merchant Requirement

Merchant will need to have the following in place before attempting Real-Time Recurring integration. 

  • User profile system with secure login process for merchant users.
  • Capabilities to store one or more PayU created payment tokens against user profiles.
  • UI with some processing intelligence to make decisions on:
    • displaying card capture for new users or users without tokenised cards.
    • ability to add new card to be tokenised against user profile
    • Ability to display a list of one or more tokenised cards for payment selection.
  • Back-end processing capability to process recurring subscription transactions.

Additional considerations:

For Enterprise Integration: As card holder data is captured on the merchant's hosted pages the merchant needs to be PCI compliant to the level required by the acquiring bank and PCI-DSS guidelines. Merchants do not need to save sensitive card holder information. The merchant needs to be able to save the token value returned in the API response against the user profile to re-use for future payment requests.

For Redirect Integration: No sensitive card holder data will be exposed to the merchant, all card capturing happens at PayU. The merchant can still process back-end transactions via Enterprise API by making use of the tokens.

To ensure integration is a smooth process please ensure that integration is first completed and tested on the PayU Staging platform before switching to production.

doTransaction amendments for Real-Time Recurring Credit Card Transactions (RTR)

Setup Call: No token exist at this time.

Merchants will need to make the following amendments to the normal doTransaction API call in order to do Real-Time Recurring Credit Card transactions with and without tokens on the PayU platform. All credit card details are required during setup. 

  • AuthenticationType = TOKEN
  • storePaymentMethod = TRUE
  • merchantUserId = Identifying value at merchant

  • Customfield

    • key = processingType

    • value = REAL_TIME_RECURRING

 

Request items to consider
<AuthenticationType>TOKEN</AuthenticationType>
<AdditionalInformation>
  <storePaymentMethod>true</storePaymentMethod>
</AdditionalInformation>

<Customer>
  <merchantUserId>123</merchantUserId>
  <regionalId>123456</regionalId>
  <countryCode>27</countryCode>
</Customer>
 
<Customfield>
  <key>processingType</key>
  <value>REAL_TIME_RECURRING</value>
</Customfield>

 

ResponseToken created and returned by PayU on successful transaction completion.

  • pmId = This value needs to be associated with merchantUserId and used for Enterprise payments. (Back-end Real-Time recurring transactions)
  • cardExpiry = Store this value to ensure recurring transactions are not requested beyond expiry date of card
  • cardNumber = Purely used by merchants for statistical reasons and UI selection

 

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

 

Additional payments: Tokens exist and used in place of credit card values. No expiry or CVV required. 

  • AuthenticationType = TOKEN
  • merchantUserId = Identifying value at merchant

  • CreditCard
    • pmId = Token representing the card. For additional recurring transactions this can be send without a CVV value in the tags. The tags are required.
  • 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:

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)

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)

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)

 

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)

 

API call examples

Please refer to the doTransaction API example page for more information