Instant bank transfers and cards: how they really compare

What account-to-account actually means

An instant bank transfer moves money directly from the payer's account to the payee's account, usually in seconds, usually around the clock, and usually on infrastructure built or overseen by the central bank. Pix is operated by the Banco Central do Brasil. UPI is operated by the National Payments Corporation of India under the Reserve Bank of India. PromptPay sits with the Bank of Thailand, and SPEI is developed and operated by Banco de Mexico, where a payment should not take more than thirty seconds after approval. The customer experience varies: a QR code to scan, a key such as a phone number or tax ID, or a push to their banking app to approve. What they share is that the payer authenticates with their own bank and instructs the payment themselves. There is no card number, no expiry date, no stored credential, and no card network authorising the transaction. That single structural difference explains almost all of the commercial differences that follow.

• Expect confirmation in seconds and availability outside banking hours on most national instant rails.
• Note that the payer authenticates with their own bank, which changes who owns the risk.
• Check whether the rail is domestic only, because most national instant schemes are.
• Confirm what identifier the customer uses: QR code, phone number, tax ID, or a one-off reference.

Where instant transfers win on conversion

Conversion improves for three reasons, and it helps to separate them. First, reach: in markets where card issuance is limited, an instant transfer is simply available to more of your addressable customers than a card is. India is the clearest example, where UPI has become the default way to pay for small amounts and person-to-merchant payments dominate transaction counts. Second, friction: scanning a QR code or approving a prompt in a banking app is faster than typing sixteen digits, an expiry date and a security code on a phone. Third, failure rates: because the payer is authenticated by their bank, there is no card decline from an issuer's risk engine, and no expired or cancelled card. The gains are largest on mobile, on low to medium ticket sizes, and among first-time online buyers. They are smallest among customers who already have a card on file with you.

• Expect the biggest uplift on mobile checkouts and on first-time buyers.
• Compare success rates by method rather than overall checkout conversion, or the effect hides.
• Watch declines disappear rather than approvals increase, because the two look different in reports.
• Present the instant rail first in markets where it is the local default.

Cost: what you pay on each rail

The honest answer is that you have to model it, because the structures differ. Card pricing typically combines a percentage with a fixed per-transaction amount and adds cross-border, currency conversion and dispute-related charges on top. Instant rails often look cheaper per transaction and carry no dispute fee, but they may have their own fixed costs and, in some markets, the merchant-side price is set by your provider rather than by the scheme. Some countries also regulate or cap certain fees. Do not compare a headline percentage. Build one model with your real numbers: monthly volume, average order value, method mix, refund rate, dispute rate, settlement currency and payout frequency, then calculate total cost and, more usefully, the amount that actually reaches your bank. Public pricing is only a first filter. Actual pricing changes with country, industry, volume, settlement currency, integration method and contract terms. Confirm against the provider's official pricing page or a written quote before you go live.

• Model total monthly cost and net receipts, not a headline percentage on a pricing page.
• Include dispute fees, refund fees, currency conversion and payout charges for the card side of the comparison.
• Ask whether the merchant-side price on the instant rail is set by the scheme, the provider, or both.
• Re-run the model after your first full month using the actual bill rather than the quote.

Refunds, chargebacks and who carries the risk

This is the clearest structural difference. On a card, the cardholder can ask their issuer to reverse a transaction, the money can be taken back from you, and you get a chance to argue with evidence. Dispute rights are built into the product, and schemes monitor merchants who generate too many. On an instant transfer, the payer told their bank to send the money, so there is generally no equivalent reversal right. That removes most chargeback exposure, which is why digital merchants favour these rails. It does not remove risk entirely. Push-payment fraud and social engineering produce losses you may still bear, mistaken transfers need handling, and some systems operate a return mechanism with defined deadlines. Brazil's Pix, for example, has a special return mechanism for fraud and operational failure, with its own timelines and exclusions. Refunds also behave differently: you usually push money back to an account rather than reversing an authorisation, which means you need the customer's details and a process.

• Plan for fraud and mistaken-payment claims instead of chargebacks on instant rails.
• Ask whether the local scheme runs a return or claim mechanism, and what its deadlines are.
• Build a refund path that pushes funds to an account, and collect the details you need at checkout.
• Keep your card-side evidence process running, because cards will still generate disputes.

Recurring payments: the account-to-account weak spot

Cards win clearly on one thing: stored credentials. A card on file lets you charge a subscription every month without the customer doing anything, and the whole subscription economy is built on that. Most instant rails were designed as push payments, so the customer has to initiate each one. That is beginning to change. Some schemes now support pre-authorisation or automatic debit variants, and providers may offer a mandate-based product layered on top of the rail, but availability varies by country, by scheme and by provider, and the customer-facing enrolment flow matters a lot. If subscriptions are central to your business, treat this as the first question you ask rather than the last. If your model is one-off purchases, top-ups or pay-per-episode, the weakness barely matters, because the customer is initiating the payment every time anyway.

• Ask specifically whether the rail supports recurring or mandate-based payments in your target country.
• Test the enrolment and the failure-recovery flow, not just the first successful charge.
• Keep cards as the recurring fallback even in markets where an instant rail dominates one-off payments.
• Build dunning logic for failed recurring attempts, whichever rail you use.

Where cards are still necessary

Cards remain the default in four situations. Cross-border: a customer in one country buying from a merchant in another will often reach for a card, because national instant rails are mostly domestic. High ticket: card limits, instalment programmes and buyer protection all suit larger purchases, and in some markets instalments are effectively expected. Recurring: as above, a stored credential is hard to replace. And cardholder expectations: in markets with high card penetration, a checkout without a card option looks incomplete and costs you trust. Cards also give you a mature dispute process, which sounds like a disadvantage until you need a defined rulebook. The practical answer for almost every merchant is both, ordered by what customers in that market actually use. The mistake is treating the choice as binary, or worse, copying the ordering from a market where customer behaviour is completely different.

• Keep cards enabled wherever you sell cross-border, regardless of how strong the local rail is.
• Use cards for higher tickets and instalments, and instant rails for smaller, frequent payments.
• Order methods on the checkout by local usage, not by cost to you.
• Do not copy your checkout ordering from another market without checking local behaviour first.

How to run the comparison on your own numbers

You do not need a data science team, you need four weeks and a spreadsheet. Split your traffic so that each method gets a fair share of exposure, ideally by showing both prominently rather than A/B testing a hidden option. Capture for each method: selection share, success rate, median time to confirmation, refund rate, dispute or claim rate, and the net amount received per order after all charges. Then add the operational column: how many support tickets each method generates, and how long reconciliation takes. Compare net revenue per hundred sessions rather than conversion alone, because a method that converts slightly worse but costs much less and disputes less often can be the better commercial choice. Re-run the exercise every quarter. Local payment habits move, scheme rules change, and providers update their products.

• Show both methods prominently so each gets fair exposure rather than testing a buried option.
• Measure net revenue per hundred sessions, not conversion rate in isolation.
• Include support tickets and reconciliation effort as real costs in the comparison.
• Repeat the exercise quarterly, because scheme rules and customer habits both move.

Questions merchants ask

Public sources

• NPCI - About UPI, participants and merchant payments
• Banco de Mexico - SPEI information for users
• Visa Acquirer Monitoring Program fact sheet
• Bank of Thailand - PromptPay and Thai QR Payment