Subscription, invoices and payment¶
Draft documentation. Billing has backend support and a partly connected frontend. The task guide follows the newer Tenant Admin Final Screens; a complete deployed journey and audience acceptance have not been verified.
Billing explains what the workspace has purchased, what it currently owes, and what happened to a requested commercial change. It helps administrators and finance teams distinguish an ongoing subscription from an individual purchase, investigate a payment problem, and find the corresponding invoice or receipt.
Start with the Billing task guide. Review usage and capacity before buying seats or storage. Workspace creation and initial payment explains the first subscription; membership and access explains assigning purchased access to people.
Who can manage billing¶
The workspace Billing area requires an organization administrator. Responsibility for finance, an organization-head designation or a product licence does not by itself grant this access. Current account, membership and branch eligibility still apply. Read billing access and recovery for the difference between administrative access, product access and initial-checkout recovery.
Read understanding billing records for paid-only invoice visibility, saved workflow amounts, subscription-summary timing and missing-record interpretation.
Conditional payment methods¶
The payment-method and verification explanation covers current conditional bank-transfer, bank-account, OPay, USSD and mobile-money support, original-operation recovery and the difference between expired instructions and a recorded failure. Availability depends on the saved checkout and current payment configuration. The inspected frontend does not yet mount the native method/verification actions, so this is not an additional click sequence or a promise that all methods appear in Billing.
Four records with different purposes¶
| Record | What it tells you | What it does not establish on its own |
|---|---|---|
| Subscription | Current plan, licensed seats, recurring amount, billing contact and period | That a particular new purchase has finished |
| Billing workflow | Progress of one requested purchase or scheduled change, its reference, amount and payment requirement | That opening checkout has taken payment or applied the change |
| Billing history | Recorded payment, workflow and subscription events over time | A separate invoice or proof that every downstream update has completed |
| Invoice and receipt | A recorded charge and, when available, its payment receipt | That the workspace already has the resulting capacity or that every purchase grants access to every member |
A workspace can have a subscription needing attention and a separate purchase waiting for checkout. Read the record and period associated with the action you are investigating. The newest-looking card is not necessarily the record for that action.
For the workspace's first payment, Checkout recovery in Workspace Access helps eligible administrators return before normal workspace access is available. That selection is not a full payment history. A missing recovery card does not prove that a payment or saved request is absent; keep its original reference for investigation.
How a commercial change progresses¶
After an eligible request is saved, Billing creates a workflow with a stable reference. Paid changes can first appear as checkout preparation, then become ready for payment when a checkout link is available. The request can be recovered through Billing workflows; repeatedly starting a new purchase is not the normal way to resume the saved one.
Zerohive verifies the payment provider's successful response before proceeding. Missing information, a verification problem or inconsistent payment details can require review. Verified payment and application to the workspace are separate stages. Check the workflow outcome and the resulting plan, seats or storage before treating the change as available for use.
Some changes require no payment immediately. The inspected backend schedules eligible plan changes and recurring storage-pack reductions for the recorded effective time. The scheduled summary is an acknowledgement of a future change. It does not mean that the lower allowance or new plan is already in effect. Background processing and the workspace's application step still have to run.
Workflow amounts are saved commercial information. A completed workflow can retain its original amount-due field; that historical amount alone is not an instruction to pay again. Use status, payment requirement, checkout availability and the actual result together.
When a payment notification arrives¶
The payment provider sends updates to Zerohive in the background. Receiving an update, verifying the payment and applying the purchased change are separate steps. An acknowledgement to the provider does not by itself mean that an invoice is paid, a purchase is complete or additional capacity is ready.
Updates may arrive more than once or arrive before the related workspace information is available. Zerohive keeps records for investigation, but repeating a notification does not necessarily repair missing or incorrect information. If the provider shows a charge while Billing is still waiting or needs review, retain the original purchase reference and payment receipt and contact support. Confirm the existing payment before starting another purchase. No fixed completion time or automatic recovery from every ordering problem has been verified.
What each purchase changes¶
The backend supports several commercial requests with different units and consequences. The current Tenant Admin guide covers the inspected capacity and Billing screen journeys; this table does not imply that every request has a connected self-service screen.
| Request | What to review before proceeding |
|---|---|
| Additional licensed seats | The number being added and the resulting total within the current plan |
| Named seat add-on | The specific access being purchased and its quantity; member assignment is a later step |
| Recurring storage | The capacity increment, recurring commitment and amount due now |
| Scheduled storage reduction | The removable packs, current usage and effective date; a saved reduction has not yet removed capacity |
| Recurring commercial add-on | The named item and price in the active commercial agreement |
| Recurring quantity add-on | The agreed item and unit quantity; these units are not automatically employee seats |
| HiveAI prepaid credits | The selected pack, returned currency and amount; successful checkout still needs verified credit application |
| Plan change | The target plan and final seat total, any amount due now, and whether application is scheduled |
Pricing differs across these requests. Some use remaining-period charges, while others use the full calculated amount. Missing or ended billing-period information can produce a full-period add-on charge. Review the actual saved summary, currency, tax and effective date rather than calculating a charge from the number of days left or from example screens. A HiveAI pack may use a USD catalog fallback when no active local-currency price is available; a negotiated commercial price follows its own agreement.
Returning to the same saved request normally retrieves its recorded terms and progress. It does not automatically refresh its price or make an expired or failed checkout usable again. Keep the original reference and obtain help when its state is unclear. The legacy one-off storage-credit purchase is retired; recurring storage packs are the current storage-purchase path.
What the main states mean¶
| Situation | Meaning | Appropriate response |
|---|---|---|
| Checkout preparing | The change has been recorded and the payment step is being prepared | Keep the reference and reopen the workflow later |
| Checkout ready | A payment link has been produced | Confirm the change, amount and currency before continuing |
| Manual review | The charge or workflow needs investigation | Retain the reference and contact the organization's support route |
| Failed payment or creation | The attempted step did not finish successfully | Read the issue; resume only if a usable checkout is offered |
| Expired checkout | The saved workflow has expired | Stop using the old payment link and reconcile any payment before starting another request |
| Payment verified, change not yet applied | Payment verification has succeeded; application remains separate | Check the workflow and resulting capacity; seek help if they remain inconsistent |
| Scheduled | A future change is recorded without immediate payment | Review its effective date and plan ahead for the resulting allowance |
| Completed | Billing has recorded completion of the workflow | Confirm the result in the appropriate workspace view and retain the financial record |
These explanations include backend states that do not yet have a verified final-screen companion. They do not invent additional buttons or a completion-time guarantee.
Charges, recurring amounts and capacity¶
Use the saved checkout summary for the requested change, including its currency, quantity, subtotal, discount, tax where applicable, amount due and payment requirement. The subscription's recurring amount and a purchase's amount due now are different quantities. Plan and contract terms, eligibility, currency, proration, discounts and tax can affect the result. Illustrative amounts in designs and previews are not current prices or a quotation.
Seat purchases increase licensed capacity. Add-on purchases provide the relevant purchased capacity or entitlement; assigning access to members remains a separate administrative task. Recurring storage packs change storage allowance. A plan change can affect multiple allowances and commercial terms. Consult the capacity guide and member guide before committing to a change.
The current purchase eligibility checks include tenant and subscription status, the selected commercial item, and applicable seat or pack constraints. The design's general “active subscription” wording does not fully express the inspected backend's suspended-workspace recovery exceptions. A visible action is not proof that the request will be accepted.
Invoices and receipt availability¶
The intended invoice experience includes paid, pending-review and failed entries, each with a readable detail page. Receipt actions depend on receipt availability. A payment still under review or a failed payment should not be represented as a paid receipt.
The current tenant invoice service makes only paid invoices available to these views, even though other states are stored internally. Frontend ledger/detail routes now load those records. That does not make the intended pending/failed invoice journeys available through a paid-only query. Page-local filters can also hide an invoice that exists on another page. If a payment or invoice is missing, investigate its original workflow and history rather than assuming it never occurred.
A paid invoice may still lack a receipt link. The lookup returns invoice details rather than generating a new PDF. The current receipt view can open a supplied saved receipt link, while Print and Export PDF use the browser print dialog for the rendered invoice summary. A saved link, local printout or displayed summary does not independently verify a new payment or guarantee that an external receipt remains accessible.
Renewal, payment problems and workspace access¶
A subscription's paid-through time, a payment attempt and a workspace pause have different effects. Current subscription access rules evaluate the precise term and current authority. A paid plan without a usable saved automatic-payment method loses paid-product coverage at expiry; it does not wait for three failed charges. A trial has no paid-renewal grace. An enabled nontrial free plan does not inherit an expired trial's paid-through limit, although workspace, account, membership and product rules still apply.
For an eligible paid subscription with freshly verified usable saved-method authority, grace can last at most three days after expiry. It ends earlier when method validity or the old plan's effective authority ends. A remembered consent choice, past payment, Active label or open connection is insufficient evidence of current grace. An inability to verify the method is different from a proven declined payment. Saved-method guidance explains consent, recording and removal.
The application-managed automatic-renewal path prepares at most three opportunities for the recorded term, with narrow due windows and current authority checks. A pending or uncertain payment can prevent another attempt; missed windows are skipped. These attempts do not extend coverage while payment is unresolved, and the last window does not extend the maximum grace period. A failed attempt can also mean that charging was rejected before any provider request, rather than that a bank declined it.
Legacy provider-managed recurring billing retains separate failure counting and a configurable default suspension recommendation after three qualifying failures. That compatibility mechanism is not the current universal access deadline or automatic-attempt schedule. Named purchase failures can have different consequences from recurring renewal failures; inspect the original workflow and coverage instead of inferring them from a generic payment label.
Verified payment must still become accepted coverage. Current and legacy acceptance can lift a billing-related pause, but do not lift an administrator or support pause merely because money was paid. Member-license restoration also retains account eligibility and capacity limits. Read payment acceptance and workspace recovery when billing succeeds but access remains unavailable. Reminders and email intent do not prove collection, accepted coverage or delivery to a reader; do not wait for an email before checking a recorded expiry.
Responsibilities and boundaries¶
Administrators and finance owners should agree who may request purchases, review scheduled reductions and retain financial evidence. Managers should confirm staffing and storage needs with that owner. Executives should assess recurring commitments and access continuity using actual contract and subscription information, rather than sample totals.
Ordinary users and external participants should contact their workspace administrator when billing affects their work. This documentation does not grant them billing access. Support should distinguish payment uncertainty, verification review, application delay and member-access problems before suggesting another purchase.
Platform finance interventions, refunds, external reversals, private commercial contracts and AI-credit accounting have additional controls and separate implementation paths. Their complete reconciliation remains open; this tenant guide does not imply that self-service refund, payment-method editing or arbitrary manual activation is available.