Insight
Adding bKash and Nagad payments to your website or app
If you sell online in Bangladesh, many of your customers will want to pay with a mobile wallet such as bKash or Nagad. Adding these to your website or app is very doable, but there are a few decisions to make first and a few mistakes that cost businesses real money. This guide explains both in plain language.
Your two main options
There are two common ways to accept wallet payments online.
Option 1: Integrate each provider directly
bKash and Nagad each offer an online payment service for merchants with its own API. You apply for a merchant account with each provider, receive credentials once approved, and your developer connects your site or app to their systems.
Good for: businesses that mainly need wallets, want the provider's own checkout experience, or have high volumes with one provider.
Keep in mind: each provider is a separate integration with its own approval process, documentation, test environment and settlement reports.
Option 2: Use a payment gateway
A payment gateway, such as SSLCommerz, gives you one integration that offers several payment methods on its hosted payment page, typically cards, mobile banking and internet banking. You have one merchant relationship, one set of reports and one technical integration.
Good for: businesses that want cards and wallets together, or want to launch with one integration.
Keep in mind: the gateway's checkout page and fees are part of the deal, and settlement goes through the gateway.
Many businesses start with a gateway and add a direct wallet integration later if most payments come through one provider. Fees, settlement times and eligibility vary by provider and change over time, so compare current terms directly with each one before you decide.
How an online payment actually flows
Whichever option you choose, the flow follows the same shape:
- The customer chooses to pay. Your system creates an order with a unique ID and the amount in Taka.
- Your server starts a payment with the provider or gateway, sending the order ID and amount. The provider returns a payment reference and a link to its payment page.
- The customer pays on the provider's page. For a wallet this usually means entering the account number, a one-time code and the PIN. Your site never sees the PIN.
- The customer comes back to a return URL on your site, with a status in the address.
- Your server confirms the payment by asking the provider directly, using the payment reference: was it completed, and for which amount? Depending on the provider this is an "execute" or "verify" step, a validation API, or both.
- Only then does your system mark the order as paid and show the customer a confirmation.
Gateways often also send a server-to-server notification (an "IPN") when a payment completes. That is valuable, because it arrives even if the customer closes the browser before step 4.
The mistakes that cost money
1. Trusting the browser
The most expensive mistake is marking an order as paid because the customer landed on your "success" page. That page address can be opened by anyone. Always confirm the payment on your server with the provider (step 5) before releasing goods or services.
2. Not checking the amount and order
When you verify, check that the amount, currency and order ID match what you expected, and that this payment has not already been used for another order. A valid payment for a smaller amount, or a reused payment reference, should never complete an order.
3. Handling the same payment twice
Customers double-tap, networks retry and notifications can arrive more than once. Your system should be idempotent: processing the same confirmation twice must not create two orders or two refunds. Store the provider's transaction ID and check it before acting.
4. Losing payments that "disappear"
Sometimes the money moves but the customer never returns to your site: the battery dies, the browser closes or the network drops. Without a server notification or a regular status check, you will have angry customers who paid for orders you think are unpaid. Use the provider's notifications where available and check pending payments regularly.
5. Keeping secrets in the wrong place
Merchant credentials and keys must stay on your server. They should never appear in your website's JavaScript or inside a mobile app, where anyone can extract them. Store them as server-side environment variables and rotate them if they leak.
6. Skipping the test environment
Providers offer sandbox or test credentials. Use them to test every path: success, failure, cancellation, timeouts, wrong amounts and duplicate notifications. Only switch to live credentials once all of these behave correctly.
Refunds and reconciliation
Plan from the start how you will handle refunds, partial refunds and disputes, and who on your team is allowed to trigger them. Some refunds can be made through the provider's API; others go through the merchant portal.
At least weekly, reconcile: compare the payments in your system with the provider's settlement report. Mismatches are much easier to fix when they are a few days old than when they are a few months old.
What a good integration looks like
- Orders and payments are separate records, linked by IDs.
- Every payment is confirmed on the server, with amount, currency and order checked.
- Duplicate confirmations are harmless.
- Pending payments are checked automatically, not forgotten.
- Credentials live only on the server.
- Customers see clear messages for success, failure and "we are confirming your payment".
- Your team has a simple screen to look up any payment and its status.
The short version
Choose between direct wallet integrations and a gateway based on which payment methods you need and how many integrations you want to maintain. Then build the integration so that your server confirms every payment before treating it as paid, and test every failure path before going live.
If you want help adding bKash, Nagad or card payments to your website or app, book a call. We will look at your checkout and suggest the simplest safe setup.