Definition
Plan provisioning starts after a plan subscription is paid. The platform sends a command to the operator from the operator mapping and writes the plan onto the IoT SIM. On success the SIM receives that data. A SIM suspended for nonpayment can resume automatically. Together with the payment callback, payment can take effect at once.
Provisioning steps
- Confirm payment: After the user pays, the payment callback notifies the platform, which checks the order status and the amount.
- Convert the mapping: The house data plan is turned into the operator product code and tariff code through operator mapping.
- Send the command: The operator API — China Mobile OneLink, China Unicom Jasper, China Telecom, and the others — writes the plan to the given ICCID or MSISDN.
- Take the receipt: The operator returns the result. The platform updates the order and the plan on the SIM. A SIM suspended for nonpayment then resumes.
When it fails
If provisioning fails, because the operator side is down or the SIM status is wrong, the platform has to retry and allow a person to step in. Keep a provisioning log so the failure can be traced. If retries still fail, tell the user and allow a refund or a manual handling.
Provisioning and billing
After a successful write, the SIM has the data or the entitlement, and data billing starts from that moment. The platform updates the plan on the SIM and the remaining allowance. A SIM suspended for nonpayment resumes when the write succeeds. Provisioning is the step in plan subscription that depends on the payment callback. A delay or a failure is what the user feels, so the operator API and the retry have to stay reliable.
Provisioning and operator mapping
Provisioning depends on operator mapping to turn the platform data plan into the operator product code and tariff code. A wrong mapping fails the write or writes the wrong plan. The mapping is set at plan packaging, with a different row for China Mobile, China Unicom, and China Telecom. The write uses the row for the operator on the SIM. After success, the plan cycle starts on the effective date. The bill and operator reconciliation both depend on that record.
Provisioning and resume
If the SIM is suspended for nonpayment, a successful write triggers resume, so payment can bring the SIM back. A failed write can be retried or handled by hand. This step sits inside plan subscription and follows the payment callback. The operator API and the retry have to stay reliable. Plan provisioning is how the IoT Cloud Platform joins the operator to its own plans.
Where the order sits when payment succeeded but the receipt has not arrived
Plan provisioning takes the house plan on an order that has been paid, turns it into an operator product code through the mapping, writes that code onto the named SIM, and stores the receipt. A payment notice only says the money arrived. The receipt says the SIM now has this block of data. Until the receipt arrives, the order is “provisioning.” The remaining allowance does not change, and a SIM suspended for nonpayment is not moved to resumed first. If a query of the operator shows the plan was in fact written, record that query result as the receipt. Do not write it again. Writing again can stack two plans, or be rejected and then mark the order failed. Only when it has failed and it is confirmed that nothing was opened does the order enter refund or a manual retry. A retry has to use the mapping that is still valid now, and the operator should see whether the code has changed since the order was placed. The link to suspend and resume is this: after provisioning succeeds, if the suspension reason is nonpayment or exhausted data, send resume. Any other reason stays cut off.
Write the identifier, or write the number
Some APIs recognize the ICCID. Some recognize the number. The provisioning record stores both. The actual submit takes whichever one that operator’s API requires. A stock SIM whose number has not been assigned yet cannot be provisioned. Open the account first. A SIM that is cancelled, retired, or already inside another provisioning must refuse the new one. Bulk provisioning returns a receipt per SIM on the list. One failure does not mean the whole batch failed, and a SIM with no receipt is not marked successful. “Credited” on the user page appears only after the receipt succeeds. The credited volume equals the plan tier. If the total the operator returns does not match the tier, the order is marked abnormal. Do not first show the user a remaining allowance that does not match. The cycle start uses the payment time or the receipt time according to the provisioning rule, and that choice should not be written separately from the first-activation-time rule.
Three questions the provisioning log must answer at reconciliation
Reconciliation asks whether this block of data was really opened, which tariff code was opened, and which bill period the open moment falls in. The log therefore needs the order number, the SIM identifier, the operator, the product code, the tariff code, the request time, the receipt time, and the original return code. The word “success” alone cannot explain a code difference on the bill. The original message can be stored with sensitive fields removed, but the codes and the return code have to be searchable. If the plan is changed immediately after provisioning succeeds, both records stay. They must not overwrite each other. If an order whose payment has been refunded still provisions successfully, a compensating job has to unsubscribe or disable that block of data. Marking the refund on the payment order is not the end. When jobs pile up, provision the orders whose payment has already succeeded first, and leave query-style sync behind, so a SIM does not sit for a long time with the money taken and no plan. If there is still no receipt after the agreed wait, move the job to a manual queue and stop new payments on the same SIM, so the user does not think it failed and pay again, leaving two provisions waiting.