A successful QR payment can still leave a business with unanswered questions: which currency did the customer pay, which account received it, and can the original transaction be refunded? When comparing payment providers in Cambodia, those details deserve as much attention as the checkout itself.
KHQR provides a useful starting point. The National Bank of Cambodia describes it as a common QR standard through which one code can accept payments from participating payment service operators. That interoperability does not make every merchant arrangement identical. Currency handling, confirmation, refunds and business payouts still need a service-specific review. NBC: KHQR documentation.
Specify the amount and currency together
For a business collecting both KHR and USD, a quote that says “KHQR supported” leaves too much open. Ask how the checkout fixes the invoice currency, where funds are credited and whether any conversion is involved.
The public merchant documentation gives practical examples. ABA's Payment Collection Service describes merchant QR acceptance in KHR and USD into an ABA account. Its PayWay KHQR guideline separately identifies transaction currency and amount; KHR amounts must not contain decimal places. These are documented product features, not proof that a PSP in your shortlist offers the same arrangement.
Request a demonstration using your intended currency and account setup. Confirm what the customer sees before approval and what appears in the merchant report afterwards. If customer and merchant currencies differ, ask who performs the conversion, which rate applies and how the result is recorded. Do not infer a conversion service from support for two currencies.
Build reconciliation around the payment, not just the QR
PayWay's KHQR guideline includes a merchant reference and a separate transaction identifier in its notification example. It also distinguishes the payer's amount and currency from the merchant's amount and currency, and states that a QR can be paid more than once. PayWay: KHQR fields and notifications.
The operational consequence is straightforward: one QR reference may not be enough to identify one receipt. Ask your proposed provider how it distinguishes separate payments from repeated delivery of the same notification. Staff need to see both events without accidentally marking two orders paid or issuing two refunds.
Consider a hypothetical Phnom Penh shop with two orders: one for KHR 80,000 and another for USD 20. These are separate example prices, not an exchange-rate quotation. Suppose the first customer pays twice, creating two confirmed KHR 80,000 receipts, while the second order receives one USD 20 payment.
Before fees, the receipts are KHR 160,000 and USD 20. The intended sales are KHR 80,000 and USD 20, leaving one KHR 80,000 payment to investigate and potentially refund under the agreed process. Keep the currencies separate. A combined total or automatic currency conversion would obscure the duplicate and introduce another reconciliation decision.
Separate payment confirmation from merchant credit
The NBC's published QR Payment Integration document, version 1.0.3 dated 6 August 2021, describes checking a payment result before updating the merchant's transaction status. It also distinguishes receipt at a Bakong account from credit to the merchant's bank account, whose timing depends on the bank implementation. This remains a useful distinction in the published architecture; obtain the provider's current implementation and terms. NBC integration document, pages 4–8.
For your shortlist, identify three pieces of evidence: the confirmed customer payment, the merchant balance or receivable, and the actual bank credit. Establish which record authorizes fulfilment, how missing confirmation is investigated and when funds become usable. A payment success message alone does not answer every settlement question.
Check the exact refund channel
Refund capability can differ even within one provider's products. The ABA Merchant app page describes in-app refunds on Android for transactions within 24 hours, with older transactions referred to merchant support. The separate PayWay Refund API documents full or partial refunds within 30 days, restricted to completed transactions and outlets or terminals with refunds enabled.
Treat these as product-specific examples, not a single Cambodia-wide rule. Ask which refund interface your contract includes, whether it covers payments from other banks, which currency is returned, who may approve a refund and how completion is confirmed. Include the hypothetical duplicate payment in the demonstration. Having a refund button is less useful if the required transaction or staff role cannot use it.
Qualify KHR and USD payouts separately
Taking a KHQR payment does not establish access to every recipient for business payouts. For example, PayWay's payout documentation describes distributions from a settlement account and requires beneficiaries to be ABA account holders or ABA merchants, registered in its beneficiary list.
For each payout candidate, confirm recipient coverage, purpose, currency, funding, limits and failed-transfer handling. Assess customer refunds, supplier payments and merchant settlement as separate operations. Obtain confirmation for your legal entity and business activity before relying on a proposed route.
Turn the Cambodia requirement into a shortlist
PayStar's 14 September 2026 snapshot contains 12 unique recorded payment offers associated only with Cambodia: seven classified as collections (Deposit) and five as payouts (Withdrawal). All 12 have a USD association; one of those same offers also has a KHR association. That is overlapping record coverage, not 13 offers or a count of available KHR providers. Independent currency, country and method links do not prove every route combination. Current availability and merchant eligibility need confirmation.
Want information about these payment options for free? Just write to us. Contact Anastasia through PayStar Discovery with your company, sales channels, currencies and payout recipients. PayStar helps structure the shortlist and qualification. Free information does not include integration, processing or all subsequent Discovery services. You select and contract directly with the PSP, which handles approval, processing and settlement.
PayStar’s role
PayStar provides information and technical services. PayStar is not a bank or PSP, does not arrange payment acceptance or settlement in its own name, does not receive or hold customer or merchant funds, and does not settle those funds. Payment services are provided by the selected provider under a direct agreement with the merchant. PayStar’s API, routing and monitoring operate within the agreed technical role.