Definition
Partner Portal (Partner Portal) is a self-service management platform provided by ICMP for Reseller channel partners. It supports SIM card management, usage inquiry, Commission commission inquiry, order management, sub-customer management, etc. Partner Portal also supports white labeling, allowing channels to offer services under their own brand, making it a core capability of the Multi-Tier Channel multi-level channel system.
Core Functions
Typical features of the Partner Portal: Card Management ——View the list of cards under the account, status, Activation activation, Suspension suspension; Usage and Billing —— Usage Analytics usage analysis, Unified Invoice billing, cost details; Commission —— Commission details, settlement status, history; Orders ——Place orders, order status, order history; Sub-customers ——Create accounts and allocate resources for downstream customers. Supports OAuth2 SSO, RESTful API integration.
White-label Capability
White-label allows channels to provide the Partner Portal externally under their own brand, domain, and logo, so that customers do not perceive the underlying platform. The platform provides white-label configurations: domain binding, theme customization, brand elements. White-label helps channels establish their own brand and enhance customer stickiness, and it is an important capability for Multi-Tier Channel channel expansion.
Implementation in ICMP
SimtoLink ICMP's Partner Portal provides full self-service capabilities for Reseller; supports Commission inquiry and reconciliation; supports white-label customization; integrates with IAM and OAuth2; Audit Trail records channel operations to meet compliance and risk control requirements.
What the Portal May Show, and Where White Label Stops
A partner portal is the working entrance through which a channel party enters the connectivity platform. The SIMs, orders, usage, and commission it shows should be limited to that party and to the downstream parties it is authorized to see. White label changes the domain, the name, and the look. It does not change the SIM ledger, the permissions, or the charging authority behind it. The channel’s customer sees its own brand. The data is still isolated by tenant on the same platform. Every button on the portal must map to one allowed action. It is not the internal operations menu reskinned and opened as a whole page.
Open the portal only when channel tier, price visibility, and action scope are already configured. A read-only reconciliation account should not have bulk provisioning or suspension. A downstream account should not see the upstream purchase price, unless the contract explicitly requires it to quote on that basis. The commission page should separate settled and unsettled amounts, so an estimate is not treated as a balance that can be withdrawn. If the portal also lets a channel set quota for its own customers, that action is bounded by the ceiling in the channel contract. A downstream party must not raise the allowance beyond what the platform has authorized. An external quote should use the rate card visible at that tier, not the floor price between the platform and the upstream party.
Treating the Channel Entrance as a Separate Network
A common error is to believe that a new domain means an independent network and an independent ledger. If the white-label portal still sits on the same SIM pool, one channel’s mistaken action can affect a shared policy, unless resources have already been cut by party. Another error is several employees sharing one portal administrator account. The audit trail can see only the channel company. It cannot see which employee exported a customer list or confirmed commission.
If single sign-on is configured so that entering the portal inherits an internal platform role, a channel user receives menus that are not theirs. A portal account should map only to a channel role and to that channel’s data scope. Accept brand, permissions, resource scope, and settlement party as four separate items. Only when all four are limited to that partner is the portal a channel tool, and not a second operations console without constraint.
A white-label domain decides only where the customer enters. It does not decide which ledger the data lives on. At acceptance, try a downstream account against an upstream order, a sibling channel’s SIMs, and an internal platform menu. All three should be refused. A watermark or header on an export should carry the channel party and the time, so a spreadsheet that leaves the portal is not taken for a platform-wide list. When a channel contract ends, disable the portal accounts first, then take back SIMs not yet allocated and operation rights not yet settled.
Viewing on a customer’s behalf must record which channel user viewed which customer. If internal platform staff need to enter the portal to check a problem, they should use an assisted identity with a time limit, not ask for the channel’s password. The assisted identity expires on its own, and exports and changes during that period are listed in the audit trail on their own. Channel users do not share accounts either, or it is impossible to tell who confirmed commission or suspended a customer’s SIM. Disable a leaver’s account the same day, and invalidate the session at the same time.
Self-service provisioning in the portal is bounded by the channel contract. Products and quantities that can be provisioned cannot exceed the range assigned to that channel. Above that range, refuse and say why. Do not provision first and discover at month end that it cannot be settled. Self-service suspension likewise acts only on SIMs under that channel. A bulk file should first show a validation result: which identities do not belong to the channel, and which statuses cannot be changed. Execute only after confirmation. A row that fails validation stays as it was. A correct row in the same file must not cause an incorrect row to be changed as well.
White label replaces only the name and the appearance the customer sees. If the footer or the help entry promises that the channel provides support, the support flow must still be able to map the problem back to a SIM and an order on the platform. A channel cannot modify the platform’s authoritative charging data, such as an invoice amount already issued. It can raise a question. The party that owns the invoice makes the adjustment. The portal is then an entrance for operations. It is not a second set of books.
A brand name on the channel portal must not appear in notices the platform sends to other channels. Notices, exports, and invoices should all check that the recipient is the party that owns the record, so one white-label page does not carry another channel’s customer names out.