bKash vs Nagad for Merchants: Checkout, Reporting and Support

Header image: conceptual illustration.

For most Bangladeshi online merchants the question is not "bKash or Nagad" but "in what order, and how". Both are major mobile financial services in Bangladesh, and many customers hold accounts with one or both. This comparison focuses on what matters to operations: checkout, reporting, refunds and support. It avoids market-share or fee claims, which change and should be checked with each provider.

Where to find official information

• bKash: merchant page and developer portal.
• Nagad: official website, including merchant information.
• Regulation: Bangladesh Bank for MFS rules.

Checkout experience

Both wallets authorise payments inside their own flow, so your site never handles the customer's PIN or OTP. When comparing, test on real devices:

• How many steps does the customer take?
• Does the flow work well on mobile web and inside your app?
• What happens if the customer switches apps or loses connection?

Measure completion rates during a pilot rather than assuming one flow converts better.

Integration route

Each can be integrated directly (subject to the provider's merchant approval) or through an aggregator. Direct integration means two separate technical projects and two contracts; an aggregator means one integration but an extra party in disputes and settlement.

Reporting

Ask each provider (or your aggregator) for:

• A transaction export with a unique ID per payment.
• A settlement report showing gross, fees and net.
• How refunds and reversals appear.

If your finance team cannot match both reports to orders in the same way, normalise them into one internal format. See payment reconciliation.

Refunds

Confirm whether each supports full and partial refunds via API, how long refunds take to reach the customer, and whether refund fees apply.

Support

Compare support hours, escalation paths, and how downtime is announced. Method-specific outages happen; a clear notice lets you hide a method temporarily instead of failing payments.

Comparison checklist

• Merchant approval confirmed in writing — bKash: ? Nagad: ?
• Refund via API — bKash: ? Nagad: ?
• Settlement schedule — bKash: ? Nagad: ?
• Itemised fee reporting — bKash: ? Nagad: ?
• Pilot completion rate (your measurement) — bKash: ? Nagad: ?

Hypothetical decision

*Invented example.* A merchant launches with bKash first because its pilot customers asked for it, then adds Nagad a month later using the same internal status model, so reconciliation and support macros work unchanged.

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.

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

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

Frequently asked questions

Should I offer both?

If your customers use both, offering both usually reduces abandoned payments. Your own data should decide.

Is one cheaper?

Pricing is contract-specific. Request written schedules from both.

Related: Nagad payment integration, bKash integration checklist.

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.

Sources

• bKash Merchant: https://www.bkash.com/en/business/merchant
• bKash Developer Portal: https://developer.bka.sh/
• Nagad: https://nagad.com.bd/
• Bangladesh Bank: https://www.bb.org.bd/