GCash and Maya Checkout for Custom Online Stores

Filipino online buyers expect GCash and Maya at checkout — often before card fields. For custom stores and operational portals (not just Shopify templates), the hard part is not displaying logos. It is wiring gateways, order state, and reconciliation so finance and ops trust the numbers.

Start with gateway, not wallet APIs

For most Philippine SMEs building a custom storefront, a licensed payment aggregator (PayMongo, Maya Business, Xendit, HitPay, and similar) is the right first move:

• One integration surface for GCash, Maya, cards, and often bank transfer or QR Ph
• Provider handles much of compliance and PCI scope for card flows
• Faster time to live than negotiating separate wallet contracts

Direct wallet integrations only make sense at serious volume — and usually alongside a gateway, not instead of one. We compared the tradeoffs in Digital Payments for Philippine Online Stores.

Checkout UX that converts on mobile

Custom checkout should:

• Show GCash and Maya prominently — not hidden behind "other payment methods"
• Redirect or embed the provider's own payment flow — never collect wallet PINs or credentials on your domain
• Return the user to a clear confirmation page with order reference
• Handle timeouts and abandoned redirects — user closed the wallet app mid-flow

Checkout must load quickly on mid-range Android over mobile data. Payment success does not matter if the redirect never renders (website speed and revenue).

Order state is the source of truth

The anti-pattern: staff mark orders "paid" after manually checking a wallet notification. The fix: payment status lives on the order object — pending, authorized, paid, failed, refunded — updated by verified webhooks from the gateway.

Your backend should:

• Create an order in pending_payment before redirect
• Accept webhook callbacks only with signature verification
• Idempotently apply the same event if the provider retries
• Never ship or fulfill on client-side "success" alone

That is standard domain modeling — same discipline as modeling the business before writing controllers.

Reconciliation finance actually needs

Accepting GCash and Maya is half the job. The other half:

• Settlement batches arrive net of fees, sometimes grouped — match to individual orders
• Partial refunds and cancellations must update inventory and books
• Payment success + order failure (and the reverse) need playbooks — not Viber archaeology
• Weekly (or daily) exception reports — paid orders without fulfillment, fulfilled orders still pending

This is operational software, not a plugin. Spreadsheet reconciliation is the tax we described in The Hidden Cost of Manual Business Processes.

Security and trust at checkout

• HTTPS everywhere on checkout and webhooks
• No storing card numbers unless you are explicitly certified for it — let the gateway tokenize
• Log webhook payloads securely for disputes, with retention policy
• Show consistent branding so redirects to Maya or GCash feel expected, not phishing-like

Test failure paths deliberately: user cancels in the wallet, session expires, webhook arrives before the browser returns. Support staff should see one order timeline — not three tabs and a group chat.

Building or fixing custom checkout?

If your store accepts wallets but ops still reconciles by hand, contact us with your current gateway and pain point. We integrate GCash, Maya, and cards into custom order systems with webhook-driven state — see custom systems and web applications for scoped builds beyond product-page templates.