PromptPay and Merchant QR for a Thai Company

When an operator says, “We need PromptPay for the company,” that request can hide several different needs. A small firm may only want customers to transfer to the corporate account without typing a bank account number. A shop may need a merchant-facing confirmation screen. A higher-volume business may need a new QR for each sale plus transaction data that can be exported and matched to orders. Those are not the same product decision.

Corporate PromptPay is the business extension of the PromptPay transfer infrastructure. Bank of Thailand guidance describes a corporate registration flow in which a 13-digit juristic-person registration number is linked to a savings or current account; an eligible organisation without that registration number may use a 13-digit tax identifier. The identifier gives a payer a way to address a transfer to the company without using the bank account number. It does not, by itself, create a complete point-of-sale workflow.

Thai QR Payment covers the QR presentation layer used for payments. The Bank of Thailand standard supports merchant-presented QR as well as customer-presented modes, and it distinguishes static from dynamic QR. A static code remains the same and can be printed. A dynamic code is generated again for each payment or transfer, which can be useful when the bank or merchant product also carries an amount or transaction reference.

Banks then add their own service layer around that standard: a merchant app, an EDC terminal, a web portal, reports, refund handling or an integration where offered. Product names vary, so the useful questions are operational: which company account receives the funds, what recipient name the payer sees, how the merchant sees a confirmed transaction, which reference fields are available, and how refunds are recorded. That is why “PromptPay,” “QR” and “Merchant QR” should not be treated as interchangeable labels.

A company that receives a few invoice payments each week does not automatically need a full merchant stack. If the customer is paying a known invoice amount and finance staff can see the funds arrive in the corporate account, Corporate PromptPay may cover the receiving side well. The weak point appears when two payments look alike: without a useful reference field, matching them to invoices can still be manual.

At a staffed counter, the decision is immediate. The employee needs a merchant-side confirmation before handing over goods or closing the service ticket. A Merchant QR product with an app or EDC workflow is built closer to that moment. A printed static QR can still be perfectly adequate for a low-volume business, but it leaves more work to the customer and the cashier, especially if the payer must enter the amount manually.

Dynamic QR becomes more valuable when the amount is generated for a specific sale and the merchant product can return data that helps identify that transaction. The QR format alone is not the benefit. The benefit is the link between the payment and the order, which can reduce wrong-amount payments and make reconciliation faster. A service business with repeated prices — for example, standard appointment fees — feels that difference sooner than a firm receiving a handful of bespoke invoices.

Multi-branch operations need another layer: location or terminal visibility, controlled staff access, consistent refund handling and reports that can be reconciled by shift or site. A single shared QR may still collect money, but it can leave management with poor answers about where a payment came from and who confirmed it. Merchant tools matter here because the operating data becomes part of the product choice.

Online and high-volume businesses usually need payment creation and status data to move between systems with less manual work. Some banks or payment providers offer APIs or other integrations, but those capabilities are product-specific and should not be assumed from the PromptPay name. Define the required workflow first — amount, order reference, confirmation, refund and export — then choose the bank product that actually supports it.

Onboarding begins with the corporate banking relationship, not with a QR graphic. The bank needs to know which legal entity is receiving funds, which account is used, who can bind the company and whether the requested payment service fits the stated business activity. Bank of Thailand guidance for Corporate PromptPay lists core evidence such as account ownership, identification for an authorised signatory or representative, corporate registration documents, tax identification where applicable and a power of attorney when relevant. It also leaves room for each bank to request additional evidence.

A merchant-acquiring product adds its own application rules. Bangkok Bank's QR Code Payments on EDC page, checked on 6 October 2026, lists a recent Ministry of Commerce registration certificate, commercial registration, identification for the authorised signatory, VAT registration and meeting minutes where settlement is directed to another legal entity. That is useful as a real bank example, not as a universal checklist for every Thai bank or every Merchant QR product.

Foreign ownership does not remove KYC or beneficial-owner review. Thai financial institutions are expected to identify and verify corporate customers and may look at ownership, controllers, business activity and the purpose of the relationship. The exact evidence and approval path therefore remain bank- and risk-specific, even when two companies look similar on paper.

The useful outcome of onboarding is a clear operating setup: the merchant agreement is in the right company name, settlement goes to the intended corporate account, authorised users are known, and the team understands what reporting the product will produce. Treat the bank's current application pack as the controlling document for that product rather than relying on a generic list copied from another bank.

Static QR is attractive because it asks very little of the merchant. The same code can remain at the counter and the customer scans it with a banking app. Under the Bank of Thailand standard, static QR is the form that does not change from one transaction to the next. Depending on the product, the customer may still need to enter the amount, which leaves the cashier responsible for confirming what actually arrived.

Dynamic QR is generated again for each payment. It becomes most useful when the sale system already knows the amount and the merchant product can associate the transaction with a reference that later appears in reporting. The exact fields are product-specific, so a dynamic code should not be assumed to carry an order number unless the bank or processor says it does. The operational advantage is less manual input and a better chance of matching the payment cleanly.

The customer's “success” screen is only one side of the transaction. The business needs its own confirmation source: a merchant app, EDC, bank portal or account record, depending on the service. A screenshot can explain what the customer believes happened; it is not the ledger that staff should use to release goods or close an invoice.

Settlement wording also varies by product. Bangkok Bank's QR-on-EDC page, checked on 6 October 2026, says funds are deposited directly to the account and can be tracked through an EDC report in its web portal. That does not create a universal settlement promise for every PromptPay or Merchant QR service. Test the exact product from scan to merchant confirmation, report and bank statement before making it part of the front-line process.

A business has two separate reconciliation questions: did the money actually arrive, and which sale does that money belong to? The first is answered by the bank or merchant system. The second requires a link to an order, invoice or checkout event. Problems start when both questions are collapsed into “the customer showed payment,” because several legitimate payments can have the same amount and look identical later in finance records.

A useful transaction trail normally includes the amount, timestamp, status and a bank or merchant transaction identifier. A richer merchant setup may also expose a terminal, location or order reference. The bank statement proves movement on the account, while the merchant portal can provide sale-level context. Neither should be assumed to contain a particular field until the exact product has been tested.

Consider a busy counter. The customer shows a successful transfer screen, the amount matches and staff want to move on. If a screenshot is treated as final proof, the merchant is relying on an image outside its own systems. A stronger workflow waits for the transaction to appear in the merchant app, terminal, portal or other bank-controlled confirmation channel before the sale is released. That is basic payment control, not an accusation that the customer is acting in bad faith.

Static QR becomes harder to reconcile when many sales look alike. Two THB 990 payments a few minutes apart might be matched by time in a quiet shop; at higher volume, that is fragile. Dynamic QR can reduce ambiguity when the product fixes the amount and returns a usable reference. For online orders or several tills, those references can be the difference between routine matching and a daily manual investigation.

End-of-day reconciliation should leave each confirmed receipt explained by a sale, while refunds are traceable back to the original transaction. An unmatched receipt should remain unmatched until there is evidence for the connection; a similar amount is not enough. That discipline is especially useful when staff, finance and the customer are looking at different screens.

The payoff appears when something goes wrong. An order-to-transaction-to-settlement trail gives the company a record it can reconstruct without relying on chat screenshots or someone's memory. As volume grows, the quality of those references and reports matters more than how quickly the first QR code can be printed.

PromptPay has its own transfer-fee framework, but that does not determine what a corporate merchant product costs. Merchant QR can sit inside a separate acquiring or EDC service with transaction charges, device terms, reporting features or other service fees. “PromptPay is free” is therefore not a usable budget assumption for a legal entity.

Read the tariff for the exact product as a package: per-transaction pricing, any terminal or service charges, transaction limits, refund treatment and settlement terms. Different channels from the same bank can have different commercial conditions. A public fee page is useful for orientation, but the current merchant agreement and tariff at onboarding are the documents that control the relationship.

Limits are equally product-specific. A limit may belong to the payer's bank, the receiving service, the merchant channel or a technical transaction type. The sensible operating rule is to record the terms for the exact service the company activates and re-check them when the bank changes the product or the business changes its payment flow.

A QR transaction answers a money question: was a specific payment processed and did funds arrive through the bank or merchant channel? Sales and tax records answer a different question: what was sold, to whom, for what amount, and which commercial or tax document the company must issue or retain. One record should not be used as a substitute for the other.

A clean workflow starts with the sale or invoice in the company's system, attaches the confirmed payment to that record, and then produces the document required for that business and transaction. The exact document can vary with the type of sale, VAT status, invoicing process and whether the company uses an electronic tax-document system. There is no single receipt format that can be inferred merely from the fact that the customer paid by QR.

Thailand's Revenue Department runs a separate e-Tax Invoice & e-Receipt framework with its own technical and tax-document requirements. A Thai QR or PromptPay payment does not automatically become an e-tax invoice or receipt. The reverse is also true: an invoice or receipt is not evidence that settlement reached the bank account; the payment record is needed for that.

Refunds expose the same separation. The payment side needs a traceable refund or reversal path supported by the service, while the accounting side needs the sale and any related documents adjusted correctly. Companies that handle refunds regularly should define both paths together so finance staff are not left trying to reconstruct them from bank screenshots later.

Bank requirements, merchant terms and tax-document obligations depend on the company's status and can change over time. The general separation of payment proof from tax documentation is stable, but the exact document set should be confirmed against the company's VAT and e-tax position and the rules in force when the transaction occurs.

One of the most useful tests happens before the payer confirms anything: the recipient name should be the one the business expects. A test transaction reveals not only whether the QR scans, but how the company is presented in the customer's banking app. If a supposedly corporate counter QR displays an unexpected individual, resolve that before launch rather than training staff to explain it away.

An inconsistent confirmation rule is a bigger operational problem than it first appears. Staff work more reliably when every shift closes a sale only after the bank or merchant system shows the transaction, while a customer screenshot remains supplementary information. Busy periods are exactly when an informal exception is most likely to become a recurring habit.

Access rights shape the process as well. Merchant apps and portals contain financial information and may expose sensitive functions, so a cashier, branch manager and finance user do not necessarily need the same permissions. Device replacement, staff departure or a lost phone should trigger an access review instead of simply passing a shared credential to the next person.

The final test is whether the business can reconstruct the day later: sales recorded, receipts confirmed, refunds processed and payments still unmatched. A single-site operator may do that with a straightforward daily reconciliation; a network may need reports by branch and shift. Retaining those reports and using a defined refund path often contributes more to control than the QR technology itself.