RDP Hosted and Direct Tokenization API

Overview

Description and Technical Requirement

‘Hosted’ and ‘Direct’ tokenization API provide the capability to safely replace or substitute sensitive card detail information or data with a unique random number or identification or token that cannot be mathematically reversed. In return merchants can provide smoother payment flow to customers, with less number of steps to get successful payment. One of the other big benefits that merchant might have is the fact that they do not need to store and handle sensitive data such as card details which it might require them to do special and tight security setup; nonetheless the rigorous process of having to be compliant.

So below are the benefits of using ‘Hosted’ and ‘Direct’ tokenization API:

  • Tokenization eliminates the need for merchants, and e-commerce sites to store sensitive payment card data on their networks. For this purpose, RDP will be the one who stores sensitive cardholder data for the payment process purpose.
  • Merchant can provide smoother and less steps of payment flow to customers, since customers will not need to fill in all card details during the payment process.
  • Merchant might not need to do those rigorous processes to be compliant of payment industry standard (only applicable to hosted tokenization API).
  • Merchant might have an ability to do post payment option.

Beside those benefits previously mentioned, the following are those benefits for using hosted tokenization API:

  • Merchant might not need to create and maintain their own payment page.
  • Merchant might pass the credit-card detail process to RDP payment gateway, to avoid the rigorous requirements or compliance of payment standard, such as PCI DSS.
  • Merchant should be able to receive any features and UI/UX updates instantly.

While, below are those benefits or advantages for using direct tokenization API:

  • Merchant can have full control of the customer’s checkout experience and their own branding elements; including having their own customized merchant’s tokenization page.
  • Merchant might have full control to store or share order or customer data.

Some requirements for hosted and direct tokenization API:

  • For hosted and direct tokenization API, RDP server will be only allowing connection via TLS 1.2 or above.
  • For direct tokenization API, merchant must comply with payment standard industry, such as PCI-DSS.
  • Direct tokenization API will only be available for some certain payment channels.

Hosted Tokenization API Process Flow

Hosted tokenization API consisted of some several steps, as mentioned below:

  1. First Phase: Merchant Request Tokenization Page URL Construction.
    Through a server to server communication; merchant send a request message to RDP
    payment gateway server to construct a tokenization page. RDP payment gateway will then
    generate an accustomed tokenization page URL to merchant.
    This tokenization page is attached with a specific session key where it will be destroyed or becomes invalid for the following reasons:

    • Expired, which is by default after 24 hours of creation the session, it will be destroyed
      (configurable).
    • Has been communicated to the bank or acquirer tokenization system.
    • Cardholders press the “Back” button on the tokenization page and returns to the
      merchant site.

    By the end of a successful first request a merchant shall received a tokenization URL.

    Merchant sends request for tokenization page URL construction.

    Fig 3-1. Merchant sends request for tokenization page URL construction.

  2. Merchant redirects customers to the generated tokenization page URL.
    The URL given in step-1 is used as a target of redirection, bringing the cardholder to RDP
    tokenization page where customer will be able to enter their card details to be tokenized.

    Merchant's customer is redirected to RDP hosted tokenization page URL.

    Fig 3-2. Merchant’s customer is redirected to RDP hosted tokenization page URL.

  3. Cardholders enter their credit card details.
    This activity is done within RDP secure tokenization-page.

    1. Cardholder press “Back” button.
      RDP redirects the Cardholder back to merchant’s site (the URL is given as a part of
      parameter in the step 1, called back_url). [end of flow]
    2. Cardholder press “Submit” button.
      RDP process and send the complete information to the bank or acquirer tokenization
      system.
  4. RDP payment gateway processes and if necessary will send the complete card information to bank or acquirer tokenization system.

    RDP process and send the complete information to respective bank or acquirer tokenization system.

    Fig 3-3. RDP process and send the complete information to respective bank or acquirer tokenization system.

  5. Bank or acquirer tokenization system returns the result back to RDP.
  6. RDP payment gateway sends the tokenization result.
    There are two channels on how RDP tell Merchant about the tokenization result. The order
    of channel arrived is not guaranteed. Push Notification is the most reliable one, as it is
    independent of cardholder’s browser situations.

    • RDP payment gateway sends a ‘Push Notification’ message.
      This is a direct communication to the Merchant’s notify_url sent at step 1. RDP packs the tokenization-result in JSON format.

      RDP payment gateway sends 'Push Notification' to merchant's notification URL.

      Fig 3-4. RDP payment gateway sends ‘Push Notification’ to merchant’s notification URL.

    • RDP payment gateway redirects cardholder back to merchant site.
      The target of redirection is redirect_url sent at step 1. RDP attaches a GET parameter
      called transaction_id. The following is the steps to handle the redirection information.

      • Merchant do server-to-server request for tokenization Result.
        Using the transaction_id from redirection and mid (merchant identification number,
        given when a merchant account is setup by RDP) Merchant do a direct query on the
        complete result. RDP returns a JSON formatted results. This ensures that the complete
        results can be filtered by merchant before being sent to cardholder.

        Merchant do transaction query to RDP payment gateway.

        Fig 3-5. Merchant do transaction query to RDP payment gateway.

Direct Tokenization API (DITAPI) Process Flow

For ‘Direct Tokenization API’, it consists of some several steps flow, as explained below:

  1. Merchant’s customers enter their card detail in merchant’s page.
    In order to tokenize the card, merchants ask their customers to enter their card details and
    some more additional info inside merchant’s page, followed by customers clicking the
    ‘Submit’ button.

    Customers enter their credit card details in merchant's page.

    Fig 3-6. Customers enter their credit card details in merchant’s page.

  2. Merchant send a request message to RDP payment gateway.
    Through a server-to-server communication; merchant prepares and send a request message
    to RDP payment gateway server in JSON format to tokenize customer’s card detail.

    Merchant send request message to RDP to tokenize customer's card detail.

    Fig 3-7. Merchant send request message to RDP to tokenize customer’s card detail.

    In sending the transaction request, merchant sends the corresponding transactions request
    to RDP’s service end-point by allocating the JSON formatted transaction request inside the
    BODY of its HTTP(S) request.

    Note:
    After merchants send the transaction request to RDP’s service end point, they will need to
    wait for a direct response from RDP payment gateway.

  3. RDP payment gateway processes those card details and send the complete card information to bank or acquirer system through a secure connection.

    RDP process and send the complete Information to respective bank or acquirer system.

    Fig 3-8. RDP process and send the complete Information to respective bank or acquirer system.

  4. Bank or acquirer tokenization system returns the result back to RDP payment gateway.
  5. RDP payment gateway sends the tokenization result to merchant system.
    At last RDP payment gateway will send the tokenization result to merchant system through
    a server-to-server communication in JSON formatted response.
    By the end of this step or process, merchant should already receive token ID for their
    customers.
  6. Retrieving transaction results.
    In the case where there is a timeout happened during transaction or somehow the
    transaction is under pending status (‘response_code’ is equal to ‘-01’ under response message), merchant can actually retrieve the transaction status through several methods as follow:

    • Via notification result that is sent by RDP payment gateway (only applicable when the
      ‘notify_url‘ parameter is sent inside the request message. Please refer to chapter 6 for further information.
    • Via query phase that similar to the hosted tokenization redirection result under chapter 7.
      The process flow is almost similar with the hosted tokenization API redirection result
      process flow under chapter 7.3 (step 3 onwards), with a small difference where under DITAPI, merchant is getting the ID of transaction (‘transaction_id’ parameter) from the response parameters (please refer to chapter 8.3 for further reference about response parameters).
      Note:
      For those merchants who are configured with the enforcement of unique transaction
      order ID, they can use their order ID as the transaction ID for the transaction query.

      DITAPI transaction process flow summary.

      Fig 3-9. DITAPI transaction process flow summary.