SMARTPAY

Maya Fee Structure for Merchants: What Affects Your Rate

Every few weeks, someone on a merchant team I'm advising asks me the same question: "What does Maya actually cost?" They've usually just gotten a quote from a payment service provider, and it doesn't match the number a colleague got months ago, and it definitely doesn't match whatever rate GCash is quoting for a similar integration. I run technical integrations for a China-based team that collects and disburses funds into the Philippines across several wallet rails, and I've learned that this question has no single answer — not because providers are hiding something, but because a Maya fee quote is actually several separate pricing decisions bundled into one number.

This article isn't going to hand you a rate card. Specific percentages depend on your vertical, your monthly volume, your risk profile, and the provider you're negotiating with, and anyone who quotes a number without asking about those things first is skipping steps. What I want to walk through instead is the structure underneath the number — the factors that make one Maya quote different from another, and a framework for comparing a Maya quote against a GCash or QRPH quote instead of just eyeballing two spreadsheets and guessing.

Why Two Maya Fee Quotes Rarely Match

If you've ever gotten quotes from two providers for what looks like the same Maya integration and found the numbers meaningfully different, you're not imagining it. A Maya-related fee quote is a composite of several independent variables, and most providers only show you the final blended number rather than the components that produced it. The factors that typically move a quote include:

  • Whether the flow is collection (money coming in from a customer) or disbursement/payout (money going out to a supplier, employee, or affiliate)
  • Whether your integration connects directly to Maya's own infrastructure or routes through an aggregator that already has a Maya relationship
  • Whether you're asking for a specific settlement speed tier, if the provider offers more than one
  • Your expected transaction volume and average ticket size
  • Your industry vertical, since risk-weighted categories are usually priced differently
  • Whether you're committing to a minimum volume or a contract term in exchange for a better rate

None of these factors are unique to Maya — they apply to how payment gateway fee structures work across Philippine payment channels generally. But Maya's specific mix of native API access, QR-based collection, and payout rails means the combinations play out a little differently than they do on GCash, which is why a side-by-side comparison needs more than just "Maya's rate" and "GCash's rate" as single line items.

Collection Fees and Payout Fees Are Priced on Different Logic

The first thing to separate in your head — and in any quote you're reviewing — is that collection and disbursement are not the same product, even though both run through the same wallet brand. Collection is Maya accepting money from a customer on your behalf and crediting your merchant balance. Disbursement (or payout) is Maya pushing money out of your merchant balance to an end recipient, whether that's a worker's wallet, a supplier's bank account, or an affiliate payout. These two flows carry different operational risk for whoever prices them. Collection fees are typically expressed against transaction value, because the provider is underwriting fraud and chargeback-adjacent risk on money coming in from an unknown counterparty. Payout fees are more often structured as a flat-ish cost per disbursement, or tiered by batch size, because the operational cost is closer to "process N instructions" than "absorb risk on N unknown payers." This matters for how you read a quote. If a provider gives you a single blended rate that supposedly covers both collection and payout, ask them to split it. A merchant heavy on collection (e-commerce, subscriptions) and light on payout will land on a very different effective cost than one heavy on payout (gig platforms, supplier settlement, payroll-adjacent use cases), even if the "headline rate" looks identical on paper.

Native Integration vs Aggregated Access: The Line Item That Moves the Rate Most

This is usually the single biggest structural factor in a Maya quote, and the one merchants evaluate least carefully. There are two broad ways to connect to Maya:

Native integration means your systems talk directly to Maya's own API surface, under a merchant agreement you (or your technical partner) hold directly with Maya. Aggregated access means you integrate with a provider that already holds a Maya relationship (plus relationships with GCash, QRPH, and others), and your transactions flow through that provider's consolidated channel. Neither path is universally cheaper — it depends on volume and timeline. Native access rewards scale: higher setup effort and often a higher minimum volume commitment, in exchange for more pricing control and direct visibility into settlement. Aggregated access trades some rate flexibility for a faster launch, since you're not negotiating a fresh merchant agreement or building Maya-specific signature and callback handling from scratch — the groundwork for that resembles how native Maya integration compares technically to native GCash integration. What an aggregator actually does behind the scenes — pooling volume across merchants to negotiate better collective terms, then tiering what it passes through — is worth understanding before assuming "aggregated" means "more expensive." It's often cheaper for a smaller merchant precisely because the aggregator's blended volume unlocks pricing an individual merchant couldn't reach alone; see what a payment aggregator actually does for the mechanics.

Factor Native — Collection Native — Payout Aggregated — Collection Aggregated — Payout
Who sets the rate Negotiated directly with Maya Negotiated directly with Maya Set by the aggregator's own tier Set by the aggregator's own tier
Fee basis Percentage of transaction value, risk-weighted by vertical Per-instruction or batch-tiered Blended percentage, often bundled across channels Flat or batch-tiered, bundled with other payout rails
Settlement tier options Usually more tiers to choose from Usually more tiers to choose from Limited to what the aggregator offers Limited to what the aggregator offers
Volume commitment Often required for the best tier Often required for the best tier Rarely required Rarely required
Integration effort Higher — direct signature/callback build Higher — direct signature/callback build Lower — one API covers multiple channels Lower — one API covers multiple channels
Best fit Established merchants with predictable volume High-frequency payout operations needing control New merchants testing the Philippine market Merchants already running mixed-channel payouts

Settlement Speed Tiers: What You're Paying For When Money Lands Faster

If a provider offers more than one settlement speed option for Maya transactions, treat that as a separate pricing lever from the base collection or payout fee, not a side detail. A same-business-day settlement tier generally costs the provider more to operate than a standard multi-day tier, because the provider is pre-funding or advancing against transactions that haven't fully cleared yet, and that pre-funding carries cost and risk that gets passed through in the rate. This is the piece of a quote that's easiest to misread as "Maya being more expensive than GCash" when it's actually "we asked for a faster settlement tier than our previous GCash setup used." If a Maya quote and a GCash quote look far apart, check whether both assume the same settlement speed before concluding one wallet is structurally pricier. The underlying mechanics of why faster settlement costs more are the same across wallets — see how same-day settlement actually works for the clearing logic behind it. Not every provider offers a settlement speed choice for every channel, and not every merchant needs the fastest tier available. If your business model doesn't need same-day cash, a standard tier is usually the more cost-efficient default, and it's worth asking for explicitly rather than accepting whatever tier a provider defaults you into.

Where the BSP OPS/EMI License Layer Fits Into Pricing

One factor that doesn't show up as a line item but affects the quotes you'll get is who you're actually contracting with. Maya's own operations sit under its BSP-issued licenses, and any provider helping you access Maya collection or payout should be able to show how its own authorization fits into that chain — either as a licensed entity in its own right or as a documented partner of one.

Philippine payment providers are expected to operate under BSP authorization as either an Operator of Payment System (OPS) or an Electronic Money Issuer (EMI), and SMARTPAY operates under BSP OPS/EMI licensing rather than as an unregistered intermediary.
Why does this affect pricing, not just compliance? A provider without clear BSP standing usually can't hold merchant funds or settle directly, which means it's almost always another layer on top of someone else's licensed infrastructure — and each additional layer between you and Maya's rails is a place where margin gets added. A lower headline rate from an unclear intermediary can cost more in practice once you factor in slower dispute resolution, less transparent reconciliation, and the risk of a counterparty that isn't directly accountable to BSP.

A Framework for Comparing a Maya Quote Against GCash and QRPH

Once you've got quotes in hand, here's the order I actually use to compare them, rather than lining up headline numbers:

  1. Separate collection from payout in every quote. If a provider won't break this out, ask again before comparing anything.
  2. Normalize for integration type. Compare native-to-native and aggregated-to-aggregated. A native Maya quote against an aggregated GCash quote tells you about the integration model, not the wallets.
  3. Normalize for settlement speed. Confirm both quotes assume the same settlement tier before comparing the rate itself.
  4. Check what volume tier the quote assumes. A rate quoted at a high-volume tier isn't what you'll actually get if your real volume is a fraction of that.
  5. Factor in QRPH where relevant. QRPH is an interoperable QR standard that both Maya and GCash can settle through, and a QRPH-routed collection may carry its own fee basis — don't assume it's a drop-in substitute for a native integration without checking.
  6. Weigh switching cost, not just rate. Live on GCash and considering Maya? Factor in the engineering time for a second native build versus routing both through an aggregator you already use.

Merchants who skip step one usually end up comparing apples to oranges without realizing it — a mostly-collection GCash quote against a Maya quote with a heavy payout component will never line up, no matter how carefully you read the decimal points. For a broader side-by-side on how the two wallets differ as merchant channels generally, the GCash Business vs Maya Negosyo comparison covers onboarding and feature differences worth reading alongside this.

Reading a Fee Breakdown Inside a Real API Response

When a Maya-related transaction settles through a properly built integration, the fee breakdown should be visible in the transaction object your system receives back, not buried in a monthly statement you reconcile by hand. Here's a representative shape of that response, with placeholder values standing in for your actual negotiated terms:

{
  "transaction_id": "TXN-SP-20261003-004471",
  "channel": "maya",
  "direction": "collection",
  "integration_type": "native",
  "settlement_tier": "standard",
  "amount": {
    "currency": "PHP",
    "gross_value": "<order_amount>"
  },
  "fee_breakdown": {
    "collection_fee": {
      "basis": "percentage_of_gross",
      "rate": "<merchant_negotiated_rate>",
      "tier_applied": "<volume_tier_id>"
    },
    "disbursement_fee": null,
    "settlement_adjustment": "<tier_dependent>",
    "fx_adjustment": "none"
  },
  "net_settlement": {
    "currency": "PHP",
    "value": "<gross_value_minus_fees>",
    "expected_settlement_date": "2026-10-04"
  },
  "status": "settled"
}

Two things to check when reviewing your own provider's response schema against this. First, whether collection_fee and disbursement_fee are genuinely separate objects rather than one merged number — a single fee_amount field with no breakdown gives you no way to audit which component changed when your effective rate shifts. Second, whether tier_applied or an equivalent field exists at all — without it, you can't verify you're billed at the volume tier your contract specifies, which matters the first time your monthly volume crosses a tier boundary mid-cycle.

Frequently Asked Questions

Is Maya more expensive than GCash for merchants?

There's no fixed answer — it depends on whether you're comparing the same integration type, the same settlement tier, and the same mix of collection versus payout on both sides. Quotes that look far apart are often comparing different structures, not different wallets.

Does Maya charge differently for QR-based collection versus direct API collection?

Typically yes, because the two methods carry different technical and risk profiles for whoever is processing the transaction. A QR collection that routes through the QRPH interoperability layer may also carry its own fee basis separate from a direct wallet-to-wallet API collection, so it's worth asking your provider to quote each method separately rather than assuming one rate covers both.

Why did our Maya quote change after we added payout on top of collection?

Because collection and payout are priced on different logic — collection against risk and transaction value, payout against operational volume and batch size. Adding payout doesn't just add a second fee on top of the first; it can also shift which volume tier applies to each flow independently.

Can we choose a faster settlement tier without renegotiating our whole Maya rate?

Ask your provider directly — some structure settlement speed as an add-on adjustment on top of the base collection or payout fee, while others bundle it into a single blended rate per tier. Knowing which model your provider uses matters before you request a change, since it affects whether the rest of your pricing stays stable.

Does going through an aggregator always cost more than a native Maya integration?

Not necessarily. Aggregators pool volume across many merchants, which can unlock pricing a single smaller merchant couldn't reach on its own with a direct Maya agreement. Native integration tends to pay off more clearly once your own volume is large and predictable enough to negotiate competitive terms directly.

What does the BSP OPS/EMI license have to do with the fee I'm quoted?

It affects how many layers sit between you and Maya's actual settlement rails. A provider without clear BSP standing is usually routing through someone else's licensed infrastructure, which tends to add cost, reduce transparency, and complicate dispute handling even when the headline rate looks competitive.

Should we run Maya and GCash in parallel, or commit to one wallet first?

That depends on where your customers already are rather than on fee structure alone. Many merchants run both in parallel from the start specifically because customer wallet preference in the Philippines is split, and the fee comparison framework above is meant to help you negotiate each channel on its own terms rather than forcing a single winner.

How do we verify we're actually being billed at the volume tier our contract specifies?

Check whether your provider's transaction API response includes an explicit tier identifier alongside the fee breakdown, as shown in the sample response above. Without that field, you're relying on a monthly statement to catch a tier mismatch after the fact instead of catching it transaction by transaction.

If you're sorting through a Maya quote and want a second set of eyes on whether the structure fits your volume and flow mix, reach out. Telegram: @LouisSMARTPAY · Email: [email protected]

相关推荐