Integrating a pay-in and payout API: a practical checklist
This is the short version of everything an integrator needs to get a payment API live safely — the same checklist our support team walks through with new platforms.
Last updated: 16 September 2026
Pick the right channel for the direction
Pay-in accepts bKash Personal, bKash Agent, Nagad Agent, Nagad Personal and Nagad Merchant. Payout accepts everything except Nagad Merchant, which is a non-API collection channel and returns a 400 on a payout request.
Validate the channel in your own code before the call. Rejecting an impossible combination locally is faster and clearer than handling a provider error afterwards.
Make the webhook the source of truth
Every result arrives twice: once in the API response and once through a signed webhook. Treat the webhook as authoritative, because it also covers the cases where your original request timed out.
Verify the HMAC-SHA256 signature before parsing the body, and compare digests in constant time. A webhook handler that processes first and verifies later is the single most common security hole in payment integrations.
Be idempotent, always
Webhooks are retried. Your endpoint must be able to receive the same order ID several times and change state only once. Store the order ID with a unique constraint and let the database enforce it.
Lock down credentials
Keep API keys and webhook signing secrets server-side only — never inside a mobile app, a browser bundle or a shared document. Keep your IP whitelist current, and rotate keys immediately if a laptop or repository is exposed.
Test the failure paths, not just the happy one
Before going live, test a wrong transaction ID, a timed-out checkout, a duplicate webhook, a payout to a channel that does not support it, and a wallet that hits its daily limit mid-flow.
The interactive playground on the Developers page lets you run these against your own credentials and read the exact response body you will get in production.