Best Payment Gateway Bangladesh: 2026 Merchant Guide

Bangladesh has become one of the fastest digitising payment markets in South Asia. Mobile financial services now move a very large share of everyday consumer value, card penetration remains modest, and a growing base of merchants — from local e-commerce brands to internationally licensed operators — need a way to collect from Bangladeshi customers reliably. Choosing the best payment gateway in Bangladesh is therefore less about brand names and more about matching your business model to the rails, settlement structure and risk appetite of the provider.

This guide is written for merchants who have to make that decision in practice: what to compare, which questions expose weak providers, how settlement really works, and what changes when your business sits in a high-risk category.

What is a payment gateway?

A payment gateway is the software layer that stands between your checkout and the financial institutions that actually move money. When a Bangladeshi customer taps "Pay with bKash", the gateway collects the payment instruction, authenticates it with the wallet or bank, waits for the rail's response, and then tells your application whether the money is real. Behind that single moment sit four separate jobs: routing the request to the right acquiring relationship, holding a durable record of the attempt, reconciling the rail's settlement file against those records, and paying the balance out to you.

It helps to separate three terms merchants often use interchangeably. A payment gateway is the technical interface — the API, hosted checkout and webhooks. An acquirer or processor holds the licensed relationship with the wallet or bank that clears funds. A payment service provider (PSP) typically bundles both, plus onboarding, risk monitoring and settlement. In Bangladesh most merchants deal with a PSP, because direct wallet relationships require local incorporation, deposits and a compliance function most businesses do not want to build.

The gateway is also where your commercial reality is enforced. Limits per transaction, per day and per method; which categories are permitted; how refunds and disputes are handled; how quickly funds land — all of that is configured at the gateway and acquiring layer, not in your storefront. That is why the selection decision deserves more scrutiny than a pricing page comparison.

Why businesses need a payment gateway in Bangladesh

Bangladesh's consumer payment behaviour is wallet-first. A merchant who only offers cards will convert a small fraction of intent, because most customers do not hold an internationally enabled card and are not used to entering card details online. A gateway that terminates bKash, Nagad and bank transfer natively removes that friction and gives you a single reconciliation surface across every method.

There are four concrete reasons merchants integrate rather than improvise:

• Conversion. Native method buttons convert materially better than a generic "mobile banking" instruction with manual reference numbers. Every manual step — copying a merchant number, typing a transaction ID, waiting for human confirmation — costs completed orders.
• Automation. Manual collection means somebody reads SMS confirmations and credits accounts by hand. That does not scale, and it creates a fraud surface (forged screenshots, duplicated reference IDs) that automated verification closes.
• Reconciliation. A gateway produces a ledger: attempt, authorisation, capture, settlement batch, payout. Without it, finance reconciles wallet statements against orders by hand at month end.
• Compliance. Regulated collection creates the audit trail that banks, auditors and licensing bodies expect — transaction narration, KYC of the merchant, and traceable settlement.

If you also pay money out — affiliate commissions, agent payouts, customer withdrawals — the same argument applies in reverse. Disbursement APIs to bKash, Nagad and bank accounts remove batch spreadsheets and the operational risk that comes with them. You can see how these pieces fit together on our payment infrastructure page, and the market-level view on the Bangladesh payment gateway page.

What a payment gateway actually does in Bangladesh

A payment gateway is the technical layer that takes a customer's intent to pay, routes it to the correct rail, and returns a definitive result to your system. In Bangladesh that rail is usually one of three things: a mobile financial service wallet such as bKash, Nagad or Upay; a domestic bank transfer over local clearing rails; or a card transaction on an international scheme.

The gateway is not the same thing as the entity holding the funds. Many merchants discover this distinction late. The gateway gives you an API, a checkout, webhooks and reconciliation data. A processor, acquirer or licensed partner is what actually settles money into an account you control. Understanding the difference is the single most useful thing you can do before signing anything — we cover it in depth in payment gateway vs payment processor.

Why local method coverage decides conversion

In most Bangladeshi checkouts, the difference between a good and a poor gateway is not fees. It is whether the customer sees the wallet they already use, branded correctly, as a first-class option. Merchants who present a generic "mobile banking" button instead of native bKash and Nagad options routinely lose a double-digit share of otherwise willing payers. Conversion is a coverage problem before it is a pricing problem.

The payment methods that matter

bKash

bKash is the largest mobile wallet by active users and the default assumption for most consumers. It performs strongly on collections, has broad agent coverage for cash-in, and is the method customers trust most for first-time payments to an unfamiliar merchant. Payouts and bulk disbursement flows are supported but generally require tighter operational discipline and clean beneficiary data.

Nagad

Nagad is state-affiliated, has grown aggressively, and often carries more favourable commercial terms in specific segments. Many merchants run Nagad as the primary wallet for unit economics and bKash as the coverage guarantee. Success rates are competitive, and the brand is well trusted in semi-urban and rural segments.

Upay

Upay has a smaller share but is meaningful in particular demographics and employer-linked user bases. It is best treated as a coverage add-on: enabling it typically lifts total addressable payers by a few percentage points at low incremental cost.

Bank transfer rails

For larger ticket sizes, local bank transfers remain essential. Wallet transaction limits are practical for consumer-sized payments but not for high-value funding. A serious gateway will pair wallet collections with dedicated Bangladeshi bank accounts and automated reconciliation so that a BDT bank credit maps to the correct customer order without manual work.

Cards

International card acceptance exists but is a minority channel for domestic Bangladeshi consumers, and issuers apply strict controls on cross-border and merchant-category-sensitive transactions. Treat cards as complementary, not foundational, unless your customer base is diaspora or corporate.

For a deeper breakdown of the operational behaviour of each wallet, see the bKash merchant payment guide and our country page on high-risk payment solutions in Bangladesh.

How to evaluate a Bangladesh payment gateway

1. Method coverage and real success rates

Ask for method-level authorisation and completion rates over the last ninety days, not a headline number. A provider quoting "98% success" without segmentation is quoting a marketing figure. What matters is completion rate per method, per ticket band, per hour of day. Wallet flows degrade during peak load and during telco or MFS maintenance windows; a good gateway shows you that honestly and has failover.

2. Settlement currency, destination and timeline

This is the question that separates domestic gateways from cross-border capable ones. A local Bangladeshi PSP will settle BDT into a Bangladeshi bank account in the merchant's local legal entity name. If your company is registered abroad, that structure may not be usable at all. Establish, in writing:

• Which currency you receive
• Which legal entity and jurisdiction receives it
• The settlement cycle (daily, T+1, T+2, weekly)
• The rolling reserve percentage and release schedule
• The FX methodology and spread if conversion is involved

3. Onboarding and documentation reality

A gateway that promises instant onboarding for any business is either not doing meaningful KYC or is going to freeze you later. Expect to provide incorporation documents, ownership and UBO details, a licence where your vertical requires one, website and flow-of-funds documentation, historical processing statements and a clear description of your customer base. Our merchant payment infrastructure guide walks through preparing this pack once and reusing it.

4. API quality and webhook reliability

You will live inside this API for years. Evaluate idempotency support on payment creation, signed webhooks with retry and replay protection, a sandbox that mirrors production semantics, clear terminal states, and a reconciliation endpoint or file that can be diffed against your ledger. Polling-only integrations are a warning sign. See how payment APIs work for the specific behaviours to test.

5. Support model and escalation

Payments fail at 2am. Ask who answers, in what channel, with what response target, and whether you get a named account contact. In Bangladesh specifically, ask how the provider communicates during MFS-side outages — silence during an outage costs you more than the outage.

6. Compliance posture

The provider should be able to explain its licensing or partnership structure, its AML and sanctions screening approach, how it handles suspicious activity, and how it treats data under Bangladeshi requirements. A provider that cannot describe its own compliance model is a liability on your balance sheet.

Pricing: what you actually pay

Headline MDR is only one component. Build a full cost model that includes the per-transaction rate by method, fixed per-transaction fees, payout or disbursement fees, FX spread on cross-border settlement, chargeback and dispute fees, monthly platform or gateway fees, rolling reserve opportunity cost, and the cost of failed transactions in lost conversion.

A gateway that is 0.3% cheaper but converts 6% worse is far more expensive. Model total landed cost per successful order, not MDR.

Domestic gateways versus cross-border capable providers

Domestic Bangladeshi gateways are excellent when you are a locally incorporated merchant selling to local customers with a local bank account and a low-risk category. They typically offer competitive local pricing and direct MFS relationships.

Cross-border capable providers matter when any of the following is true: your entity is registered outside Bangladesh, you need settlement in USD or EUR, you operate in a vertical that domestic banks will not sponsor, or you need one integration covering Bangladesh alongside India, Pakistan and Nepal. That multi-market case is covered in the cross-border payment guide for South Asia.

High-risk merchants: a different selection problem

If you operate in Forex, online gaming, betting, casino or similar verticals, most of the above still applies, but the shortlist shrinks dramatically. Mainstream international PSPs exclude these categories in their acceptable use policies. Local PSPs may accept the traffic but cannot settle it internationally.

What you need instead is a provider that is explicitly built for the category, is honest about what it can and cannot place, holds dedicated local banking relationships, and prices risk transparently rather than hiding it in reserves. Read how high-risk payment processing works and, if you are in trading or wagering specifically, the Forex payment processing guide and betting payment processing guide.

Integration checklist before you go live

1. Confirm sandbox parity with production, including failure cases and timeouts.
2. Implement idempotency keys on every payment creation call.
3. Verify webhook signatures and make handlers idempotent and replay-safe.
4. Store the provider transaction reference against your internal order ID from the first call.
5. Build automated daily reconciliation between your ledger and the provider report.
6. Define your refund and dispute workflow, including who is authorised to approve.
7. Expose native wallet branding in checkout, not a generic label.
8. Instrument drop-off by method and ticket band from day one.
9. Test peak-load behaviour and degraded-mode fallbacks.
10. Agree an escalation path and outage communication protocol in writing.

Common mistakes merchants make in Bangladesh

• Choosing on MDR alone and losing far more to conversion.
• Enabling only one wallet and assuming coverage is fine.
• Ignoring reconciliation until the first month-end, then discovering thousands of unmatched credits.
• Not asking about settlement entity until after integration is finished.
• Treating high-risk category disclosure as optional — which reliably ends in a frozen account.
• Building on polling instead of webhooks and shipping slow funding times.

How PayEurasia approaches the Bangladesh market

PayEurasia operates dedicated Bangladesh banking relationships and integrates directly with the major mobile wallets, pairing wallet collections with bank rails for higher ticket sizes. We settle cross-border on transparent terms, publish method-level performance to merchants, and are direct during onboarding about what we can and cannot support. Merchants running multiple South Asian markets use one integration across Bangladesh, India, Pakistan and Nepal rather than stitching four local providers together.

If you want the country-level detail, start with the Bangladesh payment gateway page, or contact our team with your volumes, entity structure and vertical and we will tell you plainly whether we can place it.

Security: what a serious gateway must do

Security in payments is not a single feature. It is a set of controls that a merchant should be able to verify during evaluation rather than take on trust.

Transport, storage and key handling

Every endpoint should be TLS-only with modern ciphers, and API credentials should be scoped, rotatable and revocable without downtime. Ask whether you get separate sandbox and production keys, whether keys can be limited by IP, and what happens operationally if a key leaks at 2am. A provider that cannot rotate a key without a support ticket queue is a provider that will be slow when it matters.

Webhook authenticity

Webhooks are the most commonly abused surface in payment integrations. A gateway should sign every callback with an HMAC over the raw body using a shared secret, include a timestamp to make replay detection possible, and document the exact canonical string being signed. On your side, verify the signature before parsing, reject stale timestamps, and treat webhook delivery as at-least-once: the same event may arrive twice.

Idempotency and double-charge protection

Networks fail mid-request. Without idempotency keys, a retried charge becomes a second charge and a refund workload. Insist on documented idempotency semantics on every money-moving endpoint, and implement them on your side too — see the API documentation for how PayEurasia handles idempotency keys and retry behaviour.

Fraud and abuse controls in a wallet market

Wallet fraud in Bangladesh looks different from card fraud. Chargebacks are rare on wallet rails, but you will encounter forged payment screenshots, refund-abuse patterns, agent-assisted account takeovers, and structuring across many small deposits. Useful controls include velocity limits per customer and per device, name/number matching between the wallet and the registered account, deposit and withdrawal asymmetry checks, and manual review queues for anything above a threshold you set.

Data protection and access control

Ask who inside the provider can see your transaction data, whether admin access is role-based, whether sensitive fields are masked, and whether an audit log records every administrative action. If you handle card data at all, ask directly about PCI DSS scope and whether the hosted checkout keeps your servers out of scope.

Merchant onboarding: what actually happens

Onboarding is where most Bangladesh gateway decisions stall, so plan for it as a project rather than a form.

Documents you should prepare

• Certificate of incorporation and memorandum/articles (local or foreign entity)
• Trade licence and TIN/BIN where a Bangladeshi entity is involved
• Ownership structure with UBO identification, plus passports or NID for directors and beneficial owners
• Bank statements or proof of an operating account for settlement
• Website URL with visible terms, refund policy, contact details and pricing
• Expected monthly volume, average ticket size, and a description of the product being sold
• Licence documentation where your vertical requires it

The sequence

1. Commercial scoping. Methods, currencies, volumes, settlement destination.
2. KYB and risk review. Document collection, sanctions and adverse-media screening, business model review.
3. Approval with terms. Limits, pricing, rolling reserve if applicable, settlement cycle.
4. Technical onboarding. Sandbox keys, integration, webhook endpoints, test transactions.
5. Go-live in stages. A capped live period while success rates and settlement are verified, then limits raised.

Realistic timelines range from a few days for a straightforward domestic e-commerce merchant to several weeks for a foreign entity in a regulated vertical. A provider that promises same-day approval for a complex case is either not doing underwriting or will unwind the account later. You can start the process on the merchant onboarding page.

Questions to ask before you sign

• What exactly triggers a limit reduction, a reserve increase or a hold?
• Who is the named escalation contact, and what is the response time commitment?
• What is the notice period and the fund-release schedule if either side terminates?
• Which method-level restrictions apply to my category, and can I see them in writing?

Cross-border support and getting paid outside Bangladesh

This is the single question that separates domestic gateways from providers useful to internationally incorporated merchants. Domestic Bangladeshi PSPs collect BDT and settle BDT into a local bank account held by a locally registered entity. If your operating company sits in Dubai, Cyprus, Curaçao or Singapore, that structure does not reach you.

A cross-border capable provider maintains the local collection infrastructure — bank accounts and wallet relationships inside Bangladesh — and then settles to you internationally against a clear FX and fee schedule. What to verify:

• Settlement currency and FX. Which currencies are available, what reference rate is used, and what spread is applied. A quoted 2% MDR with an undisclosed 3% FX spread is a 5% cost.
• Settlement destination. Bank account, and whether beneficiary and merchant entity must match.
• Documentation for the corridor. Invoices, contracts or licence evidence that the remitting bank will require.
• Cut-offs and holidays. Bangladeshi banking holidays and weekend structure (Friday–Saturday) shift value dates.

If you collect in more than one South Asian market, consolidate before you scale integrations — that is what the cross-border payment solutions page describes, and the countries hub summarises coverage per market.

API and integration in practice

A good integration is boring. It should take a competent developer days, not weeks, and it should fail predictably.

The shape of a sane integration

1. Create a payment intent server-side with an amount, currency, method and your own order reference.
2. Redirect the customer to the hosted checkout or invoke the method-specific flow.
3. Receive an asynchronous webhook carrying the terminal status.
4. Verify the signature, look up your order by your own reference, and apply the state change idempotently.
5. Reconcile daily against the settlement report rather than trusting webhooks alone.

What to test in sandbox before you commit

• Success, decline, timeout, and user-abandonment paths on every method
• Duplicate webhook delivery and out-of-order delivery
• Partial refunds and full refunds, including the resulting webhook events
• Rate-limit behaviour and error payload structure
• Reconciliation report format: does it contain your order reference, the method, fees and the settlement batch ID?

Operational instrumentation

Track authorisation rate by method, by hour and by amount band. A drop in bKash success at 9pm on Thursdays is a routing or capacity story, not a random fluctuation, and you can only act on it if you measure it. Ask your provider whether they will share method-level success telemetry with you; a provider that treats their own performance data as confidential is telling you something.

Settlement mechanics explained

Settlement is where merchant cash-flow planning succeeds or fails, and the details are rarely on a pricing page.

• Cycle. T+1, T+2 or weekly. Confirm whether "T" means the transaction date or the batch close date, and what the daily cut-off time is.
• Batching. Are all methods settled in one batch, or does each rail settle separately? Separate batches make reconciliation cleaner but produce more inbound transfers.
• Reserves. A rolling reserve (for example 5% held for 90 days) is normal in higher-risk categories. What matters is that the percentage, the holding period and the release schedule are written down.
• Fee deduction. Netted from the settlement or invoiced monthly. Netting is simpler; invoicing gives cleaner revenue reporting.
• Refund funding. Are refunds drawn from incoming volume or from a prefunded balance? On a low-volume day, a refund-heavy merchant can go negative.
• Reporting. You need a settlement report that ties every payout line back to individual transactions. Without it, month-end close is guesswork.

Write your expected settlement behaviour into the agreement. "Usually next day" is not a commitment.

Frequently asked questions

What is the best payment gateway in Bangladesh for e-commerce?

The best choice is the gateway that natively supports bKash, Nagad and Upay with strong per-method success rates, settles into an account your legal entity can actually use, and gives you reliable webhooks and reconciliation. For locally incorporated low-risk merchants a domestic PSP is often sufficient; internationally incorporated merchants usually need a cross-border capable provider.

Can a foreign company accept payments in Bangladesh?

Yes, but not usually by contracting a domestic PSP directly, because domestic settlement typically requires a local entity and local bank account. Foreign companies generally work with a cross-border provider that operates dedicated Bangladeshi banking and settles internationally in a major currency.

Is bKash or Nagad better for merchants?

Neither dominates in every case. bKash gives the broadest user coverage and highest trust for first-time payers, while Nagad often offers better commercial terms and strong growth. Most merchants run both and treat Upay as an incremental coverage addition.

How long does settlement take in Bangladesh?

Domestic settlement is commonly same-day to T+2 depending on the provider and method. Cross-border settlement usually adds a cycle and depends on the agreed schedule, reserve policy and banking corridor. Always confirm the exact cycle and reserve terms in your contract.

What documents are needed to onboard with a Bangladesh payment gateway?

Typically incorporation documents, ownership and UBO information, director identification, proof of address, website and product documentation, a description of your flow of funds, any required licence for your vertical, and historical processing statements if you are migrating.

Are high-risk businesses accepted in Bangladesh?

Mainstream providers generally decline Forex, gaming, betting and casino traffic. Specialist high-risk providers do support these verticals with appropriate structure, pricing and monitoring. Disclose your category up front — undisclosed high-risk traffic is the most common cause of account termination.

Where to go next

For method-level detail, the bKash and Nagad guides cover integration behaviour per wallet, while the Bangladesh payment gateway page summarises coverage and settlement for the market as a whole. Merchants selling across the region should compare markets on the countries hub, restricted categories should begin with high-risk payment solutions for Bangladesh, and developers can review the API overview before requesting sandbox credentials to size the integration effort accurately.

Conclusion

There is no single best payment gateway in Bangladesh, because the right answer depends on your entity structure, your category and where your money needs to end up. What is consistent is the evaluation method: verify method coverage against real success rates, understand the settlement chain end to end, read the onboarding requirements before you build, and test the failure paths rather than the happy path. Merchants who do that rarely need to migrate providers twelve months later; merchants who choose on headline MDR usually do.

If you are internationally incorporated, or you operate in a category that domestic PSPs decline, the shortlist narrows quickly to providers that hold local Bangladeshi collection infrastructure and can settle cross-border with documentation that survives a bank's review.

Next step

PayEurasia operates local collection rails in Bangladesh across bKash, Nagad and bank transfer, with cross-border settlement, signed webhooks and reconciliation reporting built in. If you want a straight answer about whether your business can be supported, request an integration or start the merchant onboarding process — including for high-risk verticals in Bangladesh.

Related reading

• bKash Payment Gateway and Nagad Payment Gateway — method-level integration detail
• Bangladesh Payment Gateway — market overview and coverage
• High Risk Merchant Payment Processing — underwriting and routing for complex categories
• Solutions and API — collections, payouts and developer surface
• Countries — coverage across Bangladesh, India, Pakistan and Nepal