Payment gateway selection: A practical guide for Dhaka startups

It is where the city’s layered payment habits meet: a customer moving from a bKash balance to a debit card, a small business buyer paying through a QR code, a returning subscriber expecting a saved-payment experience rather than another round of form filling.

That makes a Bangladesh payment gateway comparison for startups less about choosing the most recognisable logo and more about deciding which financial rails can carry the particular rhythm of a business. A food-delivery platform, a Facebook-first boutique, a SaaS company selling to overseas clients, and a marketplace paying out to thousands of sellers do not have the same needs, even when all of them call their problem “online payments”.

The regulatory landscape is also becoming more visible in the design of everyday commerce. From July 1, 2026, merchants are expected to accept QR payments through Bangla QR under Bangladesh Bank instructions, according to a bKash notice. The shift may look procedural, but it carries a larger implication: payment acceptance is moving towards a more interoperable public-facing layer, rather than being tied solely to one wallet’s familiar square sticker.

Start with the licence, not the sales deck

Payment gateways and payment aggregators operate in Bangladesh within the Payment System Operator, or PSO, framework overseen by Bangladesh Bank. That is the first filter for a founder. A polished onboarding dashboard, a persuasive sales pitch, or a low introductory rate cannot compensate for uncertainty over a provider’s regulatory standing.

Bangladesh Bank’s authorised-entity list includes PSOs such as Sslcommerz Limited, Soft Tech Innovation Limited, ShurjoMukhi Ltd and Portonics Limited, among others. The point is not that every licensed provider offers identical services. They plainly do not. It is that the startup should begin its procurement process with an authorised operator, then examine what that operator can actually deliver for its particular business model.

This distinction matters in a market where “payment gateway” is often used loosely. One provider may offer card and mobile financial service collection for a conventional web shop. Another may have payment links suited to a seller whose business still lives largely on Facebook, Instagram, WhatsApp and phone calls. A third may be strongest for a platform that needs subscriptions, tokenised payments or automated refunds.

Before signing an agreement, founders should ask the provider to confirm, in writing:

• the exact payment methods approved for the merchant category, rather than the provider’s general list of supported rails;
• whether the business can accept bKash, Nagad, Rocket, cards, bank-account payments and Bangla QR where relevant;
• whether payment links, APIs, plugins and mobile SDKs are included or priced separately;
• the available functions for refunds, partial refunds, recurring payments, saved credentials and payouts;
• the documentation required for onboarding, including trade licence, TIN, bank account and business verification materials;
• settlement terms, any reserve requirement, payout fees and the process for disputed transactions.

The paperwork can feel heavy for a small founding team trying to ship quickly. Yet it is part of the architecture of trust. A startup that launches with a gateway unsuitable for its cash flow often discovers the problem only after sales arrive: settlement is slower than assumed, a refund has to be handled manually, or a key payment method was never activated for that merchant account.

The right gateway is not the one with the longest list of logos. It is the one whose approved rails match the way your customers already pay.

Cost is more than the transaction rate

The most visible figure in a gateway proposal is usually the merchant discount rate, or MDR: the percentage deducted from a successful payment. It is also the number founders most often compare in isolation. That is understandable, but incomplete.

SSLCOMMERZ, for example, lists a Basic plan with a non-refundable one-time fee of ৳25,500 and a 2.5% charge per successful transaction. Its listed rate for American Express transactions is 3.5%. These are useful public reference points, especially for a new online business building an early financial model. But they are not enough to establish the full cost of accepting money.

A practical comparison needs to account for the money that moves around the headline percentage: initial setup, VAT treatment, payment-method-specific rates, refund handling, chargeback administration, bank-transfer or payout fees, and any rolling reserve or hold. Public, current price cards for several providers, including aamarPay, bKash, ShurjoPay and PortWallet, are not always readily established, and pricing can vary with merchant category, volume and the mix of payment methods.

A simple illustration shows why this matters. A 2.5% MDR looks manageable for a service with strong margins. It feels very different for a commerce startup already absorbing delivery subsidies, packaging, return rates and promotional discounts. The gateway expense should be treated as part of unit economics, alongside acquisition cost and fulfilment—not as an afterthought to be absorbed by “growth”.

For Bangla QR, Bangladesh Bank’s guidelines make the allocation especially clear: the MDR must not be passed to the customer. The merchant needs to understand the net cost before displaying a QR code at a counter, at a pop-up event, or on a delivery invoice. This is not merely a compliance detail; it affects how honestly a business prices its product.

Reach means local payment habits, not just cards

The shape of digital commerce in Bangladesh is inseparable from mobile financial services. Card acceptance remains valuable, especially for certain urban consumers, corporate buyers and international-facing businesses. But for many local startups, the wider question is whether checkout meets the customer in the payment environment they use every day.

SSLCOMMERZ lists Visa, Mastercard, bKash, Nagad and Rocket among its standard channels. aamarPay states that its accepted methods include Visa, Mastercard, UnionPay, Qcash, bKash, Rocket, Nagad, Tap, Upay, SureCash, OK Wallet and Nexus, and it advertises both API access and payment links. For a small merchant operating without a fully developed online store, payment links can be more than a convenience: they can form a bridge between informal social selling and a more traceable digital payment flow.

bKash, meanwhile, presents a different proposition. Its online-business offering includes a payment gateway, tokenised checkout, subscription payments, instant refunds, direct charges, B2C payout and APIs. Its merchant material says businesses can accept payments from more than 70 million bKash users. That figure is the company’s stated reach rather than an independently audited market-share measure, but it still explains why bKash integration is a strategic question for so many consumer startups.

The useful comparison is therefore not “SSLCOMMERZ versus bKash” in a simplistic sense. A broad gateway can offer a portfolio of rails, while a mobile financial service can offer deeper functionality inside its own payment ecosystem. A startup may need one, the other, or a combination structured through its chosen provider.

Bangla QR adds another layer of reach. Under Bangladesh Bank guidelines, merchants can accept payments from bank accounts, debit cards, credit cards, prepaid cards, MFS accounts and e-wallet accounts through the QR framework. The applicable transaction limits are generally determined by the issuer unless Bangladesh Bank sets a limit. Founders should resist treating a published platform limit as a universal ceiling for every customer and every payment type.

The value of Bangla QR is cultural as well as technical. It allows the small counter, the café table, the temporary design fair stall and the polished app checkout to participate in a more common payment vocabulary. In a city where commerce moves continuously between storefronts, couriers and social feeds, that interoperability has practical weight.

Checkout must survive the real authentication journey

A gateway integration can look elegant in a staging environment and still break confidence in production. Bangladesh Bank requires participating banks to ensure two-factor authentication for online, e-commerce, interbanking and card-not-present transactions. For founders, this means authentication should be tested as a full customer journey, not treated as a compliance tick beside a card-entry field.

The user may move from the startup’s website to a bank or wallet interface, approve an OTP or other second factor, then return to the merchant environment. Every transition creates a place where a customer can lose patience, abandon the purchase, or be left uncertain about whether money has been deducted.

The testing process should include more than a successful payment. A capable startup team will walk through:

1. A completed payment on each approved method. Test cards and local MFS options separately. The checkout experience is not identical across channels, and an integration that works for a card may behave differently for a wallet.

2. An interrupted authentication flow. Let an OTP expire, close the browser, switch applications on a mobile device, or lose connectivity briefly. The customer needs a clear status rather than a vague “processing” screen.

3. A callback or webhook delay. The application should not mark an order as paid merely because a user has been redirected. It should reconcile the final transaction status received from the payment provider.

4. Duplicate-click protection. Dhaka’s mobile internet users are accustomed to variable connections. A customer pressing “Pay” twice should not create two orders or two fulfilment requests.

5. The refund journey. A refund button in an administrative panel is not the same as a reliable customer experience. Test who can initiate it, whether it supports partial amounts, how it appears in reconciliation, and how the customer is notified.

6. The support handover. When a payment is disputed, the startup’s customer-care team needs transaction references, readable status information and a defined route to the gateway’s support team.

This is where technical integration becomes a matter of social trust. A failed payment at midnight might be a minor inconvenience for a software company. For a medicine-delivery service, a ticketing platform or a business selling a limited-run product during a launch campaign, it can quickly become a public customer-service problem.

Payment friction is rarely remembered as a technical error. Customers remember it as the moment a business seemed uncertain with their money.

Settlement is a cash-flow decision

A startup can record a successful sale and still be unable to use the money immediately. That distinction is easy to overlook in a pitch deck and unavoidable in operations.

For successful Bangla QR transactions processed through Bangladesh Bank’s network, the guidelines state that settlement takes place on the next business day. Customers and merchants should receive real-time transaction-status notifications through SMS or email, but notification is not the same thing as funds being available in the business bank account.

For a founder paying riders, freelance staff, suppliers or cloud bills from daily receipts, the settlement cycle belongs in the same conversation as pricing. It should be mapped against the company’s cash conversion cycle: how soon the startup must pay for stock or service delivery after a customer places an order.

A grocery-delivery venture with rapid supplier payments may need a different financial arrangement from a digital education platform whose costs are largely fixed. Neither model is better; their need for liquidity is simply different.

Questions worth resolving before launch include:

• What is the settlement schedule for each payment method, not just for the gateway overall?
• Are weekends and public holidays counted as settlement days?
• Is there a minimum payout threshold?
• Are reserves or rolling holds applied, and under what circumstances?
• How are failed, reversed and disputed payments shown in the merchant report?
• Can finance staff export reconciled transaction data in a usable format?
• What is the process if the startup believes a transaction has been incorrectly marked as successful or unsuccessful?

The available public material does not establish current settlement cycles, reserve policies, chargeback timelines or service-level commitments across providers. A responsible comparison must leave that uncertainty visible rather than filling it with assumptions. Ask for terms, preserve the written response, and test the reporting interface before making a long-term commitment.

A sharper way to choose between SSLCOMMERZ, aamarPay and bKash

There is no single best payment gateway for small business in Bangladesh because “small business” conceals radically different operational realities. Still, the three names often enter the same Dhaka startup conversation for understandable reasons.

SSLCOMMERZ offers a public pricing reference that helps founders begin modelling costs. Its stated standard payment channels give a conventional e-commerce business a recognisable starting point: cards alongside major local MFS options. The relevant question is whether the startup’s expected transaction mix makes the listed fee structure viable after delivery, promotion and return costs.

aamarPay’s stated acceptance list is notably broad, covering multiple card schemes, MFS services and other domestic payment options. Its payment-link offering may be especially relevant for merchants whose sales process has not yet settled into a conventional web-store format. But the business still needs a current written quotation and confirmation that the desired methods are enabled for its own account.

bKash’s platform deserves attention where the product needs deeper wallet-centred features: tokenised checkout, subscriptions, instant refunds, direct charges or B2C payout. Its scale in consumer life makes it difficult to treat MFS integration as an optional add-on for many categories. Yet bKash reach does not automatically resolve card acceptance, cross-border collections or the broader reconciliation needs of a multi-rail marketplace.

For startups earning from overseas customers, a domestic gateway should not be assumed to solve export collection by default. Bangladesh Bank’s December 2020 circular permits B2C export proceeds from internet-accessible e-commerce websites through international cards, online payment gateway service providers, digital wallets and other legitimate systems licensed by relevant regulators. The route still needs to align with foreign-exchange rules and the provider’s approval terms for that merchant.

The most durable approach is modest but rigorous: draw up the expected payment mix for the first six months, request matched written offers, test the live workflow, and make settlement visibility part of the decision. The gateway is not just an expense line. It is a small piece of urban infrastructure, shaping whether a customer in Mirpur, Banani or beyond Dhaka experiences a young company as accessible, credible and ready for repeat business.

Bangladesh’s startup economy often celebrates the front-end drama of launches, funding and user growth. Payment infrastructure is quieter. But it is in that quieter layer—where trust, regulation, interface design and everyday purchasing habits meet—that many young businesses either acquire momentum or quietly lose it.