bKash vs Nagad for Merchants: Which Bangladeshi Wallet to Prioritise

Why the comparison matters

Bangladesh runs on mobile financial services. A customer who has never held a card will still have a wallet balance topped up at an agent point, and that wallet is the default way they pay online. A merchant deciding between bKash and Nagad is really deciding how much of the addressable customer base to reach on day one.

Average ticket sizes are small and frequent, so approval rate and confirmation speed matter far more than the headline fee.

Side-by-side

Reach

bKash: The most widely held wallet, with the broadest agent network

Nagad: Strong and growing consumer base, particularly among newer digital users

Flow

bKash: Wallet authorisation with callback confirmation

Nagad: Wallet authorisation with callback confirmation, different state semantics

Ticket size

bKash: Consumer-sized transactions bounded by wallet limits

Nagad: Similar consumer-sized limits

Best for

bKash: Maximum coverage on first launch

Nagad: Incremental coverage and redundancy

Operational differences that surface later

Feature tables rarely capture what actually costs you money in production:

• Confirmation behaviour. Callback timing under load differs between providers, so a single global timeout is usually wrong for at least one of them.
• Failure taxonomy. Reason codes are not identical; map them to your own canonical set rather than displaying raw upstream strings to customers.
• Reference formats. Store each rail's reference separately so reconciliation and refunds stay unambiguous.
• Downtime patterns. Independent providers rarely degrade at the same moment, which is why running both is a resilience decision as much as a coverage one.

Agent-assisted payments are common, so a checkout that expires in 90 seconds will lose real customers who are still walking to a top-up point.

Verdict

If you must launch with one, start with bKash for reach and add Nagad quickly afterwards. Running both also gives you a form of redundancy: when one rail degrades, customers can complete on the other rather than abandoning.

What to do at checkout

1. Show both options with recognisable branding rather than a generic "wallet" button.
2. Route by amount where limits differ, before the customer hits a failure.
3. Keep a bank transfer option visible for higher-value orders.
4. Log method selection so you can measure real preference in your own traffic.

Merchant benefits

• bKash and Nagad through a single Bangladesh integration
• Automatic failover when one provider degrades
• Unified reconciliation across both rails
• Settlement on T+0 for wallet volume and T+1 for bank rails

Related guides and solutions

• Bangladesh Payment Gateway
• High Risk Payment Solution Bangladesh
• bKash Payment Gateway
• Nagad Payment Gateway
• Solutions overview
• Cross-Border Payment Solutions
• Payment Infrastructure
• High-Risk Merchant Payment Processing
• Countries hub

Talk to our team

If you are evaluating acceptance in Bangladesh, the fastest way to get a useful answer is to share your vertical, expected monthly volume and required payout frequency. Our team can confirm which rails are available to your business, what documentation underwriting will ask for, and how quickly you can go live. Start with merchant onboarding or contact us directly.

Frequently asked questions

Should I integrate bKash or Nagad first?

If you must launch with one, start with bKash for reach and add Nagad quickly afterwards. Running both also gives you a form of redundancy: when one rail degrades, customers can complete on the other rather than abandoning.

Does supporting both increase costs?

Marginally in integration effort, but the additional coverage and the resilience gained when one provider degrades normally outweigh it.

How do I handle amounts above wallet limits?

Route them to a bank rail. Detect the limit before submission so the customer sees the right option instead of a failure.

How is settlement handled across both methods?

Both settle into the same reconciled ledger with per-transaction references, on T+0 for wallet volume and T+1 for bank rails.