For Piso WiFi operators: Voucher/rate design should be tested as a transaction workflow: create a small rate, issue one voucher, redeem it as a customer, verify time/data behavior, then scale up. Menu names and pricing logic are platform-specific.

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 permissions for voucher generation, coin/bill rates, bandwidth and sales records; exact voucher screens vary by version.

Step-by-step checklist

  1. Back up the current configuration and export sales/rate data if the platform supports it.
  2. Create a low-value test rate or voucher profile.
  3. Define whether the product is time-based, data-based, subscription/account-based, or a platform-specific hybrid.
  4. Redeem the test voucher from a separate customer device.
  5. Confirm expiry, pause/resume behavior, bandwidth policy and accounting.
  6. Only then publish the full rate table and train anyone with delegated admin access.

What not to assume

Keep a clear distinction between customer-facing prices and internal admin permissions. Do not give voucher/sales/reset permissions to accounts that only need to monitor sessions. 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.

Source and verification

Primary reference for the claims scoped above: AdoPiSoft Guide: Admin Accounts and permissions. Where no first-party documentation supports a claimed default, this guide deliberately tells you to verify the installed platform instead of repeating an unsourced password.

Frequently asked questions

Is 10.0.0.1 the login for every Piso WiFi machine?

No. It is common in some deployments, including documented AdoPiSoft configurations, but the LAN address is configurable and other platforms can differ.

Is there one default Piso WiFi password?

No. Credentials belong to a platform/version/installation. We publish one only when a current source for that specific platform documents it.

Should a customer open the admin panel?

No. Customers use the captive/user portal. The admin panel is for the operator or authorized staff.