Piso WiFi Voucher Not Working: Expiry, Usage, Device, and Portal Checks

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. Voucher behavior depends on controller version and operator policy.

Step-by-step checklist

1. Re-enter the voucher exactly as issued.
2. Operator: check whether it exists, expiry/status and redemption history.
3. Confirm the customer is on the correct SSID/portal.
4. End stale sessions only through supported tools.
5. Create one new low-value test voucher to distinguish a single-code problem from a platform-wide problem.

What not to assume?

Do not clear sales/session databases as the first fix. Export/back up records first and isolate whether the problem is one voucher or every transaction. 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.

Four different reasons a valid-looking voucher can fail

The code can be mistyped or already used; it can be expired; it can exceed its maximum-user/device rule; or the portal/controller may be unable to reach the voucher/session database. Check the voucher record before issuing a replacement. If many newly generated vouchers fail at once, focus on the platform/database rather than individual customer devices.

Pause and expiration can change what “remaining” means

Current AdoPiSoft voucher settings can define expiration, pause permission, maximum users, and speed. A customer may see remaining time but still be outside the voucher’s allowed expiration window, or a voucher may be active on another permitted device. Explain the rate/voucher terms clearly before payment so support staff can distinguish a configuration rule from a technical failure.

Do not delete evidence before reconciling the sale?

Keep the voucher ID/code status, sales record, device/session record, and approximate payment time until the case is resolved. Clearing used vouchers or sales inventory may make later reconciliation harder. Staff accounts that only redeem or sell vouchers do not need permission to clear records.

Read the voucher status before issuing a replacement

Check whether the code exists, whether it was already activated, its start/expiry rules, maximum users/devices, assigned speed/data limits, pause status, and any linked session/account. If the customer copied the code from a screenshot, confirm ambiguous characters and whitespace. If the voucher was sold by a staff/reseller account, reconcile it with that sales record before creating new credit.

Replacement policy for genuine failures

Define how operators handle a valid paid voucher that fails because of system error. Preserve the original code/status, transaction proof, and failed-session evidence; then replace or restore value according to the published policy without reusing the same code in a way that can create duplicate access. If many vouchers from one batch fail, stop selling that batch and investigate the profile rather than handling every customer as an isolated incident.

What are the most common voucher checks?

Verify the exact code, batch/profile, activation state, expiry, redemption count, device/user limit, linked session/account, and controller time. Read the portal error instead of creating a replacement immediately.

Can a voucher fail because the customer changed devices?

Yes, if the voucher/profile is limited to a device or user identity. Check the configured sharing/user limit and whether the old session is still active.

Should the operator delete a failed voucher?

Usually not before diagnosis. The status is evidence for reconciliation. Mark/cancel/replace it using the platform-supported process after the cause and payment status are understood.

What if many vouchers from one batch fail?

Stop selling that batch, inspect its profile/expiry/rate settings, and test one controlled code. A batch-level problem should be fixed at the profile/configuration level rather than handled as dozens of unrelated customer cases.

Useful next steps

Worked scenario: voucher not working

Piso WiFi Voucher Not Working: Expiry, Usage, Device, and Portal Checks: voucher behavior depends on controller version and operator policy.

Illustrative case: A voucher works on the original device but not after changing the device’s network identity. Check binding and reuse policy before treating the code as stolen.

Documentation and scope

• AdoPiSoft Guide: customer accounts/voucher management context

Documentation and testing methodology