Dragonpay Online Payment

Merchant Payment Switch API

Version 0.16 – 28 May 28, 2014

Table of Contents
Table of Contents .............................................................................................2
1. About this Document ....................................................................................3
2. Intended Audience........................................................................................3
3. Change Log .................................................................................................3
4. Introduction.................................................................................................4
4.1 What is online bank debit payment? ...........................................................4
4.2 How does online bank debit payment work? ................................................6
5. Payment Switch API......................................................................................8
5.1 System Requirements ..............................................................................8
5.2 Message Passing (Merchant ->PS and PS->Merchant) ..................................8
5.2.1 Name-Value Pair Model .......................................................................8
5.2.1.1 Request Parameters.........................................................................9
5.2.1.2 Response Parameters.....................................................................10
5.2.2 SOAP/XML Web Service Model............................................................12
5.2.2.1 Request Parameters.......................................................................12
5.2.2.2 Response Parameters.....................................................................13
5.3 Additional Support Functions ...................................................................14
5.3.1 Transaction Status Inquiry.................................................................14
5.3.1.1 Request Parameters using Name-Value Pair ......................................14
5.3.1.2 Response Parameters using Name-Value Pair ....................................14
5.3.1.3 Request Parameters using XML Web Service .....................................15
5.3.1.4 Response Parameters using XML Web Service ...................................15
5.3.2 Cancellation of Transaction ................................................................16
5.3.2.1 Request Parameters using Name-Value Pair ......................................16
5.3.2.2 Response Parameters using Name-Value Pair ....................................16
5.3.2.3 Request Parameters using XML Web Service .....................................17
5.3.2.4 Response Parameters using XML Web Service ...................................17
5.3.3 Sending of Billing Information ............................................................18
5.3.3.1 Request Parameters using XML Web Service .....................................18
5.3.3.2 Response Parameters using XML Web Service ...................................18
5.3.4 Controlling the Payment Channels Selection Page.................................19
5.3.4.1 Filtering Payment Channels.............................................................19
5.3.4.2 Pre-selecting Payment Channels ......................................................19
Appendix 1 – Currency Codes ..........................................................................21
Appendix 2 – Error Codes................................................................................22
Appendix 3 – Status Codes..............................................................................23

2
1. About this Document
This document describes the Application Programming Interface (API) between
Payment Switch (PS) and the Merchant’s e-commerce website. The PS is responsible
for communicating with the financial partner’s (eg. Bank) payment gateway for
payment requests using a separate API. Upon validating the request, it redirects the
end-user to his funding source of choice. The information needed by the PS to
process a merchant payment for a transaction is transmitted using the API described
in this document.

This document provides an overall introduction to the system, including its general
architecture and structure. It then goes into detail on how to actually implement the
system.

If you have any questions please do not hesitate to contact sales@dragonpay.ph.

2. Intended Audience
The intended audience for this document is technical personnel or programmers with
background knowledge of programming and e-commerce. The examples in this
document are written in Microsoft C# .NET. However, the programmer is free to
implement the interfaces using other programming languages as long as they
conform to Web standards such as HTTP GET, Name-Value Pair, and SOAP/XML Web
Services calls.

3. Change Log
Version Date Changes
0.10 May 25, 2010 Alpha Version
0.11 June 28, 2010 Added email as required parameter
0.12 Aug 9, 2010 Changed merchant txnid to varchar(40)
Updated URL’s to api.dragonpay.ph
0.13 Nov 21, 2012 Added support for optional ‘param1’ and ‘param2’
Documented MerchantRequest.aspx
Added SendBillingInfo web method
0.14 Dec 9, 2012 Changed server name from ‘api’ to ‘secure’
0.15 Jan 25, 2013 Corrected 2nd parameter of SendBillingInfo
0.16 May 28, 2014 Changed live server from ‘secure’ to ‘gw’
Added Section 5.3.4

3
4. Introduction
E-commerce is gaining more and more acceptance by the general public each day.
Its full potential, however, is hampered by the lack of available online payment
options. While credit card remains to be the most popular online payment option,
most consumers shy away from it for fear of getting their card information
compromised. Online merchants are also very wary of credit cards because of high
fraud rate. And for those selling high-ticket items, the percentage-based fee
structure of credit cards is not appealing. Furthermore, only a small percentage of
the population has access to credit cards because of credit history requirements.

Online bank debit payment presents a very effective alternative to this dilemma.
Opening a bank account is certainly simpler than opening a credit card account. This
presents a larger potential customer base to online merchants. The online banking
interface is also inherently more secure than the usual credit card interface. This
gives assurance to the customer that the transaction is safe. And because there is
no concept of chargebacks with debit payments, merchants are also assured of
payments for their products or services.

4.1 What is online bank debit payment?

In a typical online banking session, bank customers can perform basic functions such
as balance inquiry, bills payment, checkbook reorder, and funds transfer remotely
from their homes or offices. The bank’s online interface is simply accessed using a
web browser over a secure channel (https).

Traditional E-Banking

Balance Inquiry,
Bills Payment,
Etc.

4
Under this scenario, the bank’s system assumes that it is transacting with a live
person. It responds to the requests sent by the bank customer over the browser.
These requests are made by navigating through the web interface’s menu system
and by filling up on-screen forms.

Online banking systems are normally not designed to work with e-commerce
merchants or online stores which require machine-to-machine communication. They
do not have the capability to accept requests programmatically from 3rd party
websites or applications (ex. Shopping cart systems) for debiting the bank account of
a particular customer. Subsequently, online banking systems also do not have the
capability to communicate with a 3rd party system to inform it if a payment was done
successfully or not.

Because of these limitations, it is currently impossible for online merchants to bill

customers using their bank accounts in an automated, single-flow process.
Merchants normally resort to off-line means such as asking the customer to deposit
to their bank account over-the-counter and fax them the deposit slip as proof of
payment. This makes it impossible to do e-commerce which require real-time
responses (ex. airline ticketing, digital downloads). For merchants with high-volume
transactions, the manual validation of deposit slips is also not a scalable solution.

PS seeks to address the problem by providing a “wrapper” interface to the online

banking system. This will provide 3rd party online store applications with a
programmatic interface to request for payments from the customer’s bank, and for
the bank to provide real-time feedback or confirmation if the payment was successful
or not. In doing so, PS can enable any existing online banking platform to provide e-
commerce functionality without or with very little changes, if any.

E-Commerce Enabled
Online
shopping

Web
payment
request
Real-time
E-Banking
login payment
E-Commerce Wrapper
confirmation
credentials

5
PS will also perform the role of a traffic cop. It will route the payment request to the
appropriate bank chosen by the customer. It will accept payments from the
customer in behalf of the merchant, and it will settle with the merchants on a
scheduled basis.

Multi-Bank/Merchant Model
Merchant #1 Merchant #2 Merchant #3

Shop

Request for bank payment

E-banking login credential Switch

E-Commerce Wrapper E-Commerce Wrapper E-Commerce Wrapper

E-C

Bank #1 Bank #2 Bank #3

4.2 How does online bank debit payment work?

All online transactions generally follow the same pattern.

1. Customer surfs an online store

2. Customer clicks on items that he wants
3. Item is placed in an online shopping cart
4. Customer goes to Checkout
5. Customer is presented with several payment options
6. Customer clicks on the payment option he prefers
7. Payment processing is performed
8. Online shopping is completed

Where the shopping experience generally vary is in step #7. Different payment
options have different process flows. Credit card payments are usually more
straightforward – you enter your card details; click a button to confirm; and it’s
done. Most of the time, the customer does not have to leave the store’s Checkout
page.

With most other payment options (ex. PayPal, BancNet), however, the customer’s
browser is first redirected to the secure website of the payment processor. From
there, he is asked to enter his credentials (ex. PayPal account id and password,
BancNet ATM card number and PIN). When all information is entered correctly and

6
the transaction is confirmed, the customer’s browser is redirected back to the online
store (step #8) where the shopping is completed.

The PS process flow follows general convention of the other payment options. From
the Checkout page, the customer is redirected to PS and is presented with a list of
banks to choose from.

Switch Visual Interface

Customer picks his bank from the list and clicks the button to proceed. PS will then
transfer the request to the bank using the API described in this document. At this
stage, the bank will generally perform the following operations:

1. Prompt for the necessary credentials (online banking id and password)

2. Let the customer choose from a list of available bank accounts (ex. checking
account, savings account)
3. Confirm with customer if he wants to charge the transaction against his
chosen account. At this stage, some banks may perform additional
authentication (ex. prompting for a transaction password, retrieving
confirmation via SMS or email, random number generator)

When payment processing is completed, customer is sent back to the PS using the
return API described in this document.

PS keeps track of all payment transaction requests and their statuses. It talks to the
bank systems in real-time, as well as, with the merchant shopping systems. It
performs the role of the traffic cop and ensures all messages are routed to the
appropriate party.

7
5. Payment Switch API
This section of the document describes the Merchant Payment Switch (PS) API in
detail, covering the various functions used, as well as, codes that can be used to
integrate them.

5.1 System Requirements

In order to integrate with the PS, Merchant must fulfill the following prerequisites:

1. Merchant site must be capable of getting the required data from customer
(ex. amount, item description, email)
2. Merchant site can send http request data to PS system when a customer
wishes to pay the Merchant with his bank account.
3. Merchant site must have a Postback URL to accept real-time confirmation
from PS.

Each Merchant is assigned the following:

• merchant id – unique code identifying the Merchant

• secret key – a unique password assigned to Merchant for checksum validation

Production Payment URL:

https://gw.dragonpay.ph/Pay.aspx

Test Payment URL:

http://test.dragonpay.ph/Pay.aspx

Although this document uses Microsoft .NET conventions, it should be implementable

under other operating environments (ex. Linux, PHP, Perl, Java). (Note that since
this is an alpha documentation, the Postback URL’s may change in the future.)

5.2 Message Passing (Merchant ->PS and PS->Merchant)

This section describes how the merchant will pass a request to the PS system for
payment processing and vice versa. There are currently two integration models
available – the Name-Value Pair Model and the Web Services Model.

5.2.1 Name-Value Pair Model

Under the Name-Value Pair Model, Merchant sends the request parameters using
HTTP GET with a browser redirect. The PS system only needs to read and parse the
GET Query String to extract all the necessary information.

8
The PS system can check the authenticity of the request by two means:

1. It can check the URL or IP address of the HTTP Referer and make sure it
belongs to the Merchant.
2. It can use its secret key to compute for the message digest based on the
parameters passed and compare it against the passed digest. If the
computed digest does not match, then it should reject the transaction as the
parameters have most likely been compromised.

5.2.1.1 Request Parameters

These are the parameters passed by the Merchant to the PS via name-value pairs to request
for a payment.

Parameter Data Type Description

merchantid Varchar(20) A unique code assigned to Merchant
txnid Varchar(40) A unique id identifying this specific transaction
from the merchant side
amount Numeric(12,2) The amount to get from the end-user (XXXX.XX)
ccy Char(3) The currency of the amount (see Appendix 1)
description Varchar(128) A brief description of what the payment is for
email Varchar(40) email address of customer
digest Char(40) A sha1 checksum digest of all the parameters
along with the secret key.
param1 Varchar(80) [OPTIONAL] value that will be posted back to
merchant url when completed
param2 Varchar(80) [OPTIONAL] value that will be posted back to
merchant url when completed

An HTTP GET to PS may look something like this:

https://gw.dragonpay.ph/Pay.aspx?merchantid=ABC&txnid=12345678&amount=1000.00&
ccy=PHP&description=Box+of+Chocolates&digest=a4b3d08462......

The digest is computed using the SHA1 algorithm. Below is a sample code showing
how to generate SHA1 using C# .NET:

public static string GetSHA1Digest(string message)

{
byte[] data = System.Text.Encoding.ASCII.GetBytes(message);

System.Security.Cryptography.SHA1 sha1 = new

System.Security.Cryptography.SHA1CryptoServiceProvider();
byte[] result = sha1.ComputeHash(data);

System.Text.StringBuilder sb = new System.Text.StringBuilder();

for(int i=0; i<result.Length; i++)
sb.Append(result[i].ToString("X2"));

return sb.ToString().ToLower();
}

9
The message string is built by just concatenating all the required parameters with
the assigned secret key and using the colon symbol for delimiter.

string message = String.Format("{0}:{1}:{2}:{3}:{4}:{5}:{6}",

merchantId,
txnId,
amount.ToString("#0.00"),
currency,
description,
email,
Application["secretkey"].ToString());

String digest = GetSHA1Digest(message);

String redirectString =
String.Format("{0}?merchantid={1}&txnid={2}&amount={3}&ccy={4}" +
"description={5}&email={6}&digest={7}",
paymentSwitchUrl,
merchantId,
txnId,
amount.ToString("#0.00"),
currency,
Server.UrlEncode(description),
Server.UrlEncode(email),
digest);

// send browser to Payment Switch

Response.Redirect(redirectString, true);

5.2.1.2 Response Parameters

When payment processing has completed, the PS should redirect back the
customer’s browser to the Merchant’s registered callback URL’s and pass along the
parameters below.

Parameter Description
txnid A unique id identifying this specific transaction from the
merchant side
refno A common reference number identifying this specific transaction
from the PS side
status The result of the payment. Refer to Appendix 3 for codes.
message If status is SUCCESS, this should be the PG transaction
reference number. If status is FAILURE, return one of the error
codes described in Appendix 2. If status is PENDING, the
message would be a reference number to complete the funding.
digest A sha1 checksum digest of the parameters along with the secret
key.

PS recognizes two kinds of callback URL’s – the postback URL and the return URL.
The postback URL is invoked directly by the PS and does not expect any return

10
value. Because the invocation is directly done by the PS, it is very difficult to fake.
The merchant can perform additional source IP address validation to ensure it is the
PS making the call.

The return URL is passed to the customer’s browser via an HTTP redirect. The
merchant normally responds with a visual web page reply informing the customer
the status of the transaction.

It is not necessary for the merchant to implement both callback URL’s, although it is
recommended. PS will always invoke the postback URL first before the browser
redirect to the return URL. Thus, the ideal process flow is: upon receiving the
postback URL call, the merchant’s system performs the necessary database updates
and initiate whatever back-end process is required. Then when it receives the return
URL call, it counter-checks the status in the database and provides the visual
response. If merchant does not provide both callback URL’s, PS will only invoke the
one provided.

An HTTP GET from PS to either callback URL’s may look something like this:

http://www.abcstore.com/Postback.aspx?txnid=1234&refno=5678&status=S&
message=72843747212&digest=a4b3d08462......

The digest is computed using the SHA1 algorithm. Below is a sample code showing
how to generate the SHA1 digest using C# .NET:

String digest = GetSHA1Digest(String.Format("{0}:{1}:{2}:{3}:{4}",

Request[“txnid”].ToString(),
Request[“refno”].ToString(),
Request[“status”].ToString(),
Request[“message”].ToString(),
Application[“secretkey”].ToString()));

Then compare against the passed digest:

if (GetSHA1Digest(message) != Request[“digest”].ToString())
{
// display some error message and abort processing
}
else
{
// if status = ‘SUCCESS’, process customer order for shipment
}

In cases wherein the transaction status returned is PENDING, the merchant may
receive an asynchronous call to the postback URL in the future once the funding is
completed. The format will just be similar to the HTTP GET callback described
above. If a postback URL is not defined for the merchant, PS will invoke the return
URL instead. The merchant should take care in checking the status and should only
ship goods or render service when status value has become SUCCESS.

11
5.2.2 SOAP/XML Web Service Model

For greater security, the Merchant may choose to implement the API using the XML
Web Services model. Under this model, the parameters are not passed through
browser redirects which are visible to end-users. Instead, parameters are
exchanged directly between the Merchant site and PS servers through SOAP calls.

The general flow of this method is:

1. Merchant system requests for a token from the PS via SOAP

2. PS replies with a token
3. Merchant system uploads the payment information via SOAP using the token
as reference
4. Merchant system performs a browser redirect with the token as the
parameter

The advantages of using this model are:

1. Parameters are not visible on the browser

2. Merchant server is sending the parameters directly to PS thus reducing the
likelihood of 3rd party manipulation

You may use the following URL’s as the Web Service entry point. (Note that since
this is an alpha documentation, the actual URL’s may change in the future.)

Web Service Production URL:

https://secure.dragonpay.ph/DragonPayWebService/MerchantService.asmx

Web Service Test URL:

http://test.dragonpay.ph/DragonPayWebService/MerchantService.asmx

5.2.2.1 Request Parameters

These are the parameters passed by the Merchant to the PS via SOAP to request for a
token.

Web Method: GetTxnToken

Parameter Data Type Description

merchantId Varchar(20) A unique code assigned to Merchant
password Varchar(20) The password assigned to the Merchant
merchantTxnId Varchar(20) A unique id identifying this specific transaction
from the merchant side
amount Numeric(12,2) The amount to get from the end-user (XXXX.XX)
ccy Char(3) The currency of the amount (see Appendix 1)
description Varchar(128) A brief description of what the payment is for
email Varchar(40) [OPTIONAL] email address of customer
param1 Varchar(80) [OPTIONAL] value that will be posted back to
merchant url when completed

12
param2 Varchar(80) [OPTIONAL] value that will be posted back to
merchant url when completed

The GetTxnToken() method will return a tokenid string which will be used to refer to
this transaction in future Web Method calls. Note that validity of this tokenid is
limited only to at most one (1) hour. If the value of tokenid is 3-characters or less,
it must be an error code. Refer to Appendix 2 for the list of error codes. Possible
errors are incorrect merchantId or secretKey.

After posting the transaction details via SOAP, the Merchant system performs an
HTTP GET redirect with the following parameters:

Parameter Data Type Description

tokenid Varchar(40) The id returned by GetTxnToken

The code may look like this:

String redirectString =
String.Format("{0}?tokenid={1}",
paymentSwitchUrl,
tokenid);

// send browser back to PS

Response.Redirect(redirectString, true);

5.2.2.2 Response Parameters

The response of PS to a payment request from the Merchant using the Web Service
model is just similar to the one for Name-Value Pair. Refer to 5.2.1.2 for details.

13
5.3 Additional Support Functions

The PS provides some supplementary functions allowing merchants to more tightly

integrate and automate their systems. These functions are available in Name-Value
Pair HTTP GET or POST, and XML Web Service models

5.3.1 Transaction Status Inquiry

The merchant can programmatically inquire the status of a transaction by using this
function.

5.3.1.1 Request Parameters using Name-Value Pair

These are the parameters passed by the Merchant to the PS via name-value pairs to
request for a transaction status. Name-value pairs may be sent using either HTTP
GET or HTTP POST to the MerchantRequest.aspx function.

Parameter Data Type Description

op Varchar(20) The operation to perform (value = GETSTATUS)
merchantid Varchar(20) A unique code assigned to Merchant
merchantpwd Varchar(20) The merchant’s API password
txnid Varchar(40) A unique id identifying this specific transaction
from the merchant side

string message = String.Format("{0}:{1}:{2}",

"GETSTATUS",
merchantId,
Application[“secretkey”].ToString(),
txnId);

An HTTP GET to PS may look something like this:

https://gw.dragonpay.ph/MerchantRequest.aspx?op=GETSTATUS&merchantid=ABC&
merchantpwd=MySecret&txnid=12345678

5.3.1.2 Response Parameters using Name-Value Pair

MerchantRequest.aspx will respond to the inquiry with a plain-text http reply:

Parameter Description
status The result of the payment. Refer to Appendix 3 for codes.

14
5.3.1.3 Request Parameters using XML Web Service

These are the parameters passed by the Merchant to the PS via SOAP request for a
transaction status.

Web Method: GetTxnStatus

Parameter Data Type Description

merchantId Varchar(20) A unique code assigned to Merchant
merchantPwd Varchar(20) The API password assigned to Merchant
txnId Varchar(40) A unique id identifying this specific transaction
from the merchant side

You may use the following URL’s as the Web Service entry point. (Note that since
this is an alpha documentation, the actual URL’s may change in the future.)

5.3.1.4 Response Parameters using XML Web Service

The GetTxnStatus() method will respond with a single status string:

Parameter Description
status The result of the payment. Refer to Appendix 3 for codes.

For more details on error codes due to FAILURE, or reference numbers for SUCCESS
or PENDING, please access the web-based administrator page.

15
5.3.2 Cancellation of Transaction

The merchant can programmatically cancel a pending transaction by using this

function.

5.3.2.1 Request Parameters using Name-Value Pair

These are the parameters passed by the Merchant to the PS via name-value pairs to
request for a transaction cancellation. Name-value pairs may be sent using either
HTTP GET or HTTP POST to the MerchantRequest.aspx function.

Parameter Data Type Description

op Varchar(20) The operation to perform (value = VOID)
merchantid Varchar(20) A unique code assigned to Merchant
merchantpwd Varchar(20) The merchant’s API password
txnid Varchar(40) A unique id identifying this specific transaction
from the merchant side

string message = String.Format("{0}:{1}:{2}",

"VOID",
merchantId,
Application[“secretkey”].ToString(),
txnId);

An HTTP GET to PS may look something like this:

https://gw.dragonpay.ph/MerchantRequest.aspx?op=VOID&merchantid=ABC&
merchantpwd=MySecret&txnid=12345678

5.3.2.2 Response Parameters using Name-Value Pair

MerchantRequest.aspx will respond to the request with a plain-text http reply:

Parameter Description
status Returns zero (0) if successful, else a negative number

16
5.3.2.3 Request Parameters using XML Web Service

These are the parameters passed by the Merchant to the PS via SOAP request for a
transaction status.

Web Method: CancelTransaction

Parameter Data Type Description

merchantId Varchar(20) A unique code assigned to Merchant
merchantPwd Varchar(20) The API password assigned to Merchant
txnId Varchar(40) A unique id identifying this specific transaction
from the merchant side

5.3.2.4 Response Parameters using XML Web Service

The CancelTransaction() method will respond with a single status string:

Parameter Description
status Returns zero (0) if successful, else a negative number

17
5.3.3 Sending of Billing Information

For additional fraud checking, the merchant can programmatically send the
customer’s billing address by using this function.

5.3.3.1 Request Parameters using XML Web Service

These are the parameters passed by the Merchant to the PS via SOAP request.

Web Method: SendBillingInfo

Parameter Data Type Description

merchantId Varchar(20) A unique code assigned to Merchant
merchantTxnId Varchar(20) Mechant’s unique transaction id
firstName Varchar(60) Firstname of customer
lastName Varchar(60) Lastname of customer
address1 Varchar(120) Street address
address2 Varchar(120) Village, subdivision, etc.
city Varchar(40) City or municipality
state Varchar(40) State or province
country Varchar(2) 2-char ISO country code (ex. PH, US, CA)
zipCode Varchar(12) [OPTIONAL] zip code
telNo Varchar(40) Telephone number
email Varchar(40) Email address of customer

5.3.3.2 Response Parameters using XML Web Service

The SendBillingInfo() method will respond with a single status string:

Parameter Description
status Returns zero (0) if successful, else a negative number

18
5.3.4 Controlling the Payment Channels Selection Page

There may be instances wherein the merchant would want to filter the payment
channels that they want to appear in Dragonpay’s payment selection page, or they
may want to skip the Dragonpay page altogether and go straight to the payment
details for a specific channel. There is limited support for these features and this
section discusses them in detail.

5.3.4.1 Filtering Payment Channels

Dragonpay payment channels are grouped together by type – ex. Online banking,
Over-the-Counter/ATM, etc. Merchants can programmatically instruct Dragonpay
which grouping to show when the user is redirected to the payment gateway by
using the “mode” parameter.

Mode Value Grouping Type

1 Online Banking
2 Over-the-Counter Banking and ATM
4 Over-the-Counter non-Bank
8 (unused)
16 (reserved internally)
32 PayPal
64 Credit Cards
128 Mobile (Gcash)
256 International OTC

“Mode” is a bitmask which can be OR-ed to achieve the result intended. The
following example will only show the online banking options:

https://gw.dragonpay.ph/Pay.aspx?merchantid=ABC&txnid=1234&…&mode=1

Merchants who avail of PayPal or Gcash from Dragonpay but do not want them to
appear in the dropdown list, may specify a “mode=7” to display only the basic
alternative payments in the dropdown list.

5.3.4.2 Pre-selecting Payment Channels

Dragonpay has very basic support to allow merchant to go directly to a payment

channel without having to select it from the dropdown list. This feature is currently
supported only for the following processor id’s:

Proc Id Name
GCSH Globe Gcash
CC Credit Cards
PYPL PayPal

Merchants who want to receive Gcash or PayPal payments may put separate radio
buttons at their checkout page to give user the capability to go straight to that

19
channel without stopping by the Dragonpay payment selection page by passing a
“procid” parameter.

The following example will direct the buyer to our Gcash payment page from the
merchant’s checkout page:

https://gw.dragonpay.ph/Pay.aspx?merchantid=ABC&txnid=1234&…&procid=GCSH

For PayPal and credit card acceptance, Merchant is required to apply for a separate
merchant id with the respective payment gateways. Contact our Sales for
assistance.

20
Appendix 1 – Currency Codes
Code Description
PHP Philippine Peso
USD US Dollar

21
Appendix 2 – Error Codes
Code Description
000 Success
101 Invalid payment gateway id
102 Incorrect secret key
103 Invalid reference number
104 Unauthorized access
105 Invalid token
106 Currency not supported
107 Transaction cancelled
108 Insufficient funds
109 Transaction limit exceeded
110 Error in operation
111 Invalid parameters
201 Invalid Merchant Id
202 Invalid Merchant Password

22
Appendix 3 – Status Codes
Code Description
S Success
F Failure
P Pending
U Unknown
R Refund
K Chargeback
V Void
A Authorized

23