Philippines Payment Gateway Integration for Global Merchants: Entity, API and Settlement (2026)
I lead the payments and integration side of a consumer brand headquartered outside the Philippines that sells into Metro Manila and the provinces through our own website and a couple of marketplaces. When we started, I assumed "payment gateway integration" in the Philippines meant the same thing it means in Singapore or the US: pick a provider, drop in a checkout SDK, go live. It does not. The Philippines has its own rails, its own regulator, its own wallet-first consumer behaviour and its own rules about who is allowed to hold merchant funds. This article is the version of the map I wish someone had handed me on day one. It is written for global merchants and the developers who work with them, and it covers the four layers you have to get right, in order: entity and compliance, payment method mix, technical integration, and settlement.
Integration in the Philippines Is Four Problems, Not One
Most integration guides jump straight to API keys. In practice, the API is the easiest layer. The first problem is structural: which legal entity will be the merchant of record, and whether that entity can hold a merchant account with Philippine payment channels at all. The second is product: which local payment methods you must support so you do not lose the majority of checkouts, because card penetration here is low compared with wallets and bank transfers. The third is technical: hosted checkout versus direct API, webhook handling, idempotency, reconciliation. The fourth is money movement: how pesos collected locally become funds you can actually use, in which currency, through which account. If you solve them out of order, you end up with a beautiful checkout page that cannot be settled anywhere.
Do You Need a Local Entity? Three Entry Paths
This is the question that decides everything else. GCash, Maya and the QRPH ecosystem onboard merchants through acquiring institutions supervised by the Bangko Sentral ng Pilipinas (BSP), and those institutions apply know-your-business rules that assume a Philippine-registered business. A foreign company without local registration generally cannot open these merchant accounts directly. That leaves three realistic paths.
| Entry path | How it works | Best for | Trade-offs |
|---|---|---|---|
| Local entity with direct merchant accounts | Register a Philippine company or branch, open a local bank account, apply to each wallet and bank channel separately | Merchants committing to the market long term, with local staff and local tax filings | Slowest to launch; each channel is a separate onboarding; you own every integration and every compliance obligation |
| Non-resident merchant through a BSP-licensed gateway | Contract with a gateway that holds BSP OPS or EMI authorization; the gateway onboards you under its merchant framework and exposes one API for GCash, Maya, QRPH and bank transfer | Cross-border e-commerce, SaaS, gaming and digital goods merchants that want local payment methods without a local company | You depend on the gateway's compliance posture and must verify its licence; settlement terms are set by the gateway |
| Marketplace-only | Sell through Lazada, Shopee or TikTok Shop and let the platform collect | Testing demand before building anything | No control over checkout, data or settlement timing; platform fees and policies apply |
We started on the marketplace path, moved to a licensed gateway as a non-resident merchant once our own site had traffic, and are now evaluating a local entity because our volume justifies the overhead. That staged approach is common, and the gateway path is where most global merchants spend the longest. The key diligence on that path is simple to state and easy to skip: confirm the gateway's authorization against the BSP's published lists before you sign. The difference between an operator of payment systems and an electronic money issuer is explained in what a BSP NOPS licence is and what a BSP EMI licence means.
Whoever holds your customers' pesos between payment and settlement must be a BSP-authorized OPS or EMI. If a provider cannot show you that authorization, or asks you to route funds through an individual's wallet or a company that is "still applying," treat that as a hard stop rather than a negotiating point.
Which Payment Methods to Turn On First
The Philippine checkout is wallet-first. GCash is the method most consumers expect to see, Maya is the second wallet that matters, and QRPH is the national QR standard that lets a single QR be paid from any participating wallet or bank app. Behind those sit the two interbank rails, InstaPay for real-time transfers and PESONet for batch transfers, which power bank-transfer checkout and most payouts. Over-the-counter cash channels still matter for customers without wallets, and cards remain relevant for higher-value and cross-border purchases. Our recommendation for a new global merchant is to launch with GCash, Maya and QRPH through one gateway contract, add bank transfer if your average order is high, and treat cards and OTC channels like 7-Eleven and Cebuana as a second phase once you can see what your customers actually choose.
Two things surprised us. First, the QRPH code is not a GCash feature; it is a national standard, so one QR covers wallets and banks at once, which simplifies both the physical and the in-app flow. Second, the method mix shifts by region and by product. Our Metro Manila customers skew to wallets, our provincial customers use bank transfer and OTC far more, and our highest-value orders cluster on cards. Build your method list from your own data after the first few weeks rather than from national averages.
Onboarding: What a Licensed Gateway Will Ask a Foreign Company For
Onboarding as a non-resident merchant is document-heavy but predictable. Expect to provide your home-country incorporation documents and a recent good-standing certificate, identification for directors and beneficial owners, a description of your business model that explains what you sell, who buys it and where the money goes, your website or app with visible terms, privacy and refund policies, the bank account that will receive settlement, and, for regulated verticals such as gaming or financial services, evidence of the licences you hold at home. The business description is the document that gets merchants rejected. Vague descriptions like "online trading" or "digital services" force the compliance team to assume the worst. Write it the way you would explain the business to a bank manager: concrete products, concrete customer profile, concrete fund flow.
Timelines vary by gateway and by how complete your first submission is, so I will not quote one. What I can say is that in our experience the back-and-forth on documents took longer than the technical integration, and that every day we saved was a day we saved by having the pack ready before we asked for the application link.
Technical Integration: Hosted Checkout or Direct API
Once onboarded, you choose between a hosted checkout page the gateway renders and a direct API where your own frontend renders the method selection and the gateway only handles the payment leg. Hosted is faster to ship and keeps most sensitive data off your servers. Direct API gives you control over the user experience and conversion. The trade-offs are covered in hosted checkout versus native checkout; we started hosted and moved specific high-volume flows to the API once we had reconciliation and monitoring in place. Either way, the core request pattern is the same: create an order on your side, call the gateway, redirect or render, then rely on the asynchronous webhook as the source of truth for payment status. A simplified order creation request looks like this; field names follow your gateway's documentation:
curl -X POST https://api.example-gateway.ph/v1/orders \
-H "Content-Type: application/json" \
-H "X-Merchant-Id: {{MERCHANT_ID}}" \
-H "X-Timestamp: {{UNIX_TS}}" \
-H "X-Sign: {{SIGNATURE}}" \
-H "Idempotency-Key: {{ORDER_UUID}}" \
-d '{
"out_trade_no": "WEB-20261012-004512",
"amount": "{{ORDER_AMOUNT}}",
"currency": "PHP",
"channel": "GCASH",
"subject": "Order WEB-20261012-004512",
"return_url": "https://shop.example.com/checkout/return",
"notify_url": "https://shop.example.com/webhooks/payments"
}'
The webhook handler is where most integrations go wrong. It must verify the signature, be idempotent because the same notification can arrive more than once, respond quickly so the gateway does not retry unnecessarily, and only then update the order. A skeleton in Node.js:
const crypto = require('crypto');
function verifySign(payload, secret) {
const { sign, ...rest } = payload;
const base = Object.keys(rest).sort()
.map(k => `${k}=${rest[k]}`).join('&');
const expected = crypto.createHmac('sha256', secret)
.update(base, 'utf8').digest('hex');
return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(sign));
}
app.post('/webhooks/payments', async (req, res) => {
if (!verifySign(req.body, process.env.GATEWAY_SECRET)) {
return res.status(400).send('FAIL');
}
const { out_trade_no, status, gateway_txn_id } = req.body;
// Idempotent update: only move PENDING -> PAID, ignore repeats
await orders.markPaidIfPending(out_trade_no, gateway_txn_id, status);
res.status(200).send('SUCCESS');
});
Beyond the happy path, build a query-endpoint fallback for orders stuck in pending, log every raw webhook before parsing it, and reconcile daily against the gateway's settlement report rather than against your own webhook log. The developer-level detail on collection and disbursement flows is in the developer's guide to collection and disbursement.
Settlement, Currency and Getting Money Out
Collected pesos sit with the gateway until settlement. For a non-resident merchant, the questions that matter are where settlement lands, in which currency, and on what cycle. The options we have seen in practice fall into three patterns.
| Settlement pattern | What you receive | Suits | Watch for |
|---|---|---|---|
| Settlement to a Philippine bank account | Pesos into a local corporate account you or your local entity hold | Merchants with a local entity or local supplier obligations | Requires a local account; moving funds offshore later is a separate step with its own documentation |
| Converted settlement by international transfer | Funds converted to your home currency and wired to your offshore account | Non-resident merchants with no local spending | Conversion rate and timing are set by the gateway's terms; ask how the rate is determined and how often settlement runs |
| Balance held with the gateway and used for payouts | A peso balance you draw on to pay local suppliers, affiliates or refunds | Merchants with recurring local payouts | Only acceptable if the balance sits with a BSP-authorized OPS or EMI; verify how client funds are segregated |
Settlement speed is a commercial term, not a technical one, and it varies by provider and by your risk profile, so negotiate it explicitly rather than assuming. How same-day settlement actually works under the hood is explained in D0 same-day settlement in the Philippines. If you price in multiple currencies, decide early whether the peso price or the home-currency price is the source of truth, because that choice drives your reconciliation and your refund logic; see multi-currency pricing for Philippine e-commerce.
Mistakes We Made So You Can Skip Them
We treated the webhook as optional and polled instead, which worked until traffic spiked and our polling fell behind. We launched without a refund flow, assuming refunds would be rare, and spent a painful month handling them manually through support tickets. We did not ask how the conversion rate was set for offshore settlement, and discovered the answer only when finance questioned the numbers. We assumed GCash alone was enough and lost provincial customers who wanted bank transfer. And we nearly signed with a provider that could not show BSP authorization, because its sales deck was excellent; the verification step took one afternoon and saved us from a very bad outcome.
Frequently Asked Questions
Can a foreign company accept GCash without a Philippine entity?
Not directly from GCash, in the typical case. The workable route is to onboard as a non-resident merchant under a BSP-licensed gateway that already holds the channel relationships and exposes them to you through one contract and one API.
Is QRPH a separate integration from GCash and Maya?
Technically it is a separate channel, but a good gateway exposes it through the same API with a different channel code. Because QRPH is the national standard, one QR serves both wallets and banks, which is why we recommend enabling it alongside the wallets.
How do I verify that a gateway is actually BSP-licensed?
Ask for the exact legal entity name on the authorization, then check it against the BSP's published lists of operators of payment systems and electronic money issuers. The name on the contract must match the name on the list.
Should I start with hosted checkout or direct API?
Hosted for the first launch, unless you already have reconciliation, monitoring and webhook handling built. Move high-volume or high-value flows to the API later, once you can measure the conversion difference.
What currency will I be settled in?
Collections are in pesos. Whether you receive pesos locally, a converted amount offshore, or a balance held with the gateway depends on the settlement pattern you contract for. Confirm the pattern and how any conversion rate is determined before you go live.
Do I need to register for Philippine taxes if I use a gateway?
Tax registration depends on your entity structure, your sales channels and the nature of what you sell, and it is a question for a Philippine tax adviser rather than for your payment provider. The gateway contract does not replace tax advice.
Where to Start
If you are a global merchant planning a Philippines launch, start with the entity decision, then verify your provider's BSP authorization, then build the document pack, and only then open the API documentation. Done in that order, the technical integration is the easy part. If you want to compare notes on entry paths, method mix or settlement patterns for your specific business, reach me on Telegram at @LouisSMARTPAY or by email at [email protected].