Billing and locks

What is billed

Billing belongs to the merchant account, across its stores. With Billing V4 enabled, Basic and Pro have a fixed USD subscription price paid using the Bitcoin quote on each bill. Eligible paid Live invoices accrue usage at the account's effective rate. Sandbox does not create real usage charges. Use pricing and your Billing page for the current catalog, negotiated terms and existing balances.

Due dates and the billing lock

New bills currently have a payment due date seven days after issuance, followed by a seven-day grace period. Use each bill's actual due_at and lock_at values instead of calculating dates in your integration. Existing bills retain their recorded dates.

When an applicable unpaid bill reaches lock_at, the backend blocks new Live invoice creation across all stores and new Live activation. API integrations receive HTTP 402 with billing_overdue. A dashboard warning is not the enforcement mechanism: the shared invoice service checks billing eligibility.

Merchants can still sign in, view history, use Sandbox and open Billing to pay. Existing customer invoices keep processing, including top-ups, confirmations and webhook delivery. A billing lock differs from an administrator suspending the account, which has broader access restrictions.

Returning to Live invoicing

Pay the outstanding bill using the address and exact Bitcoin amount displayed in Billing. A broadcast or an unconfirmed transfer does not clear the lock. The billing watcher must record sufficient confirmed payment. Any other overdue bill or account restriction can keep Live creation locked.

Authorized administrators can review recorded payment or waive a bill through audited controls. A waiver's coverage behavior depends on the selected resolution; merchants should read the updated bill and plan state rather than assume every waiver grants a paid plan period.

Complimentary access waives new subscription and usage charges. It does not silently erase older balances. Starter in V4 is pay-as-you-go rather than a limited paid-invoice trial; legacy Trial installations retain their exhaustion rules.

Billing errors in an integration

If creation returns billing_overdue, stop repeating the create request. Show the merchant a link to their account Billing page, retain the logical order/idempotency identity, and retry only after the restriction is resolved. Do not switch a real customer's order to Sandbox as a workaround.

Local and self-hosted development

For a local installation, use its configured URLs, such as http://localhost:3001 for the dashboard and http://localhost:4000 for the API. These addresses refer to your own computer and are not public SatLane endpoints. Wallet-free Sandbox and legacy compatibility depend on the installation's enabled contract. A local setup does not establish the availability of a production deployment. Keep deployment-specific acceptance notes outside customer integration examples.