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.

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.

Voucher settings that materially change the customer experience

AdoPiSoft vouchers can include download/upload speed, expiration, pause permission, maximum users per voucher, and a price. Those fields solve different problems. Expiration controls how long the voucher remains usable after its defined period; maximum users controls sharing; per-voucher bandwidth can differ from the network default; and pause permission affects whether time continues while a user is not actively online.

Test one voucher before printing or selling a batch

Create a single low-value voucher and redeem it from a customer device. Verify the displayed time/data, speed limit, pause behavior, expiry, device-sharing behavior, and sales record. Then disconnect and reconnect the client to confirm the session survives exactly as intended. A batch of incorrectly configured vouchers is harder to reconcile than one failed test code.

Separate staff permissions

Current AdoPiSoft admin accounts can be restricted by permission, including voucher generation, viewing or clearing vouchers, rate changes, bandwidth management, sales inventory, backups, and system actions. Staff who only sell or monitor vouchers should not automatically receive network-interface, restore, update, or super-admin permissions. Least privilege reduces both accidental changes and account abuse.

Voucher lifecycle controls worth documenting

For every voucher profile, record when validity begins, when it expires, whether unused codes expire, whether a code can be shared, how many devices/users may use it, whether pause is allowed, and whether speed/data limits override the normal customer policy. Keep the printed or displayed terms aligned with the actual configuration. If a voucher is intended for resale by staff or partner shops, use a separate batch or permission model so sales can be reconciled without giving those sellers system-level access.

How to investigate a code that “does not work”?

Check the exact code and creation batch, current status, activation time, expiry, redemption count, assigned session/device if applicable, and whether the portal reports a specific reason. A typo, already-redeemed code, expired profile, device limit, or account/session mismatch can look identical to the customer. Never solve a single-code problem by clearing the entire voucher database. Preserve the failed record long enough to understand the cause and prevent a repeat.

Can one voucher be used by several devices?

Only if the configured voucher/user limit allows it. Treat maximum users/devices as part of the product terms and test it before selling a batch.

Why does a new voucher show as expired?

Check the voucher profile validity, creation/activation rule, controller clock/time zone, and whether the code inherited an expiry setting from its batch/profile. Do not regenerate a whole batch until the reason is known.

Should voucher sellers have full admin access?

No. Use the narrowest staff permission available. A seller who generates or checks vouchers normally does not need network-interface, backup/restore, software-update, or administrator-account privileges.

What should be printed with a voucher?

Include the code, package value/time/data, important expiry/pause/device rules, the correct SSID/portal instructions, and a support contact. Do not print operator credentials or internal management addresses that customers do not need.

Useful next steps

Piso WiFi hubOpen the complete operator and customer guide index.Piso WiFi troubleshootingSeparate WAN, portal, payment and client problems.Piso WiFi securityProtect admin access, customer traffic and backups.DHCP & DNS checksFix addressing and name-resolution problems methodically.

Worked scenario: voucher settings

Piso WiFi Voucher and Rate Settings Guide: adoPiSoft documents permissions for voucher generation, coin/bill rates, bandwidth and sales records; exact voucher screens vary by version.

Illustrative case: A voucher has unused minutes but its expiry has passed. Check the package’s actual validity rules before issuing another code.

Documentation and scope

Documentation and testing methodology