Adding local payments to your product

In many markets, cards are only one way people pay. In Bangladesh, mobile wallets and local gateways are often the first choice. If a product only accepts cards, it can lose a large share of its customers at checkout.

Here’s what we plan for when a product needs local payments built in.

Treat every method the same inside the product

Customers might pay with a card, a mobile wallet or a bank transfer. Inside the product, all of them should end up in the same place: one ledger, one list of payments, one set of reports.

We build a single payment layer in the middle. Each provider plugs into it, and the rest of the product never needs to know which one was used.

Expect payments to be slow, or to fail

Some payments confirm instantly. Others take a while, and some fail halfway through. A reliable checkout handles all three:

• Pending payments are shown clearly, not treated as failed
• Confirmations from the provider are checked on the server, never trusted from the browser alone
• Retries never charge the customer twice

Keep records that match

At the end of the day, the numbers in the product need to match what the payment providers report. We store each provider’s reference for every payment, so reconciling is a quick check instead of a manual search through statements.

Test with real flows before launch

Every provider offers a test mode, and we use it heavily. But before launch we also run small real payments through each method, end to end, including refunds. It’s the only way to be sure the whole journey works.

Make the choice easy for customers

On the checkout screen, we show the methods people actually use first, with recognisable logos and clear steps. A customer who sees their usual way to pay is far more likely to finish the purchase.

Planning a product that takes payments? Tell us about it and we’ll help you choose the right setup.