Payments from an existing provider subscription¶

An organization may still have a recurring subscription managed by the payment provider. Zerohive can recognize payments from that existing arrangement after independently verifying the transaction and its subscription. Recognizing a receipt does not authorize a new charge or create a second renewal schedule.

This page explains the inspected backend behavior. It does not introduce a new screen journey. For application-managed checkout payments, use payment acceptance and coverage.

What a renewal must establish¶

A payment notification is a starting point for verification. Zerohive needs evidence that the transaction succeeded, belongs to the expected provider subscription and payment plan, uses the expected currency, and has a verified monthly or yearly billing interval.

An ambiguous subscription association, incomplete response or mismatched payment goes to reconciliation. The system does not take the first matching-looking subscription from an incomplete list. Dates supplied in the notification do not determine the accepted paid term.

The current organization must still have the corresponding provider subscription and a paid plan with an existing expiry. A renewal cannot convert an unrelated trial or activate a workspace that is still awaiting its first payment. Scheduled plan changes and stale payment evidence have separate reconciliation rules.

How the next paid term is calculated¶

The end follows the saved monthly or yearly interval in calendar months. Existing month-end anchors are preserved for early and on-time renewals. A late acceptance establishes a new anchor.

For example, an early monthly renewal of a term ending on 31 January starts on 31 January and ends on 28 February in 2026. With the original anchor retained, the following on-time term can end on 31 March. If verification is delayed until 3 March after a 28 February expiry, the accepted new monthly term runs from 3 March to 3 April. A provider's earlier charge date does not backdate that late accepted term.

A payment must also be recent enough for the current unpaid renewal boundary: its provider creation time cannot be earlier than five days before that boundary. Once the term advances, another receipt with an old creation time does not automatically buy the next term. A charge that cannot be applied still needs investigation; rejection from automatic application is not a refund receipt.

Repeated notifications and conflicting evidence¶

The accepted receipt retains its transaction, provider subscription, plan, amount, currency, interval, provider creation time and paid dates. Replaying that same receipt does not add another month or year.

If a later notification changes the accepted evidence, support must reconcile it. A different transaction is not automatically another valid term merely because the organization has already paid. Keep both transaction references if there appears to be a duplicate charge; do not create a third payment to test access.

An already accepted receipt can remain valid history after billing ownership changes. New receipts arriving after the old provider references have been removed require reconciliation against that change. See moving renewal billing into Zerohive.

Access, invoices and billing status¶

A newly accepted renewal can clear a suspension specifically caused by billing. An administrative suspension remains in place. Restoring the paid term also does not guarantee that every former member receives a licence: current account eligibility and available capacity still apply.

The invoice receives the exact accepted coverage through a separate update. Payment verification, the paid invoice and the organization's accepted term can therefore be at different stages while processing completes. If their dates disagree, reconcile the original transaction and accepted term before treating the difference as evidence that payment failed.

A notification may have supplied provisional dates before Platform computed the real term. Once the invoice has accepted the matched coverage, a later copy of those provisional dates must not replace it. This protects the recorded period without claiming that every unrelated invoice field is immutable.

Checkouts started before the newer payment process¶

An older initial checkout or plan change can need its saved billing information imported into the current subscription-payment records. Zerohive reads the original checkout, verifies its transaction again where payment is required, and checks that its organization, plan, seats, currency, amount and timing still fit.

For an initial checkout, the organization must still be awaiting payment and the saved provider association must fit that checkout. A valid saved contract price is retained; the current catalogue price is not silently substituted. Accepting payment begins the separate provisioning process rather than proving that the workspace is ready.

An old plan change may require support when another term has since been paid, the original change window has passed, or an ownership transition is pending. Its saved request is not permission to overwrite the organization's newer state. Complete plan-change timing is covered in the dedicated plan-change work still awaiting reconciliation.

Information that helps support¶

Keep the organization name, original checkout or renewal reference, provider transaction reference, expected billing interval and the paid dates currently shown. Describe whether the issue concerns payment verification, access, the invoice period or an older checkout. Share ordinary receipts through the approved support channel; a card token or stored payment secret is not needed for these comparisons.

Use billing access and recovery for administrator access during a billing interruption, and subscription access to distinguish an unexpired paid term from conditional renewal grace.