Pix, UPI and GCash: the payment methods your checkout is missing
If your checkout offers a card and nothing else, it works perfectly in the markets you came from and quietly fails in several of the ones you are trying to grow into. Not because people cannot afford your product — because you did not offer the thing they pay with.
Most software companies build checkout once, for a card-first audience, and then expand internationally without revisiting it. The result is a payment page that asks a customer in Jakarta or Lagos for an instrument they may not own, while the method sitting on their phone home screen is not on offer.
Three families of local method
Dozens of names appear across markets, but almost all of them fall into one of three groups, and the group tells you how the payment will behave.
Instant bank transfers
Real-time payment systems run by or with the central bank, moving money directly between bank accounts. Brazil's Pix, India's UPI, Singapore's PayNow, Thailand's PromptPay, Europe's SEPA Instant, the UK's open banking payments.
They clear in seconds, run continuously, and are generally cheap. The customer confirms in their own banking or payment app, often by scanning a QR code or approving a push notification. Because the customer pushes the money rather than you pulling it, there is no chargeback mechanism in the card sense.
Wallets
Stored-balance accounts, usually tied to a phone number, often with their own user base larger than local card penetration. GCash and Maya in the Philippines, OVO and DANA in Indonesia, KakaoPay in South Korea, M-Pesa in Kenya, Mercado Pago in parts of Latin America.
Customers top them up from a bank, a card, or cash at an agent, which is what makes them reach people the banking system does not. For you they behave like a redirect: the customer approves in the wallet app and returns.
Cash and voucher methods
The customer generates a code online and pays in cash at a shop or bank. Boleto in Brazil, OXXO in Mexico, Konbini in Japan, PagoEfectivo in Peru.
These are slower by design — the customer may take a day or more to pay — and the payment is not confirmed until they do. For digital products that means deciding whether to provision access on generation or on confirmation. Usually it should be on confirmation.
Instant bank transfer
- Customer appApproves in their banking app
- Bank railMoves money directly
- Confirmedseconds, no chargebacks
Wallet
- RedirectCustomer leaves your checkout
- Approve in appConfirms in the wallet
- Confirmedseconds, needs a return URL
Cash voucher
- Code issuedGenerated at checkout
- Paid at a shopOn the customer's schedule
- Confirmedhours to days
What changes in your product
Adding methods is not only a payments decision. Four things in your own system usually need attention.
Recurring billing
Cards were built to be charged again without asking. Most instant transfers were not. Some markets have mandate frameworks that allow recurring debits, with their own setup flow and rules. Others have nothing equivalent, which means subscriptions become invoices the customer actively pays each cycle — a different retention problem requiring reminders and a grace period.
Refunds
Refunding a bank transfer usually means sending money back to an account, which can require details you did not collect. Refunding a cash voucher payment means you may have no destination at all without asking the customer. Decide the flow before you need it, not during your first support ticket.
Pending as a real state
A card is approved or declined. A voucher sits in a pending state for hours. If your system only models success and failure, these payments break it. You need a pending state visible to both your support team and the customer.
Checkout layout
Offering twelve methods to everyone is worse than offering two. Detect the country, lead with what that market uses, and keep the rest behind a "more options" control. A Brazilian customer should see Pix first and should not have to scan past six irrelevant European methods to find it.
No chargebacks cuts both ways. Push-based transfers remove most fraudulent-dispute risk, which is genuinely good for a software business. They also remove the dispute process your support team may rely on to resolve honest mistakes, so your own refund policy has to be clearer than it was.
Choosing where to start
You do not need every method. You need the right two or three per market that already brings you traffic.
Start from where you already have customers failing to pay, not from a map of the world.
A practical order of work:
- Pull sign-ups or trials by country, and compare against paid conversions by country. The markets with a large gap are your candidates.
- For the top two or three, find the dominant method. It is usually one obvious answer per market.
- Check whether your provider supports it, and whether it settles into the currency you want.
- Work out recurring billing and refunds for that method before launch.
- Measure conversion by method afterwards, not just overall, so you learn whether it worked.
The underlying point
Payment habits are local in a way that almost nothing else about selling software is. Your product, pricing page and onboarding can be identical worldwide. The final step cannot. Treating checkout as something configured per market, rather than built once, is the difference between a market that converts and one that looks uninterested.
Next: how the money gets from there to your account.
What stablecoin settlement actually means