Billing state: the credit balance, the automatic top-up rule, caps, dunning, portal URL

Your organization's billing posture, read-only: dunning state (why provisions might be refused), month-to-date spend - INCLUDING usage in progress, so it runs ahead of get_usage's total_usd, which counts only what has billed (get_usage's spend_so_far_usd is this same figure) - spend caps, and (for admin/billing roles) payment method status, collection method, credit balance with when each part of it expires (credit_expiries, soonest first; expires_at: null never expires), available_to_spend_usd (the credit left once usage in progress settles - the same figure the /usage page shows; never add it to the month's spend), amount_due_usd (the total of open, unpaid usage invoices, with amount_due_oldest_due_date), payment.card_attached (a verified card is on file - the same meaning as payment_method_ok) and whether the card actually paid: payment.last_charge_succeeded, last_charge_at, last_charge_failure_code and consecutive_charge_failures (failed charges since the last one that paid; only charges on the current card count), the newest credit grants with their kind and what became of each (credit_grants, state: active, expired, used, removed or revoked), per-member spend, any prepaid-contract balance with its expiry (distinct from pooled credits - the figure to track against a prepay deal), and cash received in every shape (usage invoices, contract invoices, wires). Members see the org's dunning state plus their own numbers; org-wide money is role-gated exactly like the /usage page. Card and invoice changes are ceremonies: they live in the billing portal (the response carries the link).