Payment Gateway Philippines: Cards, Wallets and QR Ph Guide

This guide is for international ecommerce, gaming, digital-content, software-as-a-service (SaaS) and other merchants that want to collect relatively small, frequent payments from customers in the Philippines. It explains what the current public evidence establishes, what it does not establish, and what to obtain in writing before launch. Transparency: This is a HaiPay guide evaluating the provider’s public route documentation, not an independent provider ranking. Market and wallet-operator sources are used only for market facts; merchant activation and commercial terms require account-level evidence.

What a Philippine payment gateway needs to support

A useful shortlist starts with the whole payment lifecycle, not a row of logos. Check five things:

1. Shopper fit: cards, wallet handoff, wallet-specific QR and QR Ph are different customer journeys.
2. Merchant eligibility: the contracting entity, business sector, website or app, currencies and transaction profile must pass review.
3. Technical fit: the integration needs the right payment URL or QR response, browser return, server notification, status query and report flow.
4. Money movement: presentment, fees, foreign exchange, payable balance, settlement currency and bank arrival must be defined separately.
5. Exception handling: failed payments, duplicate orders, refunds, disputes, chargebacks and reconciliation need an accountable process.

The international payment gateway guide explains the wider provider-selection problem. The guide to local acquiring versus cross-border acquiring helps clarify why the merchant entity and route matter.

Cards, wallets and QR payments are not interchangeable

The word “gateway” can hide several different payment journeys. Use the shopper action as the first classification.

QR Ph is a payment standard and rail, not another consumer wallet. GCash, Maya and GrabPay are wallets or wallet-branded payment products. A wallet can participate in QR Ph and still have a separate online checkout product.

Source: Bangko Sentral ng Pilipinas, “QR Ph”, and “QR Ph Participants (as of 31 July 2026)”, verified 2026-09-02.

Card payments for international merchants

Cards remain a distinct route decision. The shopper normally enters card details and may complete issuer authentication; the merchant then needs a status, a dispute process and a settlement arrangement. Those steps should not be inferred from the presence of a card logo.

The current Philippines local-method page lists five Philippine peso (PHP) collection codes, but it does not list a Philippines-specific card code in that table. Treat card acceptance as a separately scoped credit card product and contract question. Ask which merchant entity contracts, which currencies can be presented and settled, which card schemes are enabled, and which refund and chargeback rules apply.

Source: “Philippines” API documentation, verified 2026-09-02. The cited page supports only the absence of a card row from its Philippines local-method table.

GCash: two documented route labels, not one flow

Current public documentation lists two separate GCash codes:

• GCASH_QR, described as “GCash Wallet (Activation)”;
• GCASH_URL, described as “GCash Wallet (Direct).”

Both rows are currently marked Available in the public route catalog. That status shows that the route is present in the platform directory. It does not prove that a particular merchant application is configured for either route.

The public Philippines integration schema can return a payUrl or qrCode, but it does not map every response field to a complete device-by-device GCash journey. GCash’s own consumer help shows that online payment can involve app opening or QR scanning depending on device. That operator evidence explains why QR and URL flows should not be collapsed; it does not establish the provider implementation for an individual merchant.

Before launch, test the required phone and desktop journeys. Confirm the enabled code, browser return, server notification, failed-payment path, expiry, refund support and settlement terms in writing.

Source: “Philippines” API documentation and GCash, “How to pay online with GCash”, verified 2026-09-02.

Maya (formerly PayMaya): current brand, legacy route code

The reader-facing brand is Maya (formerly PayMaya). Maya’s official update says PayMaya is now Maya, and PayMaya Enterprise became Maya Business. After this first explanation, this guide uses “Maya.”

The current technical table still uses PAYMAYA_URL. The code must remain unchanged in requests and technical records; it is a legacy technical identifier, not a second wallet. The public row is marked Available and described as a payment-gateway route. The generic response schema includes payUrl, but the public page does not map that field to PAYMAYA_URL or document its exact shopper flow. Confirm the response, handoff and activation in the merchant configuration and sandbox.

Maya’s own Checkout materials describe a Maya-hosted page and redirect flow. Those materials establish Maya’s market product and naming, not gateway fees, onboarding, settlement or refund terms.

Source: Maya, “Say Hello to Maya”, Maya Business, “Online Payment Gateway Solutions Philippines”, Maya Developers, “About Maya Checkout”, and “Philippines” API documentation, verified 2026-09-02.

GrabPay and GRPY_URL: market flow versus documented code

The public Philippines table lists GRPY_URL, described as “GrabPay Wallet,” and marks it Available. The code is URL-named, and the generic response schema can include payUrl. The public page does not map that field to this code or establish the customer screens or merchant activation.

Grab’s official Philippines online-payment material establishes that a direct GrabPay online product exists. It does not establish the gateway’s method-level flow. Do not transfer the operator’s onboarding, fee or settlement terms to a gateway contract.

Source: Grab Philippines, “Online Payment” and “Philippines” API documentation, verified 2026-09-02.

QR Ph: an interoperable standard, not a wallet

The Bangko Sentral ng Pilipinas (BSP) describes QR Ph as an interoperable common QR standard used by participating banks and non-bank e-money issuers. It supports person-to-person (P2P) and person-to-merchant (P2M) use through InstaPay. For this guide, the relevant question is the online P2M journey.

The BSP participant sheet dated 31 July 2026 is finite and role-specific. It includes sender-and-receiver, sender-only and receiver-only participants. GCash, Maya, GrabPay’s Philippine entity and Union Bank of the Philippines appear in the sheet, but their participation does not mean every institution supports every direction or every merchant route.

The public code PH_QRPH_DYNAMIC is typed as QR, described as “QRPH Dynamic Code,” and marked Available. That is route-catalog evidence. It is not evidence that every merchant account is activated, that every QR Ph participant can complete the exact online flow, or that refunds and settlement are identical across methods.

Source: Bangko Sentral ng Pilipinas, “QR Ph”, “QR Ph Participants (as of 31 July 2026)”, and “Philippines” API documentation, verified 2026-09-02.

Market existence, public route and merchant activation

A payment method should pass three gates before it appears in a production checkout:

1. Market evidence: the wallet or rail exists in the Philippines and the proposed customer journey is legitimate.
2. Provider evidence: current documentation lists a route with the required currency and status.
3. Merchant evidence: the method appears in the merchant application’s configuration and the signed quote defines the commercial and operational scope.

The merchant-configuration endpoint makes the third gate explicit. It queries the methods available to a merchant application; if no product is configured, the configuration list can be empty. The returned limit is the intersection of platform and merchant-app configuration, and the response can expose fee, settlement and refund-support fields.

Source: “Get Merchant Payment Config”, verified 2026-09-02.

Philippines Payment-Route Activation Matrix

The table below is an evidence and implementation checklist, not a promise of activation. “Available” refers only to the current public route catalog. “Written confirmation” means the merchant configuration, sandbox and signed terms must supply the answer.

The limit conflict is important: the same public Philippines page shows PHP 100–50,000 in its collection summary and method table, while the collection-application amount field says PHP 50–49,999. Do not configure production limits from either value alone. Use the live merchant configuration and obtain written confirmation.

Source: “Philippines” API documentation and “Get Merchant Payment Config”, verified 2026-09-02.

Wallet handoff, dynamic QR and card decision tree

Use these implementation rules where the approved route exposes the corresponding signals:

• Where both are documented for the approved route, treat the browser return as a customer-journey signal and the server notification as a separate integration signal.
• Do not fulfil an order only because the browser shows a success page. If the approved integration exposes a notification or status query, use that documented server-side signal to confirm the order.
• Do not infer refund support, settlement or reconciliation from the shopper’s screen. Those are merchant-operation capabilities.

The Philippines API distinguishes the successful browser return URL, failed browser return URL and optional server notification URL, and it documents collection query. The Common API documents collection-status callbacks and statement or reconciliation-report creation and retrieval. The availability and operating process for a particular merchant app still need implementation confirmation.

Source: “Philippines” API documentation and “Common API”, verified 2026-09-02.

PHP, fees, value-added tax (VAT), foreign exchange (FX) and settlement

PHP presentment and limits

The five public local-method rows use PHP. The conflicting collection ranges described above apply only to that documented Philippines pay-in page. They are not a universal Philippines limit and do not describe payout or international card limits.

Public starting prices

The public pricing page lists eligible card transactions from 2.5% + US$0.30 and local payment methods from 0.8%, priced by market.

Those are starting points, not route-specific Philippines quotes. The exact rate and scope depend on the merchant entity, payment method, market, volume, transaction quality and risk, configuration, contract and final signed quote. No public evidence reviewed for this guide supports assigning a specific rate to GCash, Maya, GrabPay or QR Ph.

VAT and foreign exchange

Do not add a Philippine VAT percentage from general tax law to a payment quote. Ask whether VAT is included in the quoted rate, how it appears on invoices and which contracting entity issues them. No Philippines-specific VAT treatment was established in the reviewed public product evidence.

Likewise, obtain the presentment currency, settlement currency, conversion event, reference basis, markup or spread, transfer fee and bank-receipt amount in writing. Do not treat a bank named in market-infrastructure material as the gateway’s acquirer, settlement bank or foreign-exchange source without a route-specific written mapping.

Settlement wording that can be compared

The current public settlement guide uses calendar-day tiers and says settlement executes on working days. Public materials do not map each Philippine route code to a settlement tier, so no route-specific settlement time is stated here.

Ask the quote to define T+N with T as the successful capture date and N counted in calendar days. It should also state the exact method and merchant entity, working-day execution rule, transaction volume and quality conditions, reserve or risk conditions, cut-off and bank-arrival expectation. A weekend or public holiday can affect when an execution reaches the merchant’s bank.

Source: “Payment Gateway Pricing & Fees” and “Payment Settlement Time: How Long It Really Takes”, verified 2026-09-02.

Merchant entity, underwriting and route activation

Treat business registration and payment-method activation as separate checks. Before investing in a full integration, ask the provider for a written preflight response covering:

• the legal entity that will contract and the countries from which it may apply;
• whether cards, PH_QRPH_DYNAMIC, GCASH_QR, GCASH_URL, PAYMAYA_URL and GRPY_URL can be activated for that entity;
• which app ID, currency and endpoint apply;
• the live limit for each route;
• required website, fulfilment, know-your-customer (KYC) and underwriting documents;
• test credentials, acceptance criteria and the production activation owner;
• restricted business models or transaction patterns; and
• any reserve, hold, review or termination conditions in the agreement.

This turns “supported in the Philippines” into an account-level implementation decision.

Payment status, refunds, disputes and reconciliation

A complete operations design separates four questions:

1. Did the shopper authorise the payment? Use the route journey plus the server-side status or notification.
2. Can the merchant return funds? Confirm whether the exact PHP route supports merchant-initiated refunds, partial refunds and status tracking.
3. Can the customer dispute the payment? Obtain the wallet, QR or card dispute rules, evidence requirements, deadlines and fees.
4. Can finance close the books? Confirm report availability, order identifiers, gross amount, fee, net amount, payment time, settlement batch and exception fields.

The Common API documents callback retries and collection/reconciliation report tools. That establishes common platform primitives, not automatic entitlement for every merchant app. The public refund-support table reviewed for this guide does not list the five PHP methods. A generic public refund fee is therefore not proof that any one Philippines wallet or QR route supports refunds.

Source: “Common API”, “Get Merchant Payment Config” and “Payment Gateway Pricing & Fees”, verified 2026-09-02.

A fair route comparison for this decision

The useful comparison is not “which logo wins?” It is whether the documented flow matches the checkout and operations your business needs.

No route should be declared the universal choice. Match the route to the customer action, then compare account-level pricing and operations on the same fields.

Philippines Quote Verification Checklist

Ask the provider to answer every applicable row in writing.

Where HaiPay may fit—and what needs written confirmation

HaiPay may be worth evaluating when the five public Philippines codes are relevant to the wallet or QR methods you want to assess and you also want to discuss a separate international card path. The public documentation provides a concrete starting point for an integration review, but the exact method-level shopper flow still requires testing.

It is not enough to launch. Obtain written confirmation of the merchant entity, route activation, PHP configuration, card scope, wallet and QR journeys, settlement, refunds, disputes, reconciliation, VAT treatment, FX and final quote. The pricing matrix’s bank-transfer category could not be mapped to an independent Philippine pay-in route, so no bank-transfer coverage claim is made.

To request an account-specific review, use the HaiPay contact page and attach the completed checklist above. You can also review the local payment product before the call.

Disclosure

HaiPay publishes this guide about its own payment service. It is commercial product information, not financial, investment, tax or legal advice. Product documentation and linked sources were checked on 2 September 2026; availability and terms can change. Obtain route-level written terms and independent professional advice where appropriate.

Sources

1. HaiPay, “Philippines” API documentation, last modified 2026-07-17; accessed 2026-09-02. Supports the public PHP route table, status labels, conflicting amount ranges, response fields, browser-return fields and collection query.
2. HaiPay, “Get Merchant Payment Config”, last modified 2026-07-13; accessed 2026-09-02. Supports merchant-app configuration, empty configuration possibility, configured limits, fee/settlement/refund fields and public refund-support scope.
3. HaiPay, “Common API”, last modified 2026-08-06; accessed 2026-09-02. Supports common callback, statement and reconciliation-report tools.
4. HaiPay, “Payment Gateway Pricing & Fees”, accessed 2026-09-02. Supports public card and local-method starting prices and quote limitations. Its bank-transfer category is not used as a Philippine pay-in coverage claim.
5. HaiPay, “Payment Settlement Time: How Long It Really Takes”, published 2026-08-24; accessed 2026-09-02. Supports the public calendar-day and working-day framework; it does not provide the required route-code mapping for this guide.
6. Bangko Sentral ng Pilipinas, “QR Ph”, accessed 2026-09-02. Supports QR Ph’s interoperable standard, P2P/P2M and InstaPay context.
7. Bangko Sentral ng Pilipinas/BancNet, “QR Ph Participants (as of 31 July 2026)”, accessed 2026-09-02. Supports current P2M participant roles and the finite participant list.
8. Maya, “Say Hello to Maya”, accessed 2026-09-02. Supports the Maya/PayMaya naming change.
9. Maya Business, “Online Payment Gateway Solutions Philippines”, accessed 2026-09-02. Supports the existence of Maya’s direct Philippine online products only.
10. Maya Developers, “About Maya Checkout”, accessed 2026-09-02. Supports Maya-hosted checkout and redirect concepts only.
11. GCash, “How to pay online with GCash”, accessed 2026-09-02. Supports device-dependent GCash online payment journeys only.
12. GCash, “WebPay”, accessed 2026-09-02. Supports the existence of GCash’s direct online merchant product only.
13. GCash, “Scan to Pay with In-store QR”, accessed 2026-09-02. Supports separation of in-store merchant QR from online flows only.
14. Grab Philippines, “Online Payment”, accessed 2026-09-02. Supports the existence and customer journey of Grab’s direct online product only.