Definition
The card lifecycle is the state path of an IoT SIM from the moment it is stocked until it is retired: stocked, then activated, then in use, then expired or suspended, then retired. Each state has its own rule. An unactivated SIM is not billed. A suspended SIM is cut off the network.
The states that matter
- Unactivated: Stocked, not yet used. No charges. It can still be activated.
- Active: In service, rated by data billing, and able to take a plan order or a plan change.
- Suspended: Cut off for nonpayment, exhausted data, or a manual suspension. Service returns only after resume.
- Retired: Expired or withdrawn. It cannot be used again and leaves the live lifecycle.
What each state allows
An unactivated SIM cannot take a plan and is not billed. An active SIM is in service, and the plan period starts on the activation date or the order date. A suspended SIM can resume after payment or renewal. The platform has to move states, query them, and do that in batches. Lifecycle management is a base function of the IoT Cloud Platform, and it has to stay aligned with the operator. Suspend and resume covers the cut-off and the return.
Sync with the operator, and the log
Lifecycle state has to stay in step with the operator, either by a scheduled API sync or by an event. Activation, suspension, resume, and retirement each write a log with who did it, when, and why, so an audit or a dispute can be replayed. Data billing and operator reconciliation both start from this state. A wrong state produces a wrong charge. A lifecycle board should count, filter, and export by state.
What else moves when the state moves
The lifecycle is tied to plan orders, plan provisioning, suspension, and resume. An unactivated SIM cannot take a plan. An active SIM can, and the plan period starts at activation or at the order. A suspended SIM resumes only after payment or renewal. A retired SIM leaves the platform and drops out of billing and reconciliation. On the IoT Cloud Platform this state is what card information query, an agent SIM pool, and resource allocation all read.
The board operations actually uses
The board counts, filters, and exports unactivated, active, suspended, and retired SIMs. Because data billing and operator reconciliation use the same state, a wrong bucket becomes a wrong charge. Every change stays in the operation log. For an IoT SIM, the lifecycle is the dimension that activation, suspend and resume, and plan orders all hang from.
Whether unused data must be settled before retirement
The card lifecycle is a state machine, not a timeline that only grows. Which edges are allowed among unactivated, in service, suspended, and retired have to be listed on their own. Retirement or cancellation is a final state: no new plan, no resume, and no return to unactivated as if the SIM were new, unless the operator really reclaims the number range and opens the account again. That should start a new lifecycle, not revive the old record. Before entering retirement, unused data and a plan that has not ended have to be dealt with: voided, converted into a refund, or left to end with the contract. Without that rule, finance and operations each compute a different number when a project closes. A SIM that is suspended but whose plan has not expired should not be marked retired directly, or reconciliation still has the operator billing monthly rent while the platform has stopped charging. The SimtoLink card lifecycle board should count by state, and list “suspended but still inside the plan period” on its own, so it is not mixed with retirement inside one “unavailable” bucket.
How to account when the platform status lags the operator
Requests to activate, suspend, or resume are accepted on the platform first. The operator receipt is what moves the state. Until the receipt arrives, the SIM should stay in “changing,” and billing keeps the rule from before the change. If the platform moves it to in service early and the operator then refuses activation, plan days are counted for a stretch that never opened. The time the receipt succeeded, the time the platform requested the change, and the time the first usage record appeared should all be kept. If billing start is configured as first use, entering “activated” in the lifecycle is not the same as the plan cycle starting. A test attach has to be markable so that it does not push the state machine. When old SIMs are migrated in bulk, do not initialize every historical SIM as in service. Replay them from the last usage record and the suspension record, or a SIM that has been silent for years is treated as an in-service asset on the new platform.
A second stock-in of the same identifier is not the old life
After an operator reclaims a number range and sells it again, the ICCID may be reused, or it may be replaced. If a reused identifier continues the old lifecycle, the new project sees the previous customer’s suspension reason and bills. The right handling is to close the old lifecycle and start with a new internal SIM id. The identifier is only the current alias, and a “formerly used” search is kept. Stocking in again without closing the old life undercounts inventory by one, because the system still thinks the SIM is in the old project. Queries for retired SIMs go to the history store by default. The live operations list does not show them, but support searching by identifier should still find “retired,” not “no such SIM.” When a lifecycle export is given to reconciliation, cut it by bill period. A SIM that crosses a month has a stretch of state in each month. Exporting only the state at month end cannot stand for the whole month. A lifecycle given to finance should carry the start and end of each stretch. If a suspension crosses the month, both stretches are present. “Still suspended at month end” cannot replace usage that was in service during the first half of the month.