Skip to content
D-bug Station

Integrating bKash and SSLCommerz in a Mobile App

4 min read
  • Mobile
  • Payments
  • Bangladesh

The payment screen is the easy part. Confirming the money on your own server is what keeps orders and payments in step.

For an app selling to customers in Bangladesh, local payment methods matter: bKash for mobile wallets, and a gateway such as SSLCommerz for cards, internet banking and other wallets in one place. Both are well established, and both are easy to integrate badly. The payment screen is the simple part; making sure orders and payments always agree is the real work.

Check the app store rules first

Apple and Google require their own in-app purchase systems for digital goods and services used inside the app: subscriptions, premium features, in-game items, digital content. Physical goods and real-world services, such as products delivered to a door, rides, bookings and bills, can use other payment methods, including local wallets and gateways. Get this decision right before building anything, because the wrong one ends in a rejected release.

Your server confirms the payment, not the app

The pattern is the same for both providers:

  1. The app asks your server to create a payment for an order.
  2. Your server creates it with the provider, using credentials that never ship inside the app.
  3. The customer completes payment in the provider's flow.
  4. Your server verifies the result directly with the provider before marking the order paid.

Never trust the app telling your server "the payment succeeded". A callback can be faked or lost; a server-to-server check against the provider cannot. Both providers offer a way to query or validate a transaction, and their notifications to your server should be verified the same way.

Plan for the in-between states

Customers close the app mid-payment, networks drop, a payment succeeds after the app has given up waiting. Store every payment attempt with a status, reconcile pending ones by asking the provider, and make it safe to receive the same confirmation twice. Refunds need the same care in the other direction.

Merchant onboarding takes time

Live credentials come after merchant approval, which needs business documents and can take a while. Start that process early, and build against the providers' sandbox environments in the meantime so the integration is ready when approval arrives.

Test the unhappy paths

Test cancelled payments, failed payments, timeouts, duplicate notifications and refunds in the sandbox, not just the successful path. Check that the order status and the money agree in every case.

Provider APIs and requirements change, so always work from each provider's current documentation and confirm details with them during onboarding. If you are building an app that takes payments in Bangladesh, our mobile engineers can help; for app store purchases, see subscriptions done right.

Building something along these lines?