If most of your customers pay with bKash, your checkout should be designed around bKash first, not around a card form with a mobile wallet bolted on at the end. That means putting the wallet at the top, keeping the hand-off to the bKash screens short and predictable, and planning for the moment someone’s OTP arrives late. This guide covers the bKash payment integration and checkout design decisions we make when building stores and apps for Bangladeshi customers.
Why bKash-first checkout design matters
Most checkout patterns online were shaped by card-heavy markets in North America and Europe. The default template is a shipping form, then a card number field, then a big pay button. In Bangladesh that template quietly works against you. Mobile financial services such as bKash and Nagad are part of everyday life, card ownership is far less universal, and cash on delivery is still a habit for many online shoppers.
When the card form is the default and the wallet is a small logo below it, you are asking the majority of buyers to hunt for the way they actually pay. Every extra moment of doubt at checkout is a chance to abandon the cart. Designing bKash-first is not a visual trick; it is matching the order of the screen to the order of real behaviour.
Start with how people actually pay
Before drawing a single screen, we map the payment mix the business expects. You do not need perfect data for this. Order history, a conversation with the customer support team, and a look at how competitors present payment options are usually enough to answer three questions:
- Which method do most buyers choose today: bKash, Nagad, card, bank transfer or cash on delivery?
- Do buyers usually pay on the same phone they browse on, or do they switch devices?
- How often does support hear about failed or duplicated payments, and at which step?
The answers decide the order of payment options, the default selection and how much space each method gets. If bKash is the most common choice, it should be preselected, visible without scrolling on a phone, and labelled in plain words such as “Pay with bKash” rather than a tiny logo.
bKash payment integration: designing the flow step by step
A typical bKash checkout hands the customer from your site to a bKash-hosted payment screen, where they enter their wallet number, confirm a one-time password sent by SMS, and authorise the payment with their PIN. Your site never sees the PIN. That hand-off is the part most stores get wrong, because the customer briefly leaves your brand and enters someone else’s interface.
Before the hand-off
Tell the customer exactly what will happen next. A single line such as “You will confirm this payment in bKash with an OTP and your PIN” removes a surprising amount of hesitation. Show the final amount, including delivery, in large type right next to the pay button, so the number on the bKash screen matches what they just saw. Mismatched totals are one of the fastest ways to make someone cancel.
During the hand-off
Keep the transition fast and branded where you can. If the bKash screen opens in a new window or overlay, make sure your page behind it shows a calm “Waiting for bKash confirmation” state instead of a frozen pay button that invites a second tap. Double taps are a common source of duplicate payment attempts, so disable the button and show progress as soon as it is pressed.
After the hand-off
When the customer returns, the confirmation page should repeat the transaction reference from bKash, the amount and what happens next. People screenshot this page. Make it worth screenshotting: order number, transaction ID, delivery estimate and a support number on one screen, with no marketing clutter competing for attention.
Planning for the failure states
The happy path is easy to design. The quality of a payment flow shows in how it handles the unhappy ones. For a wallet-first checkout we design and test each of these explicitly:
- OTP delay. SMS can arrive late. Give the customer a clear way to retry without starting the whole checkout again, and keep their cart and address intact.
- Insufficient balance. Say so plainly and offer the next best option, such as Nagad, card or cash on delivery, without losing the order.
- Customer closes the bKash screen. Return them to a payment step that remembers everything, with the bKash option still selected.
- Payment succeeded but the return failed. This is the dangerous one. Verify the payment status on the server before showing any error, so a paid customer is never told to pay again.
- Duplicate attempts. Use idempotent order handling on the back end so one order can only be paid once, however many times the button is pressed.
Write the error messages in the same plain language as the rest of the store, and offer Bangla where your audience expects it. “Payment failed, code 2023” helps nobody; “bKash did not confirm the payment. Your money has not been taken. Try again or choose another method” does.
Nagad, cards and cash on delivery: designing the fallbacks
bKash-first does not mean bKash-only. A healthy Bangladeshi checkout usually offers several methods, and the design job is to rank them, not to hide them. We tend to group options into two tiers: the one or two methods most buyers use, shown as large selectable cards, and the rest in a compact list underneath.
Payment aggregators such as SSLCommerz can bundle cards, wallets and internet banking behind one integration, which is useful when you need breadth quickly. Direct wallet integrations give you more control over the experience. Which route makes sense depends on volume, settlement needs and how much the checkout must feel like your own brand.
Cash on delivery deserves honest design too. If you charge a COD fee or limit it to certain areas, say so on the payment step, not at the end. Some stores nudge customers toward prepaying by offering a small benefit for wallet payments; that is a business decision, but it should be shown clearly and never as a hidden penalty.
Trust signals that matter in Bangladesh
Trust at checkout is local. Badges that reassure buyers in London or New York may mean little in Dhaka or Chattogram. The signals we prioritise for Bangladeshi customers are concrete and checkable:
- A local phone number and support hours, visible on the payment step.
- Recognisable payment logos used correctly, next to plain-text labels.
- A clear refund and cancellation policy, written in simple language and linked from checkout.
- Delivery partners and realistic delivery times for the customer’s area.
- An order confirmation by SMS, which many buyers trust more than email.
A payment flow is a promise. Every screen should tell the customer what will happen, how much it costs and what to do if something goes wrong.
Building it well: technical notes for the team
Good checkout design falls apart without solid engineering behind it. On WooCommerce, Shopify or a custom build, the same rules apply. Keep the merchant credentials on the server, never in front-end code. Confirm every payment with a server-side status check rather than trusting the browser redirect. Log each step of the payment lifecycle with timestamps so support can answer “did my money go through?” in seconds.
Test on the devices your customers actually use, which often means mid-range Android phones on mobile data rather than a fast laptop on office Wi-Fi. A checkout that feels instant on fibre can stall on a weaker connection, and that is exactly when someone gives up. Keep the payment page light: no heavy sliders, no autoplay video and no third-party widgets that are not essential to paying.
For stores selling both locally and abroad, we usually show the payment options based on the delivery country. A buyer in Dhaka sees bKash first; a buyer in Dubai or London sees cards and international wallets first. One codebase, two sensible defaults. If you are planning a store like this, our e-commerce website development team builds both sides from day one.
Key takeaways
- Order payment methods by how your customers actually pay; for many Bangladeshi stores that means bKash first.
- Explain the OTP and PIN hand-off before it happens and show the exact total next to the pay button.
- Design every failure state, especially “paid but the return failed”, and verify payments on the server.
- Offer Nagad, cards and cash on delivery as clear fallbacks rather than hiding them.
- Use local trust signals: phone support, SMS confirmations and plain-language refund policies.
Want a checkout that fits the way your customers pay? Our UI/UX design and development team in Dhaka designs and builds wallet-first payment flows for stores in Bangladesh and abroad. Book a discovery call and we will review your current checkout with you.