Understand an unconfirmed hosted payment¶
Draft explanation of implemented payment behavior. Use the linked task guides for the intended screen journey and current implementation differences. Provider, environment and reader walkthroughs remain pending.
A hosted payment takes place on a payment provider's checkout page. The provider can receive your payment before Zerohive receives or finishes processing its confirmation. A missing confirmation therefore needs a check against the original request. Starting a second purchase can make that situation harder to resolve.
The supported status check uses the original saved payment reference. It does not create another checkout or send another charge. Your access and the saved request determine whether the check is available.
Follow the initial workspace guide when you are creating or recovering a workspace. For an existing workspace, follow the subscription and payment guide. Those guides describe the appropriate task sequence; this page explains what the payment check can establish.
Read the outcome before deciding what to do¶
| Outcome | What it means | What to do next |
|---|---|---|
| The payment is still being checked | The provider may still report a pending payment, or the matching receipt may be going through verification and fulfillment. | Keep the original reference and allow that work to progress. Another checkout is not the next step for an uncertain payment. |
| Completion is recorded | Zerohive has recorded the original payment as completed and linked it to a paid invoice. Subscription payments also need their recorded coverage evidence. | Review the relevant billing records and the resulting subscription, purchase or workspace state. A past completed payment does not establish your current access or subscription status. |
| Review is required | This check could not establish a safely matching outcome. A payment detail, saved request or verification result may need investigation. | Preserve the reference and contact support before paying again. Review is not a refund or an instruction to replace the payment. |
| Status is unavailable | The service could not provide a usable result. Access, configuration or a communication failure can prevent a check. | Return to the original saved request when you can check again. If the issue persists, seek help with that reference. A timeout does not establish that no work was saved. |
| The original payment is still required | Zerohive still records the original request as payable and may retain its checkout link after checking the provider. | Check the original request and any payment evidence before continuing. If your bank or provider already shows a charge, seek reconciliation before another payment. |
These are explanations of the outcomes, rather than a promise that every screen uses those exact words. A result describes the check that produced it; processing can continue and a later saved-state read can show a different outcome.
A remaining link has limits¶
The check can retain the existing link when the original request still permits payment and the provider returns the supported no-transaction response. It does not issue a replacement link or prove that the provider's page remains usable. A well-formed saved link can still fail to open or expire at the provider.
If a displayed link and your payment evidence disagree, keep the original reference and have the outcome checked. A missing provider result alone is not proof that a delayed payment cannot arrive.
For a failed or expired subscription checkout, read the controlled retry rules. Replacement eligibility has its own reconciliation and authority checks. Status checking does not waive them.
Payment, purchases and saved methods are separate¶
A matching provider receipt is followed by verification and normal billing processing. The status can remain in checking while that work completes. Review the billing records, subscription access, or capacity and allowance guide for the result relevant to your purchase.
A supported manual payment can settle its original purchase without creating a reusable card or authorizing automatic renewals. Use the saved payment-method guide to understand the separate method and authorization requirements. Native payment authorization and automatic-renewal recovery also retain their own flows.
An initial subscription can be paid before completion is recorded¶
For an eligible initial workspace subscription, the original payment check can reconcile missing completion records after confirming the provider receipt and Zerohive's recorded payment acceptance and workspace preparation. This repairs the original request; it does not ask the provider to charge again. If those facts cannot be confirmed, the result can remain checking, unavailable or in need of review. Keep the original reference and use the existing recovery or support path instead of starting a second purchase.
That repair keeps the original paid invoice, tax and accepted subscription period. It does not start a new paid term, extend the earlier period or authorize a refund. An invoice, a verified payment, completed preparation and current product access answer different questions. If a refund or reversal is already under review, have that resolved through the appropriate support process before relying on the payment for another action.
A completed billing request's displayed total describes the recorded transaction. It is not a new amount to pay. A payment marked verified can still be waiting for its purchase or subscription to finish applying; follow the current result rather than an older payment link.
Get help with the original request¶
Initial workspace recovery follows the original request's ownership rules. Existing-workspace billing uses your current workspace billing access. An earlier session or a copied reference does not grant access; see billing access.
Give support the workspace, original request reference, approximate payment time, amount and currency, displayed outcome, and relevant bank or provider confirmation through the approved support channel. Explain whether you are waiting for payment confirmation, an invoice, the purchase to apply, or access to the workspace. Those are different investigation points.
Keep passwords, verification codes, complete card details and temporary payment links out of ordinary support messages.