Definition
User self-service is the self-service platform for C-end users. It supports card lookup, renewal, activation, reactivation, plan subscription, a plan change, order lookup, refunds, and an e-invoice request. With white label, the same screens can show the enterprise’s own brand.
Core Functions
- Card management: View the IoT SIM cards under the user’s name, their status, the data plan, and the data remaining. Supports card binding and unbinding, and card activation and reactivation.
- Plans and renewal: Plan subscription, a plan change, and renewal, with online payment through WeChat Pay and Alipay.
- Bills and invoices: View bill line items and request an e-invoice.
- Order center: Order history, payment status, and refund requests.
Application Value
User self-service is a key part of the B2B2C model. It extends the old B2B pattern, “enterprise to enterprise,” into “the enterprise serves C-end users through a channel.” On a self-service platform the enterprise spends less on support and users get a clearer path, and white label puts the brand in front of them and keeps them coming back. The platform also has to support compliance steps such as real-name verification and card binding.
Technical Implementation and Experience
User self-service is usually an H5 page, a mini program, or an app, and it has to work on more than one kind of device. Payment connects to WeChat Pay and Alipay, so more than one method is available. Flows such as card binding and plan subscription should be short, with fewer steps. Users can request an e-invoice, look up an order, and open a bill. With white label, the enterprise’s own brand is what they see, which makes the payment easier to trust. Interfaces have to stay up, responses have to come back quickly, and payment has to stay tied to plan delivery.
User Self-Service and Channels
Under B2B2C, a C-end user who received a card from an agent or a distributor finishes real-name verification, card binding, and plan subscription in user self-service. After payment, the payment callback fires, and the platform completes plan delivery and reactivation, which is “pay and the card comes back.” The order’s sales attribution can be traced to the channel, which supports a payment split or settlement profit sharing. User self-service is the IoT Cloud Platform entry for C-end users. Together with the agent self-service portal, it gives the platform a business-side door and a consumer-side door.
Self-service functions
User self-service supports card lookup, renewal, activation, reactivation, plan subscription, a plan change, order lookup, refunds, and an e-invoice request. With white label, the screens can show the enterprise’s own brand. Interfaces have to stay stable, and payment has to stay tied to plan delivery. User self-service is a key part of the B2B2C model: it lowers support cost and makes the path clearer for the user.
Self-service actions must land on cards the user has already bound
User self-service is the entry where the person who finally uses the card looks up and handles IoT card business. Typical actions are viewing the remaining quota, binding a new card, ordering or changing a plan, paying for a card in arrears, requesting an invoice, and viewing orders. Every action has to confirm first that this card belongs to the user who is logged in. If entering a card number alone can top the card up, a leaked card number lets someone else buy a plan for that card or bind it away. Before binding, complete the real-name registration that card requires, and check the card identity’s validation rule. Unbinding has to look at whether the card still has a cycle that has not ended and a refund that has not finished. If it does, only disable self-service permission or transfer the card to another real-name user. Do not let it disappear from the list, or the order loses its owner.
The remaining quota on the query should state the time it was counted. The user decides whether to renew from the balance on the page. If the page is yesterday’s figure, the card may just have crossed the quota while the page still shows plenty left. When the suspension reason is a violation or a reclamation, hide the action buttons or say that self-service cannot restore the card, so the user does not pay and then find reactivation refused.
Do not show the plan as active before payment is complete
The order flow is: choose a plan, create the order, pay, and wait for the provisioning result. After payment jumps to the channel, the page often returns to the self-service site before the asynchronous notice has arrived. The order should then show in progress, and the plan expiry date and the card status stay as they were. A provisioning failure has to show a state that can be retried or refunded, not a spinner that never ends. When the same card has two orders in progress at once, refuse the second or state clearly that the later one is queued, so two plans are not delivered together and their cycles do not overwrite each other.
Invoices, refunds, and renewals belong to different permissions. A clerk of an enterprise customer may be allowed only to view, not to pay. SimtoLink’s user self-service portal limits these actions to cards that are bound and allowed for self-service. The payment result still returns to connectivity management to drive delivery and reactivation. The portal itself does not change status on the carrier side.
A clerk with view-only rights cannot start a payment
An enterprise user often has a clerk sign in to the self-service portal. The clerk can view remaining quota and orders. Payment, and a change of invoice title, need a higher permission. If view rights can also start a payment, the clerk pays personally and orders a plan onto a company card, while the invoice title is still the company, and a later refund cannot find the payer. Hide the button according to permission, and check the permission again on the API. Do not rely only on the page not showing it. Unbinding, transfer of ownership, and batch export are not default permissions either. SimtoLink user self-service splits payment, invoice, and transfer of ownership into separate permissions. A change of card status still accepts only the result of the provisioning flow.