The Billplz API is a REST API for creating bills and collecting payments programmatically. All responses, including errors, are returned in JSON. The API accepts both application/x-www-form-urlencoded and application/json request bodies.

Review all integration code carefully before deploying to production. Billplz cannot accept responsibility for loss of money due to improper use of the API.

The Billplz Sandbox mirrors the production server so you can test your integration before going live. Any data created in sandbox stays in sandbox; sandbox and production are separate accounts with separate credentials.

When you are ready to go live, switch to your production Billplz Secret Key and the production endpoint. To create a sandbox account, see Create a sandbox account in the Guide.

Billplz organises payments using two core objects: Collections and Bills.

A Collection is a group of Bills. Each Bill belongs to exactly one Collection. Examples of Collections include "Tuition fee - June 2025", "Donation for flood relief", or "Event ticket payment". Each Collection has a unique collection_id used in API calls to associate Bills with it.

A Bill is a payment request issued to a customer. Each Bill belongs to a Collection and tracks the amount, payer details, and payment status.

For definitions of these and other Billplz-specific terms, see Glossary of Billplz terms.

You can create Collections through the API or from the Billplz dashboard. To start collecting payments, create a Collection first, then create Bills within it.

Step 1: Create a Bill

Your application creates a Bill via the API. Billplz returns the Bill object, which includes a unique Bill URL.

Step 2: Redirect the customer

Redirect the customer to the Bill URL. The customer selects a payment method and completes payment on the Bill Page.

Step 3: Receive the callback

After payment succeeds or fails, Billplz sends a server-side POST request to your callback_url. Your backend must capture and process this update.

The callback uses either Basic callback URL or X Signature Callback URL, depending on your configuration.

Step 4: Handle the redirect

If redirect_url is set, Billplz redirects the customer back to your site after payment. Your application should read the redirect parameters and display the payment result to the customer immediately. The redirect uses either Basic Redirect URL or X Signature Redirect URL, depending on your configuration.

If redirect_url is not set, the customer sees the Billplz receipt page instead. Your backend still receives the callback; only the customer-facing redirect is skipped.

Setting a redirect_url gives your customers a faster status update and a better experience. Note that the execution order of callback_url and redirect_url is not fixed, your system must handle both independently and prevent duplicate processing.

For a hands-on version of this flow, see API quick-start guide in the Guide.

Authenticate to the Billplz API by providing your API Secret Key in the request. You can get your API keys from your account's settings page. See Get your Billplz Secret Key for step-by-step instructions.

Authentication occurs via HTTP Basic Auth. Provide your API Secret Key as the basic auth username. You do not need to provide a password.

All API requests must be made over HTTPS. Calls made over plain HTTP will fail. You must authenticate all requests.

For an overview of Billplz authentication methods including OAuth 2.0, see Authentication overview in the Guide.

Billplz has been integrated with many systems available in the market and is continuously working to integrate with more platforms.

For a self-hosted system, you can download a production-ready module to integrate with your e-commerce system. Refer to our GitHub or Guide for the list of available modules.

Billplz provides an OAuth 2.0 integration that allows platform owners to connect merchants with Billplz. With OAuth, a merchant can integrate with your platform by signing in with their Billplz account. This means they do not have to manually copy their Billplz Secret Key, Collection ID, and X Signature Key to your platform.

All GET endpoints are subject to rate limiting. The limit is cumulative across all endpoints per IP address or per account. Making a request to one endpoint reduces the available quota for all other endpoints within the same 5-minute window.

The rate limit is either 100 requests per 5-minute window or 10 requests per 5-minute window, depending on the level of abuse.

RESPONSE HEADER

For troubleshooting guidance on 429 and other error codes, see Common API error codes in the Guide.

RESPONSE PARAMETER

When the rate limit is not exceeded, the response parameters follow the standard format for the endpoint. When the limit is exceeded, the response contains the following error parameters:

This Billplz feature allows your web application to bypass the default Billplz payment option selection page, allowing your customers to proceed directly to the payment option preconfigured in your Bill. Your customers still fall back to the payment option selection page if the settings are invalid, or the selected payment gateway is not available.

The following guide references the Create a Bill API.

How to implement

Step 1: Create a Bill with a bank code

Create a Bill through the Billplz API with filled values for reference_1_label and reference_1:

• Set the value for reference_1_label as "Bank Code"
• Set the value for reference_1 as the value of the bank code of your target payment gateway.

Step 2: Append the auto-submit parameter

Append the query parameter auto_submit=true to the Bill URL returned from the API:

https://www.billplz.com/bills/abcdef
→
https://www.billplz.com/bills/abcdef?auto_submit=true

Payment flow comparison

Standard payment flow

1. Merchant creates a Bill through the API.
2. Merchant redirects the payer to the Bill URL (returned from step 1).
3. Payer lands at the Billplz page to select a payment option.
4. Payer is redirected to the selected payment gateway to pay.
5. Once payment is completed, the payer is redirected to redirect_url / receipt page (refer to API flow).

Direct payment gateway payment flow

1. Merchant creates a Bill through the API with a valid bank code (using reference_1 and reference_1_label).
2. Merchant redirects the payer to the Bill URL with ?auto_submit=true appended.
3. Payer skips the payment option selection page and is redirected directly to the selected payment gateway to pay.
4. Once payment is completed, the payer is redirected to redirect_url / receipt page (refer to API flow).

Invalid direct payment gateway payment flow

1. Merchant creates a Bill through the API with an invalid or inactive bank code.
2. Merchant redirects the payer to the Bill URL with ?auto_submit=true appended.
3. Payer falls back to the Billplz payment option selection page to select a payment gateway.
4. Payer is redirected to the selected payment gateway to pay.
5. Once payment is completed, the payer is redirected to redirect_url / receipt page (refer to API flow).

V3 is no longer in active development. No new features will be introduced in this version. For new integrations, use V4.

Collections group your Bills by purpose or time period, for example, "Tuition fee - September 2025" or "Donation drive". Every Bill belongs to exactly one Collection. For a full explanation of how Collections and Bills relate, see API flow.

Available endpoints

• Create a Collection
• Get a Collection
• Get Collection Index
• Deactivate a Collection
• Activate a Collection

Creates a Collection with optional Split Rule configuration. The response contains the Collection's ID (required for Bill API), Split Rule details, and logo fields.

REQUIRED ARGUMENTS

OPTIONAL ARGUMENTS

RESPONSE PARAMETER

Retrieves a single Collection record.

URL PARAMETER

RESPONSE PARAMETER

Retrieves your Collections list. To utilize paging, append a page parameter to the URL, e.g., ?page=1. If there are 15 records in the response, check if there is any more data by fetching the next page, e.g., ?page=2, and continue this process until no more results are returned.

OPTIONAL ARGUMENTS

Deactivates a Collection. The API responds with an error message if the Collection cannot be deactivated.

URL PARAMETER

Collections can be activated via this endpoint. The API responds with an error message if the collection cannot be activated.

URL PARAMETER

Bills are created inside a Collection via API.

To create a Bill, you need the Collection ID. Create a Collection via the Create a Collection endpoint or through Dashboard > Collections.

The Bill's Collection is set to active automatically.

REQUIRED ARGUMENTS

OPTIONAL ARGUMENTS

RESPONSE PARAMETER

SMS delivery is ignored if your account's Credit Balance is insufficient. Sending a Bill via email is free.

Retrieves a Bill to check its current status.

URL PARAMETER

RESPONSE PARAMETER

Only due Bills can be deleted. Paid Bills cannot be deleted. Deleting a Bill is useful when payment has a time limit.

For example, you can show a timer for the customer to complete payment within 10 minutes, with a 5-minute grace period. After 15 minutes from Bill creation, check the Bill's status and delete it if it remains due.

URL PARAMETER

Retrieves a Bill's transactions. To use paging, append a page parameter to the URL, e.g., ?page=1. If there are 15 records in the response, check for more data by fetching the next page, e.g., ?page=2, and continue until no more results are returned.

URL PARAMETER

RESPONSE PARAMETER

Returns all payment methods available for a Collection, including each method's enabled or disabled status.

URL PARAMETER

RESPONSE PARAMETER

Updates the enabled payment methods for a Collection. Pass the code of each method to enable; omit a method's code to disable it.

Invalid payment method codes are ignored.

URL PARAMETER

REQUIRED ARGUMENTS

REQUIRED ARGUMENTS

Returns a list of FPX bank codes for use as reference_1 when using the Direct payment gateway feature. For a complete list of payment gateway bank codes, use Get payment gateways.

RESPONSE PARAMETER

Lookup table mapping FPX bank codes to their corresponding bank names. Use these codes as reference_1 values when creating Bills with the Direct payment gateway feature.

For FPX bank codes and their corresponding bank names, see FPX in the Reference section.

V4 is the current version and is in active development. New features are introduced in this version.

Collections group your Bills by purpose or time period, for example, "Tuition fee - September 2025" or "Donation drive". Every Bill belongs to exactly one Collection. For a full explanation of how Collections and Bills relate, see API flow.

Available endpoints

• Create a Collection
• Get a Collection
• Get Collection Index
• Customer Receipt Delivery

Creates a Collection with support for up to two Split Rule recipients. The response contains the Collection's ID (required for Bill API), Split Rule details, and logo fields.

REQUIRED ARGUMENTS

OPTIONAL ARGUMENTS

RESPONSE PARAMETER

Retrieves a single Collection record.

URL PARAMETER

RESPONSE PARAMETER

Retrieves your Collections list. To utilize paging, append a page parameter to the URL, e.g., ?page=1. If there are 15 records in the response, check if there is any more data by fetching the next page, e.g., ?page=2, and continue this process until no more results are returned.

OPTIONAL ARGUMENTS

By default, Collections follow the Global Customer Receipt Notification configuration in your Account settings. To configure the Global setting from the dashboard, see Manage receipt notifications in the Guide.

You can override the Global configuration on individual collections by calling activate and deactivate.

Activates customer receipt email delivery for a specific Collection, overriding the Global configuration to always send receipt emails.

URL PARAMETER

Deactivates customer receipt email delivery for a specific Collection, overriding the Global configuration to never send receipt emails.

URL PARAMETER

Resets a Collection to follow the Global Customer Receipt Notification configuration. Use this if you previously activated or deactivated receipt delivery for a Collection and want to restore the default Global behaviour.

URL PARAMETER

Returns the customer receipt delivery status for a specific Collection.

URL PARAMETER

RESPONSE PARAMETER

Retrieves your account's webhook rank, which determines callback execution priority. The higher the ranking, the higher the priority. 0.0 indicates the highest ranking (default); 10.0 indicates the lowest.

RESPONSE PARAMETER

Returns a complete list of supported payment gateway codes for use as reference_1 when using the Direct payment gateway feature. This includes FPX banks and all other supported payment methods.

RESPONSE PARAMETER

Lookup table mapping payment gateway codes to their corresponding names. Use these codes as reference_1 values when creating Bills with the Direct payment gateway feature.

For a complete list of payment gateway codes (FPX, card, e-wallet, and staging), see Codes in the Reference section.

Tokenization lets you securely store a customer's card details in a provider's PCI-DSS certified vault and receive a token to charge the card later.

Providers

Ways to use tokenization

• Tokenize a customer's card so they only need to enter their card details once.
• Charge the customer's card against a Billplz Bill at any time and for any amount.
• Pre-authorize a Bill payment and capture it later.

Senangpay tokenization stores 3DS Visa / Mastercard card details in Senangpay's PCI-DSS certified servers and returns a token you can use to charge the card on demand.

Available endpoints

• Create card
• Delete card
• 3D Secure update
• Charge card
• Pre-auth
• Pre-auth capture

Creates a card token for 3DS Visa / Mastercard cards. Store the response, as no card details or tokens are stored on Billplz's servers.

Flow

• Create a card and token using this endpoint.
• Redirect the cardholder to Senangpay's 3DS authentication page.
• The cardholder inputs credit/debit card details and submits the form.
• Upon 3DS verification success, Billplz sends a POST request to your callback_url containing masked card details together with CARD_ID and TOKEN.
• Compare the checksum sent, and store the card details if they match.

To charge a card with the token generated, refer to Charge card.

REQUIRED ARGUMENTS

Deletes a card.

REQUIRED ARGUMENTS

Billplz sends a POST request to the callback_url provided within an hour, regardless of whether the cardholder has completed 3D Secure verification. This callback_url also serves as the redirect_url on the client side. Handle the redirect on every 3D Secure update, whether delivered via callback or redirect.

POST PARAMETER

CHECKSUM

For security purposes, a checksum is included in the POST request so you can verify the request originated from Billplz. The checksum is computed the same way as the X Signature received on Payment Completion. Refer to X Signature for details.

Makes a Bill payment by charging a Visa / Mastercard card with a token generated.

REQUIREMENTS

• Collection without split recipients (split payment).
• Bill. email and mobile number are required during Bill creation.
• Card token and ID.

REQUIRED ARGUMENTS

Pre-authorizes a transaction with a token generated and captures the payment later. The amount is not charged to the card, but is blocked until the transaction is captured or released.

REQUIREMENTS

• Collection without split recipients (split payment).
• Card token and ID.

REQUIRED ARGUMENTS

Captures a pre-authorized transaction with a token generated. The amount is charged to the card immediately.

REQUIREMENTS

• Collection without split recipients (split payment).
• Card token and ID.
• Preauth ID.

REQUIRED ARGUMENTS

V5 is in active development. New features are introduced in this version.

Every request to a V5 endpoint must include epoch and checksum values in addition to each endpoint's required arguments.

• The epoch parameter must be in UNIX epoch time format.
• Checksum calculation is specific to each endpoint. Refer to the CHECKSUM ARGUMENTS section of each endpoint for the required values.
• Calculate checksum signatures using HMAC_SHA512 with your account X Signature key. See V5 checksum for details.

Payment Order Collections group your Payment Orders for managing disbursement transfers. Create a Payment Order Collection before creating Payment Orders within it.

The response contains the Collection ID required when creating Payment Orders.

REQUIRED ARGUMENTS

OPTIONAL ARGUMENTS

RESPONSE PARAMETER

Retrieves a single Payment Order Collection record.

REQUIRED ARGUMENTS

RESPONSE PARAMETER

Payment Orders disburse funds from your Billplz account to any bank account registered in Malaysia. Each Payment Order must belong to a Payment Order Collection.

To create a Payment Order, you need the Payment Order Collection ID. Each Payment Order must be created within a Payment Order Collection.

REQUIRED ARGUMENTS

OPTIONAL ARGUMENTS

RESPONSE PARAMETER

Retrieves a single Payment Order record.

REQUIRED ARGUMENTS

RESPONSE PARAMETER

For SWIFT bank codes used with the bank_code parameter, see SWIFT in the Reference section.

The Payment Order Limit is the pre-funded balance available for Payment Order disbursements. See Reload your Payment Order Limit for top-up instructions.

Retrieves your current Payment Order Limit.

REQUIRED ARGUMENTS

RESPONSE PARAMETER

Billplz notifies your system when a Bill or Payment Order status changes using callbacks and optional redirects. This section covers both Bill completion (V3/V4) and Payment Order completion (V5).

Callback vs redirect

Callbacks (callback_url) are server-side POST requests from Billplz to your backend, guaranteeing backend-to-backend transaction updates. Callbacks are compulsory for all integrations.

Redirects (redirect_url) are client-side browser redirects that send the customer back to your site after payment. They provide instant feedback but do not guarantee execution due to network issues, browser closures, or app closures. Redirects are optional.

You are strongly advised to integrate both, redirects for better user experience and callbacks for reliable transaction updates.

For a step-by-step walkthrough of configuring your callback and redirect URLs, see Webhook and callback setup in the Guide.

Basic vs X Signature variants

Two variants exist for each callback and redirect type:

Basic — Legacy variant disabled by default for accounts registered from September 2018 onwards for security reasons. Basic callbacks and redirects do not include data integrity verification.

X Signature — Recommended and enabled by default for accounts registered from September 2018. Includes HMAC-SHA256 signatures for Bill callbacks/redirects, allowing you to verify that requests originated from Billplz and data has not been tampered with.

Payment Order callbacks (V5) use a separate checksum mechanism. See Payment Order Callback.

Bill callback retry schedule (V3/V4)

If your endpoint fails to respond with HTTP 200 within 20 seconds, Billplz retries the callback:

• Attempt 2: 15 seconds + random 0–300 seconds after attempt 1
• Attempt 3: 15 minutes + random 0–300 seconds after attempt 2
• Attempt 4: 15 minutes + random 0–300 seconds after attempt 3
• Attempt 5 (final): 24 hours + random 0–300 seconds after attempt 4

Example: If attempt 1 is at 13:00:00, attempt 2 is at 13:00:15 + N seconds, attempt 3 is at 13:15:15 + N seconds, attempt 4 is at 13:30:15 + N seconds, and attempt 5 is at 13:30:15 + N seconds the next day.

After 5 attempts, the callback is permanently removed from the queue.

Payment Order callback retry schedule (V5)

Payment Order callbacks retry once if your endpoint fails:

• Attempt 2: 1 hour after attempt 1

After 2 attempts, the callback is permanently removed from the queue.

Account rank degradation

Billplz sends a POST request to callback_url with Bill data upon payment completion. Each request includes an x_signature generated using HMAC-SHA256 and your X Signature key, allowing you to verify that the request originated from Billplz.

See Payment Completion overview for callback behaviour, retry schedule, and variant recommendations.

If payment fails, the Bill remains in due state.

POST PARAMETER

X Signature verification

To verify that the request came from Billplz, compute the HMAC-SHA256 digest according to the steps below and compare it to the value in the x_signature parameter. If they match, the callback was sent from Billplz and the data has not been compromised.

Sample POST body POST {CALLBACK_URL}:

{:id=>"zq0tm2wc", :collection_id=>"yhx5t1pp", :paid=>true, :state=>"paid", :amount=>100, :paid_amount=>100, :due_at=>"2018-9-27", :email=>"[email protected]", :mobile=>nil, :name=>"TESTER", :url=>"http://www.billplz-sandbox.com/bills/zq0tm2wc", :paid_at=>"2018-09-27 15:15:09 +0800", :x_signature=>"0fe0a20b8d557eeae570377783d062a3816a9ea80f368860bacfa7ec3ca4d00e"}

Step 1:
Extract all key-value pair parameters except x_signature.

id="zq0tm2wc"

collection_id="yhx5t1pp"

paid="true"

state="paid"

amount="100"

paid_amount="100"

due_at="2018-9-27"

email="[email protected]"

mobile=""

name="TESTER"

url="http://www.billplz-sandbox.com/bills/zq0tm2wc"

paid_at="2018-09-27 15:15:09 +0800"

Step 2:
Construct source string from each key-value pair.

idzq0tm2wc

collection_idyhx5t1pp

paidtrue

statepaid

amount100

paid_amount100

due_at2018-9-27

[email protected]

mobile

nameTESTER

urlhttp://www.billplz-sandbox.com/bills/zq0tm2wc

paid_at2018-09-27 15:15:09 +0800

Step 3:
Sort in ascending order, case-insensitive.

amount100

collection_idyhx5t1pp

due_at2018-9-27

[email protected]

idzq0tm2wc

mobile

nameTESTER

paid_amount100

paid_at2018-09-27 15:15:09 +0800

paidtrue

statepaid

urlhttp://www.billplz-sandbox.com/bills/zq0tm2wc

Step 4:
Combine sorted source strings with | (pipe character).

amount100|collection_idyhx5t1pp|due_at2018-9-27|[email protected]|idzq0tm2wc|mobile|nameTESTER|paid_amount100|paid_at2018-09-27 15:15:09 +0800|paidtrue|statepaid|urlhttp://www.billplz-sandbox.com/bills/zq0tm2wc

Step 5:
Compute x_signature using HMAC-SHA256 and your X Signature key.

Sample X Signature key: S-s7b4yWpp9h7rrkNM1i3Z_g

Computed x_signature: 0fe0a20b8d557eeae570377783d062a3816a9ea80f368860bacfa7ec3ca4d00e

Step 6:
Compare the computed x_signature with the value in the request.

If they match, the callback was sent from Billplz and the data has not been compromised. You do not need to trigger an additional Get a Bill API call for primary status validation.

If redirect_url exists, Billplz redirects the browser to redirect_url with Bill status data appended as URL parameters. Each redirect includes an x_signature generated using HMAC-SHA256 and your X Signature key, allowing you to verify that the redirect originated from Billplz.

See Payment Completion overview for callback behaviour, retry schedule, and variant recommendations.

URL PARAMETER

X Signature verification

To verify that the request came from Billplz, compute the HMAC-SHA256 digest according to the steps below and compare it to the value in the x_signature parameter. If they match, the redirect was sent from Billplz and the data has not been compromised.

Sample GET request:

GET {REDIRECT_URL}?billplz[id]=zq0tm2wc&billplz[paid]=true&billplz[paid_at]=2018-09-27%2015%3A15%3A09%20%2B0800&billplz[x_signature]=4aab095fe5a39b1d534500988f9a0cb085cd1b6d5bbb55dd4e02ea6fa102b47b

Step 1:
Extract all key-value pair parameters except x_signature.

billplz[id]="zq0tm2wc"

billplz[paid]="true"

billplz[paid_at]="2018-09-27 15:15:09 +0800"

Step 2:
Construct source string from each key-value pair.

billplzidzq0tm2wc

billplzpaidtrue

billplzpaid_at2018-09-27 15:15:09 +0800

Step 3:
Sort in ascending order, case-insensitive.

billplzidzq0tm2wc

billplzpaid_at2018-09-27 15:15:09 +0800

billplzpaidtrue

Step 4:
Combine sorted source strings with | (pipe character).

billplzidzq0tm2wc|billplzpaid_at2018-09-27 15:15:09 +0800|billplzpaidtrue

Step 5:
Compute x_signature using HMAC-SHA256 and your X Signature key.

Sample X Signature key: S-s7b4yWpp9h7rrkNM1i3Z_g

Computed x_signature: 4aab095fe5a39b1d534500988f9a0cb085cd1b6d5bbb55dd4e02ea6fa102b47b

Step 6:
Compare the computed x_signature with the value in the request.

If they match, the redirection was sent from Billplz and the data has not been compromised. You do not need to trigger an additional Get a Bill API call for primary status validation.

Billplz sends a POST request to callback_url with Bill data upon payment completion. Basic Callback URL does not include signature verification.

See Payment Completion overview for callback behaviour, retry schedule, and variant recommendations.

If payment fails, the Bill remains in due state.

POST PARAMETER

If redirect_url exists, Billplz redirects the browser to redirect_url with the Bill ID appended as a URL parameter. Basic Redirect URL does not include signature verification.

See Payment Completion overview for callback behaviour, retry schedule, and variant recommendations.

URL PARAMETER

If callback_url exists in your Payment Order collection, Billplz sends a POST request with Payment Order data when the status changes to completed or refunded. Each request includes a checksum generated using HMAC-SHA512 and your X Signature key, allowing you to verify that the request originated from Billplz.

See Payment Completion overview for general callback behaviour and variant recommendations.

POST PARAMETER

Callback requests time out at 20 seconds. Billplz expects your endpoint to respond with HTTP status code 200.

If your endpoint cannot respond within 20 seconds or does not respond with HTTP 200, the callback is considered failed and rescheduled for a second attempt in one hour. After two attempts, the callback is permanently removed from the queue.

Checksum verification

To verify that the request came from Billplz, generate the checksum signature on your end using the values below in strict order and compare it to the checksum parameter sent with the Payment Order object. If they match, the callback was sent from Billplz and the data has not been compromised.

Sample POST body POST {CALLBACK_URL}:

{:id=>"0b924e37-7418-4d17-b234-8de424dc48e5",:payment_order_collection_id=>"0c78f8c6-5bd3-4663-8c08-9e2c805418a2",:bank_code=>"PHBMMYKL",:bank_account_number=>"1234567890",:name=>"Michael Yap",:description=>"Maecenas eu placerat ante.",:email=>"[email protected]",:status=>"refunded",:notification=>true,:recipient_notification=>true,:reference_id=>"My first payment order",:display_name=>nil,:total=>500000,:epoch=>1681895891, :checksum=>"2720f5ef16c7d04677829789fb74bccb08b90041e4e27916d85cb6fbbece58a7ab48538e8b62bcedab3b236bd38e6517860b593b8fe9bfa77bed979994f2ca1a"}

Required values for checksum signature in this order: [id, bank_account_number, status, total, reference_id, epoch]

Step 1:
Format the raw string.

Extract only the values of the keys listed above, in strict order.

object_keys: [:id, :bank_account_number, :status, :total, :reference_id, :epoch]

raw_string: "0b924e37-7418-4d17-b234-8de424dc48e51234567890refunded500000My first payment order1681895891"

Step 2:
Digest the raw string using HMAC-SHA512.

Compute the HMAC-SHA512 digest of the raw string using your account X Signature key.

example_XSignature: S-R5t3Uw6SrwXNWyZV-naVHg

generated_checksum_value: 2720f5ef16c7d04677829789fb74bccb08b90041e4e27916d85cb6fbbece58a7ab48538e8b62bcedab3b236bd38e6517860b593b8fe9bfa77bed979994f2ca1a

Step 3:
Compare your generated checksum with the one included in the callback.

If the values match, the request is valid from Billplz and the data has not been altered.