Static vs Dynamic QR Codes for Philippines Merchants
I run payment operations for a China-based retail group that opened its first Philippines storefronts a few years ago, then added a call-center-driven online store on top of the physical counters. The first QR code we ever printed was static — one sticker, taped to the counter, good for every transaction that walked through the door. It worked fine until it didn't, and the moment it stopped working taught me more about Philippines QR payment design than any vendor deck ever did. This article is the breakdown I wish someone had handed me before we scaled past a single till.
Why the Static-vs-Dynamic Decision Is Bigger Than It Looks
On the surface, static versus dynamic QR looks like a cosmetic choice — one code printed on paper, one code generated on a screen. In practice it decides how your back office closes the books every day. A static code tells the customer's wallet app "pay this merchant." A dynamic code tells the wallet app "pay this merchant this exact amount for this exact order." That one difference — whether the amount and a reference are baked into the code before the customer ever scans it — is what determines whether your finance team spends the afternoon matching bank statements to orders by hand, or whether the match happens automatically the moment the payment lands.
Most merchants don't choose deliberately. They adopt whatever their first channel partner handed them, and only revisit the decision once order volume outgrows what a sticky note and a calculator can reconcile. I'd rather walk through the tradeoff now, before that becomes your Friday afternoon.
Static QR Codes: What They Are and How They Work
A static QR code is generated once and reused indefinitely. It encodes your merchant identifier and account routing details, but not an amount or an order reference. The customer opens their wallet app, scans the sticker on your counter or your delivery bag, types in the amount themselves, and confirms. The code itself never changes — you could laminate it and nail it to the wall for the life of the business.
Under the hood, a static code built to the unified QRPH standard carries just enough structured data for a wallet to recognize the merchant and settle into your account. There's no transaction-specific payload, which is exactly why it's cheap to produce: print it once at a shop that does signage, and you're done. No screen, no POS terminal, no app integration required on day one.
The tradeoff is equally structural. Because the code carries no order information, your system has no built-in way to know which incoming payment belongs to which sale. If three customers pay the same static code within a minute of each other, all you see on the settlement side is three incoming amounts — not three order numbers. You're relying entirely on the customer typing the right figure, and on your staff cross-referencing payment timestamps against whatever paper or till log they kept on their side.
Dynamic QR Codes: What They Are and How They Work
A dynamic QR code is generated fresh for a single transaction. The amount is pre-encoded, usually along with a merchant-assigned order reference, and the code is only valid for that one purchase — typically shown on a screen at checkout, printed per receipt, or rendered on an e-commerce payment page. The customer scans, sees the amount already filled in, and confirms. There's nothing for them to type.
This is the model almost every POS vendor and e-commerce checkout defaults to once volume justifies it, because the code itself becomes the bridge between your order management system and the payment rail. The amount can't be mistyped because the customer never types it. And because the code carries a reference your system generated, the payment notification that comes back from the processor can be matched straight to the order record — no human in the loop.
The cost of that convenience is infrastructure. You need something generating a fresh code per transaction — a POS application, an e-commerce backend, or a kiosk — and typically an API call per order rather than a one-time print job. For a stall selling one product at a fixed price, that's overhead you don't need. For a store running dozens of SKUs and variable baskets, it's the only way reconciliation stays sane.
Static vs Dynamic QR Codes: Side-by-Side Comparison
| Dimension | Static QR Code | Dynamic QR Code |
|---|---|---|
| Setup cost | Very low — print once, no system integration needed | Higher — requires POS, e-commerce backend, or kiosk with API access |
| Reconciliation | Manual — payments arrive with no order reference attached | Automatic — each payment notification carries the order reference |
| Error risk | Customer-entered amount can be mistyped or deliberately altered | Amount is pre-encoded; customer cannot change it before confirming |
| Best use case | Small stalls, fixed-price counters, single-till locations | POS systems, multi-till operations, e-commerce checkouts |
| Code lifespan | Reused indefinitely for every transaction | Generated per order, typically expires after a short window |
| Hardware needed | A printed sticker or card | A screen, printer, or display capable of rendering a fresh code |
Matching the Code Type to Your Business Use Case
Static QR fits the small-footprint operator. A single-till sari-sari store, a market stall with one fixed menu board, a parking attendant collecting a flat fee — these are businesses where the amount rarely varies by much, the operator can glance at the till and verify a payment landed, and the volume is low enough that a quick manual check at closing is a five-minute job, not a daily headache. Printing one sticker and never touching the integration again is a genuine advantage, not a corner cut.
Dynamic QR fits the moment order composition gets complicated. Once you're running a POS with dozens of line items, multiple checkout counters, or an online store where baskets vary order to order, static codes stop scaling. You can't tell from a bank statement whether an incoming amount was order 41 or order 58 if both happened to total the same figure that afternoon. Dynamic codes solve this by construction — the reference travels with the payment, not alongside it.
There's also a middle path worth knowing: some merchants run static QR at the walk-in counter for simplicity and switch to dynamic QR the moment they add a delivery or e-commerce channel where orders are placed before the customer is standing in front of staff. Nothing says you have to pick one model for the entire business — the two can coexist on the same merchant account, split by channel.
The Technical Flow Behind Dynamic QR Generation
Generating a dynamic QR code is, at the API level, a request-response pattern that happens every time an order reaches the payment step. Your system calls the payment gateway with the order amount, your merchant identifier, and a reference you control — the gateway returns a QR payload (and usually a rendered image URL) that you display to the customer. Here's a representative call:
curl -X POST https://api.paysmartph.com/v1/qr/dynamic \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"merchant_id": "MCH20394",
"order_ref": "ORD-2026-0917-00231",
"amount": "{{order.total}}",
"currency": "PHP",
"description": "Order ORD-2026-0917-00231",
"expires_in": 300,
"callback_url": "https://yourstore.ph/webhooks/qr-paid"
}'A typical response hands back the rendered payload and a status you poll or wait on via webhook:
{
"qr_id": "qr_8f2a1c",
"order_ref": "ORD-2026-0917-00231",
"qr_image_url": "https://cdn.paysmartph.com/qr/8f2a1c.png",
"qr_string": "00020101021226...9A0E6304A1B2",
"status": "PENDING",
"expires_at": "2026-09-17T14:32:11+08:00"
}A few things worth understanding before you wire this into production:
The qr_string itself follows the structured EMVCo-style field format used across QRPH-compliant wallets — merchant account information, country and currency codes, the amount, and a CRC checksum are all encoded positionally. You generally don't need to parse this yourself; you render the returned qr_image_url or convert the string to an image client-side. What matters for reconciliation is that the order_ref you sent is the same string that comes back on the payment-confirmation webhook, which is what lets your order system auto-close the sale without a human checking a bank feed.
The expires_in field matters more than it looks. A dynamic code tied to a specific amount shouldn't stay valid forever — if the customer walks away and comes back an hour later, you want a fresh code rather than a stale one sitting on an order that might have changed. Most implementations set a short expiry window and simply regenerate on request if the customer needs more time.
Finally, build your webhook handler to be idempotent. Networks retry, and you don't want a duplicate callback crediting the same order twice. Keying off qr_id and order_ref together, and checking whether that order has already been marked paid before applying the update, avoids the double-credit bug that shows up the first time your payment volume gets any kind of real traffic.
SMARTPAY operates in the Philippines under BSP OPS and EMI licensing, which is what allows both static and dynamic QR flows to settle through a regulated, auditable rail rather than an informal pass-through arrangement.
Error Risk and Reconciliation: The Real Cost of Getting This Wrong
The practical failure mode with static QR isn't fraud — it's friction. A customer fat-fingers an extra digit, or rounds to a number that looks close enough, or the staff member reading the total aloud transposes it. None of this is malicious; it's just the predictable result of putting a free-text amount field between the sale price and the payment. Multiply that by dozens of transactions a day and your reconciliation process becomes a game of matching timestamps and rough amounts to a paper log, hoping nothing lines up ambiguously.
Dynamic QR removes the typing step entirely, which removes the single biggest source of that friction. It doesn't make reconciliation itself happen — you still need a system that reads the payment confirmation and closes the loop against your order records — but it gives that system something reliable to match against. This is also where the two code types diverge in auditability: a dynamic transaction carries a reference from the moment it's created, so if a payment ever needs to be traced back to a specific sale for a dispute or a refund, there's a clean paper trail rather than a reconstruction exercise.
If you're currently running static QR and starting to feel the reconciliation strain, it's worth reading how this same tradeoff plays out specifically on QRPH's own static-and-dynamic code specification, and how it compares to the deeplink-based approach some wallets use for in-app QR scanning and merchant deployment. If your checkout flow doesn't need a QR code at all — say, you're collecting payment for an invoice sent by message rather than at a counter — a payment link can skip the code entirely and achieve the same per-order traceability.
Frequently Asked Questions
Can I run static QR at my counter and dynamic QR for online orders on the same merchant account?
Yes. The two code types aren't mutually exclusive settlement methods — they're just different ways of generating a payment request against the same underlying merchant account. Many operators keep a static code for walk-in simplicity and layer dynamic generation on top once they add a channel, like delivery or an online store, where the order is defined before the customer is standing at a till.
Does a dynamic QR code expire if the customer doesn't scan it in time?
Typically yes, based on the expiry window you set when generating it. If the window passes before payment, the code stops being valid and your system should generate a fresh one rather than letting the customer attempt to pay against a stale request.
What happens if two customers scan the same static QR code around the same time with different totals?
Both payments land in your account as separate incoming transfers, but neither carries an order reference. Your staff or back office has to match each payment to the right sale using whatever manual log you keep — amount, rough timestamp, and memory. This is the core reconciliation gap that dynamic QR is designed to close.
Do I need a screen to use dynamic QR, or can I print it per transaction?
Either works. A screen at a POS counter is the most common setup because it avoids printing costs, but plenty of merchants render the code on a receipt printer per order — useful for kiosks or counters without a customer-facing display.
Is a dynamic QR code harder for a fraudster to tamper with than a static one?
The amount field is harder to manipulate because the customer isn't the one entering it — with static QR, a dishonest customer could claim they paid less than they owe and there's no encoded amount to contradict them. Dynamic QR removes that particular dispute, though it doesn't replace general payment security practices like verifying confirmation status before releasing goods.
How do I reconcile a static QR payment if the customer didn't note an order number?
You're reconciling by amount and timestamp proximity, which works reasonably well at low volume but degrades quickly as transaction count rises. If this becomes a recurring headache, it's usually the clearest signal that it's time to move that channel to dynamic generation rather than trying to patch the manual process further.
Can a static QR code be reused after I close one location and open another?
No — a static code is tied to the merchant account and routing details it was generated against, not to a physical address, but if your settlement account or merchant registration changes, you'll need a new code generated against the updated account details rather than reusing the old sticker.
If I were rebuilding our QR setup from scratch today, I'd still start static at the first counter — there's no reason to build integration overhead before you have the order volume to justify it. But the trigger for switching isn't a revenue milestone, it's a reconciliation symptom: the day your staff spends real time each afternoon matching payments to orders by hand is the day dynamic QR pays for itself. Most merchants cross that line earlier than they expect, usually right around the point they add a second till or a first online channel.
If you're weighing this for your own setup — whether that's a single POS counter or a full e-commerce integration — happy to walk through what the API side actually looks like for your specific order flow. Reach out on Telegram at @LouisSMARTPAY or by email at [email protected].