bKash & Nagad Payment Integration for ISP Billing in Bangladesh

Search "ISP billing" in Bangladesh and payment collection is almost always the first pain point ISPs bring up — not because collecting money is hard, but because collecting it without a human manually checking each transaction is. Nearly every residential and small-business customer in Bangladesh pays with bKash or Nagad rather than a bank transfer, so any serious ISP billing software has to treat mobile financial services (MFS) as the default payment method, not an add-on. This guide covers exactly how that integration works, from the customer tapping "pay" to their connection being restored automatically.

Why ISP billing in Bangladesh depends on MFS

Bangladesh has one of the highest mobile financial services adoption rates in South Asia, and bKash alone processes tens of millions of transactions a month. For an ISP, this means the overwhelming majority of subscriber payments — bill payments, renewals, and reconnection fees — arrive through bKash or Nagad rather than cash at an office or a bank deposit slip. An ISP billing system that doesn't handle these gateways natively forces staff to manually cross-check mobile banking SMS notifications against a customer list every single day, which is slow, error-prone, and doesn't scale past a few hundred subscribers.

bKash vs Nagad vs Rocket for ISP billing

Each gateway has a slightly different integration path, and a good ISP billing platform should support all three without forcing you to pick just one:

Most ISP billing software in Bangladesh, including ISP Dhaka, integrates bKash and Nagad directly and adds SSLCommerz as a single gateway that covers everything else — so a customer sees a simple "Pay Now" button with all their preferred options, without the ISP needing three separate merchant accounts wired into three separate systems.

How automatic payment verification works

The core of ISP billing payment automation is a webhook — a small notification the payment gateway sends to your billing server the moment a transaction completes. The flow looks like this:

1. The customer opens their bill in the ISP's customer portal or gets a payment link via SMS.
2. They complete the payment inside the bKash or Nagad app.
3. The gateway sends a signed webhook to the ISP billing server confirming the transaction ID and amount.
4. The billing software verifies the signature and transaction ID against the gateway's own API — never trusting the amount blindly from the webhook alone.
5. Once verified, the customer's invoice is marked paid and, if they were disconnected, their MikroTik profile is restored automatically. (See our guide on setting up MikroTik billing integration for how that restore step works under the hood.)

This whole sequence typically completes in under 10 seconds from payment to reconnection — fast enough that most customers never even need to contact support.

Setting up bKash in your ISP billing software

If you're configuring bKash integration yourself rather than using a platform that has it built in, the setup generally involves:

• Registering as a bKash merchant and getting your App Key, App Secret, Username, and Password for the Tokenized Checkout API.
• Whitelisting your callback URL with bKash so payment confirmations reach your billing server.
• Storing credentials securely — encrypted at rest, never in plain text config files, and never exposed to the frontend.
• Testing on bKash's sandbox environment before going live, including testing failed and cancelled payment scenarios, not just successful ones.
• Setting a webhook subscription so bKash notifies your server directly instead of relying only on the customer completing a redirect back to your site — this matters because customers sometimes close the app before the redirect finishes, and without a webhook that payment would never get recorded.

Reconciliation and avoiding double payments

A subtle but important part of ISP billing is reconciliation — matching every gateway transaction against exactly one invoice, so nothing gets recorded twice and nothing gets missed. Two things prevent the most common problems:

Idempotent transaction handling

If a webhook is delivered twice (which happens more often than you'd expect on unstable mobile networks), the billing system should recognize the transaction ID has already been processed and simply ignore the duplicate rather than crediting the customer's account twice.

Daily settlement matching

At the end of each day, a good ISP billing system should be able to pull a settlement report directly from bKash/Nagad and cross-check it against recorded payments, flagging any mismatch for manual review rather than letting small discrepancies quietly accumulate over a month.

Common mistakes ISPs make

• Relying only on customer-facing redirect confirmation instead of a server-to-server webhook — leads to "paid but still shows unpaid" complaints.
• Hardcoding the webhook URL with a fixed port that breaks when the server configuration changes (a real issue ISP Dhaka fixed after finding :8000 hardcoded in a settings page affecting every tenant on the platform).
• Not separating gateway credentials per company on multi-tenant billing platforms, which risks one ISP's payments being misrouted to another's merchant account.
• Skipping sandbox testing for failed payments — a system that only works for successful transactions will silently mishandle declined or cancelled ones in production.

Frequently asked questions