Definition
A primary card and a secondary card are role labels for a C-end user who holds several cards. After the user binds several IoT SIM cards to the same account, one card can be set as the primary card and the others as secondary cards. That supports family sharing, multi-device management, and similar cases. Primary and secondary cards are the IoT Cloud Platform’s multi-card management capability for B2B2C users.
Differences between the primary card and the secondary card
- Primary card: Usually the main card in use. It may carry higher usage, or it may be the entry for managing the account. When a data pool is shared, the primary card can be given a higher weight. In some cases the primary card is the billing subject, and bills and e-invoices follow the primary card or the primary-card account.
- Secondary card: An attached card that shares the account with the primary card. Usage or permissions can be set on their own. A secondary card can share the primary card’s plan or data pool, or it can order its own data plan.
Relationship with data pool
In data pool mode, the primary card and secondary card can both join the same data pool, sharing traffic according to weights. The primary card can be configured with a higher weight (e.g., 60%), and the secondary card with a lower weight (e.g., 40%), meeting the needs of family or multi-user sharing scenarios. The platform allows users to flexibly adjust the primary and secondary card settings, data pool members, and weights through user self-service .
Use Cases
Primary and secondary cards fit B2B2C cases such as several cards in a household or several devices sharing service. Through the user self-service portal, a user manages the cards on the account and can set a primary card and secondary cards. In the billing mode used for data billing, a data pool can be shared by weight, and the primary card can be given a higher weight. Typical cases include a secondary card on home broadband and several devices sharing data.
Platform capability requirements
The primary/secondary card function requires the platform to support capabilities such as multiple card binding, role configuration, and data pool weights. Users can add/remove secondary cards, adjust primary/secondary card roles, and configure data pool members and weights through user self-service . The platform needs to support aggregation display by primary card account in modules such as billing and traffic statistics , to facilitate unified management of multiple card expenses.
Cooperation with the data pool
The primary card and secondary card can jointly join the same data pool , sharing the traffic within the pool. The primary card can be assigned a higher weight (e.g., 60%), while the secondary card is assigned a lower weight (e.g., 40%), meeting the "primary card priority" usage allocation logic. When traffic billing is applied, the traffic in the pool is distributed to each card according to their weights, and the primary card may bear more usage due to the higher weight. Users can adjust the weights based on actual usage or independently purchase a data plan for the secondary card.
Who the secondary cards belong to after the primary card is disabled
A primary card and its secondary cards are roles for several IoT cards under the same user. They are not a simple copy of the voice primary-and-secondary numbers inside a carrier plan. The primary card is usually the place bills are grouped, the baseline for data-pool weight, and the anchor of the real-name subject. A secondary card can share quota inside the pool, or it can carry its own plan. The roles exist only when these cards are already bound to the same user and the real-name subject is the same. Cards on different identity documents cannot be gathered into a primary-secondary relationship just to make traffic easier to share. Otherwise suspension, invoices, and a regulatory spot check will not point at the same person.
When the primary card is unbound, suspended, or reclaimed, decide where the secondary cards go first: they follow the primary card into suspension, or one of them is promoted to a new primary card and stays online. Without that rule, after the primary card is suspended for nonpayment the secondary cards still draw traffic from the pool, and the bill has nobody who can be charged. Cap the number of secondary cards as well, so one account cannot bind unrelated devices and turn enterprise stock into cards a person can pay for.
How to allocate when the weights do not sum to 100 percent
When a shared pool is allocated by weight, the parameters that matter are each card’s weight, whether the weights are required to sum to a fixed value, and the billing period in which a weight takes effect. Writing 60 percent and 40 percent, which add to 100, is easy to read. If weights may be written as 2 and 1, allocation should use each weight’s share of the total, not treat the number itself as a percentage. If a secondary card’s weight changes from 1 to 3 partway through, state that the change affects only usage not yet billed. Bill lines already generated keep the old weight. Otherwise the user sees amounts from past months rewritten.
A common error is a primary card that bought its own plan and also holds a high weight in the pool, so the same megabyte is recorded once on the personal plan and once in the pool allocation. Before billing, decide whether this card’s usage for the period belongs to the personal plan or to the pool. Another error is a secondary card that is not activated but still holds weight. The pool then has fewer effective cards, and each card is allocated a quota that is too high. Cards that are not activated, are suspended, or have been removed should leave the allocation set. SimtoLink’s end-user management for the people who use the cards keeps this primary-secondary relationship and pool membership, so a label change on the page does not leave billing running on the old members.
Which card the invoice and the charge account follow
When the primary card is the billing subject, the invoice title, the receiving mailbox, and the account to be charged should be bound to the user who owns the primary card, not to whichever secondary card produced traffic most recently. If a plan ordered on a secondary card alone may be invoiced alone, the order must say that this money is not part of the primary card’s summary, so one payment does not produce two invoices. When the primary card changes user, historical bills that have not been invoiced keep the original title. The new title starts with the new cycle. Otherwise finance reissues an old month’s invoice under the new identity document, and it no longer matches the payment already recorded. When the primary-secondary relationship changes, SimtoLink end-user management freezes the title on bills already issued, and only cycles not yet billed read the new primary card.