Eight seconds at a Bangkok coffee counter
The customer opens a banking app, scans the QR on the counter, types an amount, and the barista's phone buzzes before the espresso finishes pouring. No terminal, no signature, no card. That is PromptPay, and it is how a large share of Thailand now pays for everything from noodles to invoices.
Behind those eight seconds there are four parties and two separate standards, and foreign merchants usually discover the difference only when the money does not arrive where they expected. If you sell into Thailand, the question is not whether to accept PromptPay. It is which part of the Thai QR ecosystem you are actually connecting to, and who holds the funds in between.
PromptPay is not one thing
The name gets used loosely. Operationally there are three products that all look like "a QR code" to the person paying.
| Product | Who it is for | How funds move | What it means for you |
|---|---|---|---|
| PromptPay | Person-to-person transfers, and merchants registered through a bank or acquirer | Instant transfer between Thai bank accounts, addressed by phone number, citizen ID or tax ID | Domestic rail. Settlement stays in THB and inside the Thai banking system |
| Thai QR Payment | Merchants at the point of sale | EMVCo-standard QR that can carry PromptPay, card-based QR or bill payment | The practical integration for retail; one code, several underlying rails |
| Bill Payment | Billers with a Biller ID | Customer pays against a reference number, often for invoices and recurring bills | Better fit for B2B invoicing than a counter QR, but requires biller registration |
If your integration partner says "we support PromptPay" without specifying which of these, you have not learned anything yet. A retail checkout, a subscription and an invoice all need different plumbing, and only one of them is genuinely real-time end to end.
What a foreign merchant can and cannot do
This is the part that decides your project plan. PromptPay itself is domestic infrastructure supervised by the Bank of Thailand. A company incorporated outside Thailand cannot simply open a PromptPay merchant account and receive THB into its own bank.
In practice there are two workable structures.
Through a payment provider with Thai acquiring. The provider is the merchant of record for the Thai leg, you contract with the provider, and you are settled in THB or a converted currency depending on the agreement. Onboarding runs on your corporate documents plus a website and category review, typically two to six weeks. This is the route most SaaS, marketplaces and cross-border e-commerce take.
Through a Thai entity. You register locally, open a Thai bank account, and contract with an acquirer directly. You get THB settlement, lower per-transaction cost at volume, and full access to Bill Payment and recurring flows. You also take on Thai tax registration, local accounting, and a compliance obligation that does not disappear when volume is small.
There is no third option where a foreign entity gets domestic rails without either a provider in the middle or a local presence. Anyone offering that is describing a provider relationship under a different name.
Settlement: THB, cut-offs, and the FX decision
PromptPay moves money instantly. Your settlement does not. The two get confused constantly, usually in a finance meeting two weeks after launch.
What actually happens: the customer's payment is confirmed within seconds, your order should be marked paid within seconds, and the acquirer then settles to you on a schedule — commonly next business day for domestic Thai merchants, and on a fixed cycle with a minimum threshold if you are settled cross-border. Weekend and Thai public holiday behaviour is set by the acquirer, not by the rail, so confirm it in writing before you promise same-day payout to your own sellers.
Then the FX decision. If you are paid in THB you hold THB risk and you need a THB bank account or a conversion arrangement. If the provider converts for you, the spread is where the real cost lives — usually quoted as "competitive rates" and never as a number. Ask for the exact rate source and the timestamp applied, then compare two providers on the same day with the same transaction size. The difference is frequently larger than the difference in the headline fee.
Refunds, and why "instant" cuts both ways
A PromptPay transfer between two people is final. That is a feature for consumers and an operational constraint for merchants: you cannot pull money back from a customer's wallet, so every refund is a new outbound payment initiated through your acquirer.
Three practical consequences. Refunds need the original transaction reference, so store it immutably. Refund windows and partial-refund support vary by acquirer and should be tested in sandbox before launch, not after the first complaint. And because there is no card chargeback network in the middle, disputes arrive as support conversations, which means your own refund policy is the real dispute mechanism.
Six reasons payments fail
| What you see | What is happening | What to do |
|---|---|---|
| QR scanned, then "transaction cannot be completed" | Amount exceeds a per-transaction limit set by the customer's bank | Show limits in the checkout copy; offer a split or an alternative rail |
| Payment confirmed by the bank, order still unpaid | Callback delayed, dropped or blocked | Query transaction status on a schedule and treat callbacks as an optimization |
| Duplicate orders for one payment | Retries without an idempotency key | De-duplicate on the acquirer transaction reference, not on amount and time |
| QR expires while the customer is still in the app | Code lifetime is short by design | Regenerate on expiry and poll status rather than assuming failure |
| Refund rejected | Window passed, or amount unit mismatch | Send minor units exactly as documented, and refund against the settled transaction |
| Works in sandbox, fails in production | Production merchant profile or category not fully approved | Complete category approval before your launch date, not on it |
Reconciliation: four fields worth insisting on
Thai QR payments produce a reference number per transaction on the domestic rail, and your acquirer will add its own identifiers on top. Before signing, confirm the settlement report lets you join back to your own orders without guessing:
- Your order reference, echoed in the callback and in the settlement file
- The acquirer transaction ID, stored once and never overwritten
- Gross, fee and net as separate columns — not a single "amount"
- Settlement batch ID and value date, plus the FX rate and its timestamp if conversion applies
If any of those are missing, month-end reconciliation becomes an exercise in matching amounts by hand, and it will not survive a volume increase.
What you should be quoted
A credible Thai QR proposal has five numbers, and a provider that cannot supply all five is not ready to be compared: the percentage fee, the fixed fee per transaction if any, the FX spread with its rate source, the settlement cycle and minimum threshold, and the refund fee. Ask for all five against a worked example — a 1,000 THB sale, refunded once, settled to your account — and compare the net figure rather than the headline rate.
FAQ
Can we accept PromptPay without a Thai company?
Yes, through a provider that holds Thai acquiring and settles to your entity abroad. You will typically be settled in THB or a converted currency rather than into a Thai bank account of your own.
Is PromptPay the same as Thai QR Payment?
No. PromptPay is the transfer scheme; Thai QR Payment is the merchant-facing QR standard that can route to PromptPay, card-based QR or bill payment. Retail integrations normally use Thai QR Payment.
Do PromptPay payments support recurring billing?
Not as a card-style recurring charge. Recurring collections in Thailand usually run through Bill Payment or a direct-debit arrangement with a local bank, both of which require a Thai entity or a provider that supports them explicitly.