> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.epaygames.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.epaygames.io/_mcp/server.

# Request & Response Format

## Response Envelope

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

```json
{
  "message": "Human-readable description of the result",
  "data": { ... }
}
```

* `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](/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`.

```json
{
    "channel_code": "QRPH",
    "amount": 1,
    "reference_no": "{{randomString}}",
    "success_redirect_url": "https://epaygames.io/success",
    "failure_redirect_url": "https://epaygames.io/failure",
    "callback_webhook_url": "https://webhook.site/c5170b54-132f-408d-b998-519668c829f9"
}
```

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

```json title="Example — nested JSON body request (Process Disbursement)"
{
    "channel": "PESONET",
    "amount": 1,
    "reference_no": "TESTINGREFNO01",
    "callback_webhook_url": "https://webhook.site/99505fde-ee07-4196-b657-36ee9c145d1d",
    "fields": {
        "bank_code": "161414",
        "sender": {
            "first_name": "John",
            "middle_name": "Sins",
            "last_name": "Doe",
            "suffix": "Jr."
        },
        "receiver": {
            "account_name": "John Sins Doe",
            "account_number": "09064194432",
            "type": "INDIVIDUAL",
            "mobile_number": "+639064194432",
            "email": "johndoes@example.com",
            "address": "Lakambini Street.",
            "barangay": "San Mateo",
            "city": "Cabanatuan",
            "zip_code": "6969",
            "gender": "MALE"
        }
    }
}
```

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:

```text
POST /v1/api/authorization/:code
```

## Content Type

JSON request bodies are sent with:

```text
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.