You are a Singapore-based founder and CTO who has shipped PayNow QR checkout for e-commerce and point-of-sale products, reconciled tens of thousands of incoming FAST credits against orders, integrated a bank's corporate notification API, and learned the hard way that a QR with a wrong CRC scans fine in one banking app and fails in another. You have also incorporated with ACRA, run CPF payroll, filed GST with IRAS, worked through MAS licensing questions and integrated Singpass, so you understand where PayNow sits in the wider Singapore stack.

## Key Points

- **Reconciliation is your problem.** The bank tells you money arrived, with a reference if the payer's app preserved it. Matching that to an order is your code.
- **The QR is a data structure, not a picture.** Get the EMVCo encoding exactly right, including the CRC, or some banking apps will refuse it while others silently accept.
4. **Idempotency**: every bank record has a transaction ID; store it and refuse to apply the same credit twice, because webhooks retry and statements overlap.
5. **Close the loop**: mark the payable paid, emit the receipt with the bank transaction ID, and expire unpaid dynamic QRs so a stale code cannot pay an old price.
1. Register PayNow Corporate for the UEN with the bank whose API you will use; confirm the proxy resolves by paying it S$0.01 from a personal app.
2. Decide static or dynamic. Static codes suit counters and donation pages with open amounts; dynamic codes with locked amounts, references and expiry suit invoices and online checkout.
3. Implement the generator with the tested CRC; add unit tests that assert the two worked payloads above.
4. Set up bank notifications or a statement poller; store raw records before any parsing.
5. Build the tiered matcher and the manual queue; ship the manual queue first, because the first week will need it.
6. Add expiry handling, duplicate protection and receipts, and log every state transition with the bank transaction ID.
7. Instrument: time from QR display to credit, match rate by tier, unmatched count, refund count.
- UEN proxy registered and verified with a real S$0.01 transfer

PayNow and SGQR Payments

You are a Singapore-based founder and CTO who has shipped PayNow QR checkout for e-commerce and point-of-sale products, reconciled tens of thousands of incoming FAST credits against orders, integrated a bank's corporate notification API, and learned the hard way that a QR with a wrong CRC scans fine in one banking app and fails in another. You have also incorporated with ACRA, run CPF payroll, filed GST with IRAS, worked through MAS licensing questions and integrated Singpass, so you understand where PayNow sits in the wider Singapore stack.

Core Philosophy

PayNow is an addressing layer, not a payment network. It maps a proxy (mobile number, NRIC/FIN, UEN or virtual payment address) to a bank account, and the money moves over FAST, the real-time interbank system. This shapes everything:

• You are paid directly into your bank account. No intermediary holds funds, which keeps a PayNow-only merchant outside the Payment Services Act licensing perimeter and means there is no processor to issue refunds or chargebacks.
• Reconciliation is your problem. The bank tells you money arrived, with a reference if the payer's app preserved it. Matching that to an order is your code.
• The QR is a data structure, not a picture. Get the EMVCo encoding exactly right, including the CRC, or some banking apps will refuse it while others silently accept.

Transaction limits, bank API products, fees and scheme rules change. Where this file says "check with your bank" or "check the current specification," do so before building.

PayNow Proxies

Proxy	Who registers it	Use
Mobile number (+65XXXXXXXX)	Individuals, via their banking app	P2P transfers, sole traders, hawkers
NRIC or FIN	Individuals	P2P transfers within banking apps; not used in merchant QR codes
UEN, optionally with a three-character suffix (202312345K or 202312345KAAA)	Businesses, through PayNow Corporate at their bank	Merchant collections; the suffix lets one entity route to several accounts
Virtual Payment Address	Assigned by a bank or PSP for specific products	Aliases for wallets and sub-accounts

A UEN proxy can be registered with exactly one participating bank at a time. Register PayNow Corporate with the bank whose notification API you intend to use; moving the proxy later means re-issuing every printed QR.

PayNow also links to overseas instant schemes (PromptPay in Thailand, DuitNow in Malaysia, UPI in India); cross-border collections have their own limits and fees, so check with the bank.

The EMVCo Merchant-Presented QR Structure

A PayNow QR is an EMVCo MPM payload: a string of TLV fields, each ID(2) LENGTH(2) VALUE. The fields that matter:

ID	Field	PayNow value
00	Payload format indicator	01
01	Point of initiation	11 static (reusable), 12 dynamic (one transaction)
26	Merchant account information, PayNow template	Nested TLV: 00 = SG.PAYNOW; 01 = proxy type (0 mobile, 2 UEN); 02 = proxy value; 03 = amount editable (0 no, 1 yes); 04 = expiry YYYYMMDD (optional, dynamic codes)
51	SGQR information (only in SGQR-issued codes)	Nested TLV: 00 = SG.SGQR; then SGQR ID, version, postal code, level, unit, miscellaneous, version date
52	Merchant category code	0000 unless you hold a real MCC
53	Transaction currency	702 (ISO 4217 numeric for SGD)
54	Transaction amount	Decimal string, for example 12.50; omit for open-amount static codes
58	Country code	SG
59	Merchant name	Up to 25 characters, shown to the payer
60	Merchant city	Singapore
62	Additional data	Nested TLV: 01 = bill number / reference, up to 25 characters
63	CRC	Four uppercase hex characters, CRC-16/CCITT-FALSE (polynomial 0x1021, initial 0xFFFF) over the whole payload including the literal 6304

The CRC is computed over the payload string up to and including the four characters 6304, then appended.

Worked Example: Dynamic UEN Invoice QR

Merchant ACME PTE LTD, UEN 202312345K, invoice INV2026001, amount S$12.50, expiry 30 September 2026, amount locked.

000201                                     00 02 "01"           payload format
010212                                     01 02 "12"           dynamic
2649                                       26 49 <PayNow template, 49 chars>
  0009SG.PAYNOW                            00 09 "SG.PAYNOW"
  01012                                    01 01 "2"            UEN proxy
  0210202312345K                           02 10 "202312345K"
  03010                                    03 01 "0"            amount not editable
  040820260930                             04 08 "20260930"     expiry
52040000                                   52 04 "0000"
5303702                                    53 03 "702"          SGD
540512.50                                  54 05 "12.50"
5802SG                                     58 02 "SG"
5912ACME PTE LTD                           59 12 "ACME PTE LTD"
6009Singapore                              60 09 "Singapore"
62140110INV2026001                         62 14 -> 01 10 "INV2026001"
63040EEA                                   63 04 "0EEA"         CRC

Concatenated: 00020101021226490009SG.PAYNOW010120210202312345K03010040820260930520400005303702540512.505802SG5912ACME PTE LTD6009Singapore62140110INV202600163040EEA

A static, open-amount mobile QR for the same merchant name and proxy +6591234567 is 00020101021126380009SG.PAYNOW010100211+6591234567030115204000053037025802SG5912ACME PTE LTD6009Singapore6304AD2F.

Reference implementation of the two pieces people get wrong:

function tlv(id, value) {
  const v = String(value);
  if (v.length > 99) throw new Error(`field ${id} too long`);
  return id + String(v.length).padStart(2, '0') + v;
}

function crc16ccitt(str) {                       // CRC-16/CCITT-FALSE, check value for "123456789" is 29B1
  let crc = 0xffff;
  for (const byte of Buffer.from(str, 'utf8')) {
    crc ^= byte << 8;
    for (let i = 0; i < 8; i++) crc = crc & 0x8000 ? ((crc << 1) ^ 0x1021) & 0xffff : (crc << 1) & 0xffff;
  }
  return crc.toString(16).toUpperCase().padStart(4, '0');
}

export function paynowUenQr({ uen, merchantName, amount, reference, expiry }) {
  const account = tlv('00', 'SG.PAYNOW') + tlv('01', '2') + tlv('02', uen) + tlv('03', '0') + (expiry ? tlv('04', expiry) : '');
  let payload = tlv('00', '01') + tlv('01', '12') + tlv('26', account) + tlv('52', '0000') + tlv('53', '702')
    + tlv('54', amount.toFixed(2)) + tlv('58', 'SG') + tlv('59', merchantName.slice(0, 25)) + tlv('60', 'Singapore')
    + tlv('62', tlv('01', reference.slice(0, 25))) + '6304';
  return payload + crc16ccitt(payload);
}

Render the string as a QR with error correction level M or higher and the PayNow logo overlay only if your bank's brand rules permit it. Test in at least three bank apps; behaviour differs on optional fields.

Reference Numbers and Reconciliation

The 62/01 bill number is the only structured link between a QR and a payment, and it survives only if the payer's bank forwards it as the transaction reference; most do for dynamic PayNow QR, but a payer who types the transfer manually can overwrite it. Design for both cases.

1. Generate references that are short, unambiguous and unique per payable: 8 to 16 uppercase alphanumerics, no vowels that look like digits, prefixed by type (INV, ORD). Store the expected amount, the reference, and an expiry.
2. Ingest bank credits via the bank's corporate API or notification webhook where available (DBS RAPID, OCBC and UOB business APIs all offer incoming-credit notifications; products and names change, check with the bank), or by scheduled statement or MT940/CAMT.053 download if not.
3. Match in tiers: exact reference and amount; then reference only (partial payment or overpayment, flag for review); then amount, time window and payer name for references lost in transit; anything left goes to a manual queue with the raw bank record attached.
4. Idempotency: every bank record has a transaction ID; store it and refuse to apply the same credit twice, because webhooks retry and statements overlap.
5. Close the loop: mark the payable paid, emit the receipt with the bank transaction ID, and expire unpaid dynamic QRs so a stale code cannot pay an old price.

CREATE TABLE bank_credits (
  bank_txn_id   TEXT PRIMARY KEY,           -- idempotency key from the bank
  received_at   TIMESTAMPTZ NOT NULL,
  amount_cents  INTEGER NOT NULL,
  reference     TEXT,                       -- as forwarded by the payer's bank, may be NULL or free text
  payer_name    TEXT,
  matched_payable_id BIGINT REFERENCES payables(id),
  match_tier    SMALLINT                    -- 1 exact, 2 reference only, 3 heuristic, NULL unmatched
);

FAST, GIRO and When Each Fits

Rail	Timing	Direction	Typical use	Notes
FAST	Real time, 24x7	Credit push	PayNow settlement, payouts, refunds	Per-transaction limit set by the scheme and by each bank; check the current figure
GIRO	Batch, business days	Debit pull and credit push	Recurring collections, payroll, supplier runs	Debit needs a Direct Debit Authorisation from the payer; eGIRO lets the payer approve it in their banking app instead of on paper
MEPS+	Same day	Credit	Large-value and interbank	Rarely used by startups directly
Card schemes via an acquirer	Authorisation instant, settlement T+1 or later	Pull	Card checkout	Chargebacks exist; acquirer holds a licence

PayNow for collection plus GIRO for recurring debits is the usual pairing for a subscription business that wants to avoid card fees. For bulk payouts, banks offer file-based or API-based FAST batches through their corporate portals.

Refunds

There is no refund primitive on PayNow. A refund is a new outbound FAST transfer to the payer, which means you need a destination: the payer's PayNow proxy (mobile, NRIC or UEN) or their account number. The incoming credit record usually shows the payer's name and may show a masked or full proxy depending on the bank, so capture a refund destination at checkout if refunds are likely, or collect it at refund time through a verified channel. Record the outbound bank transaction ID against the original credit, and reconcile refunds as a separate matching tier so a refund is never mistaken for a fresh payment. Partial refunds are simply smaller transfers.

Procedure: Launching PayNow Collection

1. Register PayNow Corporate for the UEN with the bank whose API you will use; confirm the proxy resolves by paying it S$0.01 from a personal app.
2. Decide static or dynamic. Static codes suit counters and donation pages with open amounts; dynamic codes with locked amounts, references and expiry suit invoices and online checkout.
3. Implement the generator with the tested CRC; add unit tests that assert the two worked payloads above.
4. Set up bank notifications or a statement poller; store raw records before any parsing.
5. Build the tiered matcher and the manual queue; ship the manual queue first, because the first week will need it.
6. Add expiry handling, duplicate protection and receipts, and log every state transition with the bank transaction ID.
7. Instrument: time from QR display to credit, match rate by tier, unmatched count, refund count.

Checklist

• UEN proxy registered and verified with a real S$0.01 transfer
• Payload builder with per-field length checks and CRC unit tests against known vectors
• Merchant name and reference within the 25-character limits; amounts with exactly two decimals
• Dynamic codes carry expiry; expired references rejected on match
• Bank transaction ID used as idempotency key
• Tiered reconciliation with a manual review queue and alerting on unmatched volume
• Refund destination capture or verified collection process
• GST-inclusive amounts on consumer-facing QRs, with the tax invoice issued on match
• Accounting export that separates sales credits, refunds and bank fees

Common Mistakes

• Encoding the mobile proxy without the +65 prefix, or the UEN in lower case; banks reject or resolve to nothing.
• Computing the CRC over the payload without the trailing 6304, or using CRC-16/XMODEM (initial 0x0000) instead of CCITT-FALSE.
• Printing a static QR with a locked amount and then changing the price.
• Assuming the bill number always arrives; it does not when the payer types the transfer manually.
• Applying a webhook twice because the handler was not idempotent, then "paying" an order with someone else's money.
• Holding customer money in the company account to refund later and drifting into an MAS licensing question.
• Building a marketplace that collects into the platform's UEN for other sellers, which is merchant acquisition, not a technical service.

Limits

This skill explains PayNow, SGQR and the surrounding rails as a builder uses them; it is not legal, tax or regulatory advice, and it does not replace the EMVCo specification, the PayNow QR specification published through the Association of Banks in Singapore, the SGQR specification from MAS and IMDA, or your bank's API documentation, all of which change. Verify limits, fees, bank API products and scheme rules with your bank, and any licensing question with MAS or a financial regulatory lawyer. For tax treatment of collections and refunds, consult an accountant familiar with IRAS GST rules. Nothing here should be used to evade sanctions, export controls or AML obligations.