IOSOR Learn

Two-wallet brand split: ops playbook without mixed From

Execute a clean brand split across two IOSOR prepaid wallets without cross-contamination. Master ledger separation, E.164 assignment, and cutover steps.

Two-wallet brand split: ops playbook without mixed From.

Architectural mapping and ledger isolation

Operating multiple client accounts requires strict financial and routing isolation inside your white-label CPaaS console. Start by creating distinct prepaid wallets for Brand A and Brand B. Each wallet operates independently with its own USD 20 prepaid floor, ensuring zero ledger bleed. Configure automatic balance top-ups so that low funds trigger notifications without pausing mission-critical OTP delivery. In the master ledger, tag every transaction with the specific brand ID to maintain precise audit trails for end clients.

Number assignment via JIT provisioning

Provisioning numbers («DID resources») must follow a strict Just-In-Time protocol. Never hoard unused inventory; assign E.164 formatted numbers directly to the designated brand wallet the moment an agency requests them. This JIT approach keeps MRC billing aligned with actual usage. Bind each assigned number exclusively to its parent wallet routing profile to prevent accidental traffic mixing. When a client scales past USD 1,000/month, trigger a soft review to optimize routing tiers without disrupting active campaigns.

From-address segregation and header hygiene

Mixed From-addresses destroy deliverability and confuse end-users. Enforce strict header hygiene by locking the alphanumeric Sender ID to the correct brand wallet. Configure webhooks to reject outbound SMS payloads if the declared From-address does not match the active wallet whitelist. Test DLR feedback loops rigorously to ensure delivery receipts route back to the correct billing entity. Clean From headers protect carrier reputation and eliminate cross-brand pollution.

Routing policies and traffic cutover execution

Execute the traffic cutover during planned maintenance windows to avoid message drops. Update your gateway routing tables to direct Brand A traffic strictly through Wallet A infrastructure. For Brand B, verify that all webhook listeners point to dedicated endpoints. Monitor inbound and outbound traffic in real time via the IOSOR operations console, watching for latency spikes or failed DLR flags. Keep fallback routes disabled during cutover to expose any misconfigured sender IDs immediately.

Operational validation and required links

Post-cutover validation requires checking ledger balances, webhook parity, and SMS throughput metrics. Ensure that STOP and HELP keyword handling is active on every provisioned number. Review our related operational documentation for deeper insights: check OTP launch week: prepaid checklist that prevents burn for migration steps, explore IOSOR for agencies: client brands on your white-label portal for agency workflows, and review Delivery Status SMS Playbook for Shoppers for compliance.

Start with IOSOR

Open your IOSOR console to set up isolated sub-wallets and assign independent ledger balances for Brand A and Brand B. Lock each brand's alphanumeric Sender ID directly to its designated wallet and configure a strict webhook validation gate to drop payloads with mismatched headers. Finally, point DLR listeners to brand-specific endpoints before initiating traffic cutover.

IOSOR takeaway

Managing dual-brand operations successfully requires strict ledger separation and zero tolerance for mixed From-addresses. By binding E.164 numbers and Sender IDs directly to isolated brand wallets via JIT provisioning, you insulate sender reputation and simplify accounting across campaigns.

Do configure webhook filters to reject SMS payloads that do not match the assigned wallet configuration. Don't share webhook endpoints or allow pooled DID resources to bleed across multi-tenant brand boundaries during cutover.

Was this guide helpful?

Related guides