Saved payment methods and renewal consent¶

A saved payment method can let Zerohive request a later subscription payment with the consent recorded for an earlier checkout. Paying for a term, agreeing to save a method, successfully saving it and qualifying for automatic renewal are separate outcomes. This explanation covers the inspected backend; the connected screen journey and environment availability still need verification.

What saving a method means¶

Consent belongs to a particular subscription checkout, organization and requesting account. The system retains the original choice when recovering that checkout. Reusing a request must not silently add consent or replace the person who gave it. A successful payment without saving a method can still establish paid coverage.

The hosted checkout supports a one-time payment without saving a card. That payment can establish paid coverage after verification and application, without granting renewal consent. If saving a card is explicitly selected, completing a card payment on that path requires consent and a verified stored card matching the original organization, checkout and payer context. Native card payments have separate acceptance requirements. Selecting an option does not prove verification or storage succeeded. The current workspace-creation form exposes renewal consent; this does not establish a connected consent or removal control in every Billing journey.

Validity depends on the verified payment path. Hosted and older token-based recording apply a one-year cap as well as card/token expiry; the native method path uses its verified card expiry and current merchant eligibility without that universal one-year rule. Current checks can shorten usability further or reject a revoked, changed or unavailable method. Check the recorded validity and current eligibility rather than calculating it from an old receipt or assuming every integration uses the same limit. No validity timestamp guarantees that the provider will accept a charge.

Payment success and renewal readiness¶

Payment success, stored-card verification and automatic-renewal eligibility remain separate. A hosted one-time payment does not require creating a new saved method. A payment on the explicit saved-card path must complete its required method recording before paid-access acceptance; a provider may already have collected money while that step still needs reconciliation. Manual payments do not create saved-card consent. A verified stored card can also exist while current merchant authority makes automatic renewal unavailable. Older compatibility verification has different optional-recording behavior; it must not be treated as the rule for every current card payment.

If payment appears successful but method saving or coverage is unfinished, preserve the original payment reference and ask support to reconcile it. Do not pay again solely because automatic renewal is unavailable or the expected paid access has not appeared. Inspect the accepted paid term and saved-method state separately.

Automatic charging also requires the environment to enable it and current checks to accept the stored method. A record of past consent, a receipt or a remembered card expiry does not establish present readiness. Accounts still billed through a provider-managed subscription have a separate billing-owner transition; saving a method must not be interpreted as permission for two owners to collect the same term.

A usable saved method can support the conditional paid-renewal grace described in subscription access. It does not extend a trial, buy another term or override suspension and product permissions. If current method authority cannot be verified, that is a verification problem, not proof of a declined payment.

The renewal timing explanation describes the three possible attempt windows and why an unresolved payment blocks another attempt.

What removing consent changes¶

Removal requires current organization administrator authority. Once the local revocation is committed, the method no longer supplies automatic-payment eligibility or paid-renewal grace. Existing paid coverage is not shortened merely by that removal. If access was relying on grace rather than an unexpired paid term, it can cease when current authority is checked.

An older checkout must not restore consent after its removal. The code records the revocation time and rejects saved-method evidence belonging to a checkout created at or before it. A later successful capture on that old checkout may still establish paid coverage while leaving automatic-renewal consent absent. Newly granted consent needs its own later qualifying checkout; replaying the old result is insufficient.

Removal also requests cleanup of the stored method. That cleanup runs separately from the administrator's acknowledgement. An acknowledgement is therefore not evidence that every storage cleanup step has finished. The operation does not itself cancel a separate provider-managed subscription, reverse a completed charge, issue a refund or establish the outcome of a payment already in flight.

Resolving an uncertain result¶

After an interrupted removal or payment response, preserve the original operation or checkout reference and ask the administrator or support to reconcile that action. Distinguish these outcomes:

Use billing access and administrator recovery when paid-product access is unavailable. Use the checkout retry explanation for an eligible failed or expired checkout. A saved-method issue alone is not a reason to create a replacement payment.