bKash Payment Gateway for a Restaurant Storefront

The bKash payment gateway is how a restaurant takes bKash on its own ordering site, where there is no cashier to confirm anything. A counter QR is fine for someone standing at your till, but it does nothing for a customer paying from their phone at home. The gateway fills that gap: your software creates a payment, sends the customer to bKash to approve it, then verifies the result automatically. This guide explains what the bKash payment gateway does for a restaurant storefront, the difference between sandbox and live, the credentials you need, and how Rosuii uses it to verify each payment against the order.

Where a detail can change, such as a URL or a charge, treat it as a prompt to check bKash's current developer documentation and merchant terms rather than a fixed value.

What the bKash payment gateway does

bKash's online product is commonly called Tokenized Checkout, and people also refer to it as the bKash PGW (payment gateway). It lets a website or app take a bKash payment without a person reading a confirmation screen. The flow, simplified, is:

1. The customer reaches checkout on your ordering site and chooses bKash.
2. Your server asks the gateway to create a payment for that order's amount.
3. The customer is taken to bKash to approve and authorise the payment.
4. Your server executes the payment, then queries it to confirm it really went through.
5. The order is marked paid only after that confirmation comes back.

The important part is the last two steps. The gateway does not just trust that the customer tapped a button. Your software verifies the result against bKash before treating the order as paid, which is what stops fake or failed payments slipping through. This is different from the in-store QR covered in our bKash merchant account guide, where a human reads the confirmation.

What credentials you need

To use the bKash payment gateway you need an active bKash merchant account with API access. From bKash you receive a set of gateway credentials. Based on bKash's developer documentation for Tokenized Checkout, these are:

• An app key and an app secret, which identify your application.
• A gateway username and password.

Behind the scenes, your server uses these to get a short-lived access token (a grant-token step), then uses that token to create, execute and query payments, and to issue refunds. You do not need to build that yourself if your software already supports bKash, but it helps to know what the four values are for when you paste them in. One rule matters above all: these keys belong on your server only, never in a web page or app where a customer could read them. bKash's own guidance is to never expose the app key, app secret, username or password in front-end code.

Sandbox vs live: always test first

bKash gives you two environments. Sandbox is a test environment that uses fake money and test accounts, so you can run the whole payment flow without a single real taka moving. Live (production) is the real thing. The safe order of operations is sandbox first, every time.

You get sandbox credentials and test numbers to start, build and check the flow there, and only request or switch to live credentials once it works end to end. The two environments use different base URLs, so part of going live is swapping the sandbox address and keys for the production ones. Because that detail can change, confirm the current sandbox and live endpoints in bKash's developer documentation rather than hard-coding an old one.

A safe go-live checklist

1. Enter sandbox credentials and turn sandbox mode on. No real money moves.
2. Run several test orders end to end: place an order, pay with bKash, confirm it returns as paid against that order, and check the receipt total.
3. Test a failure too: cancel a payment partway and confirm the order is not marked paid.
4. Switch to live by replacing the sandbox keys with your production app key, secret, username and password, and the sandbox URL with the live one, then turn sandbox mode off.
5. Do one small real transaction (even a few taka to yourself) and confirm it lands in your merchant statement and shows as paid before you go fully live.

Charges and settlement: confirm the current terms

Online gateway transactions usually carry a charge that the business absorbs, and the exact percentage, any caps, and the settlement timing to your bank depend on bKash's current merchant and gateway terms. These are updated from time to time, so we are not quoting a figure here. Before you go live, confirm the current charge, how and when money settles to your bank account, and how refunds are handled, then record those numbers in your own books. For how this fits the rest of your rails, see restaurant payment methods in Bangladesh.

How Rosuii uses the bKash payment gateway

Rosuii is restaurant software, not a bank or a payment processor. It does not replace your bKash merchant account or the gateway. What it does is use your gateway credentials to take and verify bKash payments on your own storefront, and then record the result against the order.

Rosuii has a real bKash integration built on Tokenized Checkout, alongside Nagad. When a customer pays on your online ordering storefront, Rosuii creates the payment, sends them to bKash, and then verifies it back against that specific order before marking it paid. You do not wire any of that up. You add your own bKash keys once in the panel, which keeps your credentials private to your restaurant, and a sandbox mode lets you test the whole flow before you switch to live.

Because the payment is tied to the order, the amount, the discount, the service charge and the VAT all sit in one place, and the order shows as paid in your reports. That is the difference between an online payment you can reconcile and a wallet notification you have to chase. Cash on delivery works out of the box for customers who would rather pay on arrival, and card payments in Rosuii are only a placeholder for now, so bKash, Nagad and cash on delivery are the real online rails. For the full picture, read restaurant software with bKash and Nagad and how to accept bKash and Nagad in a restaurant.

Common edge cases to handle

A live payment gateway is not just the happy path. A few situations come up often enough that it is worth knowing how good software handles them, so you are not left with an order in limbo:

• The customer pays but the page does not return. Their internet drops after they authorise in bKash, so the confirmation never reaches your site. This is exactly why the query step matters: software that re-checks the payment status with bKash can still mark the order paid, rather than leaving a paid customer with an unpaid order.
• The payment fails or is cancelled. The customer backs out partway. The order should stay unpaid and clearly marked so, so nobody starts cooking against money that never arrived.
• A duplicate attempt. A customer taps pay twice. The order should not be billed twice, and the second attempt should resolve cleanly.
• A refund is needed. An order is cancelled after payment. The gateway supports refunds, and recording the refund against the original order in your system keeps your numbers honest.

You do not build these yourself when your restaurant software already handles bKash, but it is worth confirming that pending and failed payments are visible to you rather than silently lost. An order that shows as paid only after a verified confirmation is the behaviour you want.

Gateway vs marketplace: where the money is yours

A point worth making for restaurant owners. When you take bKash through your own gateway on your own storefront, the order and the customer are yours and there is no per-order marketplace commission eating the margin. When a delivery marketplace takes the payment for you, it is convenient but it costs a commission on every order. Running your own gateway is part of what makes a direct ordering channel pay off. We compare the two in your own online ordering system vs a marketplace, and the commission angle in commission-free online ordering.

Put it together

The bKash payment gateway is how a restaurant takes bKash online and proves the money arrived, not just hopes it did. Get an active merchant account with API access, receive your app key, app secret, username and password, test the whole flow in sandbox, then switch to live with one small real transaction. Keep the keys on your server, confirm the current charges and settlement, and use software that verifies each payment against the order so your online takings reconcile.

Want to take bKash online and have every payment verified against the order? Start your free Rosuii account, add your bKash keys, and test in sandbox before you go live.