For customers and operators: Modern phones can use a private/randomized Wi-Fi MAC address. If a Piso WiFi platform associates paid time or vouchers with device identity, changing that identity can make a valid session appear missing even though the payment record still exists.
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. Private/randomized MAC behavior is controlled by the client operating system; how the hotspot maps sessions is platform-specific.
Step-by-step checklist
- Do not disable privacy features globally as a first step.
- Customer: reconnect to the same SSID and check whether the phone preserved the network-specific private address.
- Operator: compare session/payment logs before issuing a replacement credit.
- Check whether the controller identifies sessions by MAC, account, voucher or another token.
- If a stable device identity is required by the platform, explain the network-specific setting and privacy tradeoff clearly to the customer.
- Retest after OS updates because client privacy behavior can evolve.
What not to assume?
A randomized/private MAC is a privacy feature, not malware or proof that the customer is abusing the network. Change it only when necessary for a documented hotspot/session compatibility issue. 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.
Private MAC addresses are normal client privacy behavior
Modern phones can use a network-specific randomized/private Wi-Fi MAC address instead of the hardware MAC. That behavior reduces passive tracking across networks. It is not evidence of abuse. A problem appears only when the hotspot binds paid time or device authorization to an address that the phone later changes.
Preserve privacy unless the platform truly requires a stable identity
Ask the customer to reconnect to the same SSID and check whether the device kept the same network-specific private address. Do not tell users to disable randomized MAC globally. If the platform requires a stable identity, explain the network-specific setting and why it is needed, then retest the session. Account/voucher-based identity can reduce dependence on a hardware-like MAC.
Operator logs should distinguish identity from payment
Before replacing credit, compare the paid transaction with the session/device record. A changed MAC can create a new device record while the payment remains valid. Keep enough evidence to reconcile the case without publishing customer device identifiers or retaining them longer than necessary for legitimate operation.
How do I compare device identity safely?
Use the operator interface to compare the session/device identifier involved in the payment with the identifier presented after reconnect. Ask the customer to check only the network-specific private-address setting for this hotspot, not to reveal unrelated device identifiers. If the platform supports accounts, vouchers, or cookies that survive normal MAC privacy behavior, prefer those mechanisms where they meet the business requirement.
When a phone changes its private address?
Operating systems may keep a stable randomized address per SSID for long periods or may rotate under certain settings/versions. A network reset, “forget network,” privacy-mode change, or switching between similarly named SSIDs can also create a new identity. Design support rules around proof of payment/session rather than assuming a physical MAC uniquely represents a person. Avoid permanent customer tracking beyond what is necessary to provide and support the service.
Is a randomized/private MAC address suspicious?
No. It is a normal privacy feature on modern devices. Trouble occurs only when the hotspot relies on an address that changes and cannot map the returning client to its paid session.
Should users disable private MAC globally?
No. If the hotspot needs a stable network-specific identity, change only the setting for that SSID when truly necessary and explain the reason. Prefer account/voucher mechanisms that tolerate normal privacy features when possible.
Can forgetting the Wi-Fi network change session identity?
Depending on the operating system/settings, forgetting and rejoining can alter stored portal state or network-specific identity. Compare the operator session/device record before assuming paid credit disappeared.
How should operators handle identity logs?
Use them only as needed to provide, secure, troubleshoot, and reconcile service. Do not publish device identifiers or treat a MAC address as proof of a person’s real-world identity.
Useful next steps
Worked scenario: randomized mac session issues
Private/randomized MAC behavior is controlled by the client operating system; how the hotspot maps sessions is platform-specific.
Illustrative case: A phone changes its private Wi-Fi MAC and appears as a new customer device. Explain the identity change and apply the platform’s legitimate session-recovery policy.
Documentation and scope