Definition
Real-name verification checks the user’s identity. It connects to a public-security real-name interface or a third-party real-name service, and it supports a two-factor check and a three-factor check. It meets the real-name compliance requirement for IoT SIM cards. After verification passes, sensitive actions such as card binding and payment can be opened.
Verification Methods
- Two-factor check: Name plus national ID number. The identity is checked against the public-security database. This fits low-risk cases.
- Three-factor check: Name, national ID number, and mobile number. It also checks the mobile number against the operator’s real-name record, so it is more secure.
- Facial recognition: A liveness check plus a face comparison. This is used for high-value business or cases with strict compliance requirements.
Compliance Requirements
According to the MIIT (Ministry of Industry and Information Technology) IoT SIM cards real-name registration regulations, the activation and use of IoT SIM cards require the implementation of real-name registration. When a company builds its own IoT Cloud Platform aimed at C-end users, it must complete real-name verification before the user SIM binding and ordering a data plan. The platform needs to retain verification records and cooperate with regulatory authorities for random inspections. Real-name verification is an important step to ensure compliant operations under the B2B2C model.
Implementation Guidance
When the platform interfaces with the public security real-name interface or third-party real-name services (such as Alibaba Cloud real-name verification, Tencent Cloud Facial Recognition), it must ensure the interface is stable and responsive. If authentication fails, the reason must be clearly indicated to the user (such as name not matching ID card, facial comparison failed) and support retries. After authentication passes, the real-name status should be associated with the user account and card binding relationship, serving as an access condition for subsequent data-plan subscription , WeChat Pay , and other sensitive operations. B2B enterprise customers may be exempt from personal real-name verification but must retain enterprise qualification information.
Real-name verification and SIM binding
Real-name verification is a prerequisite for card binding. Under the B2B2C model, after a C-end user obtains a card from an agent or a distributor, they must complete real-name verification before binding the card. After binding, the user can manage the cards on the account, order plans, and pay through the user self-service portal. Real-name records must be kept for regulatory checks. When an enterprise builds its own IoT Cloud Platform for the C-end, real-name verification is a required step for compliant operation, and it is closely tied to card lifecycle and sales attribution.
Authentication method selection
Two-element identity check (name and ID number) is suitable for low-risk scenarios; three-element identity check (name, ID number, and mobile number) adds mobile number verification for higher security; facial recognition is used for high-value transactions. When the platform connects with the public security real-name interface or third-party real-name services, it must ensure the interface is stable and responds promptly. If authentication fails, the reason must be clearly communicated to the user, and retries should be supported. B2B corporate clients can be exempt from individual real-name verification but must retain corporate qualification information. Real-name verification is a core capability for the IoT Cloud Platform compliance operations.
Which card the verification result is bound to
Real-name registration for an IoT card is not optional profile data collected when someone registers on a website. It is a record that must be completed before that card is allowed to start data service. An individual user is usually checked on name and identity-document number, and sometimes also on the mobile number used to open the account or on a liveness check. An enterprise user is checked on the organization document, the person handling the request, and the batch list of cards that belong to that organization. A pass only means this person’s identity was checked. Card management still has to write the result onto a specific card: which card, which user, which check, and until when it is valid. A single “real-name complete” flag on the account means a later rebind to another card skips the registration.
Whether binding and payment are allowed depends on the real-name status of the card, not on the account having succeeded once. The status has to distinguish at least not submitted, being checked, passed, failed, and expired. A card being checked cannot be provisioned. A failure must come back with a reason a person can understand, such as the document number not matching the name, not only a channel error code. If one identity document has a cap on how many cards it may bind, the excess should be refused at submission, so the cards are not bound first and then suspended in a batch by the carrier.
When the photo, the document, and the code on the card do not match
Users often treat the barcode on the package, the identity code on the module, and the top-up number as the same number. If the real-name submission uses the wrong number, the check is recorded on another card, and the current device still cannot attach because it is not registered. The page should say which number is required, and check length and the check digit before submission. In an enterprise batch, one failed card in the list must not make the whole batch look successful. The failed rows must be exportable and resubmittable. A blurred photo, an expired document, or a document held by someone else is a materials problem. The materials have to be replaced before a retry. The same photo must not be sent at the interface again and again.
A timeout at the verification provider and a clear failure must stay separate. A timeout can be queried on the original request, so the user does not submit again and create a second check. A clear failure ends that attempt. In the end-user flow, SimtoLink treats real-name registration as a gate in front of binding and ordering inside user self-service. Only after it passes is plan delivery allowed. An unregistered card is not placed in a billable state.
How a failed card in a batch list is resubmitted on its own
When an enterprise submits real-name materials for dozens of cards at once, the check runs per card. A wrong document number on one row must not send the whole batch back, and it must not mark the whole batch as passed. A failed row keeps the card identity and the reason from the submission, and only that row’s materials may be sent again. The resubmission must query the original check number, so the same card does not stack two “being checked” records. Cards that already passed are not affected by the failed row and can go on to binding. A materials failure and an interface timeout stay separate: a timeout looks up the result first, and only a clear failure allows the materials to be replaced. SimtoLink keeps the real-name status on the card. After the batch job ends, the cards that did not pass can still be exported one card at a time.