For operators: Treat coin detection as a hardware/input problem before changing Wi-Fi settings. Check power, pulse/output wiring, configured denomination/rate and the controller input logs.
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. Hardware wiring differs by controller/coin acceptor; follow the kit vendor diagram.
Step-by-step checklist
- Power off safely before inspecting wiring.
- Check coin acceptor supply voltage and common ground per hardware documentation.
- Inspect signal/pulse wiring and loose connectors.
- Confirm denomination/rate settings in the controller.
- Use a known valid coin and watch the controller/input log.
- Replace/test the acceptor separately if pulses never reach the controller.
What not to assume?
Do not guess voltages or short signal pins. Coin acceptors and controller boards can use different electrical interfaces; use the exact hardware wiring diagram. 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.
Separate the coin acceptor from the session system
A coin path has mechanical, electrical, pulse-input, rate-mapping, and session-credit stages. First confirm the acceptor has stable power and physically recognizes the denomination. Then verify that the controller input receives the expected pulse/signal. Only after that should you inspect how the platform maps the pulse to a peso value and time/data credit.
Intermittent coins often point to hardware or power
Dirty mechanisms, loose connectors, marginal power supplies, vibration, and worn coin acceptors can produce inconsistent pulses. If software records some coins correctly and misses others, preserve the logs and inspect the physical/electrical path before changing rate tables. If no input is ever recorded, check wiring and the configured payment portal/input assignment.
Reconcile money and credits after repairs
Test with known denominations and a low-value session. Confirm the amount recorded in sales inventory matches the physical payment and that the customer receives the expected credit exactly once. After any wiring or input change, test duplicate pulses and rapid consecutive coins so one physical payment cannot create missing or duplicate credit.
Separate mechanical, electrical, and software faults
Test whether the coin physically travels through the acceptor, whether the acceptor has stable power/ground, whether its pulse/output changes when a valid coin is inserted, whether the controller input sees that signal, and finally whether the configured coin value maps to the intended rate/time. A jammed acceptor and a wrong pulse-to-value mapping can produce the same “no credit” complaint but require completely different repairs.
Protect sales data while testing hardware
Use a maintenance/test procedure that cannot silently add real customer credit or corrupt sales records. Record the number and denomination of coins used for the test, then compare hardware counts with platform sales/coin logs if available. After repair, test several accepted coins, rejected/invalid coins, rapid successive inserts, and controller restart behavior. Secure the acceptor and cash box physically; software permissions do not protect against tampering with the payment hardware itself.
How do I know whether the fault is the coin acceptor or software?
Trace the path in order: mechanical coin acceptance, acceptor power/ground, output pulse/signal, controller input, then pulse-to-value/rate mapping. Stop at the first layer that fails.
Why can some coin denominations work while others do not?
The acceptor can have denomination-specific calibration or pulse patterns. Check its programming, coin condition, supply voltage, wiring, and the controller mapping for each denomination rather than assuming the whole input is dead.
Can I clear sales logs after repairing the coin slot?
Not until test inserts and any customer disputes are reconciled. Keep enough before/after evidence to compare physical coins, controller input, credited time/value, and sales records.
What should be secured physically?
Protect the acceptor, cash box, controller input wiring, power supply, and enclosure. A strong web password cannot stop someone with uncontrolled access to payment hardware or internal wiring.
Useful next steps
Worked scenario: coin slot not detecting
Hardware wiring differs by controller/coin acceptor; follow the kit vendor diagram.
Illustrative case: Coins register physically but no credit reaches the controller. Check the approved wiring and event records with power isolated where required; do not keep accepting payments during an unresolved credit fault.
Documentation and scope