Integrating PromptPay payments reliably
Generating a QR code is different from confirming payment. Select a provider suited to the business and check current currency, fee and operating requirements.
A payment QR and a confirmed payment are different states
Displaying a QR code lets a customer start paying. It does not prove that the business has received funds. An order should distinguish awaiting payment, verification, confirmed payment, expiry and manual review. A screenshot alone should never release goods or confirm a booking.
Choose the payment flow around the business
Decide whether customers pay immediately or reserve first, whether shipping and discounts change the total, and who owns the receiving account. Then check the provider’s current documentation for supported currencies, fees, refunds and operational limits before selecting an API or QR flow.
Connect each order to a verifiable payment
Create an order reference on the server before payment starts. Store the expected amount and currency, then associate the provider’s payment reference with that order. The browser may display a QR code and status, but it must not mark the order paid by itself.
Verify payment on the server
Process the provider event or webhook using its documented verification method. Compare the order reference, amount and status with your own records before confirming payment. If notification is delayed, the checkout should explain that verification is pending rather than asking the customer to pay again immediately.
Make duplicate and out-of-order events safe
A webhook may be retried or arrive after the customer has left. Use idempotent state changes so one payment cannot deduct stock, trigger fulfilment or send receipts twice. Test expired QR codes, late confirmation, payment after cancellation and the provider’s supported refund process.
Give finance and support a reconciliation path
Keep only necessary payment references, timestamps, amounts and status history. Provide a queue for manual review and a way to reconcile provider records. Define who may correct a status and retain the reason for that change.
What to prepare for a project estimate
Bring the purchase flow, product types, payment channels, stock or invoicing systems and real cancellation or refund cases. These details help decide whether a standard checkout, an improvement to the existing flow or a custom integration is appropriate.
PromptPay acceptance before opening sales
Use the provider’s supported test environment. Check expected amounts, order references and server-confirmed states. Agree reconciliation and provider-supported refund handling. A self-generated QR alone cannot establish automatic confirmation without a trusted event or status source.
| Area | What to agree |
|---|---|
| Success | Verify amount/reference before fulfilment |
| Repeated event | Update once; no repeated stock action |
| Late payment | Reconcile actual state after expiry |
| Refund | Provider-supported steps and history |
Prepare for the estimate
Provide the current URLs, approved example data, owners and the most important workflow. Distinguish the first release from later additions so teams can estimate the same scope and agree acceptance before work.
Read the related decision guide →
Sources
Have a project to discuss?
Share the context and goal. We’ll help identify a practical first scope.
Explore the related serviceLet’s talk