Billing flows and payment lifecycle

For a workspace without an active paid entitlement: 1) the operator selects a plan; 2) NOWPayments creates a checkout invoice; 3) the operator pays on the hosted page; 4) the signed webhook confirms status; 5) reconciliation upgrades the workspace. The backend refuses a new purchase for a different plan, or an invoice checkout, while an entitled subscription is active, even after cancellation but before its recorded expiry. The one exception is a balance top-up for the same plan as a live (or renewal-pending) balance subscription: that is treated as a refill and funds the existing subscription rather than opening a second one. A second purchase is also refused with payment_already_pending while an unfinished checkout exists. A hosted checkout that never received a provider payment expires automatically 24 hours after it was created (status expired), after which a new checkout can be started; a checkout that did receive a payment blocks until that payment finishes or fails.

The billing console only has hosted checkout (billing-checkout-form), balance top-up (billing-balance-form), and cancel. create_email_subscription/2 exists in Billing but has no LiveView event, form, or route. Do not treat email + cycle invoices + reminders as a supported operator-UI flow.

1) Operator selects a paid plan and deposit currency. 2) NOWPayments creates a sub-partner balance payment. 3) The funded provider balance supports recurring plan renewal. Recurring provider credentials must be configured.

Canceling stops renewal, but paid access remains until the subscription's recorded expire_date; there is no additional fixed 30-day grace period. Reconciliation returns the workspace to Starter after entitlement expires. Only then can the operator purchase a different paid plan; immediate switching is not implemented.

POST /webhooks/nowpayments verifies the HMAC-SHA512 signature, stores a deduplicated inbox event, enqueues durable processing, and returns 202. Invalid signatures return 401; persistence or enqueue failures return 503. Background processing retries up to 20 attempts and plan reconciliation is safe to repeat.

BILLING_ENABLED=false leaves cross-agent message delivery unbilled. When enabled and the balance is insufficient, message dispatch persists a failed record (error code 7001) and returns HTTP 400 with detail insufficient_funds and no payment intent. The same message_id is already claimed and cannot be routed by replay. After credits are topped up, inspect the failed record and use a new message_id for a deliberate new send. Credit-purchase NOWPayments events enter the same signature-verified, idempotent webhook inbox as plan billing and use robotscenter_<workspace_id>_credits_<timestamp> order IDs.