Checkout creation, readiness and uncertainty¶

Requesting a payment starts a saved checkout operation. Zerohive records its terms before contacting the payment provider. A hosted checkout can then provide a payment link; the separate native-payment protocol can prepare a payment without a hosted link. A request acknowledgement, a ready checkout and a verified payment are different stages. The current mounted billing status view presents hosted payment; native backend services alone do not establish an available native payment form.

This page explains the inspected backend behavior. It does not add screen steps or assume that the work-in-progress frontend exposes every state.

The conditional payment-method explanation covers native manual methods, bank verification and their current availability limits. An empty native method list is not proof that a hosted checkout is unavailable, and implemented native services do not establish a mounted payment form.

From saved request to payment link¶

A link is an invitation to pay, not a receipt. Returning from the provider page is also not, by itself, proof that paid coverage or a purchased feature has been applied. Read payment notifications for the handoff into verification, then payment acceptance and coverage for the subscription outcome.

A repeated request must still fit its original organization, reference, amounts, currency, target terms and consent. Reusing a reference does not permit a different purchase to replace the saved one.

Amount, tax and consent¶

The checkout uses the saved net amount and the configured tax quote. Applicable tax is added to obtain the total sent to the provider. Once a tax quote is stored for the workflow, resuming checkout preparation reuses it; a later tax configuration change does not silently reprice that saved checkout.

The system uses its configured country tax history for the request time. A zero tax line describes that calculation, not an independent determination of tax obligations. Check the final currency, net amount, tax and total alongside the original request.

For an application-managed subscription checkout, the payment is created without a separate provider recurring schedule. A hosted one-time payment can establish paid coverage without saving a card or granting renewal consent, once verification and application succeed. If you explicitly choose to save a card and pay by card, that path also requires matching verified card and stored-method evidence. Native card payment has separate acceptance requirements. Paying once does not create a new saved method or automatic-renewal eligibility. A provider can already have collected money while verification, required method storage or fulfillment still needs reconciliation; do not pay again to repair that gap. See saved payment methods and consent.

Some older workflows use provider-managed recurring subscriptions. Their recurring-plan creation and eventual billing-owner transition are separate from the newer subscription checkout.

Why an interrupted result needs reconciliation¶

The provider may receive a request even when Zerohive does not receive its response. The durable creation-start record prevents a later delivery from assuming that no external request happened.

If creation throws an error after that record is saved, the workflow is marked for review with a general explanation. If processing is interrupted, the saved start can remain until recovery examines it. Reprocessing that recorded start does not blindly create another checkout.

An uncertain result therefore does not establish that no link exists, that no charge can occur, or that payment failed. Keep the original checkout reference. Support needs to reconcile the provider result and the saved workflow before authorizing any replacement.

Likewise, a provider may return a link before the final local save succeeds. Until that result is reconciled, the original operation remains the relevant evidence; starting another checkout can obscure what happened.

Local expiry¶

The default pending-payment expiry setting is 24 hours, with processing driven by the hourly billing job. Configuration and processing time affect when the state changes, so this is not a promise that a link closes at an exact minute.

The expiry sweep selects eligible pending, preparing and ready workflows by their original creation time. It does not treat a known in-progress dispatch or a manual-review state as an ordinary unpaid checkout to expire.

Local Expired means the platform's workflow has aged out under that rule. The expiry sweep does not itself disable the provider link or verify the final provider transaction. A controlled checkout retry must establish the original result and close the old checkout where required before creating a replacement.

The age of a saved payment link alone does not establish whether the provider will still accept it. Zerohive does not infer provider expiry from an assumed one-hour link lifetime. Use the current checkout result to understand the platform's status, and retain any provider receipt if opening or completing payment fails. A displayed link is not proof of payment; a failed opening is not proof that a previous payment failed. Follow the existing reconciliation or retry guidance before making another payment.

Expiry of an initial workspace checkout also has a separate onboarding consequence. Expiry of another billing workflow must not be interpreted as deletion or cancellation of the organization.

Scheduled changes and automatic renewals¶

A zero-cost scheduled plan change does not need a provider checkout. Billing records its effective date, and application is handled separately; see plan changes.

Automatic renewal uses a stored-method dispatch and verification path rather than presenting a hosted checkout for that attempt. See renewal timing and recovery. A checkout-ready status, a saved method and an automatic charge are not interchangeable.

Information to keep when asking for help¶

Keep the original organization and checkout reference, the status shown, whether you reached the provider, and any provider transaction receipt. Describe whether the issue is a missing link, interrupted creation, a payment awaiting verification or a purchase awaiting application. Do not make a second payment merely to discover which stage the first one reached.