Piso WiFi Not Working? Captive Portal, Internet, Voucher, and Router Checks

Start with the correct platform and role

Piso WiFi is a category of prepaid/captive-portal deployments, not one standardized router firmware. A vending/controller platform, the upstream ISP router, and separate Wi-Fi access points can all have different addresses and credentials. The customer portal and the operator admin page are also different security roles. The layer-by-layer method applies broadly; platform menu names do not.

Step-by-step checklist

1. Check power and physical link LEDs before changing software settings.
2. Test internet from the controller/upstream router without the captive portal if your platform provides a safe diagnostic method.
3. Confirm clients receive an IP, gateway and DNS.
4. Open the captive portal directly and test a free/test session if available.
5. Test coin/bill/voucher/payment as a separate layer.
6. Check controller logs, storage and software version before factory-resetting anything.

What not to assume

Do not wipe the controller because one phone fails. First test another customer device and rule out private DNS, VPN, stale captive-portal state or randomized-device identity. Likewise, 10.0.0.1 is only a private IPv4 address. Its presence does not identify the software by itself, and changing the address does not change how the vending/session system works.

Customer-side checks

• Stay connected to the Piso WiFi SSID and turn off a VPN temporarily if the portal will not open.
• Do not type operator credentials into a public search result.
• If a portal fails only on one phone, test browser captive-portal state, Private DNS, MAC randomization and date/time before blaming the machine.
• Keep payment/voucher proof until the session is confirmed.
• For pause/resume or voucher issues, use the same device when the platform ties sessions to a device identity.

Operator-side checks

Troubleshoot in layers. Confirm stable power, then WAN internet, controller WAN/LAN interfaces, DHCP/DNS, access-point reachability, captive-portal service, payment input, and finally the user/session database. If every client fails, focus on shared infrastructure. If one client fails, compare that client with a working one before rebooting or resetting the system.

Security and reliability

• Change initial/factory administrator credentials after setup.
• Keep customer traffic separated from the management LAN where the platform supports it.
• Use official software updates and make backups before upgrading.
• Protect the controller, coin acceptor and power hardware from moisture, heat and unstable power.
• Use a proper access point for coverage and capacity rather than assuming the controller board’s radio can serve a busy area.
• Never expose the admin dashboard directly to the public internet through an unrestricted port forward.

Network architecture matters more than the portal IP

A healthy installation normally has a clear upstream/downstream design: ISP modem or ONT, then the device responsible for routing/session control, then switches/access points serving customers. Avoid accidental double DHCP, overlapping subnets and a consumer Wi-Fi router running NAT behind the vending controller unless the design intentionally calls for another routed boundary. Label WAN and LAN cables so a maintenance visit does not silently reverse them.

Payment and session integrity

When money or vouchers are involved, troubleshoot payment confirmation separately from internet access. Keep transaction/session logs long enough for legitimate support and reconciliation, but do not collect secrets that the payment provider does not require. For digital wallets, the operator should never request a customer PIN or one-time password. Test duplicate payments, failed callbacks, controller restarts and recovery after power loss before advertising a new payment option.

Maintenance checklist

• Keep the controller/router and access-point software on supported releases from the official vendor.
• Back up configuration before updates and store a copy away from the machine.
• Check power supply, ventilation, storage health and cable condition.
• Review peak-hour WAN utilization, loaded latency and access-point client counts.
• Audit admin accounts after staff/vendor changes and remove access that is no longer needed.
• Test the customer journey—from joining Wi-Fi through payment, portal access, session expiry and reconnect—after every major change.

Check the exact platform before using credentials or reset steps

Piso WiFi systems are not one standardized firmware. Match the machine name, installed version, controller type and local network before applying a login, password-recovery or reset instruction. If the device label or installed platform shows a different address or workflow, use the information for that exact machine rather than forcing a value from another platform.

Use the symptom to choose the layer

If the SSID is missing, start with power and the access point. If the SSID is visible but clients receive no valid IP, inspect DHCP and the controller LAN. If the portal opens but paid sessions have no internet, inspect WAN status, authorization, and DNS. If coins or digital payments register but time is not credited, keep the payment/session database separate from the internet path. A single phrase such as “Piso WiFi is down” is not enough to choose a fix.

Check the controller before resetting it

Current AdoPiSoft dashboards expose internet status, WAN/LAN information, uptime, RAM, storage, and other system health indicators. Those observations are more useful than an immediate factory reset. Low storage, repeated power loss, a failing SD card, an offline WAN, or a disconnected interface can all produce customer symptoms while the portal still partially works.

One-device failures are different from whole-site failures

When only one phone fails, compare it with a working client. Check VPN, Private DNS, cached captive-portal state, randomized MAC behavior, and whether the client received the same gateway/DNS. When every client fails, focus on common infrastructure: controller, WAN, access point, switch, power, DHCP, and payment services.

Fast failure matrix

No SSID: check AP power/uplink/configuration. SSID but no IP: check controller LAN, DHCP, VLANs, and accidental second DHCP servers. Valid IP but no portal: check gateway reachability, captive-portal service, client VPN/Private DNS, and portal detection. Portal works but no public internet: check WAN, DNS, authorization, and upstream routing. Payment accepted but no time: check payment callback/input, session creation, logs, and the customer identity used by the system.

Collect evidence before rebooting

Record dashboard internet status, WAN/LAN addresses, uptime, storage state, recent errors, affected AP, client IP/gateway/DNS, and whether another device works. Rebooting can temporarily clear a symptom while deleting the timing needed to diagnose it. Use a reboot after evidence is captured and when it tests a specific theory; reserve factory reset or reflash for documented recovery situations where the configuration can be rebuilt.

Frequently asked questions

Useful next steps