Accepting payments in Southeast Asia. 7 chapters and a final quiz.

Chapter 1. Choosing your entry point, market by market.

The entry point is the contractual counterparty through which a merchant reaches a market’s payment rails. To choose one, first identify the payment method that actually carries most of the value in that market, then the company that gives access to that rail. In the five markets in scope, both answers are almost always national. An operator owned by the central bank or a banking association builds the rail, while the technical entry point is usually a local aggregator. An international acquirer offers one contract for all five countries, but not the same quality of access to the five domestic rails. The cost of that choice is the share of demand left outside the checkout. A Malaysian launch with a card integration alone, for example, misses FPX, which still ranks ahead of cards as Malaysia’s leading online payment method.

Four questions to ask before you sign

• What exactly is the counterparty’s regulatory status? A bank, an e-money issuer, a payment system operator, or a purely technical aggregator with no license of its own that resells someone else’s access. The answer determines who holds your funds between collection and payout.
• Does the provider expose the national QR in DYNAMIC mode, with a reference field? Access to the static QR only is not access to the rail. It is a sticker, and you cannot reconcile it.
• Which domestic routing requirements apply, and who handles them? GPN in Indonesia, MyDebit in Malaysia, local TPN switching in Thailand: these are not commercial options but conditions for operating in the market.
• In what currency, to which account, and how fast will you be paid? A dollar payout from Singapore for sales in rupiah is a different transaction, with a different FX risk, than a rupiah payout to an Indonesian account.

Chapter 2. Integrating the national QR: from static to dynamic.

All five QR standards in the region are built on the same technical specification, the EMVCo merchant-presented mode, in which the merchant displays a code and the payer scans it. The encoding is TLV (tag, length, value), readable by any compliant app. The code format is the same from one country to the next. The differences lie in the operator that issues it, the rail it settles on, and the field that holds the order reference. A developer who has integrated QRIS will find the same grammar in Thai QR Payment, DuitNow QR, QR Ph, and SGQR. They will still have to build five integrations, because the API, merchant onboarding, and reconciliation file are national. Each of the five countries is a separate integration project.

TAG LEN VALUE                      ROLE

00  02  01                          Payload Format Indicator
01  02  12                          Point of Initiation Method
                                      "11" = STATIC, reusable indefinitely
                                      "12" = DYNAMIC, single-use code  <-- what you need
26  ..  <scheme template>            Merchant Account Information (tags 02 to 51)
      00 .. <national scheme identifier>
      01 .. <merchant ID assigned by the acquirer>
52  04  5999                        Merchant Category Code (ISO 18245)
53  03  360                         Currency, ISO 4217 NUMERIC
                                      360=IDR  764=THB  458=MYR  702=SGD  608=PHP
54  ..  75000.00                    Amount: DECIMAL STRING in EMVCo format,
                                      NOT an integer in minor units
58  02  ID                          Country, ISO 3166-1 alpha-2
59  ..  <merchant name>             What the payer sees BEFORE confirming
60  ..  <city>
62  ..                              Additional Data Field Template
      01 .. <Bill Number>             <-- your order number
      05 .. <Reference Label>         <-- your reconciliation key
63  04  <CRC>                       CRC-16/CCITT-FALSE (polynomial 0x1021, init 0xFFFF)
                                      computed over EVERYTHING before it, "6304" included

Static or dynamic: what the choice means for operations

• A static code encodes neither an amount nor a reference. The merchant reconciles by eye, based on the amount and the time. That leaves it open to a fake transfer confirmation, because a phone screen is not proof of credit.
• A dynamic code carries your order number in the additional data template (tag 62). That field, and only that field, makes reconciliation automatic: it comes back in the acquirer’s file and in the credit notification.
• A dynamic code must expire. A single-use code with no expiry becomes a reusable one. Set a TTL on the server side, invalidate the code on the first credit notification, and reject any second credit with the same reference.
• The displayed name affects conversion. The payer’s app shows tag 59 before confirmation. If the registered legal name differs from the brand the customer knows, some payers drop off on the last screen. Aligning the two is part of onboarding, not an administrative detail.
• The credit notification is the source of truth. Neither the scan, nor the payer app’s return, nor a screenshot confirms an order. Only the notification pushed by your acquirer, or failing that a call to its status API, should trigger shipment.

Chapter 3. Connecting super-app wallets.

An e-wallet is a payment app backed by a balance held with the company that runs it. In this region, it is the channel through which most payers arrive, especially in the Philippines and Indonesia. That leaves the merchant with two decisions. The first is how to accept wallets: through the national QR, which covers every issuer with a single integration, or through direct integrations, one wallet at a time. The second is the counterparty review, since most of these companies are not banks. Their status determines the kind of risk the merchant carries on collections awaiting payout.

Two ways to accept wallets, and how to choose

• Through the national QR. One acquirer integration makes every compliant issuer acceptable. That is the whole point of QRIS, DuitNow QR, and QR Ph, each mandatory for issuers in its country. You gain coverage and an MDR that is either regulated or negotiated once; you lose the direct relationship with the payer’s app.
• Directly, one wallet at a time, with one integration per brand, usually through a redirect or a deeplink into the app. You gain the in-app experience, marketing campaigns, and sometimes a better rate; you pay for every integration, every contract, and every reconciliation file.
• Rule of thumb: start with the national QR in markets where it is mandatory (Indonesia, Malaysia, the Philippines), and add a direct integration only for a wallet where you expect enough volume, or a commercial campaign, to pay for it.
• Recurring payments cannot run on QR or on a standard wallet. These rails are payer-initiated. A subscription requires a debit mandate (DuitNow AutoDebit in Malaysia, GIRO / eGIRO in Singapore) or a card.

Chapter 4. Costing cash on delivery and moving customers off it.

Cash on delivery (COD) means the customer pays for an order in cash when the courier hands it over. It creates a logistics chain that collects payments on the merchant’s behalf. A third party collects the cash, consolidates it, and pays the seller on its own schedule. It carries three costs that no fee schedule shows: refusals at the door, the round-trip shipping, and the cost of carrying the cash. On top of that comes counterparty risk on a logistics provider that is usually not a payment institution. So a COD assessment looks at this full cost and at the rails that can replace it, not just at the collection fee the carrier charges.

MODEL

  Expected cash       E = P x (1 - r)
  Collection fee      L = E x f_cod
  Lost round trip     R = P x r x (a + b)
  Cash carry cost     T = E x t x (d / 365)

  Cost of collection  C = L + R + T        measured against E, not P

  P     = average order value, tax included
  r     = refusal rate at the door
  f_cod = carrier's fee on the cash collected
  a, b  = delivery cost / return cost, as % of order value
  t     = annual cost of capital
  d     = CONTRACTUAL delay before the cash is paid out, in days

WORKED EXAMPLE — working assumptions, replace with YOUR negotiated figures

  P = 100   r = 15%   f_cod = 2%   a = 4%   b = 4%   t = 12%   d = 21

  E = 100 x 0.85                    = 85.00
  L = 85.00 x 0.02                  =  1.70
  R = 100 x 0.15 x (0.04 + 0.04)    =  1.20
  T = 85.00 x 0.12 x 21 / 365       =  0.59
  --------------------------------------------
  C = 3.49  on 85.00 collected      =  4.11 %

  Compare with the QRIS MDR on the same order for an Indonesian merchant
  in the UKE / UME / UBE categories: 0.7% (Bank Indonesia schedule).

WHAT THE MODEL LEAVES OUT
  · the 15% of refused orders generate NO revenue at all:
    the hit to margin is far larger than the collection cost itself
  · d is a real delay only if it is in the contract; otherwise it is a hope
  · the risk that the carrier holding your cash defaults is not
    in C: you manage it with an exposure cap, not a rate

What to get from the carrier in writing

• A payout file itemized by order, not a lump-sum payout. Without the order number in the file, reconciliation goes back to manual, and fixing that is a logistics negotiation, not a payments one.
• A contractual payout deadline (D+n), with a late-payment penalty. Until it is written down, it varies, and the carrier funds its working capital with your money.
• A cap on the cash held on your behalf at any one time, and the guarantee mechanism that backs it.
• How refusals at the door are handled: who pays for the return, how quickly the product is back in sellable stock, and at what refusal rate the pricing gets renegotiated.
• A refusal rate you measure yourself, not one the carrier reports: cross-check parcels shipped, collected, and returned against your own systems.

Chapter 5. Checking licensing, ownership, and routing before you collect.

Three separate regulatory layers determine whether you can collect payments in a market, and on what terms. Who is allowed to collect funds is set by the licensing regime. Which route the transaction must take depends on the domestic routing requirement. And in at least one case, the rules also set who must own the capital of the operating entity. All three are matters of law, not commercial negotiation with a provider. Check them in the relevant regulator’s register before you sign the contract.

Merchant of record or local entity: the trade-off

• Volume and time horizon. Below a certain volume, a local entity never pays back the cost of incorporation, compliance, and administration. A merchant of record, a licensed third party that sells in its own name and pays you out, is the sensible way to test a market.
• Settlement currency. Getting paid in local currency into a local account almost always requires a local presence. Without one, you are paid in a hard currency, at an FX margin you do not control.
• Domestic routing. Where routing is mandated (GPN, MyDebit, TPN), your acquirer handles it. The question becomes “Is my acquirer connected to the right switch?” not “Do I need to connect to it?”
• Price. A correctly classified domestic merchant pays the domestic rate. A cross-border seller using a collecting provider pays for access on top: the MDR gap is the price of having no local entity.
• Tax exposure. Collecting locally, invoicing locally, and paying local indirect taxes are three linked issues to work through with a local adviser. This course does not cover them.

IDENTITY AND RIGHT TO OPERATE
  [ ] counterparty's license or authorization number, LOOKED UP IN THE
      REGULATOR'S REGISTER (Bank Indonesia, Bank of Thailand, Bank Negara
      Malaysia, MAS, Bangko Sentral ng Pilipinas) — never from a marketing page
  [ ] exact type of entity: bank / e-money issuer /
      payment system operator / technical aggregator with no license of its
      own, reselling someone else's access
  [ ] for a multi-country group: the LOCAL entity and its LOCAL license,
      not the head office's license

MONEY
  [ ] do funds pass through an account in your name or the provider's
      account? safeguarding, and who bears the risk if it defaults
  [ ] currency, country of the settlement account, contractual D+n timing
  [ ] FX: who sets the rate, when, and with what disclosed margin
  [ ] MDR IN WRITING, by merchant category
        Indonesia: UMI / UKE / UME / UBE classification -> Bank Indonesia schedule
        Malaysia:  DuitNow QR rate set by the ACQUIRER, confirm in writing

TECHNICAL
  [ ] SNAP-compliant APIs if Indonesia
  [ ] domestic routing: GPN (Indonesia), MyDebit (Malaysia), TPN (Thailand)
      -> which licensed switch, and who handles the routing
  [ ] DYNAMIC QR confirmed, with a reference field exposed by the API
  [ ] recurring: is a debit mandate available? (DuitNow AutoDebit, GIRO/eGIRO)
  [ ] reconciliation file: format, transaction-level detail,
      frequency, delivery channel

Chapter 6. Setting expectations for cross-border QR links.

A cross-border QR link connects two national instant payment systems so that a payer can pay abroad with the app from their home country. In 2021, the PayNow–PromptPay link between Singapore and Thailand became the world’s first connection between two retail instant payment systems using proxy addressing. In 2022, five central banks signed the Regional Payment Connectivity (RPC) memorandum of understanding: Bank Indonesia, Bank Negara Malaysia, Bangko Sentral ng Pilipinas, the Monetary Authority of Singapore, and the Bank of Thailand. Vietnam, Brunei, and Laos joined later. For the accepting merchant, the transaction is a domestic payment. A traveler scans the merchant’s national QR with their home app, and the merchant receives a domestic payment in local currency, with no extra integration. Currency conversion, limits, and settlement are handled between the operators. For a merchant, what these links are worth comes down to the volumes they carry.

• You don’t control the FX, and it is unregulated. The rate applied, and how transparently it is shown, varies from link to link, with no regional rule. Your foreign customer pays a different effective price depending on their home corridor, and you cannot fix that.
• Limits are set by the two central banks, not by you or your acquirer, and they vary by link. Find them out before you go live, not in production.
• You collect as you would domestically. The payment reaches you in local currency, settled on the national rail: no FX line shows up on your side, and no special accounting entry is needed. That is the main benefit for a merchant.
• The Philippines remains outside the bilateral QR network, even though the BSP signed the RPC. Inbound payments from another country in the region go through a private gateway or a BSP-licensed provider that offers the regional wallets.
• The bilateral model is a structural ceiling. Each link is a full project between two operators: a complete network of 10 countries would take 45 links.

Chapter 7. Reconciling: keys, settlement cycles, and multiple currencies.

Reconciliation means matching every collection that lands in the bank to the order that generated it. Three failures get in the way, and they compound across five markets. There is no key, because the rail did not carry the seller’s order reference. There is no common cycle. The rail runs 24/7, while settlement follows the national RTGS and its business days. There is no common currency. Five collections arrive in rupiah, baht, ringgit, Singapore dollars, and pesos, paid out on different dates and converted at different rates. The fix is data discipline set up before the first transaction, because no tool can rebuild after the fact a key the rail never carried.

Settlement follows the national RTGS, not the 24/7 rail

• In Indonesia, Bank Indonesia operates BI-RTGS; bulk positions go through SKNBI, and BI-FAST settles on a net basis.
• In Thailand, BAHTNET (Bank of Thailand, since 1995, migrated to ISO 20022) settles the net positions of PromptPay and the NITMX bulk systems.
• In Malaysia, RENTAS (operated by PayNet for Bank Negara Malaysia, since 1999) settles RPP and Interbank GIRO positions.
• In Singapore, MEPS+ (Monetary Authority of Singapore, since 2006) is the final settlement point for FAST, GIRO, and the local card schemes.
• In the Philippines, PhilPaSS / PhilPaSS+ (Bangko Sentral ng Pilipinas, since 2002, rebuilt on ISO 20022) settles the net positions of InstaPay and PESONet.
• The consequence is the same everywhere: a payment received at midnight on a Sunday is final for the payer but not yet available to you. The gap between finality and availability is the classic source of cash position discrepancies. Model it in advance instead of absorbing it.

order_id              your reference, pushed into the QR (tag 62-01 or 62-05)
rail                  QRIS | THAI QR | DUITNOW QR | QR PH | FPX | VA | COD
amount_local          GROSS amount, in local currency
currency_local        IDR | THB | MYR | SGD | PHP        (ISO 4217 alpha-3)
mdr_local             fee withheld, in local currency
net_local             amount_local - mdr_local           <- what the bank pays out
settlement_date       VALUE date at your settlement bank, set by the
                      national RTGS cycle — NOT the rail's timestamp
fx_rate               rate applied ON THE SETTLEMENT DATE, never on the
                      transaction date
net_reporting         net_local / fx_rate                <- the amount booked
rail_reference        the rail's technical reference, when the rail provides one

GOLDEN RULE
  RECONCILE in local currency: net_local against the local bank statement.
  CONSOLIDATE in the reporting currency afterward.
  Doing it the other way around (convert, then reconcile) creates rounding
  differences that no tool can explain later.

MINOR UNITS: the trap that springs when you expand
  ISO 4217 assigns 2 decimal places to IDR, THB, MYR, SGD, and PHP,
  and 0 to the Vietnamese dong (VND).
  A data model that stores "everything in cents" works in the five
  markets in this course, and breaks the day you add Vietnam.
  Store the currency AND its exponent; never hard-code the exponent.