Scoping Cross-Border KHQR Acceptance

Assume a merchant with a visitor-heavy customer base — a hotel group, a restaurant cluster, a retailer near a major site. Its Cambodian customers already pay by KHQR. Its foreign customers largely do not: they arrive holding a payment app that works everywhere at home and nowhere here, discover the merchant takes cards at a materially higher cost or cash only, and behave accordingly. The bilateral corridors change the available answer. Where a corridor is live and the merchant's bank has enabled it, a visitor scanning the merchant's code with their home app can complete a payment that settles to the merchant in the ordinary way. The merchant's question is therefore narrow and practical: what has to change in our systems, what has to change in our bank arrangement, and what can we honestly tell staff and customers about which apps work? That last part is not a rhetorical flourish. The commonest failure of a cross-border acceptance rollout is not technical. It is a sign at the counter listing logos the merchant cannot actually accept, put up because someone conflated a corridor existing with a corridor being enabled on that merchant's account.

The integration work is smaller than the topic suggests, which is a point worth making plainly rather than obscuring to justify a fee. On the merchant side, cross-border acceptance is largely the same acceptance the merchant already has. The code presented to the customer is generated the same way. The confirmation arrives the same way. The settlement lands in the same account. What changes is that the payment reaches the merchant's bank over a corridor rather than domestically, and that the merchant's systems now see transactions denominated differently from the amount they requested. So the real integration work is in the record-keeping, not the payment: capturing the corridor a transaction arrived on, the amount the customer was charged in their own currency, the rate and fees applied, and the amount actually settled — and carrying all of that into the merchant's accounting records so that a month-end reconciliation can be completed without guessing. What the integration does not cover is everything that involves the money itself. Conversion, corridor selection, and settlement are performed by licensed institutions. CamFinTech does not route payments, does not convert currency, does not hold client funds, and does not operate a rail. An integrator who offers to compare rates across banks and route each transaction through the best one is offering to become a payments business, and should be assessed as one — including whether it holds the licence that activity requires.

The engineering error to avoid is treating corridors as interchangeable because they are all reached through the same acquiring relationship. They differ in ways that reach the merchant's systems. Transaction and daily limits are not uniform. Settlement timing is not uniform. The currency the customer is charged in, and therefore the rounding behaviour the merchant sees, is not uniform. Refund and reversal handling — the part every merchant discovers late — is the least uniform of all, because a reversal across a corridor is a different operation from a domestic one and is not always available on the same terms. The design response is to model the corridor as an explicit attribute of a transaction from the first line of code, rather than inferring it later from a currency or a fee pattern. A merchant that has recorded the corridor can answer a question about a specific payment months later. One that has not is reduced to reconstruction. The second design response is to make corridor enablement configuration rather than code. Corridors get enabled, and occasionally suspended, on a timetable set by banks and authorities. A merchant should not need a software release to reflect that, and the customer-facing surface — what staff are told, what signage says, what the checkout displays — should be driven from the same configuration so it cannot drift out of step with reality.

CamFinTech builds the client side: the capture of corridor and currency data, the changes to the merchant's payment records, the reconciliation logic, the accounting export, and the operational tooling that lets the merchant see which corridors are enabled and what each transaction actually cost. Fee-only, handed over on completion. The merchant operates it and holds the bank relationship. The bank enables corridors, sets terms, performs conversion and settles funds. Where a merchant needs to negotiate better terms, that is the merchant's negotiation with its bank; we can help it understand what to ask for and what the data shows, which is a different thing from conducting it. We do not hold client funds, do not operate a rail, and do not host or transmit client transaction traffic. Where an engagement touches an approval or an enablement, the client is the applicant of record and we neither influence nor claim to influence the decision of any bank or regulator. On cross-border work specifically there is one further limit worth stating, because the topic invites it. Compliance obligations attaching to cross-border flows — reporting thresholds, screening duties, the merchant's own obligations under its acquiring agreement — are matters for the merchant, its bank and its licensed advisers. We build systems that produce the records those obligations require. We do not interpret the obligations, and we do not represent clients to anyone.

Establish availability first, in writing, from the bank. Which corridors, for which merchant category, on what terms, with what limits. Nothing downstream is safe to plan before this exists, and the temptation to start building while waiting for it is exactly how a merchant ends up with signage promising acceptance it does not have. Then extend the transaction record. Corridor, customer-side currency and amount, rate, fees, settled amount. This is a data-model change and it is far cheaper before the first cross-border transaction than after a few thousand of them. Then reconciliation and reporting, so that the merchant can see the true cost per corridor and hold its bank to the agreed terms. Then the customer-facing surface, driven from the enablement configuration, and staff briefing driven from the same source. The ordering is deliberate: the record-keeping ships before the acceptance is advertised, so the merchant is never in a position of taking payments it cannot fully account for.

Cambodia's position here is unusual and worth understanding on its own terms. Multiple operational bilateral linkages is not the normal state of affairs for a market of this size, and it means acceptance infrastructure a merchant builds for domestic KHQR extends outward as corridors open, rather than requiring a separate international acceptance project. That is the strategic case for treating the domestic rail as primary and letting cross-border arrive as configuration on top of it. It is also the reason the integration work is modest: the merchant is not building a cross-border payment capability, it is recording the additional attributes of payments arriving over a capability the rail already has. An integrator whose proposal for this work is large should be asked precisely which of the functions in the table above it intends to perform, and under what licence.