Bank transfer or card gateway? How Sri Lankan customers actually pay

Most online store templates assume a card gateway. You add products, connect Stripe or a local acquirer, and customers type in a card number. It is clean, it is automatic, and for a lot of Sri Lankan businesses it quietly loses sales.

The reason is not technical. It is that a meaningful share of your customers either do not have a card they are willing to use online, or have one and would rather not. They will pay — by bank transfer, the way they already pay for everything else — but only if you let them.

What actually happens when you force cards

The customer fills a cart, reaches checkout, sees that a card is the only option, and leaves. You never find out. There is no error in your logs and no support ticket, just a cart that was abandoned for a reason nobody records.

Meanwhile the orders keep arriving on WhatsApp, because that is where the customer went instead. Which means you now have a website that looks like it takes orders and a phone that actually takes them.

The bank transfer flow, done properly

The instinct is to treat bank transfer as a downgrade — a bit of text saying "deposit to this account and send us the slip." That works until you have twenty orders a day, at which point somebody is spending their morning matching bank slips to orders by hand.

The fix is to treat it as a real payment method and build it properly:

1. Customer places the order and the system holds it as awaiting payment. The order exists, with a reference number, before any money moves.
2. The account details and the exact amount are shown on screen, along with that reference. Ambiguity here is what causes the reconciliation work later.
3. The customer uploads a photograph of the slip against that order. Attaching it to the order is the whole trick — it is what stops the matching problem existing at all.
4. Staff see a verification queue, not an inbox. One screen listing orders awaiting payment with the slip beside each one. Approve or reject.
5. Approval moves the order forward automatically and the customer is told.

The customer's experience is barely different from a card checkout. Your experience is completely different from chasing slips.

Why the reference number matters more than it sounds

The single largest source of manual work in bank-transfer checkout is a customer transferring the right amount with no indication of what it is for. Two customers sending LKR 4,850 on the same morning is an afternoon of detective work.

Generating a short reference, showing it prominently, and asking for it in the transfer description removes most of that. It will not be perfect — some people will always ignore it — but attaching the uploaded slip to a specific order covers the rest.

When you should use a gateway

This is not an argument against cards. Use a gateway when:

• You sell to customers abroad, where bank transfer is impractical.
• Your order values are low and your volume is high — manual verification does not scale to hundreds of small orders a day.
• You sell something delivered instantly, where waiting for a human to approve a payment defeats the point.

The right answer for most Sri Lankan businesses selling physical goods locally is both: offer the card gateway for whoever wants it, and a properly built bank transfer flow for everyone else. What you should not do is offer only cards because that is what the template did.

What this looked like in practice

When we built the commerce and POS system for a pre-cut vegetable supplier in Sabaragamuwa, this was one of the first decisions. Their customers pay by bank transfer. Card penetration in the towns they serve is low, and gateway fees come straight out of thin margins on vegetables.

So we did not force cards. We built the slip-upload and verification queue as a first-class part of the system, and we made the messy part — working out who had actually paid — the thing the software does rather than the thing a person does every morning. You can see the whole build in the ShortcutFood case study.

That is the general principle, and it is worth more than the specific technique: match the software to how your customers already behave. Changing the software is cheap. Changing thousands of customers' habits is not.

If you are weighing this up for your own business, that is exactly the kind of thing worth talking through before anyone writes code — it is part of how we scope custom software.