QR Ph QR Code Payments: What the Philippines' Unified Standard Actually Is

What QR Ph Is: A Nationwide Standard Led by the Central Bank

Let's start with the basic concept. QR Ph (also written QRPH) is not a payment code invented by any single e-wallet company. It is a nationwide, unified QR code standard led by the Bangko Sentral ng Pilipinas (BSP), the Philippine central bank. Before QR Ph, GCash had its own code and Maya had its own code. A merchant who wanted to accept both had to display several different codes at the counter — fragmented for everyone involved.

Under QR Ph, a merchant only needs to display one code. Whether a customer pays with GCash, Maya, or a mobile banking app from one of the dozens of participating banks, they scan the same code, and funds land correctly in the merchant's account, with no separate registration or printed materials needed for every platform. A similar standardization logic shows up in transfer clearing: since February 2026, the BSP has required digital banks and e-wallets to route transfers through the standardized InstaPay and PESONet clearing rails rather than running their own separate arrangements. QR Ph moves in the same direction.

For the bigger picture of payment access in the Philippines — licensing, settlement, integration formats — see our overview of the Philippines payment gateway landscape; this article stays focused specifically on the QR Ph standard.

The Technical Foundation: A Standardized Code Built on EMVCo

QR Ph's technical foundation is built on the internationally recognized EMVCo QR code framework. EMVCo isn't something invented locally in the Philippines — it's a payment technology standard developed jointly by major card networks, and it underpins many countries' "one code, many wallets" QR payment systems. Singapore's SGQR and Thailand's PromptPay run on the same underlying logic as QR Ph; each country's central bank or regulator has simply adapted the specific rules to local conditions.

What this means practically for merchants: QR Ph is not a hastily improvised local workaround, but a technical approach built on a mature, internationally tested standard. The merchant information, amount, and transaction reference fields encoded in the QR image follow a common format, so apps from different banks and wallets are all reading the same "grammar" when they parse the code — that shared grammar is the technical reason a single code can be recognized by dozens of different institutions' apps at once. A merchant doesn't need to understand EMVCo's field structure in detail, but knowing this is a standardized, internationally validated technical framework, rather than one platform's proprietary protocol, helps explain why "one code, many scans" works, and why it tends to stay stable rather than suddenly breaking because one wallet pushed an app update.

QR Ph vs. a Wallet's Own QR Code: Where the Real Difference Is

This is where merchants new to the Philippine market often get confused: a single wallet's own QR code and a QR Ph code look like the same black-and-white square, but the logic behind them is completely different.

In other words, a single wallet's QR code is platform-exclusive; QR Ph is standard and interoperable. That doesn't mean merchants can stop paying attention to individual wallets altogether — GCash, the Philippines' largest e-wallet by user count (registered users well over 90 million), together with Maya, covers the large majority of the country's active digital users, and QR code payments now account for more than half of all digital transaction volume. Merchants still need to understand which apps their target customers actually use. But from an integration and materials-management standpoint, QR Ph substantially cuts down the "one code per wallet" complexity — and that's the core difference from a wallet's own proprietary QR code.

How Merchants Use It: Three Activation Methods, Two Integration Formats

Once you understand what QR Ph is, the practical question for a merchant becomes how to actually put the standard to work — and there are a few layers of choices involved.

Start with activation methods. Three are common:

• Web-based H5 activation — suited to merchants without their own app; customers scan or tap to launch a wallet app directly from a web page;
• In-app SDK integration — suited to merchants who already have a native app, requiring the mobile engineering team to work with the provider on the integration;
• Offline static/dynamic QR codes — common for physical stores and restaurants, pairing naturally with QR Ph's one-code-fits-many-wallets design so the counter no longer needs a row of different codes.

Then there are two common integration formats: one redirects the customer to a third-party checkout page, briefly taking them off the merchant's own site or app before returning them; the other is "native direct integration," where the customer stays on the merchant's own page to scan or launch the app, with no redirect at all. Each has its place — redirect-based integration is usually faster to set up, while native direct integration is friendlier to the user experience but requires more technical work.

On settlement speed, two common terms come up: "D0 same-day settlement" (funds land the same day as the transaction) and "T1 next-day settlement" (funds land the next day). Not every provider runs D0 across the board, and it's worth asking upfront exactly which applies and whether there are exceptions — for example around holidays or unusually large transactions — rather than finding out after going live that settlement doesn't match expectations.

What Merchants Should Watch For: Process, Risks, and Verifying a Provider

Once the technical path is settled, the integration process generally follows this framework: submit company documentation for due diligence to satisfy the central bank's KYC/anti-money-laundering requirements; the provider assigns a sandbox environment where both technical teams work through order creation, payment callbacks, and refunds; once testing passes, a pre-launch review covers transaction reconciliation, payment success rates, and risk-alert mechanisms; the integration then moves to production and goes live; afterward, the merchant dashboard's transaction reports are used to keep watching reconciliation and anomalies.

A few details are worth clarifying during sandbox testing: whether payment results come through your own active queries or a pushed webhook callback; whether the interface handles idempotency properly if the same payment gets notified twice, so you don't double-credit an account; and whether refunds go back through the original payment method or as a separate transfer, and whether the time-to-credit matches the original payment. Clarifying this during sandbox testing beats discovering problems after going live.

Who ends up using QR Ph collection capabilities: sellers running cross-border e-commerce stores in the Philippines (see our guide to cross-border e-commerce entry for background), local online shops, subscription or pay-per-use services, chain retail and dining businesses with high-frequency small transactions, education and training providers collecting tuition, logistics platforms handling cash-on-delivery, and agencies or service companies collecting deposits. There's one hard prerequisite: the company must already be established in the Philippines (SEC registration completed) — providers doing due diligence will ask for registration documents, director information, and a business address, and none of that moves forward without the entity in place. Preparation around company formation and corporate bank account setup is covered in our company formation service.

A few realities worth knowing upfront: working with a licensed provider doesn't mean handing off all responsibility — the KYC/AML documentation that's supposed to come from your company still has to come from your company. And not every business claiming to offer "payment integration" actually holds a BSP-issued OPS or EMI license; sub-contracting or unlicensed pass-through arrangements do happen, and it's worth verifying independently against the BSP's publicly searchable registry of licensed electronic money issuers and operators of payment systems. One licensed provider we're aware of is SmartPay (paysmartph.com), which works on GCash native direct integration, QR Ph aggregated collection, and Maya disbursement, and holds both OPS and EMI authorization from the BSP. Merchants can verify the license and compare pricing themselves, and can reach out through their Telegram community (t.me/smartpaymanila) to learn more.

Fee structures, settlement cycles, and the number of channels supported vary from provider to provider, so it's worth comparing a few. And the GCash/QR Ph systems themselves get updated from time to time — integration isn't a one-time task.

Official Sources

QR Ph is a central-bank-led standard, so the most authoritative source is the BSP's own website. For the official introduction and latest updates on QR Ph, see the Bangko Sentral ng Pilipinas (BSP); for company registration verification, see the Securities and Exchange Commission (SEC). (Last checked: September 2026)

About this guide and Yixing

Want someone to check your documents against the current requirements? → Yixing can review your case with you

Yixing is a private consulting company registered in the Philippines (SEC Reg. No. CS202009551; BI Accreditation No. CA-202624381-1). This guide does not name or rate other providers and does not promise any outcome; approval rests with the competent authority, and the rules in force are those it currently publishes. For legal disputes or case-specific judgments, consult a practising lawyer — this is not legal advice.