QR Ph Aggregated Collection: What's Actually Behind One QR Code in the Philippines

What Aggregation Actually Means Behind One QR Code

QR Ph is the national QR code standard led by the Bangko Sentral ng Pilipinas (BSP), the Philippine central bank — it isn't a proprietary code owned by any single wallet provider. A merchant displays one QR Ph code, whether a static code printed at the counter or a dynamic one generated by a point-of-sale system, and in principle GCash, Maya, and dozens of participating bank apps can all scan that same code to complete a payment. That's the most literal sense of "aggregation": what the customer sees is one code, but there are multiple settlement paths running behind it.

The underlying technology follows the internationally recognized EMVCo QR code framework — the same logic used by Singapore's SGQR and Thailand's PromptPay, not a homegrown experiment. This matters because it tells you where the aggregation actually happens: the merchant isn't manually integrating a dozen different wallet APIs or juggling a dozen sets of credentials. Instead, a licensed intermediary — one holding BSP's Operator of Payment Systems (OPS) recognition — has already connected GCash, Maya, and multiple banks' clearing interfaces on the back end. The merchant only has to maintain one interface, typically a single API or SDK, and the aggregator routes and settles behind the scenes.

You can also think about this from the "interface" side rather than the "code" side. For an online store or a subscription business taking payments online, what the merchant integrates with is usually not a physical QR code but a unified checkout interface — the customer might see different options up front, but on the merchant's dashboard it all shows up as one transaction record with one reconciliation logic. That consolidation is really the value of aggregation. For the fuller picture of this payment topic, see our overview of payment gateways in the Philippines.

Aggregated Collection vs. Going Direct With One Channel

If your customers are overwhelmingly on one wallet, going direct — a "native" integration where the customer scans a code or launches the app right inside your own page, with no redirect — has real advantages: your team only has to master one provider's documentation and one set of invocation methods (web-based H5 activation, in-app SDK integration, or a static/dynamic QR code for in-store use), and you can tailor the experience closely to that one wallet's interaction patterns.

The tradeoff is coverage. Connecting only one wallet means that the moment you want to also accept a different wallet or bank-app payments, you're starting a new due-diligence process and a new technical integration from scratch — every additional channel adds its own layer of maintenance. Aggregated collection exists to solve exactly this: the merchant signs with one licensed aggregator, integrates once, and the aggregator has already wired GCash, Maya, and multiple banks into the same clearing network on the back end — coverage that, in principle, matches most of the digital users reachable under the QR Ph standard.

One caveat worth flagging: aggregating channels doesn't aggregate away the risk. Routing every channel's settlement through one aggregator means that aggregator's stability, fee structure, and settlement timelines now govern your entire payment experience, not just one channel. Getting that one choice wrong has a bigger blast radius than picking the wrong single-channel provider — which is exactly why verifying the aggregator's license matters more here than in a single-channel setup.

Who Aggregated Collection Tends to Fit

Based on what we've seen, a few merchant types have the clearest need for aggregation: cross-border e-commerce sellers entering the Philippines, local online stores, subscription or pay-per-use services, chain retail and dining businesses with high-frequency small transactions, schools and training institutes collecting tuition, logistics platforms handling cash-on-delivery (COD), and intermediary or service companies collecting deposits. What these have in common is a customer base spread across payment preferences — rather than connecting one channel and slowly adding more, it makes more sense to cover the main entry points at once.

Whichever route you take, one prerequisite doesn't change: the company entity has to be established first. An aggregator's due-diligence process will ask for registration documents, director information, and a business address, and company setup has to be done before payment integration can move forward. If you haven't registered yet, our guide to registering a company in the Philippines covers the registration steps, and opening a corporate account is covered in our guide to opening a corporate bank account in the Philippines. Cross-border sellers who haven't mapped out the broader setup process yet can also check our guide to cross-border e-commerce entry into the Philippines.

What to Ask When Onboarding With an Aggregator

Before anything else, verify the license. An entity that processes payment or fund-transfer solutions is recognized by the central bank as an Operator of Payment Systems (OPS); issuing e-wallet balances itself requires Electronic Money Issuer (EMI) status. Both are approved by the BSP, which evaluates whether the applicant has real financial capacity, operational capability, and governance in place. The BSP publishes a list of registered EMIs and OPS entities, so you can check a provider's claimed license number and registered company name yourself — not every business that claims to do "payment integration" actually holds these licenses; sub-licensing and unlicensed pass-through arrangements do happen.

Once the license checks out, worth asking about next:

• Settlement speed — same-day (D0) or next-day (T1) settlement, and whether the provider is consistent about it or has exceptions;
• Which invocation methods are supported: web-based H5 activation (for merchants without their own app), in-app SDK integration (which needs mobile engineering resources), or static/dynamic QR codes for in-store scanning — and whether that matches your actual business setup;
• During sandbox testing: whether payment results come via active polling or a pushed webhook, and whether the interface is idempotent — i.e., whether a duplicate notification for the same transaction can cause double-booking;
• Whether refunds go back through the original payment path or as a separate transfer, and whether the refund timing matches the original payment timing.

The broader onboarding flow is roughly the same regardless of provider: submit company documents for due diligence (to satisfy BSP KYC/AML requirements) → get assigned a sandbox environment where your engineering team tests order creation, payment callbacks, and refunds → go through pre-launch review (transaction reconciliation, payment success rates, risk-alert mechanisms) → cut over to production → keep monitoring reconciliation and anomalies through the merchant dashboard's transaction reports. None of these steps disappear with aggregation — what aggregation saves you is not repeating them per channel.

As one example, a licensed provider we're aware of, SmartPay (paysmartph.com), offers native GCash integration, QR Ph aggregated collection, and Maya disbursement, and holds both OPS and EMI recognition from the BSP. Worth verifying independently and comparing actual fees and settlement terms — their business Telegram is @LouisSMARTPAY, with a community group at smartpaymanila.

A Licensed Aggregator Doesn't Mean You Can Walk Away

Working with a licensed aggregator doesn't take payments off your plate entirely. KYC and AML documentation that's supposed to come from your company still has to come from your company — the aggregator won't handle that step for you. Fee structures, settlement cycles, and the number of channels each provider actually covers all vary, so it's worth comparing more than one option rather than signing with whoever says yes first.

It's also worth remembering that GCash and QR Ph systems get interface or rule updates from time to time — integration isn't a one-time task. Someone on your technical side needs to keep an eye on provider notices about interface changes, whether you go aggregated or direct.

Official Sources

For official information on the QR Ph standard, see the BSP's multimedia page: Bangko Sentral ng Pilipinas (BSP). For company registration information, 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.