bKash Payment Gateway Integration: What Merchants Should Verify

Header image: conceptual illustration.

bKash is one of the most widely used mobile financial services in Bangladesh, and many merchants want it at checkout. bKash describes its merchant offering on its business merchant page and publishes technical documentation on its developer portal. This guide does not replace that documentation; it lists what merchants and their developers should verify so the integration works reliably in production.

Direct integration or through an aggregator?

You can integrate with bKash directly as a merchant, or accept bKash through a payment aggregator that offers several methods. Ask yourself:

• Do you need only bKash, or several methods through one contract?
• Who will hold the merchant relationship and handle disputes?
• Which option fits your business registration? Eligibility is decided by bKash or the aggregator, not by your developer.

Before you write code

• Merchant account approval. Confirm in writing that your business type is accepted and which products (for example checkout or tokenised payments) are enabled.
• Sandbox credentials and test wallets.
• Product choice. bKash's developer documentation describes different payment products; confirm which one your contract covers.
• Refund capability and whether refunds are full, partial, or both.

During integration: what to verify

1. Token handling. API credentials and access tokens are server-side only, never in browser or app code.
2. Create payment → customer authorises → execute/confirm. Follow the documented sequence exactly and store each response.
3. Server-side confirmation. After the customer returns, confirm via the API that the status is completed and that the merchant invoice/reference, amount and currency match your order before marking it paid. Do not trust redirect parameters alone.
4. Status query for uncertain cases. If execution times out, query status before retrying, so you don't create duplicates.
5. Your own idempotency. Generate a unique merchant invoice/reference per payment attempt, linked to the order. Allow only one active attempt per order: block a new attempt while one is pending or unknown, and permit a controlled new attempt once the previous one has definitively failed, been cancelled or expired (confirmed by status query). Only one attempt per order may ever be marked paid. See idempotency in payment APIs.
6. Error mapping. Map provider error codes to clear customer messages; never ask customers for their PIN or OTP in your own interface.

Reconciliation

Store the bKash transaction ID against your order ID. Each day, compare your paid orders with the merchant transaction report and with settlement. Differences usually fall into three groups: paid at bKash but not marked paid (missed confirmation), marked paid but not in the report (investigate immediately), and refunds.

Hypothetical test plan

*Example only.* Successful payment; customer cancels; insufficient balance; network timeout during execute; same order submitted twice; full refund; partial refund. Each case should leave exactly one consistent state in your database.

Why bKash matters to merchants

bKash combines the widest user base in Bangladesh with a dense agent network for cash-in and cash-out, which means it reaches customers far beyond the banked, card-holding population. For a merchant, the practical consequences are:

• The largest single pool of payment-ready consumers in the country.
• High trust for first-time payments to unfamiliar merchants.
• Behaviour habits that make the wallet the assumed default at checkout.
• Reach into semi-urban and rural segments that cards do not serve.

A checkout that presents bKash prominently, with its own branding, converts measurably better than one that hides it behind a generic wallet label.

How bKash payments work for merchants

Payment initiation

The customer selects bKash at checkout. Your gateway creates a payment with an amount, a merchant reference and a callback destination. The customer is directed into a confirmation flow, where they authenticate and approve the payment.

Confirmation and crediting

On approval, the payment is executed and a result is returned. A well-built integration relies on a signed webhook to credit the order, not on the customer returning to your success page — customers close tabs, lose connectivity and switch apps.

Terminal states

Every bKash payment should resolve to a definitive state: completed, failed, cancelled or expired. The state that hurts merchants is the ambiguous one — created but never confirmed. Define a timeout, sweep unresolved payments against the provider's query endpoint, and never leave an order in limbo.

Integration best practice

1. Use idempotency keys on payment creation so a retried request never creates a duplicate charge.
2. Store the provider reference against your internal order ID immediately.
3. Verify webhook signatures and make handlers idempotent — assume duplicates and out-of-order delivery.
4. Poll only as a safety net, never as the primary crediting mechanism.
5. Handle expiry explicitly with clear customer messaging and an easy retry path.
6. Present bKash natively with correct branding and BDT formatting.
7. Log every state transition with timestamps for reconciliation and dispute evidence.
8. Test degraded modes — timeouts, duplicate webhooks, late confirmations — in sandbox before launch.

The general API behaviours to validate are set out in how payment APIs work.

Limits, ticket sizes and rail pairing

Wallet transactions are designed for consumer-scale amounts and are subject to per-transaction and periodic limits set at the wallet and regulatory level. Merchants with higher average order values should pair bKash with bank transfer rails so customers are not blocked at the limit ceiling, and should surface the applicable limit before the customer attempts payment rather than after failure.

A practical structure many merchants use: wallets for small and mid-sized payments, bank rails above a defined threshold, with the checkout automatically recommending the appropriate method by amount.

Improving bKash success rates

Success rate is influenced by more than the rail:

• Method prominence. Native branding and top placement lift completion.
• Clear amount display. Ambiguity about the final charged amount causes abandonment during confirmation.
• Session handling. Keep the merchant session alive so the customer returns to a working order page.
• Time-of-day awareness. Rails degrade under peak load; monitor hourly completion and alert on deviation.
• Retry paths. Offer an immediate alternative method after a failure rather than a dead end.
• Failover. If your provider supports multiple routes to the wallet, health-based routing recovers volume that a single path loses.

Track completion rate by hour, ticket band and customer cohort. Aggregate numbers hide the patterns that are actually fixable.

Payouts and disbursements

Many merchants need outbound bKash flows: refunds, customer withdrawals, agent commissions or partner payments. Payout capability differs from collection capability and should be evaluated separately.

Verify with your provider:

• Per-transaction and daily payout limits
• Beneficiary validation before submission, to reduce returns
• Status lifecycle including returned or reversed payouts
• Batch capability and file formats if you disburse at volume
• Reconciliation of failed payouts back into your ledger
• Realistic completion timelines, including at peak

Payout reliability is a customer-trust issue. In verticals where customers withdraw balances — trading, gaming, marketplaces — it is the single most visible part of your payment operation.

Cross-border settlement of bKash collections

bKash settles in BDT to Bangladeshi bank accounts. A merchant incorporated outside Bangladesh cannot generally hold such an account, so international merchants collect through a partner that operates dedicated Bangladeshi banking and settles abroad in a major currency. Get the settlement cycle, reserve terms and FX methodology in writing — see the cross-border payment guide for South Asia and the Bangladesh payment gateway page.

Where bKash sits alongside other methods

A complete Bangladeshi collection strategy usually looks like: bKash for the broadest coverage and first-time payer trust, Nagad for competitive economics and strong growth, Upay as an incremental coverage add-on, and bank rails for larger tickets. Comparison and selection guidance is in best payment gateway Bangladesh. High-risk merchants should also read how high-risk payment processing works.

Common mistakes

• Crediting orders from the browser redirect instead of the webhook.
• No timeout policy, leaving payments permanently pending.
• Generic wallet branding at checkout.
• Ignoring payout capability until customers request withdrawals.
• No daily reconciliation, so unmatched credits accumulate.
• Single-route dependency with no failover during peak load.

Frequently asked questions

Can I mark an order paid when the customer returns to my success URL?

Only after confirming the status server-side with the API.

Should my site ever collect a customer's wallet PIN?

No. Authorisation happens in bKash's own flow.

Related: bKash vs Nagad for merchants and our bKash payment gateway page.

How do merchants accept bKash payments?

Merchants integrate bKash through a payment gateway that creates a payment with an amount and merchant reference, directs the customer into the bKash confirmation flow, and credits the order on a signed webhook confirming execution, with a query-based sweep as a safety net.

What are the transaction limits for bKash payments?

Wallet payments are subject to per-transaction and periodic limits set at the wallet and regulatory level, sized for consumer payments. Merchants with higher order values should pair bKash with bank transfer rails and display applicable limits before the customer attempts payment.

Can bKash be used for merchant payouts?

Yes, many providers support outbound bKash disbursement for refunds, withdrawals and commissions, but coverage, limits, batch support and return handling vary. Test payout capability separately from collections before relying on it.

How can I improve bKash success rates?

Present bKash natively and prominently, display the exact amount clearly, credit from webhooks rather than redirects, define timeouts and sweeps, offer immediate alternative methods after failure, monitor completion by hour and ticket band, and use health-based routing where multiple paths exist.

Can a foreign company collect bKash payments?

Not directly, because bKash settles in BDT to Bangladeshi bank accounts that generally require a local entity. Foreign merchants collect through a cross-border provider operating dedicated Bangladeshi banking and settling internationally.

How long does bKash settlement take?

Domestic settlement is commonly same-day to T+2 depending on provider and agreement, while cross-border settlement adds the agreed remittance cycle. Confirm cycle, reserve percentage and release timing contractually.

Sources

• bKash Merchant (business): https://www.bkash.com/en/business/merchant
• bKash Developer Portal: https://developer.bka.sh/