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 the national interoperable QR standard used for fund transfers and payments through InstaPay. GCash, Maya and GrabPay offer 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-09.

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.

HaiPay’s Philippines coverage matrix lists Visa and Mastercard. The Philippines local-method API lists five Philippine peso (PHP) wallet and QR collection codes, so card integration should be scoped separately through the credit card product. Confirm the contracting entity, enabled schemes, presentment and settlement currencies, authentication, refunds and chargebacks before launch.

Source: HaiPay’s “Payment Gateway Pricing & Fees” and “Philippines” API documentation, verified 2026-09-09.

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-09.

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

Maya (formerly PayMaya) is the current consumer brand. PayMaya Enterprise was renamed Maya Business.

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-09.

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-09.

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-09.

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-09.

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-09.

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 because the browser shows a success page. Verify any received notification’s signature and use a server-side collection-order query to confirm payment, verifying the query response under the current signing rules. Match the merchant application, internal order, expected amount and currency, and successful status before fulfilling once. A failed signature, mismatched values, a failed payment, or an unresolved pending or timeout state must not trigger fulfilment. Resolve a missing or invalid notification only through an independently verified query and the documented recovery process; handle repeated notifications and concurrent retries idempotently.
• 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, “Common API”, “API Description and Common Rules” and “Configuration Settings and Signature Rules”, verified 2026-09-09.

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

For US merchants contracting through HaiPay’s US entity, US-issued cards start at 2.5% + US$0.30 per transaction; cards issued outside the US start at 4.0% + US$0.30. Actual rates follow a business and risk review. These US card-product rates are not a Philippine-merchant quote. Local payment methods start from 1.2%, such as QRIS in Indonesia. Method rates, FX charges and applicable local taxes are listed separately in the merchant quote. The QRIS starting point is not a Philippine wallet or QR Ph rate.

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

Selected local payment methods in the Philippines can settle as fast as T+1. The quote must identify the schedule for each enabled route and merchant entity. Card settlement requires separate account-specific confirmation.

Confirm the starting event for T, day-counting unit, cut-off, payout schedule, holiday treatment and bank transit for each enabled method in your merchant quote. A T+N label alone does not establish a bank-arrival date.

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

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. Has the payment been confirmed? Use a verified server-side query to match the merchant application, order, expected amount, currency and successful payment status before idempotent fulfilment. Keep partial, excess, failed, mismatched or unresolved payments out of automated fulfilment and send them through the relevant exception workflow. Shopper authentication or browser navigation alone is not proof of payment.
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-09.

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.

HaiPay’s public coverage matrix also lists Philippine bank transfers. The PHP collection API lists the wallet and QR routes above; confirm which enabled pay-in route and bank-app journey implement the bank-transfer category for your account. The bank-account payout codes in the same API describe a separate capability.

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 9 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-09. 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-09. 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; “API Description and Common Rules”; and “Configuration Settings and Signature Rules”, accessed 2026-09-09. Support common callback, statement and reconciliation-report tools, request and response signature requirements, and payment-status confirmation.
4. HaiPay, “Payment Gateway Pricing & Fees”, accessed 2026-09-09. Supports starting prices and published Philippines coverage categories. The approved quote and merchant configuration establish the account’s enabled routes and commercial scope.
5. HaiPay, “Payment Settlement Time: How Long It Really Takes”, published 2026-08-24; accessed 2026-09-09. Supports selected local methods as fast as T+1 and the separation of settlement, payout and bank transit. No card schedule or day-counting unit is assumed. Timing guidance rechecked October 16, 2026. The quote confirms the route-specific timeline.
6. Bangko Sentral ng Pilipinas, “QR Ph”, accessed 2026-09-09. 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-09. Supports current P2M participant roles and the finite participant list.
8. Maya, “Say Hello to Maya”, accessed 2026-09-09. Supports the Maya/PayMaya naming change.
9. Maya Business, “Online Payment Gateway Solutions Philippines”, accessed 2026-09-09. Supports the existence of Maya’s direct Philippine online products only.
10. Maya Developers, “About Maya Checkout”, accessed 2026-09-09. Supports Maya-hosted checkout and redirect concepts only.
11. GCash, “How to pay online with GCash”, accessed 2026-09-09. Supports device-dependent GCash online payment journeys only.
12. GCash, “WebPay”, accessed 2026-09-09. Supports the existence of GCash’s direct online merchant product only.
13. GCash, “Scan to Pay with In-store QR”, accessed 2026-09-09. Supports separation of in-store merchant QR from online flows only.
14. Grab Philippines, “Online Payment”, accessed 2026-09-09. Supports the existence and customer journey of Grab’s direct online product only.

Source: HaiPay pricing and settlement guidance, accessed October 16, 2026. Account-specific availability, pricing and settlement arrangements are confirmed in the merchant quote.