To accept QR and mobile wallet payments, first work out which kind you need. Card wallets such as Apple Pay and Google Pay are added through your card payment gateway and charge a card saved on the customer's phone. Local QR and wallet rails, such as LankaQR in Sri Lanka, DuitNow QR in Malaysia or M-Pesa in Kenya, move money straight from the customer's bank or wallet account, and you connect to them through a bank, a gateway or the wallet operator. In both cases, showing the QR code or the button is the easy part. The real work is knowing, reliably, that the money arrived.
Card wallets vs local QR and wallet rails
Both get called "mobile payments", but they work quite differently.
| Card wallets (Apple Pay, Google Pay) | Local QR and wallet rails | |
|---|---|---|
| What pays | A card stored on the phone | A bank account or wallet balance |
| How you connect | Through your card gateway, which must support the wallet | Through a bank, a gateway that supports the scheme, or the wallet operator's API |
| What the customer does | Taps a button and confirms with face, fingerprint or PIN | Scans a QR code, or approves a request in their banking or wallet app |
| Confirmation | Comes back with the payment request, like a card payment | Usually arrives separately, by webhook or status check |
| Refunds | Through the card gateway, like any card refund | Depends on the scheme. Some support refunds by API, others need a manual transfer |
Card wallets mostly make checkout faster for people who already pay by card. Local rails reach people who prefer paying from their bank or wallet, or who rarely use cards online. Many businesses need both.
Local rails worth knowing
Sri Lanka: LankaQR
LankaQR is Sri Lanka's national QR standard. Customers can scan a LankaQR code with any participating bank or wallet app, so a merchant doesn't need a separate code for each app. Merchants get LankaQR through an acquiring bank or a payment provider. It's common in shops, and it's also useful for online orders and invoices. There's more on local payments on our Sri Lanka page.
Malaysia: DuitNow QR
DuitNow QR is Malaysia's national QR standard, accepted by participating banks and e-wallets through a single code. Online stores often offer it next to FPX online banking and cards. See our Malaysia page for more.
India: UPI
UPI is the best-known example of what a national real-time payment system can do. Customers pay from their bank accounts through many different apps, by scanning a QR code or approving a request sent to their phone. It's worth knowing as context, because several other countries' schemes follow a similar idea.
Kenya: M-Pesa
M-Pesa is a mobile money service rather than a bank QR scheme. For online payments, the usual pattern is a prompt sent to the customer's phone. They enter their M-Pesa PIN, and your system is told the result by callback. Paybill and till numbers cover in-person and manual payments. Our Africa page has more on mobile money.
Qatar and the Gulf
Gulf countries have their own local wallets and instant payment services, run by banks, telecom companies or national payment networks, alongside heavy use of cards and Apple Pay. Which ones matter depends on the country and your customers, so ask your gateway which local wallets it supports in each market you sell in.
Static vs dynamic QR
A static QR code is the same every time. It identifies the merchant, and the customer types in the amount. It's simple and works well printed on a counter, but matching a payment to a specific order is hard. You end up relying on the amount, the time, and whatever reference the customer remembered to type.
A dynamic QR code is generated for each payment. It carries the amount and a unique reference, so the customer can't pay the wrong amount and your system knows exactly which order was paid. For online checkouts, invoices and anything you want to reconcile automatically, use dynamic QR wherever the scheme and your provider support it.
Webhooks and confirmations
With a QR or wallet payment, the customer pays in a different app, often on a different device. Your checkout can't see it happen. You find out in one of two ways:
- Webhook (callback). The provider calls your server when the payment succeeds or fails. This is your main source of truth.
- Status check. Your server asks the provider for the status of a payment reference. Use this as a backup when a webhook is late, and when a customer says they've paid but the order still shows as pending.
A few rules that save a lot of trouble:
- Verify each webhook's signature, or confirm it with a status check, before marking an order as paid.
- Handle duplicate webhooks without processing the order twice.
- Give every dynamic QR an expiry time, and decide in advance what happens to a payment that arrives after it.
- Never mark an order paid because the customer tapped "I've paid" or sent a screenshot. Screenshots are easy to fake.
Reconciliation
QR and wallet payments often settle differently from cards: in separate batches, on their own schedule, with their own reports. Each payment should carry your order reference all the way through to the settlement file, so it can be matched automatically. Late payments, payments to expired codes and amounts that don't match the order need somewhere to go, such as a review queue for your team, rather than failing silently. With static QR, expect more matching by hand, and plan staff time for it.
Mobile vs desktop UX
The same payment method needs a different flow depending on the device.
- Desktop: show the QR code large and clear, with the amount, the merchant name and a countdown if it expires. The customer scans it with their phone. Keep the page listening for the result and move on by itself once payment is confirmed.
- Mobile: a customer can't scan a QR code on the screen they're holding. Where the scheme supports it, offer a button that opens their banking or wallet app directly, or ask for a phone number for push-style payments like M-Pesa. Offer "save QR image" only as a fallback.
- Coming back to your app: after paying in another app, the customer returns to yours. Show a clear "checking your payment" state, then success or a next step. Don't show an error just because the webhook hasn't arrived yet.
- Apple Pay and Google Pay: show only the button that matches the device, and only when the wallet is set up.
Checklist before you go live
- Decide which card wallets and local rails your customers actually use
- Confirm your gateway or bank supports each one in your country
- Use dynamic QR with a unique reference for online orders
- Verify webhooks, with status checks as a backup
- Set a QR expiry time and a rule for late payments
- Test on desktop and on real phones, including switching between apps
- Test refunds, or write down the manual process if the scheme has no refund API
- Match a real settlement report against your orders
Scheme rules and provider coverage change, and this guide is general rather than legal advice, so check current rules with your bank or provider.
We build payment flows into apps and platforms, including local QR and wallet integrations. See our apps and platforms work, or contact us for a quote.
Questions people ask
Do I need a separate integration for Apple Pay and Google Pay?
Usually not. If your card gateway supports them, you enable them through the gateway. There's still setup to do, such as verifying your domain for Apple Pay on the web and configuring merchant details in your app.
Can I accept LankaQR on my website?
Yes, if your bank or payment provider supports LankaQR for online payments. Ask for dynamic QR codes with a reference per order, and a way to receive payment confirmations on your server.
Are QR payments cheaper than card payments?
Often, but not always. Fees depend on the scheme, your provider and your agreement. Compare the total cost, including any time your team spends matching payments by hand.