Payment notifications and what happens next¶
A payment provider can notify Zerohive after a charge succeeds or fails, or after a provider-managed subscription changes. Receiving that notification is one step in the billing process. It does not, by itself, establish that your subscription has been paid, your purchase has been applied or your workspace is ready.
These processing rules run behind the billing screens. The frontend is still being completed, so some stages may not yet have a visible status indicator.
Processing also depends on the payment integration configured for the environment. The current hosted-payment callback path handles supported completed-payment notices; other event types can be acknowledged without reaching the older processing path. Older recurring subscriptions and native payments need their matching integration and recovery checks. A provider's delivery acknowledgement alone does not establish that a cancellation, failure or subscription update was applied.
When a payment is reported as successful¶
Zerohive associates the notification with its saved payment and requests independent verification. The exact receipt and invoice steps differ between current hosted payment, native payment and older compatibility workflows. Verification checks the provider's evidence against the saved purchase. The relevant service must then accept and apply the business change.
For a subscription, those later checks establish the accepted payment and coverage dates. An initial workspace also needs its separate provisioning work. An additional seat, storage purchase or AI-credit purchase has its own application path. A provider success message therefore cannot promise that every part is available immediately.
See payment acceptance and coverage for subscription dates and replay rules, and checkout creation for the stages before payment.
Renewal reminders¶
Zerohive checks for renewal reminders on an hourly schedule. An active organization with an active subscription and a future next-payment date can qualify for reminders at 14, 7 and 1 days before that date. These are processing milestones, so an email is not promised at an exact hour.
If processing catches up after more than one milestone, it chooses the nearest relevant reminder and records the older missed milestones as skipped. For example, a first check about five days before renewal can issue the seven-day reminder and skip the fourteen-day reminder. It does not send every missed notice together. A reminder already recorded for that renewal date and milestone is not an instruction to send it again.
The notification path requests the organization's billing contact and active organization administrators as recipients. Actual recipients and delivery depend on the notification service and email delivery. An internal record labelled sent belongs to the request-to-send stage; it does not certify that someone received or read an email. Missing email also does not extend coverage or authorize another payment attempt.
The reminder amount comes from the organization's recurring billing snapshot. It is not a newly calculated renewal quote, accepted invoice or proof of a charge. Review the current payment summary, applicable tax and accepted coverage when a payment is required. See renewal timing and recovery for the separate rules governing automatic attempts.
Repeated, delayed or unmatched notifications¶
Providers may deliver the same notification again. Zerohive uses protocol-specific saved receipt identities and binding checks to handle repeats; older compatibility receipts have different duplicate rules. This is not a promise that every late, altered or out-of-order message will automatically reconcile every billing state.
A notification that cannot yet be associated with an organization can be retained without applying a purchase. A later delivery may make that association possible. This does not create a new payment or authorize a different organization to use the original payment.
Keep the original organization, checkout reference and provider transaction receipt when asking for help. State whether the payment was reported successful, whether a paid receipt is visible and whether the subscription or purchase has actually changed. These are separate observations. Support may need to reconcile the saved request and provider evidence before deciding what to do next.
Do not make another payment simply because the original notification is delayed or a purchase is still being applied. Use the checkout recovery guidance for interrupted or uncertain attempts.
When a charge fails¶
A failed charge can mark the related billing workflow and invoice as failed. A failed recognized one-time checkout does not enter the legacy recurring-payment collection counter. This classification includes application-managed initial subscriptions, trial conversions, renewals, plan changes and the supported one-time purchase workflows.
Automatic subscription renewal also has its own attempt, verification and recovery rules. Read renewal timing and recovery; the legacy provider failure counter is not the schedule for those attempts.
For older provider-managed recurrence, qualifying failure notifications can increase a consecutive-failure counter. The default recommendation threshold is three. Below the threshold, the subscription can be marked past due. Reaching the threshold requests billing suspension, but Zerohive checks the current commercial access before applying it: valid paid access or grace does not become blocked merely because a counter reached three.
A billing suspension also does not replace an existing suspension for another reason. The current subscription, commercial coverage and suspension reason matter more than a failure count on its own. See subscription access.
When a provider subscription changes or is cancelled¶
A routine subscription-update notification cannot establish a new billing owner or replace the current provider subscription. Zerohive accepts it for synchronization only when it still matches the current provider subscription and plan, with no billing-owner transition pending.
A cancellation matching the current provider-owned subscription can move the organization through the configured fallback-plan and providerless-billing rules. It can remove paid storage capacity and affect plan eligibility. An old subscription's cancellation is ignored, and an in-progress billing-owner transition is handled through its own confirmation process.
The change of billing ownership preserves the accepted paid terms under different rules. Do not treat its provider cancellation as a request to discard those terms or cancel the organization.
When the initial workspace checkout expires¶
Expiry of an initial subscription checkout has a separate onboarding consequence. If the organization is still awaiting its first payment when Zerohive handles the expiry, the workspace enters the closed lifecycle state called deprovisioned, and its subscription is cancelled. This expiry rule does not close a workspace that has already moved on to provisioning or active use.
This local expiry decision does not itself close the provider payment link or prove that no payment was received. It also does not certify that all downstream cleanup or data removal has completed. An uncertain or late payment needs reconciliation against the original checkout and the current workspace state.
Expiry of another kind of billing workflow does not trigger this initial-workspace closure rule.
Scheduled changes with no payment today¶
A plan change or recurring storage reduction can be saved for a future effective date without requiring payment today. When its scheduled processing becomes due, Zerohive requests application of that saved change. It still has to be applied by the service that owns the organization's plan or capacity.
A due activity or a workflow waiting for application is therefore different from an applied change. A payment-related date on a no-payment change is not by itself a receipt that money was collected. Check the requested change, its effective date and the resulting subscription or capacity. Keep the original workflow reference if the expected change is delayed. See plan changes and the Billing task guide for the intended review and tracking journey.
Payment information retained for reconciliation¶
Zerohive's receipt record retains a short digital fingerprint instead of the full notification message. Current hosted receipts use minimal payment-identity content rather than retaining the complete incoming body. Selected fields needed for billing, such as transaction reference, amount, currency and customer contact, are handled separately where that protocol supplies them. This does not mean that billing records contain no personal information, or that every fingerprint represents a copy of the entire original message.
For support, provide the checkout reference and ordinary transaction receipt. Never send a card security code, full card credentials or payment token.