Catalog second month: In setup still must not debit as Live

Maintaining strict billing integrity within a white-label CPaaS environment requires a precise distinction between active services and those still undergoing configuration. When a catalog item is marked as «Setup» or «Coming Next», it signifies that the technical infrastructure is not yet ready for production traffic. As you transition into the second month of service, the system must respect these flags to prevent premature debits. This ensures that your prepaid balance is only utilized for services that are fully operational and capable of handling OTP, SMS, and DLR webhooks effectively.

Monitoring Status Transitions

The transition from the first month to the second is a critical period for automated billing scripts. In many legacy systems, there is a risk that any item older than 30 days might be automatically promoted to a «Live» status regardless of its actual readiness. Within the system, we utilize a JIT (Just-In-Time) assignment logic that prevents this. A service remains in a non-billable state until the specific technical triggers—such as successful 10DLC registration or heartbeat signals—are confirmed. This granular control prevents the common trap of paying for inactive routes.

Billing Logic for Non-Live Catalog Items

To maintain transparency, the platform enforces a rule where only items with a verified «Live» badge generate recurring costs. If an item is stuck in the setup phase due to pending documentation or technical delays, the second-month invoice must reflect a zero-cost row for that specific resource. This prevents the «false live» scenario where users are charged for capacity they cannot yet utilize. This logic is essential for maintaining the USD 20 prepaid floor, ensuring the ledger remains balanced and predictable.

Avoiding Unexpected Debits

Unexpected debits often occur when the system fails to reconcile the catalog state with the billing engine. Our architecture uses a prepaid hold mechanism. When a number or service is requested, the funds are held but not fully assigned until the service is active. If the service remains in setup into the second month, the hold persists without converting into a permanent debit. This is a safeguard against the False Live badge: incident path which details the recovery steps for misaligned states.

Verification and JIT Provisioning

JIT provisioning ensures that resources are only fully allocated at the moment of need. This model replaces the outdated concept of maintaining a static inventory that drains balance. During the second month, the system performs a re-verification of all «Coming Next» items. If the requirements for «Live» status are not met, the item is kept in a dormant billing state.

Scaling Beyond the Soft Review

As your catalog grows and you move past the initial setup phases, your monthly volume will require automated reconciliation.

Start with IOSOR

Open the second-month invoice beside the catalog. For every recurring rent row, confirm the product was Live on the 1st UTC. An In setup or Coming next item that merely aged past thirty days still bills zero as Live — reverse that rent line before you call it second-month capacity.

Related: Catalog Incident Week: False Live During an Incident Still Must Not Debit Catalog invoice week: false Live must not bill as Live.

IOSOR takeaway

Do: treat second month as calendar rent only for chips that stayed Live. Age does not promote In setup.

Don't: auto-flip In setup to Live because the row is older than thirty days, or collect Live MRC on a setup product.