For users and operators: The customer portal starts/redeems sessions; the admin portal changes business/network settings. They may share a host/IP but must not be treated as the same permission level.
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 demonstrates granular admin permissions; other platforms implement roles differently.
Step-by-step checklist
- Customers should use only the captive/user portal controls exposed to them.
- Operators should reach admin functions only from authorized management access.
- Secondary staff accounts should get only necessary permissions.
- Do not place admin credentials in signs, QR codes or public portal HTML.
- Audit/reset shared credentials after staff changes.
What not to assume
A public portal link is safe to advertise; an admin URL/password is not. Never ask ordinary customers to log into the router/controller admin panel to buy or resume time. 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 customers should be able to do
A customer portal can present rates, payment controls, voucher entry, account login, remaining balance/time/data, and session controls such as pause when enabled. It should not expose WAN/LAN configuration, admin-account management, backups, software updates, logs, or unrestricted sales data. If a normal customer can reach those controls without authorization, treat it as a security issue.
What administrators manage
Operator dashboards commonly control interfaces, rates, payment portals, vouchers, bandwidth, user/session records, portal appearance, backups, system logs, updates, and staff accounts. Current AdoPiSoft permissions show how granular this can be: a secondary admin can be permitted to manage vouchers or view sales without receiving network-interface or restore permissions.
Support should never require sharing the super-admin password
For staff or a technician, create a limited account when the platform supports it, then remove or disable that access afterward. Customers should provide transaction/session details, not admin credentials. Keeping the two roles separate protects both the business configuration and customer data.
Keep customer and operator actions clearly separated
The customer portal should expose only what a user needs: rates, voucher/payment entry, remaining credit, session controls, basic account information where supported, and help/contact. The operator interface can expose sales, users, vouchers, rates, network interfaces, access points, bandwidth, backups, software updates, logs, and administrator accounts. Mixing those roles increases both confusion and security risk.
Support without asking for admin secrets
A customer reporting lost time or a failed payment should provide transaction/voucher details, device/session information needed by the platform, approximate time, and symptom—not the operator password. Likewise, support staff who only reconcile sales do not need full network or backup privileges. Use granular admin roles when supported and keep an audit/change log for actions that alter rates, customer credit, or system configuration.
Frequently asked questions
What should a customer portal contain?
Only customer-facing functions such as packages/rates, payment or voucher entry, remaining credit/session controls, account features where supported, terms, and support information. It should not expose operator configuration.
What belongs in the operator portal?
Authorized functions can include sessions/users, vouchers, rates, sales, payment settings, network interfaces, APs, bandwidth, backups, updates, logs, and admin accounts, depending on the platform and staff role.
Should support staff use the super-admin account?
Not if granular roles are available. Give support/sales staff the minimum permission needed to inspect or correct customer issues while protecting network, backup, software-update, and administrator controls.
What information can a customer safely provide for support?
A transaction/voucher reference, approximate time, package purchased, portal message, and the device/session identifier required by the platform are usually more relevant than any administrator credential. Never ask for wallet PINs or OTPs.
How to validate the explanation on your own network
For Piso WiFi User Portal vs Admin Portal: What Each One Is For, look for an observable before/after signal: route table, lease, DNS answer, gateway reachability, radio association, WAN status, application behavior, or latency under load. A setting is understood when you can predict which observation it should change and which observations it should leave alone.
Keep recovery access available
When a change can affect Wi-Fi, LAN addressing, routing, or admin access, keep an Ethernet path or documented recovery method available before pressing Save.