Moving renewal billing into Zerohive¶
Some organizations have an existing recurring subscription managed by the payment provider. Moving renewal billing into Zerohive asks that provider to stop its old recurring schedule, verifies the result, and then removes the old schedule from the organization's billing record. This transition preserves the accepted paid term. It does not itself buy another term or enable a new automatic payment method.
This explanation describes the inspected implementation. The matching screen journey and availability in your environment still need verification.
Who can request the transition¶
The requester must be a current, active organization administrator. The organization must be active or suspended specifically for billing. A request can fail if the old subscription cannot be identified reliably, there is no applied paid term, a trial is in progress, a plan change is scheduled, or a payment remains pending or under review.
The system keeps one pending transition for a subscription. A second request while it is pending refers to that existing transition. It does not replace the original requester or start another cancellation. If there is no provider-managed subscription attached, the response can already describe application-managed billing without creating a transition.
What happens after the request¶
| Stage | What it establishes |
|---|---|
| Request saved | Zerohive has recorded the intended change and its original subscription details |
| Current authority checked | The saved request still matches the organization, subscription and authorized administrator |
| Cancellation started | Zerohive has recorded that it is about to contact the provider |
| Provider cancellation verified | A separate provider read confirms the specific old subscription is cancelled |
| Change applied locally | Zerohive has accepted the matching confirmation and removed the old provider billing references |
A saved-request acknowledgement is not the same as a completed change. An interrupted response does not establish whether cancellation succeeded. The system retains the original transition for recovery.
Before starting the provider request, current authority is checked again. If it is no longer allowed, the transition is rejected without starting that cancellation. After a cancellation has started, recovery needs to establish its outcome even if authority later changes; it must not assume the external action did not happen.
An older provider integration may require historical reconciliation that the current provider adapter cannot safely perform. In that case an authorized request can remain unresolved before cancellation is dispatched. A saved or uncertain transition therefore does not prove that the provider received a cancellation. Support must establish both the dispatch evidence and the actual provider result.
What stays paid¶
When the confirmation applies, the current plan, licensed seats, subscription status and paid-period dates stay as they were. For example, a term paid through 31 October remains paid through that date merely because its renewal owner changes. This operation does not issue a refund, erase a receipt or start a fresh billing month.
The old provider subscription and plan references are removed. Existing automatic-payment eligibility is also revoked. The transition does not silently transfer old consent into a new automatic-renewal arrangement. A later qualifying checkout and current saved-method checks are separate; see saved payment methods and consent.
If access was relying on conditional renewal grace, removal of automatic-payment eligibility can affect that access. An unexpired paid term and conditional grace are different. See subscription access and how paid periods are accepted.
When the result is uncertain¶
A timeout, unavailable provider or incomplete cancellation evidence leaves the result unresolved. Recovery checks the recorded transition and reads the provider's state. It does not blindly send another cancellation after the recorded start.
An unresolved transition can therefore need investigation. Background reconciliation is not a promise that the provider will answer within a particular time or that every case repairs itself. A successful cancellation acknowledgement alone is insufficient: verification must also find the exact old subscription in consistent cancellation evidence.
Keep the original transition reference when contacting support. Ask whether the request was saved, whether external cancellation started, whether cancellation was verified, and whether that confirmation was applied locally. Avoid using a new payment or unrelated cancellation as a test of the outcome.
A delayed notification about the old provider subscription does not automatically mean that paid access should be reset. The implementation checks whether that subscription is still the current provider owner and protects a pending ownership transition. Support should reconcile the original transition before treating an old notification as a new cancellation request.
After completion¶
Check the paid term, current billing owner and automatic-renewal readiness separately. A completed owner change can preserve paid access while leaving automatic renewal unavailable. Use renewal timing to understand later application-managed attempts and billing access and recovery when ordinary paid-product access is unavailable.
The existing provider renewal explanation covers accepted receipts and delayed payments from the earlier arrangement.