RDP Redirect API

Overview

Redirect Payment API Service Function

Redirect Payment API is supporting these following transaction service functions:

Payment (Pre) Authorisation Transaction
The availability of this function depends on the capability of the bank and/or acquirer.
‘(Pre) Authorization’ transaction will be normally only confirm the cardholder’s ability to pay, ensuring that the customer’s credit card account is in good standing with sufficient funds to complete the purchase. The transaction amount will be reserved on the customer’s credit card but will not be charged yet until merchant is doing capture or settlement process. This method is mostly used by merchants who have a delayed in order fulfilment process.Since there might be a delay in charging the customer, this payment or transaction type might not be applicable to digital wallet payment service, such as AliPay, DBS PayLah!, WeChat, etc.
Payment Sale Transaction
‘Sale’ transaction will combine the (pre) authorization and auto capture (settlement) process, in order to fulfil the order immediately, where issuing bank will straight away charge customer for their order. Credit card associations require merchants to submit a sale transaction request when they fulfil an order immediately.

Payment page screen on Redirect Payment API - desktop interface.

Fig 3-1. Payment page screen on Redirect Payment API – desktop interface.

Payment page screen on Redirect Payment API - mobile interface.

Fig 3-2. Payment page screen on Redirect Payment API – mobile interface.

Description and Technical Requirement

Redirect API (RAPI) is Red Dot Payment (RDP) web service that’s handling payment service with the payment page can be either managed by third party processor or payment gateway, such as Red Dot Payment (Hosted Order Page – HOP mode), or managed and handled by the merchant itself (Silent Order Page – SOP mode).

The following are those benefits for using Redirect Payment API HOP mode:

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 Redirect Payment API SOP mode:

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

Some requirements for Redirect Payment API (RAPI):

For this Redirect Payment API (RAPI), RDP server will be only allowing connection via TLS 1.2 or above.
For ‘Silent Order Page (SOP)’ mode, merchant must comply with payment standard industry, such as PCI-DSS.
Silent Order Page (SOP) mode will only be available for some certain payment channels.

iFrame Limitations on Redirect Payment API (RAPI)

Alternative payments, such as Alipay and China Union Pay don’t work on iFrame.
Very difficult to support or troubleshoot iFrame related issues, and RDP may not be able to advise.
Security vulnerability concerns when iFrame is used, such as Cross Frame Scripting Software Attack.

RDP heavily discourages iFrame to be used for Redirect Payment API.
You will bear the risks for any issues and problems encountered on iFrame.

Redirect Payment API Process Flow

The process flow for ‘Redirect Payment API’ is differentiated or distinguished into 2 flows, depends on who host or own the payment page. And those 2 process flows are mentioned or elaborated below.

Process Flow for Redirect Payment API Hosted Order Page (HOP)

The process flow for Redirect Payment API Hosted Order Page (HOP) consists of these several
steps below:

First Phase: merchant send request for payment page URL construction.
Through a server to server communication, merchant send a request message to RDP payment gateway server to construct a payment page URL. RDP payment gateway will then generate an accustomed payment page URL to merchant.
This payment 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 / acquirer.
- Cardholders press “back” button on the payment page and returns to the merchant site.
By the end of a successful first request, merchant shall receive a payment page URL.

Fig 3-3. Merchant send request for payment page URL construction in first phase.
Merchant redirect customer to the generated payment page URL.
The URL given in step 1 is used as target of redirection, bringing the cardholder to RDP payment page.

Fig 3-4. Merchant’s customer is redirected to RDP hosted payment page URL
Cardholders enter their card details inside RDP secure payment page.
There are 2 possible activities are done within RDP secure payment-page, as follow:
1. Cardholders press the “Back” button.
  For this, RDP will redirect cardholders back to merchant’s URL website (the URL parameter that’s given as a part of one of the parameter in the step 1, called back_url).[End of flow]
2. Cardholders press the “Pay” button.
  RDP will process and send the card detail and payment information to the respective bank or acquirer. During this process, the cardholders might need to enter their OTP (One Time Password) to go for further process.
RDP process and send the complete payment Information to respective bank or acquirer.
As mentioned above, during this process, the cardholders might need to enter their OTP(One Time Password) to go for further process.

Fig 3-5. RDP process and send the complete payment Information to respective bank or acquirer.
Bank or acquirer process the request and returns the payment or transaction result back to RDP.
RDP send the payment or transaction result to the merchant.
There are two channels on how RDP inform merchants about the payment or transaction result. The order of channel arrived is not guaranteed. Push Notification is the most reliable one, as it is independent of cardholder browser situations or connectivities.
- RDP send a Push Notification.
  This is a direct communication to the merchant’s notify_url parameter that’s sent at step 1. RDP packs the payment or transaction result in JSON format.
  
  Fig 3-6. RDP payment gateway sends ‘Push Notification’ to merchant’s notification URL.
- RDP redirects cardholder back to merchant URL website.
  The target of this redirection is the redirect_url parameter that’s sent at step 1. RDP also attaches a parameter called transaction_id. Below are the step to handle a redirection information.
  - Merchant do server-to-server request for Payment 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 transaction status. RDP will then send a response in a JSON formatted message. This step will ensure that the complete transaction result can be filtered first by merchant before being sent to cardholder.
    
    Fig 3-7. Merchant do transaction query to RDP payment gateway.

Process Flow for Redirect Payment API Silent Order Page (SOP)

The process flow for Redirect Payment API Silent Order Page (SOP) consists of these several steps below:

Merchant’s customers proceeds with payment and enter their card detail in merchant’s payment page.
When merchant’s customers proceed with payment, they are entering their card details inside merchant’s payment page, before they click the ‘Pay’ or ‘Submit’ button.

Fig 3-8. Customers enter their credit card details in merchant’s payment page.
First Phase: merchant send request for payment process URL construction together with card details.
Through a server to server communication, merchant send a request message RDP payment gateway server together with card detail information that previously entered by customer or cardholders, in order to construct a payment page URL. RDP payment gateway will then process the request and generate an accustomed payment process URL to merchant.
This payment URL 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.
By the end of a successful first request, merchant shall receive a payment URL.

Fig 3-9. Merchant send request for payment URL together with customer’s card details.
Merchant redirect customer to the generated payment URL.
The URL given in step 2 is used as target of redirection, bringing the cardholder for payment process. RDP will then process and send the complete payment information to respective bank or acquirer (Figure 3.5). During this process, the cardholders might need to enter their OTP (One Time Password) to go for further process.
Bank or acquirer process the request and returns the payment or transaction result back to RDP.
RDP send the payment or transaction result to the merchant.
There are two channels on how RDP inform merchants about the payment or transaction result. The order of channel arrived is not guaranteed. Push Notification is the most reliable one, as it is independent of cardholder browser situations or connectivities.
- RDP send a Push Notification.
  This is a direct communication to the merchant’s notify_url parameter that’s sent at step 1. RDP packs the payment or transaction result in JSON format (Figure 3.6).
- RDP redirects cardholder back to merchant URL website.
  The target of this redirection is the redirect_url parameter that’s sent at step 2. RDP also attaches a parameter called transaction_id. Below are the step to handle a redirection information.
  - Merchant do server-to-server request for Payment 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 transaction status. RDP will then send a response in a JSON formatted message. This step will ensure that the complete transaction result can be filtered first by merchant before being sent to cardholder. Please refer to figure 3.7.