A Piso WiFi site should advertise GCash or Maya only when the installed vending platform or payment add-on explicitly supports the integration you are using. This page is an evaluation checklist; it does not assume that every Piso WiFi controller has a built-in GCash/Maya connector.
1. Verify that the platform actually supports the payment method
Start with the vending/controller vendor’s current documentation, supported add-on list, or API/payment-provider documentation. Confirm whether the integration uses a supported QR flow, API, merchant account, webhook/callback, wallet balance, or a separate third-party module. A generic captive portal that can display a QR image does not by itself prove automatic GCash or Maya session credit.
2. Define the exact payment-to-session mapping
Write down the expected mapping before testing: for example, which payment amount corresponds to which time/data package, whether fees are deducted, whether partial/over-payments are accepted, and whether a payment can credit more than one session. The controller should not rely on a customer-entered “I paid” button as proof of settlement.
3. Test success, delay, failure, and duplicate callbacks
| Test | Expected result |
|---|---|
| Successful payment | One confirmed transaction creates exactly one intended session credit. |
| Delayed callback | The portal stays pending and does not issue duplicate time while the payment provider is still confirming. |
| Failed/cancelled payment | No paid session is credited. |
| Callback is delivered twice | The integration treats the provider transaction ID idempotently and credits the customer only once. |
| Customer reconnects after payment | The credited session remains tied to the controller’s documented account/session identity rather than being lost or duplicated. |
4. Keep payment confirmation separate from Wi-Fi/network health
A customer can pay successfully while the controller has no upstream internet, and the network can be healthy while a payment callback fails. Keep those as separate status checks. If the portal receives confirmed payment but cannot start a session, investigate the controller’s payment/session logic. If the session starts but internet access fails, move to the dedicated DHCP/DNS/WAN troubleshooting guides instead of mixing network repair into the payment workflow.
5. Reconcile controller records with provider records
At the end of a test period, compare the payment provider’s transaction identifiers, amounts, statuses, timestamps, and refunds with the controller’s credited sessions. Differences should be explainable. Keep a process for correcting a paid-but-not-credited customer without manually exposing wallet credentials.
Security and privacy rules
- Never ask customers for their GCash/Maya PIN, password, OTP, or recovery code.
- Use the payment provider’s supported authentication/checkout flow rather than collecting wallet secrets in the captive portal.
- Restrict API keys/webhook secrets to the server/controller component that actually needs them.
- Do not place merchant secrets, transaction tokens, customer phone numbers, or account identifiers in public screenshots.
- Log enough transaction metadata for reconciliation, but keep retention and access appropriate to the business and jurisdiction.
Go-live decision
Do not advertise automatic GCash/Maya acceptance until you can complete a small test matrix for success, failure, timeout, duplicate notification, reconnect, and refund/manual correction. If the installed platform has no documented integration, keep payment manual or use a supported provider/module rather than presenting a custom workaround as an official feature.
Useful next steps
Worked scenario: gcash maya payments
GCash and Maya Payments for Piso WiFi: Integration Checklist: do not infer a specific GCash/Maya integration from a generic Piso WiFi installation; check the current vending software/payment add-on.
Illustrative case: A payment confirmation arrives late after the customer retries. Reconcile transaction IDs and platform records before issuing duplicate credit; never request a wallet PIN or OTP.
Documentation and scope