Small stores often adopt this simple network layout: a single broadband line connects to a router, serving guest Wi‑Fi, POS terminals and office PCs altogether. While they share the same internet circuit, they also share risks. The core question is: where should captive portal authentication be deployed? Do POS cash registers need to pop up the authentication page as well?
An improperly placed authentication mechanism will either lead to compliance gaps or disrupt daily business.
The root cause lies in different trust levels of terminals. Guest devices are untrusted and subject to mandatory real‑name authentication, while POS devices are in‑house assets best managed via MAC whitelisting.
POS and office terminals: Gain direct access to a dedicated POS & office subnet via MAC whitelisting, with guaranteed bandwidth priority.
Guest terminals: Go through real‑name authentication on Cloud Portal. Multiple verification methods are supported: SMS, identity documents (including passports, Hong Kong, Macao and Taiwan certificates), and WeChat login. Internet access is permitted only after verification passes.
Physically it is still one broadband line, but traffic is split at the Cloud Portal layer. Guests complete authentication; trusted devices pass through directly.
To sum up: authentication for visitors, whitelisting for in‑store equipment, with no mutual interference.
This model is easy to explain during inspections. When auditors ask where guest authentication runs, the answer is Cloud Portal. When they ask why POS terminals skip the portal, the answer is whitelist direct access. Every type of terminal follows a clear, defensible rule. The physical line is shared, while security policies remain independent.
Authentication and logging: Once guests finish real‑name verification, their phone number, MAC address, IP address, online start time, visited URL, uplink and downlink traffic are bound to the session and saved in cloud audit logs.
Order No.176 explicitly requires recording and retaining user registration information and internet access logs. For public Wi‑Fi scenarios, logs shall be retained for no less than six months, with sufficient storage capacity to avoid premature roll‑over. Records can be retrieved and exported by phone number or time range when audits arrive.
Isolation and security: The guest network and POS network are isolated via VLAN, so guest terminals cannot reach the payment system. No public port mapping is enabled for the POS subnet to reduce exposure to external scanning.
Real‑name authentication also improves guest experience: anonymous unauthorized access is blocked, reducing Wi‑Fi piggybacking and malicious bandwidth occupation. Two logical networks run on one physical broadband without disturbing each other.
Sharing a broadband line does not mean mixed management. Deploy authentication on the guest path, apply whitelisting for POS devices, store logs on the cloud and implement network isolation. Even a single shared broadband circuit can satisfy compliance requirements fully.
Q: How to maintain the whitelist when adding new POS terminals later?
A: Add the MAC address of the new device to the whitelist on the management backend. No modification to the underlying network structure is needed.
Q: Will guest authentication slow down POS transactions?
A: No. The two types of terminals are on separate subnets with independent policies. POS traffic is insulated from guest authentication and peak internet traffic.
Q: The broadband service is provided by the carrier. How is this traffic split implemented?
A: Traffic separation is implemented by Cloud Portal and network policy controls. There is no need to replace the existing broadband service or ONT, bringing almost no disruption to the store.