Definition
Suspension and reactivation is the management of suspension and reactivation for IoT SIM cards. Reasons for suspension include arrears, data used up, a violation, and device reclamation. Reactivation is triggered after payment or renewal. A successful payment can reactivate the card automatically and, together with plan delivery, produce “pay and the card comes back.”
Types of Suspension
- Arrears suspension: The card is suspended automatically when the plan expires without renewal or the account balance is too low. After payment, reactivation is usually automatic or manual.
- Suspension when data is used up: The allowance inside the plan is exhausted and overage billing is not enabled. The card comes back only after a new plan is ordered or the current one is renewed.
- Violation suspension: The card was used for a prohibited purpose and was suspended by the carrier or the platform. Reactivation is requested after an appeal or a correction.
- Manual suspension: The enterprise suspends cards on devices being reclaimed, or on a project that is ending, so cost stays under control.
Automated service restoration
After the user pays or renews through WeChat Pay or Alipay, the payment callback starts plan delivery and reactivation, which is “pay and the card comes back.” The platform needs batch suspension and reactivation, and a way to filter the cards, so operations can run them. See the suspension and reactivation entries.
Service suspension and restoration linked with business operations
Suspension and reactivation is a core part of IoT SIM card status management. It stays tied to traffic billing, plan subscription, and user self-service. When data is used up or the account is in arrears, suspension can start automatically. After the user renews, a payment callback reactivates the card. The platform can warn before suspension, for example when 10% of the data remains, so the user is less likely to lose connectivity without notice. A violation suspension and a manual suspension need a clear operation log and an approval process. The command must reach the carrier reliably, so the card status matches the platform.
Suspension and Reactivation with Card Lifecycle
Suspension and reactivation is the transition between the "In Use" and "Suspended" states in the SIM card lifecycle . When suspended, the SIM enters a suspended state and cannot access the network; upon reactivation, it returns to in-use status. The platform must support batch suspension and reactivation based on ICCID , MSISDN , batches, and other criteria. Suspension and reactivation records must be retained to facilitate carrier reconciliation and auditing. Under the B2B2C model, end-users can automatically reactivate service through user self-service after payment; agents can perform suspension and reactivation operations for their subordinate SIMs through the agent self-service portal .
Types of Suspension and Reactivation
Reasons for suspension include arrears, data used up, a violation, device reclamation, and a manual suspension. Arrears and a used-up allowance are usually triggered automatically. A violation or a manual suspension has to be triggered by a person. Reactivation waits for payment or renewal, and a payment callback can reactivate the card automatically. Suspension and reactivation is a core part of IoT SIM card status management, and it stays tied to plan subscription and plan delivery. See the suspension and reactivation entries for the separate steps.
Which side’s status the suspension command follows
Suspension and reactivation change whether an IoT card can start a data session. The status the platform shows must match the carrier side. Otherwise the page says the card is usable while the device fails to register, or the page says suspended while the card is still consuming traffic. Before a suspension is sent, the reason code has to be known: nonpayment, quota used up, a violation, device reclamation, or an operations action. The reason code decides the condition for reactivation. Nonpayment and a used-up quota can be reactivated automatically when payment succeeds or a new plan takes effect. A violation or a reclamation must have the reason code lifted by a person. Arrival of a payment must not open the card automatically, or a card that was stopped can come back on a small renewal.
The command carries the card identity, the action, the reason, and the request number. When the carrier returns “accepted,” the platform status must not be changed straight to suspended. It should stay in progress and query the final result by the request number. A retry after a timeout must reuse the same request number, or query first, so two suspensions are not recorded as two independent operations and reactivation later releases only one of them.
Successful reactivation does not mean the plan has been renewed
Reactivation after a nonpayment suspension is often tied to plan delivery, but the two are still separate steps. Reactivation alone, without a new plan, lets the card register again and then produce usage records under no plan or under a pay-as-you-go rule, and the arrears return immediately. Plan delivery alone, with reactivation failing, means the user’s bill is paid and the device is still offline. An automated flow tells the user service is restored only after both steps succeed. If either step fails, the fact of payment is kept, and the work enters a provisioning queue that can be retried.
A batch suspension needs a batch number and a failure list. One invalid card identity must not roll back cards in the batch that already succeeded, and the whole batch must not be marked successful. SimtoLink’s suspension and reactivation keeps the reason code, the carrier receipt, and the payment trigger on the same card-status record, so it is possible to explain why this card went offline and which order later restored it.
Accepted does not mean the card is already suspended
The carrier often returns first that the command was accepted. Whether the card actually ended up suspended waits for a status query. If the platform shows the card as suspended at the moment of acceptance, the user stops using it while the card is still online and still being billed. If a failed query then changes the status back to in use, a suspension already sent may take effect later, and the page and the network are opposite again. While the request is in progress, a second command in the opposite direction should be blocked until the original request number has a final receipt. A final failure keeps the reason and allows a retry of the original request. SimtoLink suspension and reactivation uses the receipt as the condition for a status change. Accepted only means the command is in flight. If several queries still have no final result, the card stays in progress and goes to a person. Do not automatically change it back to in use, and do not mark it suspended early. In the same batch, failed cards are retried on their own. Cards that already succeeded are not affected.