QRPH Interoperability Explained: One QR Code, Every Philippine Wallet and Bank (2026)
I run payments for a hospitality group with properties in Manila, Cebu and Palawan, and our head office is not in the Philippines. When we first looked at QR payments here, we assumed we would need a GCash QR at the front desk, a Maya QR next to it, and perhaps a bank QR for guests who prefer their banking app. That assumption was wrong, and understanding why is the single most useful thing a foreign operator can learn about Philippine payments. The country runs a national QR standard called QR Ph, usually written QRPH in merchant circles, and its entire purpose is interoperability: one code that any participating wallet or bank app can scan and pay. This article explains what that interoperability actually means at the technical and operational level, how a payment travels from a customer's app to your account, where the edges and limits are, and what it changes about how an international business should integrate. For the onboarding side, see how to become a QRPH merchant; for the collection use case, see QRPH collection services for international businesses.
What Interoperability Means in the Philippine Context
In many markets, QR payments grew up as closed loops: each wallet issued its own QR, readable only by its own app. The Philippines took a different route. Under its National Retail Payment System framework, the Bangko Sentral ng Pilipinas (BSP) issued Circular No. 1055 in 2019 adopting a National QR Code Standard, and the industry rolled it out under the name QR Ph. The standard is built on the EMVCo merchant-presented QR specification, the same family of specifications used by several other national QR schemes in Asia. Interoperability here has a precise meaning: a QR Ph code generated by a merchant onboarded with one participating institution can be scanned and paid by a customer using the app of any other participating institution, and the funds clear between the two institutions through the national real-time rails rather than through a private agreement between the two brands.
The practical consequence is that the QR is not a GCash feature, a Maya feature or a bank feature. It is a payment address that belongs to the merchant and is resolved by the ecosystem. For a foreign operator, this collapses what would have been several integrations into one, and it removes the question "which wallet should we support" at the point of sale, because the code answers it for you.
The Standard, the Rails and the Governance: Three Things People Confuse
Three separate things make QRPH work, and conversations go wrong when they are mixed up. The first is the standard itself, the data format inside the QR: merchant identifiers, the acquiring institution, optional amount, reference fields and a checksum, laid out according to the EMVCo template. The second is the clearing rail. Person-to-merchant QR Ph payments ride on InstaPay, the real-time interbank transfer network, which is why a QR Ph payment from a bank app lands in a wallet-held merchant account in near real time and why the same account can also receive ordinary InstaPay transfers. The technical difference between the two national rails is covered in InstaPay vs PESONet for merchants. The third is governance. The Philippine Payments Management Inc. (PPMI), the industry body recognised by the BSP to manage the retail payment system, together with the BSP, sets participation rules, dispute procedures and technical certification for institutions that want to issue or acquire QR Ph transactions. Merchants do not deal with this layer directly; their acquiring institution or licensed gateway does.
| Layer | What it is | Who operates it | What the merchant sees |
|---|---|---|---|
| QR Ph standard | EMVCo-based data format for merchant-presented QR codes | Defined under BSP Circular 1055 and industry rules | The code itself, static or dynamic |
| Issuing side | The customer's wallet or bank app that scans the code and debits the customer | Participating banks and e-money issuers | Nothing directly; the customer's confirmation screen |
| Clearing rail | Real-time interbank network that moves funds between issuer and acquirer | InstaPay automated clearing house | A transaction reference and, if exposed, a clearing status code |
| Acquiring side | The institution holding the merchant's receiving account and generating or registering the merchant's QR | Participating banks, e-money issuers and their licensed gateways | Merchant portal, settlement reports, API and webhooks |
| Governance | Participation rules, certification, dispute handling | BSP and PPMI | Indirectly, through the acquirer's terms and dispute process |
How One Payment Travels Through the System
Walk through a single payment. A guest at your Cebu property opens a bank app, taps the QR scanner, and points it at the dynamic QR your point-of-sale system has just rendered for their bill. The app parses the EMVCo payload, recognises it as QR Ph, reads the acquiring institution and merchant identifier, and displays the merchant name and amount for confirmation. On confirmation, the bank debits the guest and sends a credit instruction over InstaPay to your acquiring institution, identifying your merchant account. The acquirer credits your account and, if you are connected through a gateway, the gateway emits a webhook to your system with the order reference you embedded in the QR. Your point of sale marks the bill paid. The guest's bank was never in a commercial relationship with your acquirer; the rail and the standard did the work.
Two details matter for integration. First, the order reference you embed in a dynamic QR is the key that lets you reconcile the payment automatically; a static QR with no reference forces you to match on amount and time. The difference is explained in static vs dynamic QR codes for merchants. Second, the webhook is the source of truth for your system, not the guest's confirmation screen, because the guest's screen reflects the debit while your webhook reflects the credit, and in edge cases those can diverge.
Person-to-Person and Person-to-Merchant Are Not the Same Product
QR Ph launched first for person-to-person transfers, where one individual's app generates a code another individual scans to send money. Person-to-merchant followed as a distinct use case with its own rules: merchant onboarding and know-your-business checks by the acquirer, merchant category codes, settlement into a merchant account, and participation in merchant dispute procedures. Some small businesses still accept payments on a personal P2P QR. For an international operator, that is not a viable path: you need the merchant product, because it is the one that gives you a registered merchant identity, settlement reporting, refund and dispute handling, and the ability to connect systems through an API. It is also the one your acquirer's compliance team will insist on once your volume is visible.
What Interoperability Changes About Your Integration
If you come from a market where each wallet is a separate integration, QRPH changes your architecture in three ways. You integrate once with an acquirer or a licensed gateway and receive payments from every participating app. Your point of sale generates one QR per transaction instead of asking the customer which wallet they use. And your reconciliation deals with one channel called QRPH, with the paying institution recorded as a data field rather than as a separate integration. A simplified request to generate a dynamic QR through a gateway looks like this; field names follow your provider's documentation:
curl -X POST https://api.example-gateway.ph/v1/qrph/dynamic \
-H "Content-Type: application/json" \
-H "X-Merchant-Id: {{MERCHANT_ID}}" \
-H "X-Timestamp: {{UNIX_TS}}" \
-H "X-Sign: {{SIGNATURE}}" \
-H "Idempotency-Key: {{ORDER_UUID}}" \
-d '{
"out_trade_no": "CEBU-FD-20261013-00231",
"amount": "{{BILL_AMOUNT}}",
"currency": "PHP",
"expires_in": 300,
"subject": "Room 412 folio",
"notify_url": "https://pms.example.com/webhooks/qrph"
}'
# Typical response (abridged)
# {
# "out_trade_no": "CEBU-FD-20261013-00231",
# "qr_payload": "00020101021228...6304A1B2",
# "qr_image_url": "https://cdn.example-gateway.ph/qr/....png",
# "expires_at": "2026-10-13T14:05:00+08:00"
# }
The qr_payload string is the EMVCo-formatted data you render as a QR image. Your webhook handler should verify the signature, treat the notification idempotently, and only then update the folio. In Node.js the skeleton is short:
app.post('/webhooks/qrph', async (req, res) => {
if (!verifySign(req.body, process.env.GATEWAY_SECRET)) {
return res.status(400).send('FAIL');
}
const { out_trade_no, status, payer_institution, channel_ref } = req.body;
// Record which issuing institution paid; useful for reconciliation and support
await folios.markPaidIfPending(out_trade_no, { status, payer_institution, channel_ref });
res.status(200).send('SUCCESS');
});
QRPH Compared With Wallet-Specific and Card QR
Interoperable does not mean identical to every alternative. The table below is how we explain the trade-offs to colleagues at head office who are used to card-centric or closed-loop markets.
| Dimension | QRPH (national standard) | Wallet-specific QR | Card-scheme QR |
|---|---|---|---|
| Who can pay | Any participating bank or wallet app | Only users of that wallet | Cardholders whose issuer supports the scheme's QR |
| Clearing rail | InstaPay for person-to-merchant | Wallet's internal ledger, or its own rails | Card network |
| Integrations needed | One acquirer or gateway | One per wallet | One per scheme or via an acquirer |
| Status in the Philippines | Mandated as the standard; proprietary QR phased out for covered institutions | Largely replaced by QR Ph for merchant payments | Niche, mostly for cross-border cardholders |
| Dispute path | Acquirer-led under national rules | Wallet's own process | Card scheme chargeback rules |
| Best for | Any merchant serving local customers | Closed ecosystems, loyalty-driven flows | Tourists and foreign cardholders |
In early 2023 the BSP directed covered institutions to display only QR Ph on their channels from the first of July that year and to retire proprietary QR codes. For a merchant, this means the question of which QR to print is largely settled; what remains is the choice of acquirer, the static-versus-dynamic decision, and how to connect your systems.
Where Interoperability Has Edges
Interoperability is strong but not frictionless, and foreign operators should know the edges before they promise anything to head office. Participation is by institution: a customer whose bank or wallet is not yet a participating issuer cannot pay a QR Ph code, though the participant list has grown to cover the major wallets and banks. Maintenance windows at any participating institution or at the clearing rail can delay or fail individual payments, and the clearing status code, when your gateway passes it through, is the fastest way to tell whose window it was. Limits apply on the customer's side and are set by the customer's own institution, so the same QR may be payable by one guest and declined for another. Refunds are not a reverse scan; they are a separate payout initiated by the merchant through the acquirer, so your refund flow needs its own design. And the receiving account's status matters: a merchant account that is suspended or restricted by the acquirer fails every payment regardless of which app scans it. Fee structures on the acquiring side also vary by institution and contract; how they are typically built is covered in the QRPH fee structure explained.
One compliance point sits underneath everything above. The institution that holds your QR Ph merchant account, receives the InstaPay credits and settles them to you must be a BSP-authorized operator of payment systems (OPS) or electronic money issuer (EMI), and that authorization must be in the legal name on your contract. Interoperability means any participating app can pay your code; it does not vet the party on your side of the transaction. That diligence is yours, and the BSP's published lists make it a short exercise. What the OPS category covers is explained in what a BSP NOPS licence is.
Frequently Asked Questions
Is QRPH the same as a GCash QR code?
No. GCash is one participating institution that can both issue payments to and, through its merchant products, acquire payments on QR Ph codes. A QR Ph code acquired through any participant can be paid from the GCash app, the Maya app, or a participating bank app alike.
Do I need separate QR codes for wallets and banks?
No. A single QR Ph merchant code is readable by participating wallet and bank apps. That is the point of the standard.
Which rail does a QRPH payment use, and why does it matter?
Person-to-merchant QR Ph payments clear over InstaPay. It matters because the status codes, the maintenance windows and the dispute procedures you will encounter are those of the InstaPay ecosystem and your acquirer, not of the customer's wallet brand.
Can an international business obtain a QRPH merchant code without a local company?
Acquirers generally onboard Philippine-registered businesses. Foreign operators typically either set up a local entity or onboard as a non-resident merchant under a BSP-licensed gateway that holds the acquiring relationship. The onboarding requirements are described in the linked guide on becoming a QRPH merchant.
Static or dynamic QR for an interoperable setup?
Dynamic for anything connected to a system, because the embedded order reference makes reconciliation automatic and the expiry limits misuse. Static is acceptable for low-volume counters where a staff member checks the confirmation manually.
If the customer's app shows success but my system shows nothing, is interoperability broken?
Almost never. That pattern usually means the credit reached your acquirer and the webhook to your system failed or was rejected. Check the gateway's order query endpoint and your webhook logs before assuming a clearing problem.
Does QRPH work for online checkout as well as in-store?
Yes. The same dynamic QR can be rendered on a web or in-app checkout page for the customer to scan with their phone, or presented as a payload the customer's app opens directly on mobile. The clearing and settlement path is identical.
Where to Start
If you operate in the Philippines from abroad, QRPH is the one integration that gives you the widest reach for the least architecture. Start by choosing an acquirer or licensed gateway whose BSP authorization you have verified, decide on dynamic QR for anything connected to a system, embed your own order reference in every code, and build your webhook handler and reconciliation before you print a single sign. If you want to compare notes on QRPH rollout across multiple properties or storefronts, reach me on Telegram at @LouisSMARTPAY or by email at [email protected].