Bangladesh: bKash, Nagad and a bank account are not interchangeable

“We can connect bKash and Nagad through one API” says nothing about the accounts receiving the money. In Bangladesh, the first processing question comes before the API: is the recipient acting as a merchant, agent, personal wallet holder or payment intermediary? These roles have different purposes, access conditions and restrictions. A familiar mobile number does not explain the legal or accounting structure.

bKash and Nagad are prominent local mobile financial services. They are not ranked here: registrations, active users and merchant payment volumes measure different things. For integration selection, the more useful questions concern the actual product available, its contract and whether the money trail can be reconstructed without relying on an intermediary’s assurances.

Four roles behind similar screens

A personal transfer, merchant purchase, agent cash service and enterprise disbursement are different transactions. Bangladesh Bank separately describes P2P, P2B and B2P among domestic MFS services. Consequently, “this wallet receives transfers” does not prove that the account may collect other companies’ revenue at scale. An approved role matters more than a working button.

The bKash Merchant application asks for shop and contact details, information about NID, trade licence and bank account. It is an application followed by verification, not automatic acceptance. A separate Personal Retail Account serves small retail and f-commerce businesses. “Personal” can be misleading here: the operator explicitly classifies PRA as a business account.

The published PRA page specifies identity and SIM requirements and payment-receipt ceilings of BDT 30,000 per transaction and day, and BDT 500,000 per month. These figures concern that particular product, checked on 12 October 2026, rather than all bKash accounts. Obtain the current schedule for your chosen category before contracting. One account type’s limits must not become a promise about another.

Questions for Nagad when sales outruns documentation

Do not copy bKash statuses, refund APIs or account rules into a Nagad integration simply because both services resemble mobile wallets. The public Nagad limits page checked for this article did not yield a populated numerical table. A universal current limit is therefore deliberately omitted. That is a specific verification boundary, not a claim that limits do not exist.

Request the provider’s legal entity, exact merchant product, acceptance terms, sample report, directional limits and current integration documentation. When an aggregator is involved, establish who contracts with Nagad and who owns an incorrect-status incident. A demonstration credential or unofficial library does not establish production eligibility for your business.

A useful supplier test is to demonstrate one permitted test payment, its original reference, recipient-side entry and settlement line. Repeat with cancellation before payment and a refund afterward. Missing documented answers should not be replaced with “it usually works”; the relevant route stays outside the launch scope.

Payment evidence needs more than a phone number

Your ledger should separate the order ID, attempt, provider, operation type, destination account, BDT amount, timestamps and financial-event reference. Evidence comes from the servicing provider or bank. A payer screenshot helps locate a transaction but should not independently trigger fulfilment or an internal balance credit.

SSLCOMMERZ provides a documented gateway example: the merchant sets tran_id; val_id supports validation; bank_tran_id identifies the bank-side transaction. VALIDATED means a successful payment was validated again, not paid twice. Refunds use separate refund_trans_id and refund_ref_id values; successful initiation is not refunded status. These are SSLCOMMERZ fields, not native bKash or Nagad specifications. Gateway documentation.

Imagine two customers sending identical amounts within a minute. A system retaining only a phone number, amount and screenshot has an ambiguous match. A sound design establishes the available verified identifiers, partial-match rules and manual-review queue in advance. An operator should not select the “closest-looking” order to improve a conversion metric.

The bank is another layer, not a bigger wallet

Bangladesh Bank distinguishes BEFTN, NPSB and RTGS. BEFTN involves batch exchange, NPSB interbank switching for supported operations, and RTGS real-time gross settlement within its operating framework. Bank payments should not all be promised the same completion time. The selected bank, channel, processing schedule and account product matter.

For merchant settlement, identify where the MFS payment ends and the transfer into the bank begins. Acceptance, withdrawal, refund and possible currency conversion are separate cost lines. If a customer pays BDT 1,000, a smaller bank credit should not automatically become an underpayment: first inspect contractual deductions. The opposite mistake is crediting the full amount again when a settlement batch arrives for payments already recorded.

Renaming prohibited activity does not make it ordinary commerce

The official bKash merchant notice expressly lists gambling and participation in or organization of online betting among prohibited categories. The operator reserves termination and legal remedies. An offer to process that traffic through an “ordinary merchant account” is not legitimized by the customer’s overseas gaming licence.

The same applies to incident management. Disguising purpose, using another person’s account or switching to personal transfers does not fix a contractual mismatch. For a lawful business, resilience comes from an approved product, a verified recipient chain, access to reports and a named owner for every unresolved payment. Those features, rather than the number of checkout logos, determine whether the integration is usable.