Retry a subscription checkout without losing payment history¶
A failed or expired checkout does not prove that no payment occurred. Subscription retry first reconciles the old attempt, then decides whether a linked replacement is allowed. It keeps the old reference and the subscription terms so that recovery is not treated as an unrelated purchase.
This page describes the linked-replacement recovery contract. The existing Billing task guide follows inspected Final Screens; a connected action for every retry outcome has not yet been verified. The rules here do not introduce a new button or promise that a preview link can take payment.
The separate saved-checkout investigation can retire one blocking noninitial intent only under its explicit staging-test grant. It does not create this linked replacement or preserve an earlier price for a new quote. Its current-account absence exception cannot be used to bypass the protocol and verified-payment rules below.
Which requests qualify¶
Retry eligibility depends on the saved payment protocol as well as its state. The ordinary entry permits failed or expired subscription-payment workflows; native payment also has a narrow ready-state entry that must independently reconcile a dispatched failed or voided attempt. A ready label alone does not authorize replacement. A request waiting for verification, under manual review or completed cannot be replaced simply to get another link.
An eligible organization administrator must act for the correct workspace. Initial workspace checkout has a narrower recovery path available before an organization session is selected; see billing access. If the original payment request included consent to save a payment method, another administrator cannot use this retry to take over that consent. The original requesting account must satisfy the current administrator checks.
What the platform checks before a replacement¶
Current hosted-v3 checkout cannot be replaced through the historical link-closure verifier. Its unknown or interrupted outcome needs its own verified receipt and reconciliation. Native payment checks the saved merchant-owned attempt and independently verifies its result before closing it for retry; missing or undispatched attempts are insufficient. Only failed or voided native evidence can authorize that closure.
The compatibility hosted path first asks the provider to disable the saved link, then checks the matching reference, transaction and currency. Its outcomes below apply to that path, rather than to every modern payment.
| Reconciled outcome | Consequence |
|---|---|
| Definitively failed or cancelled, with the expected amount or zero charged | A replacement may proceed after current administrator and subscription checks. |
| Successful for the expected amount | The existing payment is sent for normal verification; a replacement is blocked. |
| Pending, missing transaction, inconsistent identity/currency/amount or unconfirmed closure | The outcome remains unresolved. A replacement is blocked. |
| Automatic renewal failed before any provider dispatch was recorded | A narrow separate path can permit retry without a provider transaction to reconcile. |
A hosted attempt with no saved link is not automatically eligible for replacement. Contact support if the available status cannot establish what happened. Do not interpret a missing provider lookup result as proof that no payment can arrive later.
Terms and history stay connected¶
A replacement preserves the original intent, plan reference, seats, currency, net amount, coverage boundary, billing cadence and payment-method consent. The server validates these against current subscription state. This is not a way to silently change the plan, price, coverage period or consent while describing the action as a retry. Review the displayed total and any tax on the resulting checkout.
When a replacement is accepted, the original local subscription-payment intent is cancelled and the new intent is linked to it. That cancellation is not a refund or proof that an external transaction was reversed. Repeating recovery for the same original resolves to its existing linked replacement when it can be verified; it must not create an unlimited series of unrelated replacements. Changed terms, another pending payment or an already-paid renewal can prevent a new request.
Understand the response and get help¶
A retry acknowledgement identifies the replacement workflow and its recorded state. It is not a payment receipt, an immediate checkout URL or proof that subscription access has been restored. The workflow may still be preparing while its background work arrives. Keep both the original and replacement references.
If the earlier payment is being verified, wait for that investigation rather than beginning another purchase. If the subscription terms changed, review the current workspace and checkout state before deciding what is now required. If authority cannot be checked, the result is uncertainty rather than permission to bypass recovery.
Give the administrator or support team the workspace, original and replacement references, displayed states and relevant payment time through the approved support channel. Distinguish payment verification from subscription application and member access. Never send passwords, session tokens or full card details.
See checkout creation and uncertainty for the distinction between a saved request, dispatch, a ready link and local expiry.