Piso WiFi Pause Time: How It Works and How to Resume a Session

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. Use the portal controls shown by the installed platform. Do not assume menu names or time limits from another vendor.

Step-by-step checklist

1. Open the same captive portal used to start the session.
2. Look for Pause, Suspend, Pause Time or an equivalent control.
3. Confirm the portal reports the session as paused before disconnecting.
4. Return with the same device when possible, then use Resume/Continue.
5. If no pause control exists, the operator may have disabled it or the platform/version may not support it.

What not to assume

Pause limits and the number of allowed pauses are platform settings. Check the installed portal or operator configuration instead of assuming a universal duration. 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.

Pause behavior depends on the session type

Time credit, data credit, subscription access, and vouchers can have different pause and expiry rules. Current AdoPiSoft session settings allow operators to define pause limits and expiry rules for time, data, and time-with-data-capping sessions. Its voucher settings also include an Allow Pause option. That means a user should never assume that every paid session can pause, or that the pause limit on one machine applies to another.

Why a resumed session may appear missing

A hotspot may associate an active session with a device identity, account, cookie, voucher, or a combination of these. Changing phones, forgetting and rejoining the SSID, clearing browser state, or using a different private/randomized MAC can break that association depending on the platform. Before purchasing again, reconnect to the same SSID and portal, confirm the device identity settings have not changed, and ask the operator to compare session/payment logs.

Operator checklist for fair pause rules

Define pause limits, expiry, offline behavior, and reconnection rules before selling time. AdoPiSoft can pause active sessions automatically when internet connectivity is down and can resume sessions when users reconnect, depending on session settings. Test those behaviors after controller reboots, WAN outages, and access-point roaming so customers do not lose paid time because of infrastructure failures.

How to troubleshoot a pause dispute

Record the payment or voucher time, session start, expected remaining credit, device identity used by the platform, and the exact moment the user pressed Pause or disconnected. Then compare the customer view with the operator session record. A pause problem can be a policy problem, an identity problem, or a clock/expiry problem; those require different fixes. If the session expired while paused because the package has an absolute expiry, restoring “remaining minutes” may not be the same as extending the package validity.

Design pause rules customers can understand

Publish the rule before payment: whether pause is allowed, whether there is a maximum pause duration or number of pauses, whether package expiry continues while paused, and whether a returning device must use the same account or network-specific MAC. A simple rule reduces support disputes more effectively than a hidden technical setting. Operators should test pause, device sleep, Wi-Fi off/on, access-point roaming, controller reboot, and WAN outage separately because each event can exercise a different session path.

Frequently asked questions

Useful next steps