Request & Response Format

The shared JSON envelope, request conventions, and payload shapes used across both APIs
View as Markdown

Response Envelope

Every endpoint in both APIs returns JSON wrapped in the same consistent envelope:

1{
2 "message": "Human-readable description of the result",
3 "data": { ... }
4}
  • message — a short, human-readable description of what happened. Often empty ("") on GET/list endpoints, and populated with a confirmation string on POST/action endpoints (e.g., "Transaction has been successfully generated.", "Authenticated.").
  • data — the actual payload. Depending on the endpoint, this is either a single object (e.g., a token, a generated transaction) or an object containing a named array (e.g., data.transactions, data.wallets, data.channels, data.banks).
  • errors — present instead of data on a 422 Unprocessable Entity validation failure, as an object keyed by field name. Other failure responses (401, 403, 404, 500, etc.) omit errors and just return a message. See Error Handling for details.

Request Formats

Requests use two different conventions depending on the endpoint:

  • Query parameters — used for simple GET requests and for the Payments API’s Create Token (credentials passed as ?username=...&password=...).
  • JSON body (raw) — used for POST endpoints that create or process something, such as Generate Transaction, Process Disbursement, Get Authorization, and the Disbursement API’s Create Access Token.
1{
2 "channel_code": "QRPH",
3 "amount": 1,
4 "reference_no": "{{randomString}}",
5 "success_redirect_url": "https://epaygames.io/success",
6 "failure_redirect_url": "https://epaygames.io/failure",
7 "callback_webhook_url": "https://webhook.site/c5170b54-132f-408d-b998-519668c829f9"
8}

Here’s a nested JSON body request (Process Disbursement), showing how recipient/sender details are grouped under fields:

Example — nested JSON body request (Process Disbursement)
1{
2 "channel": "PESONET",
3 "amount": 1,
4 "reference_no": "TESTINGREFNO01",
5 "callback_webhook_url": "https://webhook.site/99505fde-ee07-4196-b657-36ee9c145d1d",
6 "fields": {
7 "bank_code": "161414",
8 "sender": {
9 "first_name": "John",
10 "middle_name": "Sins",
11 "last_name": "Doe",
12 "suffix": "Jr."
13 },
14 "receiver": {
15 "account_name": "John Sins Doe",
16 "account_number": "09064194432",
17 "type": "INDIVIDUAL",
18 "mobile_number": "+639064194432",
19 "email": "[email protected]",
20 "address": "Lakambini Street.",
21 "barangay": "San Mateo",
22 "city": "Cabanatuan",
23 "zip_code": "6969",
24 "gender": "MALE"
25 }
26 }
27}

The exact shape of fields depends on the channel — e.g., an e-wallet channel like maya includes a mobile_number at the top of fields, while a bank-transfer channel like PESONET relies on bank_code plus sender/receiver details.

Path Parameters

At least one endpoint uses a path parameter rather than a query string or body field — Get Authorization, which takes the code directly in the URL:

POST /v1/api/authorization/:code

Content Type

JSON request bodies are sent with:

Content-Type: application/json

Comments in Sample Bodies

Some sample response bodies in this collection include inline // comments (e.g., "expires_in": 3600 // In seconds.) purely for documentation purposes within Postman. These are not valid JSON and won’t appear in actual API responses — they’re illustrative annotations only.