QRPH Fee Structure Explained for Philippines Merchants

I run technical operations for a cross-border e-commerce brand that moved part of its fulfillment into the Philippines a while back. When our local finance lead first asked me to "just tell her what QRPH costs," I realized I didn't actually know — not because nobody had told me, but because the honest answer has more moving parts than a single number can hold. If you're setting up QR Ph acceptance for the first time, you've probably run into the same wall: your aggregator gives you a rate, but when you ask where that rate comes from, the explanation gets vague fast.

This article is the explanation I wish someone had given me before I signed anything. It's not a replacement for your contract's fee schedule — no one outside your own aggregator can tell you your exact numbers — but it will tell you what's actually happening inside that one quoted rate, who the other parties in the chain are, and what questions separate a transparent partner from one that's hoping you won't ask.

QRPH Is an Interoperability Standard, Not a Single Biller

The first misunderstanding I had to unlearn: QRPH (officially QR Ph) is not a company, and it doesn't send anyone an invoice. It's a standard maintained under the Philippine central bank's retail payment framework, designed so that any participating bank or e-wallet can scan or generate a compliant QR code and have the transaction clear regardless of which wallet the customer happens to be holding. That interoperability is the entire point of the standard — one merchant QR code that a customer paying from one wallet and a customer paying from a competing wallet can both use, without the merchant needing a separate arrangement with each one.

Because QRPH is infrastructure rather than a merchant-facing product, there is no single "QRPH fee" that every merchant pays, the way you might pay a flat courier rate regardless of destination. What you actually pay depends on who is standing in the chain between your checkout counter and the money landing in your settlement account — and that chain has more links than most new merchants expect when they first read a rate sheet.

The Three Parties Who Actually Touch Your Transaction

Strip away the branding and every QRPH transaction passes through roughly the same relay of participants:

The acquiring participant. This is the bank or licensed entity on your side of the transaction — the one that "acquires" the payment on behalf of the merchant and submits it into the QR Ph clearing system. In practice, most merchants never deal with the acquiring participant directly; this role sits behind your aggregator's infrastructure, invisible on your invoice but very much present in the cost.

The issuing participant. This is your customer's wallet or bank — the party that issued the account the money is coming from. Every wallet or bank that participates in QR Ph is, from the network's point of view, an issuing participant on transactions initiated by its own users, and each one can have slightly different internal economics.

The aggregator, or payment service provider, you actually signed with. This is almost always the only entity a merchant has a direct commercial relationship with. The aggregator stitches together acquiring access, settlement, reconciliation, and a merchant dashboard, and it's the one that quotes you a single all-in rate. For a fuller breakdown of what this role covers day to day, see what a payment aggregator actually does for a merchant.

A current list of the banks and wallets participating in QR Ph as acquiring or issuing institutions is worth knowing even if you never deal with them directly — see the QRPH participants list of acquiring and issuing institutions — because it tells you how wide your acceptance actually reaches once you go live, and which wallets your customers are most likely paying from.

Where the Cost Actually Comes From

Here's the part that's genuinely confusing if you're new to interoperable payment economics: the fee you pay isn't invented by any single party out of thin air. It's assembled from pieces that reflect the work and risk each participant is carrying.

The acquiring side carries settlement exposure, runs compliance and fraud monitoring on the inbound transaction, and absorbs operational cost for staying connected to the shared QR Ph rail. The issuing side — the customer's wallet or bank — is the one authenticating the customer, holding the float, and releasing the funds; issuing-side participants have historically built a cost component into interbank economics on most payment rails, and QRPH is no exception. None of this is unique to the Philippines or to QRPH specifically — it mirrors how acquiring and issuing costs have split on card networks and other interoperable rails for decades. What's different about QRPH is that it's public-interest infrastructure built for universal acceptance, so the structure tends to be flatter and more standardized than a proprietary scheme.

On top of that two-sided structure sits your aggregator's own margin — the part that funds the API, the dashboard, the settlement reporting, the support line you call when a transaction doesn't reconcile, and the compliance overhead of staying in good standing as a licensed intermediary. That margin is where aggregators actually differentiate from each other, because the acquiring and issuing components are largely fixed by network participation, not by your choice of partner.

Chain Participant	Role in the Transaction	What Their Cost Reflects	Who Sets It	Can a Merchant Negotiate It?
Acquiring participant	Submits the merchant's transaction into the QR Ph clearing system; carries settlement and compliance exposure on the merchant side	Settlement risk, fraud monitoring, connection to the shared QR Ph rail	Network-level participation terms	Not directly — merchants don't contract with this layer
Issuing participant (customer's wallet or bank)	Authenticates the customer and releases funds from their account	Customer authentication, float, funds release	Network-level terms, varies by wallet or bank	No — determined by whichever wallet the customer happens to use
Aggregator / payment service provider	The merchant-facing partner that bundles acquiring access, settlement, reconciliation, and support into one quoted rate	Platform, API, dashboard, compliance overhead, merchant support	Commercial agreement with the merchant	Yes — this is the component most open to negotiation
Merchant	Receives the net settlement after all upstream components have been deducted	Not applicable	Not applicable	Can shop around aggregators and negotiate volume-based terms

Why Your Aggregator Gives You One Number

When your aggregator quotes a single rate for QRPH acceptance, they're not hiding anything by doing so — they're doing what every payment intermediary does, which is absorb multi-party complexity so you don't have to reconcile three separate invoices for one sale. The quoted rate is meant to already include the acquiring-side cost, whatever issuing-side cost applies based on which wallet the customer used, and the aggregator's own margin, blended into a single figure you can actually put into a pricing spreadsheet.

The trade-off is that bundling makes it hard to tell, from the quoted rate alone, how much of what you're paying is network cost you'd owe no matter who you signed with, and how much is the aggregator's own markup. That distinction matters more than it sounds like it should, because the markup is the only part of the number that's actually negotiable. If you want context on how this plays out across channels beyond QRPH specifically, this general explainer on how payment gateway fee structures actually work is a useful companion read.

SMARTPAY operates in the Philippines under BSP-regulated OPS and EMI authority. We bring that up here specifically because licensing is the thing that should make a provider willing to walk you through this chain in the first place — a regulated intermediary has nothing to gain from keeping the structure vague, and a lot to lose from getting caught doing it.

Reading an Actual Fee Breakdown

Once you're live, the clearest way to see this chain in action isn't your sales contract — it's your settlement or reconciliation feed. A well-built aggregator API will show you the breakdown per transaction, not just a net figure. Below is the shape of what that typically looks like; field names and structure are illustrative, and your actual API's schema will differ in its specifics:

{
  "transaction_id": "QRPH-TXN-REF-PLACEHOLDER",
  "channel": "QRPH",
  "qr_type": "dynamic",
  "issuing_participant": "wallet_or_bank_placeholder",
  "acquiring_participant": "acquirer_entity_placeholder",
  "gross_amount": "<<order_value>>",
  "fee_breakdown": {
    "acquiring_component": "<<network_cost_component>>",
    "issuing_component": "<<interchange_style_component>>",
    "aggregator_margin": "<<contracted_rate_component>>"
  },
  "net_settlement_amount": "<<gross_amount_minus_fee_breakdown>>",
  "settlement_batch_reference": "<<settlement_cycle_id>>",
  "status": "settled"
}

A few things worth noticing in this structure — not the placeholder values themselves: the fee_breakdown object separates three distinct components instead of handing you one combined deduction. If your current provider's reporting only ever shows a single net figure with no breakdown, that's a legitimate thing to push back on. You're entitled to see what you're actually paying for, even in cases where the underlying network-level components aren't something your aggregator controls directly.

Static vs. Dynamic QR Codes Change the Math

One detail that trips up merchants moving from a generic wallet QR code to a proper QRPH integration: a static QR code (the same code printed once, scanned by many customers who then enter their own amount) and a dynamic QR code (generated per transaction with the amount embedded) aren't always priced identically by every aggregator, because they carry different reconciliation and fraud-monitoring overhead on the acquiring side. A dynamic code tied to a specific order reference is easier to reconcile automatically and harder to misuse, which is part of why most serious e-commerce and in-store setups move toward dynamic codes once volume justifies the integration work. If you're deciding between the two for your own setup, it's worth mapping that decision against your transaction volume and refund pattern before you lock in a rate card, since switching later usually means renegotiating.

Questions Worth Asking Before You Sign

After going through this exercise for our own integration, here's what I'd tell a peer evaluating a new aggregator for QRPH acceptance:

• Does the quoted rate already include both the acquiring-side and issuing-side components, or are there scenarios where an additional pass-through cost can appear depending on which wallet the customer used?
• Can the aggregator show a per-transaction fee breakdown in the settlement report, or only a net number with no component detail?
• Is the rate the same for static and dynamic QR codes, and if not, which one actually applies to your checkout flow?
• What happens to the fee on a refunded or disputed transaction — is any portion of it returned, or is it absorbed as a cost of doing business?
• Is the margin portion of the rate negotiable as your volume grows, and does the contract actually say so?

If a prospective partner can't answer these cleanly, that's informative in itself. For merchants still earlier in the process, it's worth reviewing what QRPH merchant onboarding actually requires before you even get to the pricing conversation, since some of the documentation and setup steps affect which aggregators will take you on in the first place.

What the BSP Framework Means for You Here

The reason this whole chain is knowable at all — rather than a black box you simply have to trust — comes down to the regulatory structure QRPH sits inside. Participants in the network operate under central bank oversight, and intermediaries like aggregators that aren't banks themselves typically operate under the BSP OPS licensing framework that governs non-bank payment operators. That licensing structure is also why asking "who gets what portion of this fee" is a completely reasonable question to put to any provider, not an awkward one. The system is built to be auditable at the regulator level, which means it can be explained at the merchant level too.

Is QRPH cheaper than accepting cards?

It depends on your transaction profile rather than on QRPH being categorically cheaper. QRPH tends to have a flatter, more standardized cost structure than card schemes because it's built as shared public infrastructure rather than a proprietary network, but your actual landed cost still depends on your aggregator's margin and your transaction mix. Don't assume; ask for a side-by-side comparison on your own volume.

Does my aggregator set the QRPH fee, or just pass it through?

Both, in different proportions. The acquiring and issuing components reflect network-level economics that your aggregator doesn't unilaterally control. The margin layered on top of that is set by your aggregator and is the part you can actually negotiate.

Why didn't my settled amount match my invoice amount exactly?

This is almost always the fee breakdown being deducted before funds land, sometimes combined with a rounding convention on how partial fee components are calculated. If the gap looks larger than your rate card implies, ask your aggregator for the per-transaction breakdown rather than assuming it's an error.

Can I negotiate my QRPH rate?

You can generally negotiate the aggregator's margin component, especially as your volume grows or if you're bundling QRPH with other channels. The acquiring and issuing components are a function of network participation and are much less flexible, which is exactly why understanding the split matters before you try to negotiate anything at all.

Does the fee change depending on which wallet my customer uses?

It can, because the issuing participant on the other side of the transaction varies by wallet or bank, and that leg of the chain sits outside your aggregator's direct control. A transparent aggregator should be able to tell you whether their quoted rate absorbs that variability or passes some of it through to you.

Is a QRPH fee the same thing as an "aggregator fee"?

No. The aggregator's margin is one component inside the total rate you're quoted, not a separate charge stacked on top of it. Confusing the two is probably the single most common source of merchant frustration when a settlement doesn't match expectations.

Do static and dynamic QR codes cost the same to accept?

Not necessarily. Some aggregators price them identically; others differentiate because dynamic codes carry different reconciliation overhead on the back end. Confirm this specifically for your own checkout flow rather than assuming parity.

What should I actually ask for in writing before I sign?

Ask for the fee breakdown structure (not just the blended rate), confirmation of whether static and dynamic codes are priced the same, and the refund/dispute fee policy. A partner willing to put all three in writing before you sign is telling you something useful about how they'll behave after you sign too.

If you're setting up QRPH acceptance and want an actual fee breakdown for your specific volume and business type rather than general principles, reach out directly: @LouisSMARTPAY on Telegram or [email protected] by email, and we'll walk through what applies to your setup.