GCash QR Code Payment: GCash's Own Code vs QRPh, Which One Should Merchants Use

GCash's Own QR Code and QRPh Are Not the Same Thing

Many merchants assume "GCash QR code" and "QRPh QR code" are the same thing, and that pasting up one sticker is enough. They're actually two different systems. GCash's own collection code is generated inside the GCash app itself, and it belongs entirely to GCash's own wallet ecosystem — when a customer scans it, the money moves directly out of their GCash balance and into the merchant's own GCash account. It's essentially an internal wallet-to-wallet transfer.

QRPh (QR Ph) is different. It's the national, unified QR standard led by the Bangko Sentral ng Pilipinas (BSP), part of the broader Philippines payment gateway landscape, not a private protocol built by any single wallet company. A merchant who displays one QRPh code can, in principle, be scanned by GCash, Maya, and dozens of participating banks' apps — no need to display a separate code for every wallet or bank.

On scale: GCash alone has over 90 million registered users, and together with Maya the two cover the large majority of the Philippines' active digital users; QR-based payments already account for more than half of all digital transaction volume nationwide. That's exactly why merchants get stuck choosing — GCash's user base is genuinely large, but QRPh's coverage is, in principle, broader. The two aren't really substitutes for each other; they solve different problems.

Who Can Scan Whose Code: The Technical Difference

The difference in user experience comes down to what's underneath. GCash's own code runs on GCash's own payment protocol, and both the sender and receiver need to be inside the GCash ecosystem — strictly speaking, only someone with the GCash app installed and a funded balance can scan it and pay. It's a wallet-internal transfer, not an inter-institution settlement.

QRPh runs on the internationally common EMVCo QR framework — the same underlying logic as Singapore's SGQR or Thailand's PromptPay. As long as different institutions all connect following that standard, one code can be recognized by every participating app. So a static code carrying the QRPh mark can, in principle, be scanned by GCash, Maya, and participating banks' apps at once, and what's happening behind it is cross-institution clearing and reconciliation, not a single wallet's internal transfer.

This push toward unification isn't limited to QR codes either. Starting February 2026, the central bank has required digital banks and e-wallets to route transfers through two standardized clearing rails, InstaPay and PESONet, rather than each running its own separate arrangement — merchants opening a corporate account are worth reading up on the difference between InstaPay and PESONet before going further. The direction is consistent whether you're looking at QR codes or interbank transfers: the central bank keeps pushing toward unified standards that different players can all plug into, which is exactly why aggregator codes like QRPh matter more over time.

Which Code Should Your Business Actually Display

There's no one-size-fits-all answer to whether a merchant should post GCash's own code or a QRPh aggregator code — it depends on the business and the customers. A quick comparison:

A few common reader profiles for reference:

• Cross-border sellers entering the Philippines, local online shops: cross-border e-commerce customers are a general mix, so coverage usually matters more than depth — QRPh is often the safer default. If most traffic comes from inside the GCash ecosystem, native GCash integration keeps the experience in-app.
• Chain retail and F&B (high-frequency, small-ticket transactions): which app a walk-in customer uses is essentially random, so one QRPh static code at the counter usually covers most customers instead of taping up several wallet codes side by side.
• Subscription or pay-per-use services, schools and training centers collecting tuition: these usually trigger payment online rather than scan in person, and often end up needing both — QRPh for coverage, native GCash for a smoother experience for heavy users.
• Logistics platforms collecting cash-on-delivery (COD), agencies or service companies collecting deposits: small-ticket, high-frequency flow means one QRPh code at delivery or the front desk usually covers most customers regardless of wallet.

In practice, many merchants do both: a QRPh static code at the counter for broad coverage, plus native GCash integration in their own site or app for heavy users. The two aren't mutually exclusive.

Integration Formats, Trigger Methods, and Settlement Timing

Whichever code a merchant uses, there are generally two integration formats: redirecting to a third-party checkout page, where the customer briefly leaves the merchant's site or app, or "native integration," where the customer scans or one-taps to launch the app right inside the merchant's own page with no redirect — smoother, but a heavier technical lift.

There are three common ways to trigger payment: web-based H5 activation, suited to merchants without their own app; in-app SDK integration, suited to merchants with a native app and a mobile team; and offline static or dynamic QR codes, the most common format for storefronts and restaurants, pairing naturally with QRPh's one-code-fits-many-wallets model.

Settlement speed usually comes in two flavors — "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 does D0 across the board, so it's worth confirming exactly which one applies and whether there are exceptions, along with whether the receiving corporate bank account needs any extra setup.

The broader onboarding flow generally runs: submit company documentation for due diligence (KYC/anti-money-laundering) → sandbox testing of order creation, payment callbacks, and refunds → pre-launch review (reconciliation, success rate, risk alerts) → cut over to production → ongoing reconciliation through the dashboard's transaction reports. Worth nailing down during sandbox testing: whether results come via active polling or a webhook; whether duplicate notifications could cause double-booking (idempotency); and whether refunds return via the original payment method or a separate transfer, with matching timing.

How to Verify a License and Choose a Provider

Whichever code a merchant integrates, the entity behind the technical connection is doing one or both of two things the central bank regulates: handling payment or fund-transfer solutions, classified as an Operator of Payment Systems (OPS); and issuing e-wallet balances, which requires Electronic Money Issuer (EMI) status. Both licenses are approved by the central bank, which reviews genuine capital strength, operational capacity, and governance — the process typically runs on a quarterly timescale, not weeks.

The central bank publishes a public list of registered EMIs and OPS operators, so merchants can check a provider's claimed license number and company name against it — worth not skipping, since not every outfit claiming to do "payment integration" actually holds a BSP OPS or EMI license; sub-licensing or pass-through arrangements aren't rare. Fee structures, settlement cycles, and channel coverage also vary by provider, so it's worth comparing a few. And working with a licensed provider doesn't mean handing everything off — KYC and anti-money-laundering documentation that's the merchant's own responsibility still has to come from the merchant.

One licensed provider this site is aware of, stated plainly for reference: SmartPay (paysmartph.com) handles native GCash integration, QRPh aggregator collection, and Maya disbursement, and holds both OPS and EMI status from the central bank — whether it fits a particular business is worth confirming directly via Telegram or comparing against other options. The company entity needs SEC registration first; if setting up a Philippine company hasn't happened, due diligence has no documentation to review, and company formation support can help get that moving.

Official Sources

For the QRPh standard and the OPS/EMI license categories referenced in this article, readers can check the central bank's own pages directly. Last verified: September 2026.

Bangko Sentral ng Pilipinas (BSP) publishes information on the QRPh standard; company registration details can be verified on the Securities and Exchange Commission (SEC) website.

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.