How to Become a QRPH Merchant: Onboarding Requirements Explained

I run payments and integrations for a China-based company that sells hardware and operates a subscription service into the Philippine market. When our local operations lead pushed for QR code acceptance, to match how Filipino shoppers actually pay in stores and on delivery, I made the same assumption I would have made in most other markets: pick a wallet's QR SDK, integrate it, done. That assumption cost me a few confusing weeks, because what merchants here actually need isn't a single wallet's QR code. It's QRPH, the central bank's interoperable QR standard, and the onboarding path for it looks nothing like a typical wallet integration. This is the explanation I wish someone had handed me on day one.

What QRPH Actually Is (and Why It's Not a Single-Wallet Integration)

QRPH, also written QR Ph, is the national QR code standard set by the Bangko Sentral ng Pilipinas (BSP), the Philippine central bank. The entire point of the standard is interoperability: one QR code, printed once at a counter or generated once at checkout, can be scanned by a customer regardless of which participating bank or e-wallet app they use. That is fundamentally different from a GCash QR or a Maya QR, where only users of that specific wallet can pay through that specific code.

For a foreign merchant used to thinking in terms of "integrate wallet A, then wallet B, then wallet C," QRPH collapses that into a single rail. In practice that still means working with a technology partner, because QRPH itself is a clearing and messaging standard, not a product you buy off a shelf. A customer's bank or wallet still has to actually support QRPH as a participant for the code to work on their side, which is why checking participant coverage before launch still matters.

Dimension	Single-wallet QR (e.g. GCash QR, Maya QR)	QRPH
Who can scan it	Only users of that one wallet's app	Any customer whose bank or e-wallet participates in QRPH
Merchant setup	One QR per wallet you want to accept	One QR code, interoperable across participating institutions
Clearing path	Stays inside that wallet's own rails	Routed through the national QR Ph interoperability scheme
Best fit	Merchants whose customer base skews heavily to one wallet	Merchants who want broad bank and wallet coverage without stacking multiple QR integrations

Two Paths to Accepting QRPH: Direct BSP Participation vs a Licensed Participant

There are really only two ways to end up with a working QRPH merchant setup. The first is becoming a direct participant in the BSP's QR Ph clearing arrangement yourself. In theory this is open to financial institutions that meet the BSP's own supervisory and capital requirements. In practice, for an ordinary merchant, a developer-led startup, or a foreign-owned company without a Philippine banking license, this path is not realistic. Direct participation is designed for banks and large e-money issuers, not for a retailer or a SaaS company that simply wants to accept payments.

The second path, and the one almost every merchant actually takes, is onboarding through a licensed participant: a payment gateway or aggregator that already holds the relevant BSP authorization and has already built the connection into the QR Ph clearing switch. You apply to that participant, they run their own compliance and onboarding process on you, and once approved you integrate against their API rather than against the central bank's infrastructure directly.

A licensed participant in this context means a company holding a BSP Operator of Payment System (OPS) license, or operating as a BSP-supervised Electronic Money Issuer (EMI). That license is what allows the company to legally sit between your business and the national payment rails, rather than merely claiming to.

If you want the fuller breakdown of what separates a direct clearing participant from an indirect one, and what qualifies as a BSP OPS license in the first place, I go into more detail in this explainer on what a BSP OPS license actually covers. For the technical side of how QR Ph compares with the other two national rails, the earlier piece on how QR Ph differs from InstaPay and PESONet is worth reading before you scope your integration.

Criteria	Direct BSP Participation	Onboarding via a Licensed Participant
Who this is realistic for	Banks and large e-money issuers meeting BSP capital and supervisory requirements	Retailers, platforms, SaaS companies, foreign-owned merchants, developers
Licensing burden on you	You must hold or obtain direct BSP authorization	None — you rely on your participant's existing BSP OPS/EMI license
Technical build	Build and maintain a direct connection into the national QR Ph clearing switch	Integrate against a single REST API exposed by the participant
Typical timeline	Extended, and gated by regulatory approval, not just technical readiness	Shorter, since compliance review and technical onboarding run in parallel
Ongoing compliance load	Full regulatory reporting obligations as a supervised entity	Your participant carries the regulatory reporting; you still handle your own KYC on customers where applicable

Business Documents You'll Need Before You Apply

Whichever licensed participant you approach, the know-your-business (KYB) review looks broadly similar. Expect to be asked for your business registration documents (SEC registration for a corporation, DTI for a sole proprietorship, or equivalent incorporation documents if you're applying as a foreign entity), a current business or mayor's permit, proof of your registered business address, and identification for your authorized signatories and beneficial owners. If your company is foreign-owned or foreign-incorporated, be ready for an extra round of verification on the parent entity and on whoever is authorized to sign on its behalf, since most participants treat foreign structures as a higher scrutiny tier by default rather than as an exception.

You'll also typically need to describe your settlement bank account, since payouts from the licensed participant land there, and provide some description of your actual business model and expected transaction patterns. This isn't a formality: it's how the participant satisfies its own anti-money-laundering obligations to the BSP, and inconsistent or vague answers here are a common reason applications stall rather than get rejected outright.

Technical Requirements on Your Side

On the engineering side, the bar is lower than the compliance side but still real. You need a server that can make authenticated outbound calls to the participant's API, a publicly reachable HTTPS endpoint to receive asynchronous payment notifications (webhooks), and the ability to generate and store a signing key or certificate used to verify that notifications genuinely came from the participant and weren't spoofed. Most participants will also expect you to handle idempotency correctly, since a network retry on your side or theirs should never result in crediting the same order twice.

If your business model needs a QR code rendered on a physical receipt printer or counter display rather than shown on a screen, you'll also want to confirm the participant's QR payload format supports the image size and error-correction level your hardware needs, something that's easy to overlook until you're debugging a printer in a pilot store.

The Onboarding Process, Step by Step

1. Application and document submission. You submit your business documents and a description of your use case to the licensed participant.
2. Compliance and KYB review. The participant's compliance team checks your registration, ownership structure, and risk profile against its own BSP-mandated policies.
3. Sandbox credentials issued. Once your application clears initial review, you're given test API keys and a sandbox environment to build against.
4. Technical integration and testing. Your team wires up QR generation, payment notification handling, and reconciliation against sandbox transactions.
5. Final account setup. Settlement account details, go-live checks, and any remaining risk sign-off happen here.
6. Production go-live. You're switched to live credentials and can start accepting real QRPH payments.
7. Ongoing monitoring. Transaction monitoring, periodic document refreshes, and reconciliation become part of your regular operations.

None of these steps are unique to QRPH specifically; this is roughly the same shape as onboarding to any regulated payment rail in the Philippines. What's specific to QRPH is step four, because the QR generation and the interoperability logic behind it work a little differently from a single-wallet integration, which is worth walking through in actual code.

Generating and Verifying a QRPH Transaction: What the Integration Looks Like

Most licensed participants expose QRPH as a REST endpoint that returns either a QR payload string or a hosted QR image, tied to a merchant-generated order reference. A typical request to create a dynamic QRPH QR code for a specific order looks something like this:

curl -X POST https://api.example-gateway.ph/v1/qrph/generate \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "merchant_id": "MCH20260931",
    "order_no": "ORD-2026-00417",
    "amount": "1250.00",
    "notify_url": "https://yourapp.example.com/webhooks/qrph",
    "expire_seconds": 300,
    "sign": "a1f9c0e7b2d4...signature_hash"
  }'

# Example response
{
  "status": "success",
  "qr_string": "00020101021226...",
  "order_no": "ORD-2026-00417",
  "qr_expire_at": "2026-10-03T20:15:00+08:00"
}

Note that the amount shown above is just a placeholder inside an API payload, not pricing guidance. Once the customer scans and pays through their own bank or wallet app, the participant sends an asynchronous callback to your notify_url. Verifying that callback is the step teams most often get wrong, because it's tempting to trust the payload without checking the signature:

const crypto = require('crypto');

function verifyQrphCallback(payload, receivedSign, secretKey) {
  const base = Object.keys(payload)
    .filter(k => k !== 'sign')
    .sort()
    .map(k => `${k}=${payload[k]}`)
    .join('&');

  const computedSign = crypto
    .createHmac('sha256', secretKey)
    .update(base)
    .digest('hex');

  return computedSign === receivedSign;
}

// In your webhook handler:
// if (!verifyQrphCallback(req.body, req.body.sign, MY_SECRET_KEY)) {
//   return res.status(400).send('invalid signature');
// }

This is standard webhook hygiene, but it matters more on an interoperable rail like QRPH, because the notification could in theory be describing a payment that cleared through any of several participating banks or wallets on the customer's side. You're trusting the participant's signature, not a single wallet's app session.

How Long Onboarding Actually Takes

I'll be direct about this because vague promises are exactly what got me confused in the first place: there is no fixed number of days that applies to every applicant, and any participant who commits to a specific date before having seen your documents is speculating, not estimating. In my own experience, document review and compliance sign-off is usually the longer stretch, especially for a foreign-owned entity, while the technical integration itself can often run in parallel once sandbox access is granted. The biggest variables are how complete your documentation is on the first submission, whether your ownership structure needs extra verification, and how much back-and-forth your engineering team needs during sandbox testing before cutting over to production. A realistic range tends to run from a few weeks on the fast end to a couple of months if your documents need multiple rounds of clarification.

Settlement and Staying Compliant After You Go Live

Once you're live, your relationship with the licensed participant doesn't end at integration. Settlement happens on a cycle the participant defines in your agreement, funds land in your registered bank account, and you'll want your own reconciliation process that matches your order records against the participant's transaction reports rather than relying purely on the webhook stream, since webhooks can occasionally be delayed or need retries.

You also inherit some ongoing compliance responsibility of your own, even though the participant carries the primary regulatory burden. That typically means keeping your own business documents current with them, cooperating with periodic reviews, and applying reasonable KYC on your own customers if your business model calls for it.

It's worth repeating: the entity sitting between you and the national QR Ph rail should be able to show you its BSP OPS or EMI authorization on request. If a prospective participant can't produce that, you're not actually onboarding onto QRPH — you're taking on counterparty risk with no regulatory backing behind it.

If your use case is specifically collection from international customers or cross-border order flows rather than a domestic storefront, the considerations shift slightly, and I've written separately about how international businesses collect payments in the Philippines through QRPH. It's also worth checking the current list of QR Ph participant banks and e-wallets before launch, since coverage on the customer side is what actually determines how useful your QR code is in the field.

Frequently Asked Questions

Can a foreign company become a QRPH merchant directly?

Direct BSP participation is realistically limited to supervised financial institutions. A foreign company can accept QRPH payments by onboarding through a licensed participant holding a BSP OPS or EMI authorization, which is the path almost all merchants, foreign or local, actually use.

What's the real difference between QRPH and a wallet's own QR code?

A wallet's own QR code only works for that wallet's users. QRPH is interoperable, meaning a single code can be scanned by customers across multiple participating banks and e-wallets, provided their institution supports QR Ph.

Do I need a Philippine bank account to receive QRPH settlements?

In almost every onboarding flow, yes. Settlement from your licensed participant is paid into a bank account registered during onboarding, so you'll need a local account, or an arrangement with your participant that covers how funds reach you.

Can one integration handle both QRPH and other payment methods?

Most licensed participants expose QRPH alongside other collection methods under a single API, so a merchant who already integrated card or wallet collection with the same participant often only needs to add the QRPH endpoint rather than build a parallel system.

What happens if my customer's bank hasn't joined QRPH yet?

Coverage has expanded over time but isn't universal. If a customer's bank or wallet isn't a QR Ph participant, they won't be able to pay through that code, which is why checking the current participant list and offering an alternative payment method matters for conversion.

Is QRPH only for physical point-of-sale, or does it work for e-commerce too?

Both. A static QR code printed at a counter and a dynamic QR code generated per order at online checkout use the same underlying standard; the difference is just whether the amount is fixed in advance or generated per transaction.

Does becoming a QRPH merchant require its own separate contract from other payment methods?

That depends on the participant. Some bundle QRPH into the same merchant agreement as their other collection methods, while others treat it as a distinct product with its own sign-off, which is worth clarifying early rather than assuming.

If you're scoping a QRPH integration and want a second opinion on documentation, timeline, or how the technical pieces fit your existing stack, reach out directly: @LouisSMARTPAY or [email protected].