Testing & Sandbox

Sandbox/Staging Hosts

Point {{payments_api_host}} and {{disbursement_api_host}} (see Environments & Setup) at these values while integrating.

Sandbox Credentials

The collection ships with working sandbox/staging credentials so you can exercise both APIs end-to-end before going live:

These same credentials work for both the Payments API’s Create Token and the Disbursement API’s Create Access Token.

The Testing Folder (Disbursement API)

A dedicated Testing folder exists under the Disbursement API, separate from the core functional folders (Authentication, Wallet, Disbursement, Authorization). It’s explicitly scoped to development and QA purposes only.

Repost Transaction

POST /v1/api/disbursement/transactions/repost?reference_no=TESTINGREFNO01

• Purpose: re-triggers the webhook callback for an existing transaction, identified by reference_no.
• Use case: testing your webhook handler’s response to transaction status events (e.g., success, failed) without having to initiate a brand-new payout every time you want to test delivery.

1
{
2
    "message": "Transaction callback notification has been successfully reposted."
3
}

Why a Repost Utility Matters

Webhook integrations are notoriously hard to test reliably, because triggering a real event usually means creating a real transaction and waiting for it to settle. Repost Transaction sidesteps that: point it at a reference_no you already have, and it re-fires the callback so you can confirm your endpoint:

• Receives the payload correctly.
• Parses the status (success/failed) correctly.
• Responds appropriately (e.g., with the HTTP status your webhook sender expects to consider delivery successful).

Practical Testing Checklist