GCash vs PayMaya (Maya): Which Payment Channel Should Philippines Merchants Integrate

I lead payment integration for a China-based team selling into the Philippines, and "GCash or Maya" comes up in our Slack almost every time we onboard a new storefront. Most of what you'll find online answers a different question — which wallet a shopper should carry, which card has better perks, whether PayMaya and Maya are the same app. None of that tells an engineering or finance lead what they actually need: which channel to point an API at, how long onboarding realistically takes, what the settlement rhythm looks like once money starts moving, and which one fits the business model at hand. This article is written from that seat — the merchant side, not the consumer side — and it's the comparison I wish someone had handed me before our first integration sprint.

GCash and Maya Are Not the Same Company, and That Matters for How You Build

Before anything else: GCash and Maya (the wallet formerly branded PayMaya) are two separate e-money issuers with separate ownership, separate apps, and separate backend infrastructure. They don't share a settlement network the way two banks on the same clearing system might. GCash sits inside Globe Telecom's ecosystem; Maya grew out of a card-and-wallet business before rebranding from PayMaya to Maya. Both are regulated as electronic money issuers by the Bangko Sentral ng Pilipinas, and both show up in the same breath because they cover overlapping use cases for the same consumer base — but from an integration standpoint, treating them as interchangeable is the first mistake teams make. Every API key, every webhook contract, every settlement account is channel-specific. If your checkout only wires up one of them, you aren't "covering e-wallets" in the Philippines — you're covering half the market, and often not the half you'd expect once you look at real transaction logs.

SMARTPAY operates under its own BSP-regulated OPS (Operator of Payment System) and EMI (Electronic Money Issuer) licenses, which is part of why we can sit between a merchant and both GCash and Maya through one compliant settlement pipe instead of a patchwork of resellers who may or may not be licensed themselves.

Side-by-Side: What Merchants Actually Need to Compare

Consumer comparisons stack up app ratings, cashback, and card perks — none of which moves the needle for a finance or engineering lead deciding where to point production traffic. The table below is what we actually use internally when scoping a new integration, narrowed to the dimensions that change how you build and how you plan cash flow.

Dimension	GCash (merchant/API side)	Maya (merchant/API side)
API documentation maturity	Long-established collection and payout endpoints; documentation is dense but assumes you already know the Philippine payments vocabulary (merid, tno, sign fields are standard)	Documentation has improved significantly since the PayMaya-to-Maya rebrand but still has more gaps around edge-case error codes than GCash's older, more battle-tested set
Settlement rhythm	Multiple settlement arrangements available depending on your onboarding tier; higher tiers tend to unlock faster cycles	Comparable tiered structure, though Negosyo/entry-level accounts often default to a slower cycle than their GCash Business counterparts until volume is proven
Onboarding requirements	Business registration, valid IDs of signatories, proof of business address, and a review period before go-live; stricter scrutiny for certain high-risk verticals	Broadly similar document set, with Negosyo (small business) and enterprise-tier onboarding split into different review tracks and different turnaround expectations
Fee structure	Tiered by volume and settlement speed; collection and payout are priced as separate line items	Also tiered by volume, with its own separate pricing for collection versus disbursement; not a drop-in substitute for GCash's fee schedule
Dispute/chargeback handling	Formal merchant dispute portal with defined evidence submission windows	Dispute workflow exists but historically required more manual back-and-forth through account management than GCash's self-service flow

Read that table as directional, not a locked-in promise from either company — both platforms update requirements and pricing tiers periodically, and whatever you're quoted during onboarding is the source of truth, not any article.

API Maturity and Developer Experience

This is where our engineering team actually spends its time, and it's the part consumer-angle articles skip entirely. GCash's collection and payout APIs have been in production longer, which shows up in small but meaningful ways: more consistent error codes, a clearer split between a failed signature and a failed transaction, and a sandbox that behaves closely enough to production to catch most integration bugs before go-live. For merchants outside the Philippines who need a technical path into GCash specifically, we've written up the collection-and-payout pattern in GCash Collection and Payout API: A Technical Path for Foreign Merchants in the Philippines, covering parts a general API reference won't — how signature verification and webhook retries actually behave under load.

Maya's API has caught up substantially, but our team still runs into more undocumented edge cases — certain refund states, certain partial-payout combinations — where support's honest answer is "that's not in the docs yet." Neither platform publishes a full spec you can drop into Postman and trust blindly; both require a sandbox pass with real test transactions before production keys.

Most merchants we onboard don't build GCash and Maya as two separate codebases — they sit both channels behind one aggregation layer so checkout logic doesn't care which wallet the customer picked, only settlement and reconciliation need to know. A simplified version of that request:

curl -X POST https://apix.example.com/api/v1/pay/create \
  -H "Content-Type: application/json" \
  -d '{
    "merid": "M1008XXXX",
    "channel": "gcash",
    "tno": "ORDER20261003001",
    "amt": "1500.00",
    "notify_url": "https://merchant.example.com/callback/pay",
    "sign": "A1F3C9..."
  }'

const crypto = require('crypto');

function buildSign(params, key) {
  const sorted = Object.keys(params).sort()
    .map(k => `${k}=${params[k]}`).join('&');
  return crypto.createHash('md5').update(sorted + key).digest('hex').toUpperCase();
}

async function createOrder(channel, tno, amt, merid, apiKey) {
  // channel is either "gcash" or "maya" — same request shape,
  // the aggregation layer routes to the right upstream API and
  // normalizes the callback payload before it reaches your system.
  const params = { merid, channel, tno, amt };
  params.sign = buildSign(params, apiKey);

  const res = await fetch('https://apix.example.com/api/v1/pay/create', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(params),
  });
  return res.json();
}

That "channel" field is doing the real work. Your checkout, order state machine, and reconciliation job don't have to branch on which wallet the customer tapped — the actual engineering payoff of treating this as an integration decision instead of a consumer preference poll.

Onboarding and KYB: Getting a Live Merchant Account

Both channels want a real, verifiable business behind the application: SEC or DTI registration depending on entity type, valid government IDs for signatories, proof of business address, and evidence of what you actually sell. Where the paths diverge is in how review is structured. GCash Business accounts generally move through a tier system — your initial tier caps transaction volume and settlement speed, and you move up as you demonstrate clean history. We've broken down that upgrade path and what reviewers actually check for in GCash Business vs Maya Negosyo comparison, worth reading alongside this article if onboarding timeline is your main constraint.

Maya splits merchant onboarding between Negosyo (smaller, often single-location businesses) and a separate enterprise track for higher-volume operations. Foreign-owned entities or unusual business models — subscription billing, gaming top-ups, cross-border e-commerce — should expect more manual review on either platform, not less, since those categories draw extra scrutiny from BSP-regulated issuers regardless of wallet.

One practical note: the documents a reviewer rejects are rarely the ones you'd expect — proof-of-address mismatches and unclear ownership structures cause more back-and-forth than anything about the business model itself. Budget review time accordingly rather than assuming either platform moves at the same pace twice.

Settlement Speed and Cash Flow Planning

Settlement is where "which is better" stops being abstract and starts affecting payroll and supplier payments. Both GCash and Maya offer tiered settlement arrangements, and in both cases the cycle you get on day one isn't the cycle you're stuck with — it improves as account history and volume build trust with the issuer. We won't quote a specific number of hours or days as a blanket promise here, because actual timing depends on tier, transaction mix, and operational factors on the issuer's side outside any integrator's control. Directionally: GCash's settlement options for established, higher-tier accounts tend to be the benchmark other wallets get compared against, and we've laid out how that cycle works, tier by tier, in GCash settlement cycle breakdown.

The planning implication is simple — don't design your cash flow model around a single wallet's best-case settlement window. If running both channels, treat each one's settlement rhythm as independent in your finance reporting until you have enough history to know how they land relative to each other for your business.

Fee Structure and Dispute Handling: The Two Costs That Don't Show Up in the Headline Rate

We're intentionally not putting numbers in this section — fee schedules on both platforms are tiered, change periodically, and the rate quoted to a high-volume gaming platform isn't the rate quoted to a small D2C store, so any figure printed here would be stale by the time you read it. What matters structurally: both GCash and Maya separate collection fees from payout/disbursement fees, both scale pricing with volume commitments, and neither publishes one flat rate for every merchant category. We maintain regularly-reviewed breakdowns of how each schedule is actually built — see how GCash structures its merchant fees and Maya's merchant fee structure — but the only figure that matters for your decision is the one quoted directly to your account during onboarding.

Because both GCash and Maya are e-money issuers supervised by BSP, any integration partner you plug into — including SMARTPAY, operating under its own BSP OPS/EMI licenses — should be sitting inside that same regulatory perimeter, with fee schedules and settlement terms disclosed in writing rather than negotiated informally.

A pattern worth flagging: merchants comparing fee quotes across channels without normalizing for settlement speed. A faster settlement tier usually carries a different cost structure than a slower one, so comparing a fast-tier GCash quote against a slow-tier Maya quote isn't actually comparing the channels — it's comparing two different service levels.

Dispute handling is the other cost that doesn't show up in a rate card, and most comparisons skip it entirely. GCash runs a merchant-facing dispute process with defined evidence-submission windows and trackable status. Maya's dispute flow works, but leans more on back-and-forth with account support than a self-service portal — fine at low dispute volume, slower once transaction count climbs. For categories with structurally higher dispute rates — subscription billing, digital goods — build evidence-collection habits (timestamps, IPs, delivery confirmations) to the stricter of the two standards from day one.

Which Business Types Fit Which Channel

After enough integrations, patterns show up. Broad-based e-commerce storefronts generally want both channels live from day one, since checkout abandonment climbs the moment a customer's preferred wallet isn't an option — this isn't a "pick one" market. Subscription and SaaS billing tends to favor whichever channel has more mature recurring-charge and tokenization support for the use case at hand, worth re-checking per project rather than assuming last year's answer still holds. Gaming and digital-goods platforms, which run high transaction counts with meaningfully higher dispute exposure, benefit most from whichever channel's dispute workflow an operations team can actually keep up with — in our experience that's leaned toward GCash's more self-service process, though that reflects our own team's bandwidth, not a universal rule. Cross-border sellers care less about which wallet the customer tapped and more about how cleanly settlement reconciles against their accounting system.

The honest takeaway after running both channels across a range of merchant types: few businesses should pick one as a philosophy. The more common decision is sequencing — which channel to integrate first based on launch timeline and onboarding bandwidth, and when to add the second. Running both through a single aggregation layer, as in the code example above, removes most of the reason to pick a side at all.

Frequently Asked Questions

Is PayMaya the same as Maya, and is that the same as GCash?

PayMaya and Maya are the same company under a new brand name — the rebrand changed the name and app presentation, not the underlying issuer or licensing. GCash is a completely separate company and e-money issuer; they're mentioned together because they're the two largest wallet players in the Philippines, not because they're related entities.

Which is better, GCash or Maya, for accepting merchant payments?

Neither is categorically better — they serve overlapping but not identical customer bases, and the "better" one depends on your business type, dispute exposure, and how much onboarding friction you can absorb right now. Most merchants we work with end up running both rather than picking one.

Do GCash and Maya settle through the same rail?

No. Each is its own e-money issuer with its own settlement infrastructure and account relationships with partner banks — they aren't interchangeable at the settlement layer, even though both ultimately move funds into a merchant's bank account.

Can I integrate both GCash and Maya through a single API?

Through a licensed aggregation layer, yes — your application sends one request format with a channel parameter, and the aggregator routes it to the correct upstream API and normalizes the callback. Going direct to both issuers separately means maintaining two codebases, two signature schemes, and two reconciliation processes.

What's the real difference between a GCash card and a Maya card, from a merchant's perspective?

For merchants this matters far less than it does for consumers comparing card perks. What matters on the merchant side is whether card-funded transactions from either wallet route through the same collection API as wallet-balance transactions, or need separate handling — an integration detail to confirm with the channel you're onboarding onto, not a consumer feature comparison.

Does Maya require more documents than GCash for a business account?

The core document set is broadly similar — business registration, signatory IDs, proof of address — but the review tracks differ, with Maya splitting Negosyo and enterprise onboarding and GCash using a tier-based progression. Expect comparable effort on both, with friction points varying by business type rather than by platform.

How long does it take to go live with GCash versus Maya?

We won't put a fixed number on this, since review timelines depend on document completeness, business category, and current review volume on the issuer's side — none of which an integrator controls. Incomplete documentation is the single biggest driver of delay on either platform, more so than any structural difference between them.

Should a new merchant start with GCash, Maya, or both at once?

If the launch timeline allows it, both from day one avoids leaving checkout conversion on the table. If you need to sequence due to onboarding bandwidth, start with whichever channel your target customers use more heavily for your vertical, and treat the second integration as a near-term follow-up rather than an eventually-maybe.

If you're scoping a GCash and Maya integration and want a second opinion on tiering, settlement planning, or structuring a single aggregation layer across both, reach out directly — Telegram @LouisSMARTPAY or email [email protected].