Second catalog product: badge handover

Second catalog product: badge handover.

Catalog state when the second product lands

Deploying a second product into a white-label prepaid CPaaS creates immediate UI state risks. Operators often fight stale badges across rapid billing events. When a tenant buys a virtual number alongside an existing OTP workflow, the control panel must reflect JIT allocation without lagging behind the ledger. A prepaid hold reserves funds while routing rules bind the asset to the workspace profile. Review your foundational routing logic via Catalog ops when many products ship to keep UI state tightly synchronized with actual wallet events.

Preventing false Live status during handovers

Premature activation breaks tenant trust faster than bad pricing. A service must never flip to a Live badge before DLR telemetry and heartbeats confirm true line readiness. Here's the trap: painting a badge green on allocation request rather than confirmed upstream response. If a badge flips too early, customer traffic hits dead routes and support queues explode. Read False Live badge: incident path to see how bad status signals cascade into billing disputes.

Tenant onboarding and initial credit guardrails

Every new tenant starts on firm financial footing with a USD 20 prepaid floor. This initial balance shields platform infrastructure against automated card testing while leaving headroom for real verification traffic. When spending scales past a soft review limit near USD 1,000/month, automated flags inspect usage patterns without freezing clean traffic during quiet hours. Tenants configure their first asset using the White-label one account: first honest path workflow.

Multi-service status comparison table

Webhooks and HB synchronization mechanics

Real-time state transitions require strict heartbeat routines and resilient webhook delivery. What happens when a network drop hits during asset binding? When a number binds to a workspace, the platform dispatches a signed JSON payload to the tenant endpoint. If the endpoint fails to acknowledge receipt, the UI holds the handover badge in a transitional provisioning state until ledger reconciliation finishes. This guarantees DLR continuity for high-volume SMS traffic.

Start with IOSOR

Open the second-product chip. Leave it In setup until bind and a delivered DLR confirm the new line. The first product stays Live on its own row — it does not donate a badge. Flip Live only after the provisioned webhook and the prepaid hold match. Write the name of who handed the badge.

IOSOR takeaway

A second catalog product is a second promise. The handover badge follows confirmed bind, not the allocation request.

Do: keep the new chip In setup until webhook plus hold agree, then name the owner who flipped.

Don't: paint Live because the first product already works, or because JIT assigned a number.