How a payment becomes subscription coverage¶
A successful provider payment, an accepted subscription term, a completed billing workflow and a usable workspace are separate milestones. This explanation describes the inspected backend for application-managed initial subscription payments, trial conversion and renewal. Provider-managed legacy renewal and plan-change application have additional rules; the connected screen journey and deployed availability remain separately unverified.
Payment must match the saved request¶
The platform records the organization, plan, licensed seats, currency, amount, term, billing cadence and consent before applying a payment. Verification must match the saved checkout. Changing the current subscription while an earlier payment is unresolved can make that payment need reconciliation rather than automatic application.
A hosted one-time subscription payment can establish paid coverage without saving a card or granting renewal consent. Verification must still bind the payment to the saved organization, checkout, amount and currency, and the platform must apply the paid term. When card saving is explicitly selected and the provider payment uses a card, its separate verification and method-recording requirements must also succeed; native card payments retain their own acceptance rules. A provider may already have collected money while fulfillment is incomplete. Reconcile the original payment instead of paying again. Paying once does not create a new automatic-renewal method; see saved methods.
A pending result is different from a confirmed failure. A paid amount that does not match the saved request is also a reconciliation issue. Preserve the original payment and workflow references; paying again does not resolve the mismatch. The retry explanation describes when a replacement is eligible and why the original result must be settled first.
The paid term uses the acceptance time established through server-side verification and the saved subscription terms. Dates supplied with a provider notification do not independently grant an arbitrary coverage period. The paid invoice's total can include tax, while the subscription intent also retains its underlying net amount.
When the new term starts¶
| Payment situation | Coverage behavior |
|---|---|
| Initial subscription or trial conversion | The paid term starts at acceptance; trial conversion does not wait for the remaining trial to finish |
| Renewal accepted before current expiry | The new paid interval starts at the existing expiry, preserving the time already paid for |
| Renewal accepted exactly at expiry | The next interval starts at that boundary |
| Renewal accepted after expiry | A full new term starts at acceptance and uses that new billing day |
| The same accepted payment is delivered again | Matching evidence is recognized without buying another term or moving its dates |
The inspected ledger supports one-month and twelve-month cadences. Calendar months are not fixed thirty-day periods. A short month uses its last available day while retaining the original billing day for a later timely renewal. For example, a monthly term beginning on 31 January 2027 at noon UTC ends on 28 February at noon; an early or on-time renewal then ends on 31 March at noon. A renewal accepted late on 1 March instead starts its new term then and ends on 1 April.
An early renewal keeps the current period's original start while recording the future interval purchased by that payment. Read the individual payment's paid interval and the overall paid-through date together. A scheduled plan change may also defer application of its target terms; payment acceptance alone should not be treated as proof that the new plan is already active.
What happens to existing access and add-ons¶
An accepted payment can reinstate a workspace suspended for billing. It does not remove a suspension imposed for another reason. People still need eligible accounts, memberships, product assignments and permissions. Automatic restoration of previously downgraded memberships depends on the platform's current eligibility and capacity rules; payment does not guarantee that every person regains every prior access right.
An add-on already scheduled to end does not gain an extra term merely because the base subscription was renewed early. Its original scheduled end remains relevant. Review the continuing items in the renewal quote rather than assuming all past extras are included.
An initial payment starts workspace provisioning as a separate step. Recording paid coverage does not mean infrastructure preparation has completed or that the workspace can already be opened. Use the current workspace state as well as the payment state when deciding whether setup needs attention.
Invoice dates and delayed updates¶
Platform's accepted paid interval is sent to Billing for the matching paid invoice. The accepted interval replaces provisional provider dates once. Repeated identical evidence retains those dates; conflicting accepted periods require reconciliation. The recorded next-payment date follows the accepted period end and does not guarantee a successful automatic charge at that time.
Invoice creation, accepted coverage and workflow completion can arrive separately. A missing or provisional invoice period is not sufficient proof that the payment failed. Likewise, a completed-workflow label alone is not a substitute for checking current coverage and workspace readiness. Ask support to compare the saved payment, accepted period and invoice when they disagree.
Use subscription access for exact expiry and grace rules and billing access for administrator recovery. Keep the original reference and observed message when reporting a mismatch. An unresolved payment should be reconciled before another purchase is attempted.
See plan-change requests and pricing for target seats, prepaid price differences and zero-net scheduled changes.