Billing flows and payment lifecycle

1) Operator selects a plan in the billing UI. 2) A NOWPayments checkout invoice is created. 3) Operator completes payment via the NOWPayments checkout page. 4) NOWPayments webhook confirms payment status. 5) Workspace plan is upgraded upon confirmed payment.

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 the provider subscription. Paid access remains only until the subscription's recorded expire_date; there is no additional fixed 30-day cancellation grace period. Reconciliation returns the workspace to Starter after entitlement expires.

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, message dispatch reserves workspace credits and returns HTTP 402 with extra.payment_intent when the balance is insufficient. Credit-purchase NOWPayments events enter the same signature-verified, idempotent webhook inbox as plan billing and use robotscenter_<workspace_id>_credits_<timestamp> order IDs.