Scoping a Multi-Channel KHQR Acceptance Build

Assume a retailer operating physical stores in several provinces, an e-commerce site, and a mobile app with a loyalty programme. Each channel was built at a different time against a different provider. In store, a card terminal from one bank accepts international cards and that bank's own QR code. Online, a gateway handles cards and a couple of wallets. In the app, a third SDK handles a fourth set of methods. Three costs follow from that shape, and they are the reason a consolidation project gets funded. The first is reconciliation effort. Finance receives settlement files from several providers on different schedules in different formats, and matches them by hand against the sales records in the ERP. The work scales with the number of providers, not the number of transactions. The second is inconsistent acceptance. A customer can pay by their preferred method in one channel and not another. Where a proprietary bank QR is the only code on the counter, every customer banking elsewhere is pushed back to cash. The third is the absence of a single view of payment data. Nobody can answer which methods are used where, at what times, at what basket size, because the answer lives in three systems that do not share a transaction identifier.

The technical goal is narrow: one payment service inside the merchant's own estate, exposing a channel-appropriate interface at the front and speaking one bank's Bakong API at the back. For in-store payments, the service generates a dynamic KHQR code carrying the exact amount, the merchant identifier and a unique transaction reference, rendered on a customer-facing display as the sale is finalised. Dynamic rather than static matters more than it sounds: a static counter-top code cannot pre-populate the amount, so the customer types it, and every mistyped amount becomes a reconciliation exception. For e-commerce, the same service generates a code in the checkout page together with a deep link, so a customer already on a phone can jump straight into their banking app instead of scanning their own screen. For the mobile app, there is no code to scan at all — the KHQR payload is handed to the banking app as a deep link. All three paths converge on one transaction record, one settlement reconciliation, and one export into the ERP.

A build of this kind decomposes into four services, and the separation between the third and fourth is the one that inexperienced integrations get wrong. Code generation produces EMVCo-conformant KHQR payloads. The tag structure is fixed by the standard, but merchant-specific fields, the transaction reference and the CRC have to be assembled correctly for every transaction, and a payload that a validator accepts is not the same as one that every wallet in the field renders. Transaction management holds the lifecycle. A pending record is created when a code is generated; a webhook from the bank moves it to confirmed; downstream effects — receipt, stock, loyalty accrual — hang off that transition and nothing else. Settlement monitoring is a different problem from payment confirmation, and conflating the two is the classic defect. An individual Bakong payment confirms in seconds. The money arrives in the merchant's account on the sponsor bank's batch schedule. A system that treats a payment webhook as proof of funds received will reconcile cleanly and still be wrong about cash position. Reconciliation matches three sets of records against each other: the payment service's own transactions, the bank's settlement statement, and the sales records in the POS, e-commerce and ERP systems. Its output is not a number but a list of exceptions, classified by kind — timing difference, amount mismatch, missing on one side — because that classification is what determines who has to act.

This is the part of the scenario that determines whether the engagement is one CamFinTech can take at all, and it is worth setting out before architecture rather than after. CamFinTech builds the client side: the payment service, the channel adapters, the reconciliation logic, the ERP export, and the tests and documentation that let the merchant's own team run it. The work is charged as a fee for that build. There is no commission, no share of transaction value, and no markup on anything a third party invoices. The merchant operates what we hand over. It runs on their infrastructure, under their control, carrying their traffic. We do not host or transmit client transaction data — a multi-tenant service standing in the payment path is a different kind of business with a different licensing posture, and it is not this one. The sponsor bank is the licensed operator. It holds the merchant relationship, provides the Bakong connectivity, sets the merchant discount rate, and settles the funds. We never hold client funds and we never operate a rail. Where the same engagement also involves navigating an approval — a merchant registration, an accreditation, a licence application — the client is the applicant of record, and CamFinTech neither influences nor claims to influence any regulator's or bank's decision. Where we do both the build and the approval work for one client, we say so and price them as two separable scopes.

The sequencing principle is to put the first channel where a defect is cheapest to discover, not where the volume is. That means e-commerce first. It carries lower transaction volume than the shop floor, its customers are more tolerant of a payment option that is visibly new, and the whole path — code generation, webhook, settlement, reconciliation, ERP export — can be exercised end to end without anyone standing at a till waiting. Point of sale follows, and it starts in a small number of stores rather than all of them, because the failure modes at this stage are physical rather than logical: screen placement, glare, code size, and what a cashier does when a customer's scan does not take. Those are learned in a shop, not in a test suite. The mobile app comes last, because it is the smallest increment. By then the backend is proven and the app change is a deep link and a status callback. A plan of this shape typically runs across a small number of months rather than weeks, with the pace set by the sponsor bank's testing windows and the merchant's own release calendar — both of which are outside the integrator's control and should be scheduled as constraints rather than assumed away.

Four are worth naming at design time because each is cheap to prevent and expensive to retrofit. Polling instead of webhooks. Asking the bank's API repeatedly whether a payment has landed adds latency the customer experiences at the counter and generates API load that scales with waiting time rather than with sales. Where the sponsor bank offers webhook notification, the design should take it, and should still reconcile against the settlement statement rather than trusting the webhook as the only record. Treating confirmation as settlement. Covered above; it belongs on this list too, because it survives code review easily. A payment confirmed is a payment owed to you, not a payment received. Static codes in a retail setting. They are simpler to deploy and they push amount entry onto the customer. The reconciliation exceptions that follow cost more than the dynamic implementation saved. Assuming the integration is the hard part. It generally is not. Getting staff to offer the payment method at the counter, when habit says card or cash, decides whether the build is used. That is a change-management cost and it belongs in the plan and the budget, not in a footnote.

The specific merchant is invented; the architecture is not. Any organisation accepting payments across more than one channel in Cambodia faces the same choice between bolting KHQR on as a fourth payment method and rebuilding around it as the primary rail. The case for the latter rests on where the infrastructure is going rather than on where it is. Interoperability means one registration reaches the whole network. Settlement is real-time at the payment layer. Cross-border corridors extend the same acceptance surface to visitors from partner countries without a second integration. Each subsequent Bakong capability tends to arrive as an addition to an interface a merchant already speaks. An architecture organised around that rail absorbs those additions as features. One organised around cards, with KHQR attached at the side, absorbs each of them as another integration project.