RDP Merchant API

Overview

Description and Requirements

Red Dot Payment (RDP)’s Merchant API (MAPI) provides the capability for merchant to perform capture, pre-authorization, refund, or void to transactions. Through this API, RDP is providing these following functions:

• Capture (Settlement) transaction
  This is a follow-up transaction for a pre-authorization transaction that formerly triggered either through ‘RDP Direct Payment API 2.0’ or ‘RDP Connect API’. When a certain amount of card-holder’s account is already blocked by pre-authorization, the amount can later be captured or settled to merchant’s account within a certain valid period. The valid period varies per bank or acquirer.
  The final result of the capture or settlement transaction is similar to sale (auto-captured) transactions that formerly also triggered either through ‘RDP Direct Payment API 2.0’ or ‘RDP Connect API’. Regarding to the settlement timing, it is also varied according to different banks or acquirers.
  Transactions that are applicable to pre-authorization and capture scenario has the flexibility to capture partial amount instead of the original full amount, but this is still dependent on banks or acquirers’ regulation. Some financial institutions might only allow the full amount to be captured and settled.
• Refund transaction
  Refund transaction is a type of transaction to cancel previous captured or settled transaction, where it will transfer back the fund or money from merchant’s account to the customer’s account. In other words, refund transactions are always associated with those transactions that has been settled or captured where the money or funds have already been transferred from the customer’s account to merchant’s account.
  The process of transferring the fund or money itself might take a couple of days, subjected to the acquirer or bank.
  The availability or capability for doing refund transaction is highly dependent on the capability of bank or acquirer.
• Void transaction
  Void transaction is another transaction type that cancels the original pre (authorization) or sale transaction. But it differs from refund transaction, where those original transactions can only be voided if they have not been captured or settled yet. So under this circumstance, no money or fund is ever actually being transferred from customer’s account to merchant’s account.
  And similar to refund transaction, the availability or capability for doing void transaction is also highly dependent on the capability of bank or acquirer.
  At the very minimum, merchant system must be able to do these following things in order to be linked properly to the RDP payment gateway:
  • Merchant’s system must pass all of those required or mandatory parameters to RDP
    payment gateway.
  • Any other fields, such as customer name, address, etc must be stored in merchant system
    and retrievable via the ‘Order Number’ and ‘Transaction ID’ field that will be passed back to
    merchant system.
  • Merchant system must be also able to calculate and/or generate the transaction signature
    as part of data integrity measurement for transaction request and response interface
    between their website and RDP payment gateway.

RDP server only allows connection via TLS 1.2 or above.

Merchant API Process Flow

Merchant API consists of some several steps, as mentioned or explained below:

1. Merchant system sends transaction request to RDP payment gateway.
   Through a direct server to server communication; merchant system sends a transaction
   request message to RDP payment gateway.
2. RDP payment gateway processes the transaction request and sends the transaction
   information to the bank or acquirer system; followed by returning the transaction result
   back to RDP payment gateway.
3. RDP send the transaction result back to merchant system.

   

   Fig 3-1. Merchant API process flow.