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
  • Online banking
  • OTC and ATM cash
  • Mobile wallet
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
  • Within the Dragonpay group of payment methods, payouts are available to perform in the Philippines by using the Banks of the Philippines payment method.
  • The full and partial refunds are available only directly from the Dragonpay service.
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.

Table 1. Bills payment facilities and their corresponding amount limits
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 method.

The following diagram provides the detailed picture of the payment processing procedure.

Figure: Purchase sequence when using Payment Page

  1. Customer initiates purchase by using the web service.
  2. The merchant web service sends to the specified ECommPay URL the purchase request for processing the purchase by using Payment Page.
  3. The payment platform receives the request for processing the purchase by using Payment Page.
  4. The payment platform performs the initial request processing that involves validation of the required parameters and signature.
  5. Requested Payment Page is generated into the ECommPay payment platform as specified in the project settings and the request parameters.
  6. Payment Page is displayed to the customer.
  7. 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).
  8. The payment platform receives the purchase request for payment processing in the Dragonpay service.
  9. The payment platform performs the internal purchase request processing and sends it to the Dragonpay service.
  10. The purchase request is processed on the Dragonpay side.
  11. The Dragonpay service generates the data for redirecting the customer to the Dragonpay form and sends it to the payment platform.
  12. The payment platform sends to Payment Page the data for redirecting the customer to the Dragonpay form.
  13. The customer is redirected to the Dragonpay form.
  14. The customer selects one of bills payment facilities on the Dragonpay side.
  15. The Dragonpay service displays a payment instruction. Payment instructions are different and depend on the selected bills payment facility.
  16. The customer completes all the payment steps required by the payment instruction and is redirected to the result waiting page on Payment Page.
  17. The payment is processed on the Dragonpay side.
  18. Dragonpay service sends the payment result notification to the payment platform.
  19. The payment platform sends the callback to the web service.
  20. The payment platform sends payment results to Payment Page.
  21. 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:

  1. 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
  2. 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 method
    • otc-atm-dragonpay—the OTC and ATM cash method
    • mobile-dragonpay—the mobile wallet method
  3. If required, you can also add any other additional parameters Payment Page supports.
  4. 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:

  1. Send a request with all the required parameters and signature to the ECommPay URL.
  2. Perform redirection of a customer to the Dragonpay service.
  3. 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

  1. Customer initiates purchase on the merchant web service by using one of the Dragonpay methods.
  2. The web service sends the request for processing the purchase by using Gate to the specified ECommPay URL.
  3. The payment platform receives the request for processing the purchase by using Gate.
  4. The payment platform performs the initial request processing that includes validation of the required parameters and signature.
  5. The payment platform sends to the web service response with request receipt confirmation and correctness check result.
  6. The payment platform performs the internal payment request processing and sends it to the Dragonpay service.
  7. The purchase request is processed on the Dragonpay side.
  8. The Dragonpay service generates the data for redirecting the customer to the Dragonpay form and sends it to the payment platform.
  9. The payment platform sends to the web service the callback that delivers the data for redirecting customer to the Dragonpay form.
  10. The customer is redirected to the Dragonpay form.
  11. The customer selects one of bills payment facilities on the Dragonpay side.
  12. The Dragonpay service displays a payment instruction. Payment instructions are different and depend on the selected bills payment facility.
  13. The customer completes all the payment steps required by the payment instruction.
  14. The payment is processed on the Dragonpay side.
  15. The Dragonpay service sends the payment result notification to the payment platform.
  16. The payment platform sends the callback to the web service.
  17. 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:

  1. 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.
  2. 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 method
        • otc_atm—the OTC and ATM cash method
        • mobile—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
  3. 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:

  1. Get a callback with the redirect_data object from the payment platform.
  2. Generate full redirect URL in the following format {url}?tokenid={tokenid}&mode={mode} by using parameter values contained in the redirect_data object.
  3. 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 method
      • 6—the OTC and ATM cash method
      • 128—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.