Piso WiFi is a prepaid public-access network model widely used in the Philippines. Use this hub to reach the correct customer portal or operator controls, plan the network, manage rates and sessions, and troubleshoot payment, portal, bandwidth, access-point, DHCP/DNS and recovery problems.
Start here
For customers
Use the captive portal for payment, voucher entry, remaining time and any pause/resume feature offered by that machine. You should not need the operator’s admin password. If the portal does not open, stay on the hotspot Wi-Fi, temporarily disable VPN/Private DNS if appropriate, and open the local portal supplied by the operator.
For operators
A stable deployment begins with clean network architecture: ISP modem/ONT → vending/controller WAN → controlled LAN → access points. Keep only one intended DHCP/routing authority per client network, separate management from customers where supported, and make backups before firmware, rate or network changes.
Piso WiFi operator guides
Troubleshooting
AdoPiSoft login details are platform-specific
AdoPiSoft documents 10.0.0.1/admin and an initial admin/admin sign-in for its machine-activation workflow. That information belongs to AdoPiSoft and should not be reused as an LPB, JuanFi, ISP-router or generic Piso WiFi password. Once an AdoPiSoft machine is commissioned, use the current administrator account configured on that installation.
How a Piso WiFi network fits together
A typical installation has several roles that search results often collapse into one “router”: the ISP modem/ONT supplies internet, the Piso controller enforces portal/payment/session policy, and one or more access points provide radio coverage. Some kits combine roles in one box; larger deployments separate them. The admin address belongs to whichever device/platform is doing management on that LAN, so 10.0.0.1 should be treated as a common configuration choice, not the definition of Piso WiFi.
| Layer | Main job | Common failure symptom |
|---|---|---|
| ISP modem/ONT | Internet handoff | All users offline even though local portal may open |
| Piso controller | DHCP/portal/session/payment policy | Portal, vouchers, timers or payments fail |
| Access point | Wi-Fi coverage/capacity | Weak/slow Wi-Fi in one area while wired internet is fine |
| Payment hardware/service | Coin/bill/digital payment input | Internet works but paid time is not credited |
AdoPiSoft and LPB are different systems
Do not assume that an AdoPiSoft address, menu, credential, backup file or session rule works on LPB. Identify the installed platform and version before attempting administrator recovery or configuration changes. For LPB machines, use the software/license source or machine vendor for the installed-build recovery procedure and preserve sales, voucher and network data before any reflash or reset.
Performance planning for a real hotspot
Size the network for peak users, not an empty-store speed test. Measure wired WAN capacity and latency, then design per-user shaping so uploads cannot saturate the connection. Use enough access points to keep clients at usable signal levels; prefer wired backhaul where practical. Crowded 2.4 GHz, hidden-node problems and overloaded wireless mesh links can make a fast ISP line feel slow.
Operator change-control checklist
- Record current software version, IP plan, WAN method, rates, portal theme and payment settings.
- Back up before upgrades, rate changes, LAN subnet changes or hardware replacement.
- Change one logical group at a time and run a complete customer transaction afterward.
- Keep a rollback path and off-device copy of the last known-good backup.
- Document which staff account changed what when multiple people administer the machine.
Customer privacy and safe payments
Public Wi-Fi operators should collect only the information required for service, support and applicable legal/accounting needs. Keep admin and transaction data protected, limit staff permissions, and avoid exposing customer device history publicly. GCash, Maya or other wallet integrations should never ask the hotspot operator to collect a customer PIN, OTP or account password. Use the payment provider/platform’s supported confirmation mechanism.
Business and policy basics
Display rates, time/data limits, pause/expiry rules and refund/support contact clearly before payment. Use an ISP plan and deployment permitted for the intended use, keep equipment electrically safe and weather-protected, and follow applicable Philippine privacy, consumer, telecommunications and local business requirements. For a specific commercial deployment, confirm the ISP terms, software licensing, privacy obligations, consumer requirements, and local business rules that apply to the location and service model.
Frequently asked questions
Is 10.0.0.1 always the Piso WiFi portal?
No. It is common and AdoPiSoft documents it in current guides, but a private LAN can be changed. Read the actual gateway/platform configuration.
Can users change Piso WiFi settings?
Ordinary users should only see customer/session controls. Network rates, admin accounts, WAN/LAN configuration and payment settings belong to authorized operators.
What should an operator back up?
At minimum: controller configuration, rate/voucher settings, network addressing, custom portal assets where supported, and any records required for legitimate business reconciliation. Store backups securely off the machine.
Why does a portal open but there is no internet?
The local controller can be healthy while the upstream WAN/ISP is down. Test each layer separately rather than resetting the portal.
How to use this Piso WiFi section
If you are a customer, start with the captive portal, pause/session, voucher, or “portal not opening” guides. If you operate the machine, start with the exact platform, network layout, backup, security, bandwidth, and payment guides. A customer should never need the operator super-admin password to buy or use internet time, while an operator should not troubleshoot a WAN outage from a customer payment screen.
Current AdoPiSoft details that are useful in real installations
AdoPiSoft currently documents 10.0.0.1/admin for machine activation and lists admin / admin for that initial activation workflow. Its network setup also offers several LAN schemes, including 10.0.0.1/20 as the most commonly used option plus 20.0.0.1/20, 192.168.11.1/24, and 192.168.22.1/24. Those are configurable network choices, not a rule that every Piso WiFi machine must use 10.0.0.1.
The platform also exposes controls for customer accounts, vouchers, bandwidth limits, session expiration/pause behavior, admin permissions, backups, system logs, sales inventory, network interfaces, and access-point setups. That means a reliable deployment should be documented like a small managed network rather than treated as one “router page.”
A practical launch checklist for a Piso WiFi operator
- Confirm the ISP plan/backhaul is stable and appropriate for the intended use.
- Document the modem/ONT, controller WAN, controller LAN, switch, access points, and payment hardware.
- Use a non-conflicting LAN and confirm every customer device receives the intended IP, gateway, and DNS.
- Change initial administrator credentials and create limited staff accounts where supported.
- Configure rates, vouchers, expiry, pause rules, bandwidth, and outage behavior before accepting public payments.
- Back up the working configuration and store a copy off the controller.
- Test one new customer from Wi-Fi join through payment, browsing, pause/reconnect, and expiry.
- Test power loss, WAN outage, and controller reboot so recovery behavior is known before a real failure.
What to measure before adding more users
Measure wired WAN download, upload, loaded latency, and packet loss, then repeat from Wi-Fi near each access point. Count peak concurrent users rather than relying on a quiet-hour speed test. If the WAN is healthy but one area is slow, investigate radio coverage, interference, channel use, and backhaul. If all areas slow down together at peak hours, investigate upstream capacity and shaping. If only authenticated customers are slow while the local admin interface is responsive, check platform bandwidth rules.
Payments, vouchers, and customer disputes
Treat the payment record, voucher/session authorization, and internet path as separate pieces of evidence. A successful wallet or coin transaction does not automatically prove that the controller credited the correct session. Preserve the transaction time, amount, voucher/session record, and device/account identifier needed for support until the issue is reconciled. Customers should never be asked for a wallet PIN, password, or OTP.
Maintenance that prevents common failures
- Review storage health and free space on controllers that use SD cards or flash storage.
- Keep network and vending software on supported releases from the correct vendor.
- Inspect power supplies, UPS/surge protection, ventilation, coin hardware, and Ethernet connectors.
- Check access-point client load and peak-hour channel conditions.
- Review admin accounts and remove old staff/vendor access.
- Keep a dated change log for rates, network settings, software updates, AP replacements, and payment changes.
- Run a complete customer test after every major change.
Choose the next guide by symptom
If the portal does not appear, use the captive-portal guide. If clients get no proper IP or domains fail, use the DHCP/DNS guide. If paid time disappears, use the session-expired and randomized-MAC guides. If the network is slow, use the bandwidth and slow-internet guides. If coverage is weak, use the router-versus-access-point and AdoPiSoft access-point guides. If the machine was recently reflashed, updated, or moved to new storage, review backup/restore and activation before changing unrelated settings.