Dragonpay
Overview
Dragonpay is a group of payment methods that allows you to process payments by using online banking, cash over-the-counter at physical retail channels and ATM, as well as mobile wallet Gcash. Purchases can be processed by using Payment Page and Gate.
General information
Payment method type |
|
---|---|
Countries and regions | PH |
Payment currencies | PHP |
Currency conversion | On the ECommPay side (For more information about currency conversion, see Currency conversion.) |
Purchases | + |
Payouts | * |
Stored credentials payments | – |
Full refunds | + |
Partial refunds | + |
Chargebacks | – |
Notes |
|
Onboarding and access fee | Refer to your ECommPay key account manager. |
Interaction diagram
Payment processing by using one of the Dragonpay payment methods requires merchant web service, one of the ECommPay interfaces, and the ECommPay payment platform, as well as the Dragonpay service that provides payment processing that involves banks and other parties.
Operations support
Interfaces | Amount, PHP | |||||
---|---|---|---|---|---|---|
Payment Page | CMS Plug-ins | Gate | Dashboard | Minimum | Maximum | |
Purchases | + | – | + | – | 1.01 | 1,999,999.99 |
Full refunds | * | – | * | – | * | * |
Partial refunds | * | – | * | – | * | * |
* To request a full or partial refund, customer needs to submit the online refund form.
For more information about bills payment facilities and their amount limits, see Bills payment facilities and their amount limits.
Processing scenarios
In the Dragonpay methods, purchase involves customer redirection to the Dragonpay form.
Figure: Payment by using Payment Page
Figure: Payment by using Gate
The sections that follow provide detailed information about what you need to perform payments and how you can analyse the information on payments and operations.
Bills payment facilities and their amount limits
Bills payment facilities are provided by Dragonpay. Each of the facilities has individual code used to identify the bills payment facility in callbacks and specific requirements for amount limits.
The table below provides information about these bills payment facilities for informational purposes only, as it may change without additional notice; for the most recent list of supported bills payment facilities, contact your ECommPay key account manager.
Code | Bills payment facility | Amounts, PHP | |
---|---|---|---|
Minimum | Maximum | ||
Online banking | |||
BDO | BDO Internet Banking | 1.01 | 999,999.99 |
BOG | Bogus Bank | * | * |
BPI | BPI ExpressOnline (Fund Transfer) | 1.01 | 999,999.99 |
BPIB | BPI ExpressOnline (Bills Payment) | 50.01 | 1,999,999.99 |
MBTC | Metrobankdirect | 1.01 | 999,999.99 |
CBC | Chinabank Online | * | * |
LBPA | Landbank ATM Online | 1.01 | 199,999.99 |
RCBC | RCBC Online Banking | 1.01 | 999,999.99 |
RSB | RobinsonsBank Online Bills Payment | 10.01 | 999,999.99 |
UBE | Unionbank EON | 1.01 | 999,999.99 |
UBP | Unionbank Internet Banking | 1.01 | 999,999.99 |
UCPB | UCPB Connect | 1.01 | 999,999.99 |
AUAL | Alipay | * | * |
AUWC | WeChat Pay | * | * |
BITC | Bitcoin | * | * |
OTC and ATM cash | |||
BDOA | Banco de Oro ATM | 200.01 | 999,999.99 |
BDRX | BDO Cash Deposit w/ Ref | 1.01 | 1,999,999.99 |
BPXB | BPI Bills Payment | 1.01 | 999,999.99 |
MBTX | Metrobank Cash/Check Payment | 1.01 | 1,999,999.99 |
AUB | AUB Online/Cash Payment | 10.01 | 999,999.99 |
BOGX | Bogus Bank Over the Counter | * | * |
CBCX | Chinabank ATM/Cash Payment | 1.01 | 11,999.99 |
EWBX | EastWest Online/Cash/Check Payment | 1.01 | 49,999.99 |
LBXB | Landbank Cash Payment | 1.01 | 999,999.99 |
PNBB | PNB eBanking Bills Payment | 1.01 | 999,999.99 |
PNXB | PNB Cash Payment | 1.01 | 999,999.99 |
RCXB | RCBC Cash Payment | 25.01 | 999,999.99 |
RSBB | RobinsonsBank Over the Counter | 1.01 | 999,999.99 |
RSXB | RCBC Savings Cash Payment | 1.01 | 999,999.99 |
SBCA | Security Bank ATM Bills Payment | 1.01 | 999,999.99 |
SBCB | Security Bank Cash Payment | 1.01 | 999,999.99 |
UBXB | Unionbank Cash Payment | 1.01 | 1,999,999.99 |
UCXB | UCPB ATM/Cash Payment | 1.01 | 999,999.99 |
BAYD | Bayad Center | 50.01 | 199,999.99 |
LBC | LBC | 50.01 | 199,999.99 |
SMR | SM Dept/Supermarket/Savemore Counter | 50.01 | 199,999.99 |
CEBP | Cebuana Lhuillier PeraPal | 1.01 | 1,499.99 |
MLH | M. Lhuillier | 180.01 | 999,999.99 |
* | Cebuana Lhuillier Bills Payment | 1,500.01 | 999,999.99 |
RDS | Robinsons Dept Store | 50.01 | 199,999.99 |
ECPY | ECPay (Pawnshops, Payment Centers) | 50.01 | 999,999.99 |
RLNT | RuralNet Banks and Coops | 20.01 | 99,999.99 |
Mobile wallet | |||
GCSH | Globe GCash | 1.01 | 2,499.99 |
* For more information, contact to the Dragonpay support service. |
Purchase by using Payment Page
General information
In the Dragonpay methods, when processing a purchase by using Payment Page, the merchant web service is required to send a request with all the required parameters and signature to the ECommPay URL and get the callback with the payment result from the payment platform. When opening Payment Page, you can either allow your customer to select the Dragonpay methods from the list of other payment methods on Payment Page or have Payment Page opened with one of the Dragonpay methods selected. For more information about preselecting payment methods, see Preselecting payment methods.
The following diagram provides the detailed picture of the payment processing procedure.
Figure: Purchase sequence when using Payment Page
- Customer initiates purchase by using the web service.
- The merchant web service sends to the specified ECommPay URL the purchase request for processing the purchase by using Payment Page.
- The payment platform receives the request for processing the purchase by using Payment Page.
- The payment platform performs the initial request processing that involves validation of the required parameters and signature.
- Requested Payment Page is generated into the ECommPay payment platform as specified in the project settings and the request parameters.
- Payment Page is displayed to the customer.
- The customer selects one of the Dragonpay payment methods and agrees to use the method (or accepts the method already selected on Payment Page and agrees).
- The payment platform receives the purchase request for payment processing in the Dragonpay service.
- The payment platform performs the internal purchase request processing and sends it to the Dragonpay service.
- The purchase request is processed on the Dragonpay side.
- The Dragonpay service generates the data for redirecting the customer to the Dragonpay form and sends it to the payment platform.
- The payment platform sends to Payment Page the data for redirecting the customer to the Dragonpay form.
- The customer is redirected to the Dragonpay form.
- The customer selects one of bills payment facilities on the Dragonpay side.
- The Dragonpay service displays a payment instruction. Payment instructions are different and depend on the selected bills payment facility.
- The customer completes all the payment steps required by the payment instruction and is redirected to the result waiting page on Payment Page.
- The payment is processed on the Dragonpay side.
- Dragonpay service sends the payment result notification to the payment platform.
- The payment platform sends the callback to the web service.
- The payment platform sends payment results to Payment Page.
- A page with the payment result information is displayed to the customer.
The sections that follow discuss in more details the request format and the Payment Page parameters to use in the Dragonpay payment methods and provide the information on the format of callbacks with payment results. For the general information on how to use the API, see Payment Page API Description.
Request format
There are several things you must consider when using the Dragonpay methods:
- You must provide values for the basic minimum of parameters. Listed below are the parameters that are mandatory for any payment method:
- customer_id—the unique ID of the customer within your project
- project_id—the project ID obtained from ECommPay
- payment_id—payment ID unique within the project
- payment_amount—payment amount in minor units
- payment_currency—payment currency in ISO-4217 alpha-3 format
- If you need to have Payment Page displayed with one of the Dragonpay methods selected, set the force_payment_method parameter to:
online-banking-dragonpay
—the online banking methodotc-atm-dragonpay
—the OTC and ATM cash methodmobile-dragonpay
—the mobile wallet method
- If required, you can also add any other additional parameters Payment Page supports.
- After you specify all the parameters you need, you must create the signature for the request. For instructions on how to sign a payment request, see Signature generation and verification.
Thus, a correct payment request in the Dragonpay methods must include project, customer and payment IDs, amount and currency of a payment in the appropriate currency and the signature, as shown in the following example:
EPayWidget.run( { payment_id: 'ECT_TEST_15470375651583', payment_amount: amount for example, payment_currency: 'currency for example', project_id: 580, customer_id: '123', signature: "kUi2x9dKHAVNU0FYldJrxh4yo+52Kt8KU+Y1Y4HASCQ9vyS O\/RLCvhtT4DqtVUkDJrOcZzUCwX6R\/ekpZhkIQg==" } )
For information about all parameters available in the Dragonpay methods, see Payment Page invocation parameters.
Callback format
In the Dragonpay methods, the callbacks that deliver purchase results use the standard format described in Callbacks.
Note that unlike other payment methods, in the Dragonpay methods, the callbacks do not contain any specific method name from the group of the Dragonpay payment methods. Instead, the callbacks contain the following data:
dragonpay
—the payment method group name passed in the method parameter of the payment object.- The name of bills payment facility within specific payment method passed in the endpoint_id parameter of the operation.provider object. (For more detailed information about bills payment facilities and their codes, see Bills payment facilities and their amount limits.)
The following example of callback contains an information about successful 10.00 PHP
purchase made in the 580
project by using the UCPB ATM/Cash Payment
bills payment facility.
Figure: Example of a successful purchase callback
{
"project_id": 580,
"payment": {
"id": "ECT_TEST_15470375651583",
"type": "purchase",
"status": "success",
"date": "2019-01-14T15:32:47+0000",
"method": "dragonpay",
"sum": {
"amount": 1000,
"currency": "PHP"
},
"description": "ECT_TEST_15470375651583"
},
"operation": {
"id": 19907000002680,
"type": "sale",
"status": "success",
"date": "2019-01-14T15:32:47+0000",
"created_date": "2019-01-14T15:29:25+0000",
"request_id": "1f6b17a91782602b127403ba97f0b2cff2d82791-92
d62a12c048b7cb7c057cfb11112119c7db8307",
"sum_initial": {
"amount": 1000,
"currency": "PHP"
},
"sum_converted": {
"amount": 1000,
"currency": "PHP"
},
"provider": {
"id": 1165,
"payment_id": "WVUFHH55",
"auth_code": "",
"endpoint_id": "UCXB"
},
"code": "0",
"message": "Success"
},
"signature": "FZZUc4IZa1zO+WokUvz063QqsFnUPevaQBE8l/Zq3hd
dq9wyhWRWkeLL8xdU8sWDWFn54K3f0BVSakCedm2dxw=="
}
The following example of callback is for a payment rejected due to amount or frequency limitation.
Figure: Example of a declined purchase callback
{
"project_id": 580,
"payment": {
"id": "ECT_TEST_1547027708135",
"type": "purchase",
"status": "decline",
"date": "2019-01-09T12:58:04+0000",
"method": "dragonpay",
"sum": {
"amount": 1000,
"currency": "PHP"
},
"description": "ECT_TEST_1547027708135"
},
"operation": {
"id": 12225000002575,
"type": "sale",
"status": "decline",
"date": "2019-01-09T12:58:04+0000",
"created_date": "2019-01-09T12:27:59+0000",
"request_id": "ac0ff611f811045c4b3f82c499158c0d02f9e1d5-4343dab2d9ffbd3d71d453931db2a1870aed09eb",
"sum_initial": {
"amount": 1000,
"currency": "PHP"
},
"sum_converted": {
"amount": 1000,
"currency": "PHP"
},
"provider": {
"id": 1165,
"payment_id": "U3N9EUE4",
"date": "2019-01-09T20:28:05+0000",
"auth_code": ""
},
"code": "20101",
"message": "Decline due to amount or frequency limit"
},
"signature": "Cova73mh3yF+2awvR5qDPN1DpVAfv+LVQanLRze1KjqkNYWri
8KtVl5A6W2wve4gZPq/m/uDS618+RTk4sSB3w=="
}
Related topics
The following topics might be useful when implementing payments by using Payment Page:
Purchase by using Gate
General information
In the Dragonpay methods, when processing a purchase by using Gate, the merchant web service is required to do the following:
- Send a request with all the required parameters and signature to the ECommPay URL.
- Perform redirection of a customer to the Dragonpay service.
- Get the callback with the payment result from the payment platform.
The following diagram provides the detailed picture of the payment processing procedure.
Figure: Purchase sequence when using Gate
- Customer initiates purchase on the merchant web service by using one of the Dragonpay methods.
- The web service sends the request for processing the purchase by using Gate to the specified ECommPay URL.
- The payment platform receives the request for processing the purchase by using Gate.
- The payment platform performs the initial request processing that includes validation of the required parameters and signature.
- The payment platform sends to the web service response with request receipt confirmation and correctness check result.
- The payment platform performs the internal payment request processing and sends it to the Dragonpay service.
- The purchase request is processed on the Dragonpay side.
- The Dragonpay service generates the data for redirecting the customer to the Dragonpay form and sends it to the payment platform.
- The payment platform sends to the web service the callback that delivers the data for redirecting customer to the Dragonpay form.
- The customer is redirected to the Dragonpay form.
- The customer selects one of bills payment facilities on the Dragonpay side.
- The Dragonpay service displays a payment instruction. Payment instructions are different and depend on the selected bills payment facility.
- The customer completes all the payment steps required by the payment instruction.
- The payment is processed on the Dragonpay side.
- The Dragonpay service sends the payment result notification to the payment platform.
- The payment platform sends the callback to the web service.
- The customer receives the payment result from the web service.
The sections that follow discuss in more details the request format and the Gate parameters to use in the Dragonpay payment methods and provide the information about formats of the data for redirecting customers and the information about the format of callbacks with payment results.
Request format
There are several things you must consider when using purchase requests in the Dragonpay methods:
- You perform purchases by sending a POST request to the following endpoint:
/v2/payment/online-banking/dragonpay/sale
. This endpoint is an online banking endpoint of the /v2/payment/online-banking/{payment_method}/sale group. - You must provide values for the basic minimum of the following objects and parameters:
- general—object that contains general request identification information:
- project_id—the project ID obtained from ECommPay
- payment_id—payment ID unique within the project
- signature—signature created after you specify all the required parameters. For more information about signature generation, see Signature generation and verification.
- payment—object that contains purchase information:
- amount—purchase amount in minor units
- currency—purchase currency in ISO-4217 alpha-3 format
- extra_param—specific method name from the group of Dragonpay payment methods:
online_banking
—the online banking methodotc_atm
—the OTC and ATM cash methodmobile
—the mobile wallet method
- customer—object that contains customer information:
- id—the unique ID of the customer within your project
- ip_address—customer IP address
- general—object that contains general request identification information:
- If required, you can also add any other additional parameters Gate supports.
Thus, a correct payment request in the Dragonpay methods must include project, customer and payment IDs, signature, amount and currency of the purchase, specific method name from the group of the Dragonpay payment methods, customer IP address, as shown in the following example:
{ "general": { "project_id": 2852, "payment_id": "EPd6db-b9db", "signature": "U5LCm6489ly9cXCKIVBNV0mFr4XiCruECSyQEbT1hSX J70zuH4s05cFDqLks8ZJMR6iNdlUtm1EdHHdA3D19Qg==" }, "payment": { "amount": 10000, "currency": "PHP", "extra_param": "online_banking" }, "customer": { "id": "123", "ip_address": "248.121.176.220" } }
Formats of the customer redirection data
In the Dragonpay methods, when redirecting customer to the Dragonpay form, it is required to do the following:
- Get a callback with the redirect_data object from the payment platform.
- Generate full redirect URL in the following format
{url}?tokenid={tokenid}&mode={mode}
by using parameter values contained in the redirect_data object. - Open the full redirect URL by using GET (HTTP) method.
The redirect_data object contains the following parameters with values received from the Dragonpay service:
- method—the request method
- body—object that contains following information:
- tokenid—token ID for purchase. Note that validity of this token is limited only to at most one hour.
- mode—numeric ID of one of the Dragonpay methods:
1
—the online banking method6
—the OTC and ATM cash method128
—the mobile wallet method
- url—basic URL for redirecting to the Dragonpay form
The following example of callback code contains required parameters: the request method, the IDs of token and one of the Dragonpay methods, as well as basic URL.
"redirect_data": { "method": "GET", "body": { "tokenid": "f252d914dce5f0522da611d9e33fb781", "mode": "1" }, "encrypted": [], "url": "https://gw.dragonpay.ph/Pay.aspx" }
Format of callback with purchase results
In the Dragonpay methods, the callbacks that deliver purchase results use the standard format described in Callbacks.
Note that unlike other payment methods, in the Dragonpay methods, the callbacks do not contain any specific method name from the group of the Dragonpay payment methods. Instead, the callbacks contain the following data:
dragonpay
—the payment method group name passed in the method parameter of the payment object.- The name of bills payment facility within specific payment method passed in the endpoint_id parameter of the operation.provider object. (For more detailed information about bills payment facilities and their codes, see Bills payment facilities and their amount limits.)
The following example of callback contains an information about successful 10.00 PHP
purchase made in the 580
project by using the UCPB ATM/Cash Payment
bills payment facility.
Figure: Example of a successful purchase callback
{
"project_id": 580,
"payment": {
"id": "ECT_TEST_15470375651583",
"type": "purchase",
"status": "success",
"date": "2019-01-14T15:32:47+0000",
"method": "dragonpay",
"sum": {
"amount": 1000,
"currency": "PHP"
},
"description": "ECT_TEST_15470375651583"
},
"operation": {
"id": 19907000002680,
"type": "sale",
"status": "success",
"date": "2019-01-14T15:32:47+0000",
"created_date": "2019-01-14T15:29:25+0000",
"request_id": "1f6b17a91782602b127403ba97f0b2cff2d82791
-92d62a12c048b7cb7c057cfb11112119c7db8307",
"sum_initial": {
"amount": 1000,
"currency": "PHP"
},
"sum_converted": {
"amount": 1000,
"currency": "PHP"
},
"provider": {
"id": 1165,
"payment_id": "WVUFHH55",
"auth_code": "",
"endpoint_id": "UCXB"
},
"code": "0",
"message": "Success"
},
"signature": "FZZUc4IZa1zO+WokUvz063QqsFnUPevaQBE8l/Zq3hddq9wyhW
RWkeLL8xdU8sWDWFn54K3f0BVSakCedm2dxw=="
}
The following example of callback is for a payment rejected due to amount or frequency limitation.
Figure: Example of a declined purchase callback
{
"project_id": 580,
"payment": {
"id": "ECT_TEST_1547027708135",
"type": "purchase",
"status": "decline",
"date": "2019-01-09T12:58:04+0000",
"method": "dragonpay",
"sum": {
"amount": 1000,
"currency": "PHP"
},
"description": "ECT_TEST_1547027708135"
},
"operation": {
"id": 12225000002575,
"type": "sale",
"status": "decline",
"date": "2019-01-09T12:58:04+0000",
"created_date": "2019-01-09T12:27:59+0000",
"request_id": "ac0ff611f811045c4b3f82c499158c0d02f9e1d5
-4343dab2d9ffbd3d71d453931db2a1870aed09eb",
"sum_initial": {
"amount": 1000,
"currency": "PHP"
},
"sum_converted": {
"amount": 1000,
"currency": "PHP"
},
"provider": {
"id": 1165,
"payment_id": "U3N9EUE4",
"date": "2019-01-09T20:28:05+0000",
"auth_code": ""
},
"code": "20101",
"message": "Decline due to amount or frequency limit"
},
"signature": "Cova73mh3yF+2awvR5qDPN1DpVAfv+LVQanLRze1KjqkNYW
ri8KtVl5A6W2wve4gZPq/m/uDS618+RTk4sSB3w=="
}
Related topics
The following topics might be useful when implementing payments by using Gate:
Analysis of payments results
As with other payment methods ECommPay offers, when using the Dragonpay method, you have several options to analyse the information about payments and operations performed by using the method—alone or in conjunction with other methods.
You can load and analyse all the necessary information in Dashboard, for instance you can use the analytic panels on the Analytics tab to this end.
Also, you can export the information for further analysis by using third party analytical tools. The following options are available:
- Dashboard allows you to download reports in CSV and XLS formats—by using the tools on the Payments tab. You can perform export as a one-time download to your local computer or have payment data regularly exported and delivered to email addresses you specify.
- Data API allows you to have payment information exported in JSON format and delivered to a URL you specify. The payment information is exported by using the /operations/get queries.
If you have any further questions regarding payment data analysis, contact ECommPay technical support.