Definition
Card status is where an IoT SIM sits in the card lifecycle at this moment: whether it can be used and whether it can attach. The usual values are unactivated, active, suspended, and cancelled. The IoT Cloud Platform and the operator keep the value together. Management, billing, and operations all read it.
The four values
- Unactivated: In stock, not yet activated, and not usable. An activation validity window may apply. Past that date the SIM can be reclaimed or flagged.
- Active: Activation is done and a plan is on the SIM, so it can attach. Billing follows first activation time.
- Suspended: The SIM was activated and is now suspended for nonpayment, data overage, or a violation, so it cannot attach. The reason can be nonpayment, exhausted data, or a manual hold.
- Cancelled: Retired and no longer in use. It cannot be restored. Typical cases are a damaged SIM, a closed project, or a user leaving the service.
How a SIM moves
The path is unactivated, then active, then suspended and back to active through suspend and resume, and finally cancelled. The platform can suspend and resume. A suspended SIM returns to active after payment, more data, or an approval. The change is sent to the operator so the bill and the network policy stay on the same state.
Where the status is read
Status is a core field on card information query and on the IoT Cloud Platform board. The platform syncs it with the operator and can filter, count, and export by it. Operations uses the mix of states to see stock, activation rate, and suspension rate. A suspended SIM can resume after payment or approval.
Finer labels that do not replace the four
Some setups add pre-activation, a test period, and a silent period. Pre-activation means a plan is configured and the SIM is not yet formally activated. A test period is a trial after activation. A silent period is a SIM that has produced no data for a long time. Those labels help operations spot an odd SIM and tune plans and stock. They still sit under one of the four main states.
How the two sides stay aligned
The platform and the operator sync in real time or near it, through operator integration. An operator-side change, such as a nonpayment suspension or an exhausted-data suspension, is pushed in. The platform updates its copy and may raise a data alert or notify the user. A suspension or resume started on the platform is sent the other way. If the two copies drift, billing and the network policy drift with them.
Does a silent period count as already activated
Card status answers whether data service is allowed right now. It is not the stage name used in a sales pitch. Unactivated means the account has not been opened or first use has not finished, and there should be no formal plan cycle. Activated means the SIM can be used. When the data bundle starts to be charged is governed separately by first activation time. Suspended means the SIM was usable and is now cut off. Cancelled or retired means the lifecycle has ended. Some operations language adds a silent period, a test period, or pre-activation. Those can be sub-statuses. They cannot replace the main status. If a silent period can still attach, the main status is activated, and the plan has simply not started or is on a low test price. If it cannot attach, the main status should be unactivated or suspended. Writing the silent period as a fourth status, level with suspension, that “looks stopped but is actually billing” makes support pick the wrong resume button. SimtoLink card status monitoring filters on the main status. The sub-status only explains the reason.
When the two sides disagree, which change wins
The platform and the operator each hold a status. A change synced in and a command this platform sent can cross. The rule is that a command this platform has sent, and that has no receipt yet, holds “changing.” An older query result must not overwrite it. Only a receipt or a query whose timestamp is newer than the start of “changing” may land. If the timestamp is missing, the queried value cannot be written straight over the local one. If the operator has suspended the SIM while the platform still shows activated, whether billing stops depends on the contract. Some stop charges from the operator’s suspension moment. Some stop only when the platform acknowledges the suspension. Neither can be left vague, or reconciliation is missing a whole stretch of usage. Status history has to be replayable. Keeping only the current value cannot explain why a charge was taken yesterday.
Can a query show an older status than the alert
A monitoring alert and the SIM detail query may read different update times. The alert arrives first, the detail is still an old cache, and an operator who resumes from the detail operates a SIM that is already being handled, a second time. The detail API should return a status version or an update time, and the alert handling page should carry the same version. If the version is behind, refresh is required. A bulk status change returns success, failure, or skip for each SIM. Skip reasons include already in the target status, SIM already cancelled, the operator has no right, and the operator rate limit. A rate-limited SIM stays in the queue for retry. It is not marked failed and then clicked again by a person, which would duplicate the command. Cancellation is one-way. The screen should not put it on the same “disable” button as suspension. Test SIMs and production SIMs are distinguished by a mark other than status, so test traffic does not run a production SIM’s state machine into suspension. When a test mark expires and the SIM is to become production, run an explicit status confirmation. Deleting the mark alone must not inherit a suspension reason that was written badly during the test period.