For Piso WiFi operators: A reliable Piso WiFi deployment has four separate layers: internet/WAN, the vending/controller platform, captive-portal/session logic, and Wi-Fi access points. Build and test each layer independently before taking payments.
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. AdoPiSoft documents WAN selection, LAN setup and multiple LAN addressing options; other controller platforms have their own architecture.
Step-by-step checklist
- Choose a legal, stable ISP/backhaul and document its modem/ONT handoff.
- Install the controller/vending system and set a private LAN that does not conflict with the upstream router.
- Connect a dedicated access point for real coverage; do not rely on a weak controller-board radio for a commercial area.
- Configure captive portal, rates/vouchers, session behavior and fair bandwidth policy.
- Protect the admin network/credential and change documented factory credentials after commissioning.
- Test new users, returning users, payment, power recovery, WAN failure, DNS, device isolation and session expiry before launch.
What not to assume
Do not copy WAN VLAN, PPPoE, APN or optical settings from another operator. Your ISP/controller combination determines those values. 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.
Build the network in dependency order
Start with the ISP handoff and confirm stable wired internet before adding captive-portal logic. Connect the controller WAN to the modem/router, configure the controller LAN on a non-conflicting private subnet, then add the access point or switch layer. Only after clients receive the correct IP, gateway, and DNS should you enable payment, vouchers, rate rules, and bandwidth shaping. This order makes every failure easier to isolate.
Choose the LAN deliberately
AdoPiSoft currently offers multiple LAN schemes in its network setup, including 10.0.0.1/20, 20.0.0.1/20, 192.168.11.1/24, and 192.168.22.1/24. The important design rule is to avoid overlap with the upstream router and any VPN or management network. A private range should be chosen for compatibility and clarity, not because a tutorial says every machine must use 10.0.0.1.
Commission the payment path last
Before accepting money, test one new customer from association through captive portal, payment, session start, pause/resume if offered, expiry, and reconnect. Then simulate WAN loss and power recovery. A machine that takes payment while internet status is down creates avoidable disputes; platforms that support online-status checks should be configured and tested so customers are not charged for a service the controller knows is unavailable.
Address plan and physical layout checklist
Document the upstream modem/ONT subnet, controller WAN, controller LAN, DHCP pool, reserved/static management addresses, access-point management addresses, and any management VLAN. Keep the customer DHCP pool away from statically assigned infrastructure addresses. Label both ends of WAN, LAN, AP, coin/payment, and power cables. If a second building or outdoor AP is involved, document the backhaul type and surge/grounding plan as well as the logical IP path.
Acceptance test before opening to customers
Use at least two different customer devices. Verify SSID discovery, DHCP, portal detection, a low-value payment or voucher, DNS, normal browsing, video/voice latency, pause/resume if offered, expiry, reconnect, and isolation between customer devices where supported. Repeat after a controller reboot and after a temporary WAN disconnect. Finally, confirm the operator can restore the last known-good backup without guessing which file belongs to which machine.
Frequently asked questions
Should the Piso controller and ISP router use the same subnet?
Normally they should not create overlapping routed LANs. If the controller WAN sits behind an ISP router, give the controller customer LAN a different, non-conflicting network unless the platform architecture explicitly requires another design.
Do I need a separate access point?
A small controller may provide Wi-Fi, but a commercial area often benefits from purpose-built APs placed for coverage and capacity. The AP should normally bridge the customer network rather than create an unintended second NAT/DHCP boundary.
What should be tested before accepting the first payment?
Test WAN stability, client DHCP/DNS, portal detection, payment or voucher credit, browsing, pause/expiry rules, bandwidth, customer isolation, controller reboot, WAN outage behavior, and one restore-ready backup.
Can I copy another operator’s WAN, VLAN, or PPPoE settings?
No. WAN authentication, VLANs, optical settings, APNs, and provider requirements belong to the specific ISP and equipment. Copying them can break service or interfere with provider-managed voice/IPTV features.