For customers, operators and technicians: A captive portal sits between a newly connected client and normal internet access. The network gives the client local addressing, detects or redirects an unauthenticated web request, presents payment/login/session controls, then authorizes traffic according to the controller’s policy.
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. Modern operating systems have captive-portal detection behavior, while vending platforms implement payment/session policy in their own way.
Step-by-step checklist
- Client associates to the Wi-Fi SSID.
- DHCP/IPv6 configuration supplies network parameters.
- The device performs a connectivity/captive-portal check.
- The user is directed or prompted to the local portal.
- Payment, voucher or account policy authorizes a session.
- The controller/firewall permits internet traffic until the session policy expires or is paused.
What not to assume
HTTPS is designed to resist silent interception. A legitimate hotspot should not ask users to install an unknown root certificate or ignore certificate warnings simply to browse the internet. 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.
What happens from Wi-Fi join to paid internet
The client associates to an access point, receives IP configuration from the hotspot network, and performs a connectivity check. Until authorized, the controller/firewall restricts normal internet traffic and presents or signals a captive portal. The user pays, enters a voucher, or signs into an account; the controller then changes policy for that session/device until the credit expires, is paused, or the authorization is otherwise removed.
Why HTTPS changes portal behavior
Secure websites authenticate the destination and are designed to prevent a hotspot from silently replacing them with a login page. Modern operating systems therefore use captive-portal detection and dedicated portal windows. A well-designed hotspot should not require users to bypass certificate warnings to get online.
The local portal can work during an internet outage
The portal lives on the local network, so it can remain reachable even when the ISP link is down. Platforms can use WAN-status checks to prevent or pause paid access during outages. For troubleshooting, this is useful: portal reachability proves local connectivity, while a failed external test points farther upstream.
Authorization state is the key concept
Before payment/login, the controller usually places the client in a restricted state with access only to local portal resources and any explicitly allowed services needed for payment or connectivity detection. After successful authorization, policy changes for that session/device/account. Expiry, logout, pause, device-identity change, or operator action can return the client to the restricted state without the Wi-Fi association itself disconnecting.
Why portal troubleshooting needs several layers
Wi-Fi association, DHCP, DNS, HTTP/HTTPS behavior, firewall/walled-garden rules, payment confirmation, and session authorization all happen at different layers. A portal window failing to pop up does not prove the controller is down, and a portal page loading does not prove the WAN works. Test local gateway/portal reachability, then public IP connectivity, then DNS, then authorization/payment. That sequence turns “portal broken” into a specific failure that can actually be fixed.
Frequently asked questions
Why can Wi-Fi show “connected” before payment?
Association to the AP only establishes the local wireless link. The controller can still restrict normal internet access until the client is authorized through payment, voucher, account, or another permitted method.
Why do modern phones use a special captive-portal window?
Operating systems probe connectivity and, when they detect a restricted network, open a small sign-in flow. This avoids requiring a hotspot to interfere with secure HTTPS sites.
What is a walled garden?
It is a restricted pre-authentication set of destinations/services that users can reach before full authorization, often including the local portal and required payment/connectivity endpoints. It should be as narrow as the service requires.
What does portal reachability prove during troubleshooting?
It proves at least some local Wi-Fi/IP path to the controller is working. It does not prove DNS, public internet, payment confirmation, or authorized-session forwarding. Test those separately.