For users and operators: 10.0.0.1 is a private address commonly used by Piso WiFi captive-portal/vending systems, but it is not a universal admin address for every machine. AdoPiSoft officially documents 10.0.0.1/admin for its WiFi vending-machine activation workflow.
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. These AdoPiSoft details apply to the documented AdoPiSoft workflow; other Piso WiFi platforms and firmware can use different paths and credentials.
Step-by-step checklist
- Connect to the actual Piso WiFi network.
- For a customer portal, first try the portal presented automatically by the network; if the operator uses 10.0.0.1, type http://10.0.0.1 in the address bar.
- Operators using AdoPiSoft can follow its official guide for http://10.0.0.1/admin.
- If the address fails, read the device default gateway instead of guessing.
- Never enter an operator/admin password into a third-party website or search-result form.
What not to assume?
AdoPiSoft’s documented admin/admin credential is scoped to its documented activation workflow. It must not be copied onto LPB, JuanFi, a TP-Link router, or an arbitrary Piso WiFi build. 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.
Customer portal, router page, and vending admin are three different things
When a phone joins a Piso WiFi network, 10.0.0.1 can represent the local gateway or captive-portal endpoint, while an operator path such as 10.0.0.1/admin can expose a protected vending dashboard on a specific platform. The upstream internet router can still have a completely different address. If a page asks for payment or shows remaining time, it is probably the customer portal; if it exposes rates, interfaces, vouchers, sales, backups, or admin accounts, it is an operator interface. Customers should not attempt administrator sign-in.
What AdoPiSoft currently documents?
AdoPiSoft documents 10.0.0.1/admin for machine activation and an initial admin / admin sign-in in that workflow. Its current network guide also lists 10.0.0.1/20 as the most commonly used LAN option alongside other configurable subnets. That makes 10.0.0.1 a strong AdoPiSoft context, not a universal Piso WiFi credential. If the machine uses another platform or the operator changed the LAN, read the active gateway and installed platform before troubleshooting.
If 10.0.0.1 opens but the internet still does not work
A working local page proves only that the client can reach the local controller. Check WAN status next. AdoPiSoft exposes WAN and LAN information on its dashboard, including internet status and interface information. If the portal loads while WAN internet is down, resetting customer devices will not repair the upstream connection. If WAN is healthy but customers remain offline, move to DHCP/DNS, session authorization, and access-point checks.
Before changing anything on 10.0.0.1
Capture four values from the connected device: its IP address, subnet/prefix, default gateway, and DNS server. If the gateway is not 10.0.0.1, do not force a static address simply to make a tutorial work. The customer device may be on another subnet, behind a separate access point/router, or connected to the wrong SSID. If the gateway is 10.0.0.1 and the portal opens, the local path is healthy enough to reach the controller; a missing internet connection should then be investigated upstream rather than treated as a login-address failure.
Safe administrator handoff
For a business installation, record which person owns the local admin account, the platform manager/cloud account if one exists, the recovery email, the machine/device ID, the LAN plan, and the location of the latest backup. Do not store the actual password in customer-facing notes. When staff change, rotate local and platform credentials and review delegated accounts so former installers or employees do not retain unnecessary access.
Why does 10.0.0.1 open a payment page instead of router settings?
On a Piso WiFi network, 10.0.0.1 can be the customer portal or controller gateway rather than the upstream ISP router. A payment/time screen is a customer-facing captive portal. Do not enter operator credentials there; use the platform-specific admin path only if you are the authorized operator.
Can I use 10.0.0.1 when my phone shows another gateway?
Usually no. The active default gateway shown by the connected device is the better clue. A changed LAN, extra router, different controller platform, or separate AP network can move management away from 10.0.0.1.
Does 10.0.0.1 prove the machine is AdoPiSoft?
No. Private IP addresses can be reused by unrelated products. AdoPiSoft documents this address in its own setup, but the IP alone cannot identify the software or a valid password.
What should an operator record before resetting a 10.0.0.1 machine?
Record the platform/version, machine or Device ID, WAN/LAN values, rates, vouchers/sessions, payment settings, AP layout, administrator ownership, and a compatible backup. Reset only when the recovery procedure for that exact platform is known.