Use the Billing tab to review subscription state, plan usage, billing actions, and authorised environments.

Billing is where Payloads shows what the org is entitled to use and whether the subscription service is keeping that information up to date. In production, this is also where admins can manage billing actions. In sandboxes and scratch orgs, it helps confirm whether the environment is authorised to inherit the production subscription.

Billing also shows whether the subscription service is running. That service checks the Payloads Hub for current plan and entitlement details.

The subscription service must keep running successfully. If the service stops or cannot refresh subscription state for any reason, Payloads enters a seven-day grace period. If the issue is not resolved within that period, Payloads will stop operating until the subscription service can verify the org again.

Billing shows the local subscription state and the actions available for upgrading, managing billing, or authorising environments.

When Payloads is first installed, Billing may ask you to start the subscription service.

Start the service so Payloads can check this org's plan and entitlements with the Hub. After it starts, Payloads schedules regular subscription checks.

If the first check fails, Billing shows the error and Payloads retries automatically. Review the visible error before making configuration changes elsewhere; a subscription check problem is usually separate from Payload or Credential setup.

Do not ignore subscription service failures. Payloads can continue during the seven-day grace period, but it is a short recovery window rather than a permanent fallback.

The Current Plan card shows the active plan name and subscription state.

Use this to confirm whether the org is verified, in a grace period, payment-required, unverified, or otherwise needs attention. If a user reports that something looks restricted, check the current plan and state before assuming the Payload configuration is wrong.

The Home tab also surfaces subscription state when it needs operational attention.

If the org is in a grace period because subscription checks are failing, fix the subscription service before the seven-day window expires. After that, Payloads will cease to operate until verification succeeds again.

Billing shows current usage against plan limits.

Payload usage is based on the number of Payloads in the org. Transformation usage shows whether Transformations are enabled for the current plan and how they are being used.

If usage is close to a plan limit, review whether old or unused Payloads and Transformations should be cleaned up before upgrading. A tidy configuration is easier to support and makes plan usage easier to explain.

Use Refresh subscription when Billing looks stale or when you have just changed a subscription, plan, or authorised environment.

Refresh asks the Hub for current subscription details and updates the local subscription state.

If refresh fails, review the error shown in Billing and check whether the org can reach the Payloads Hub. Do not edit subscription state records manually to force a different result; the local state should come from the subscription service.

A failed refresh should be treated as an operational issue. If refresh continues to fail, Payloads may stop operating after the seven-day grace period.

In production billing mode, Billing can show Upgrade and Manage Billing actions.

Use Upgrade to open available plan options. Use Manage Billing to open the billing portal for the current subscription.

If Billing says billing is managed from production, open the production org that owns the subscription. Sandbox and scratch orgs may show subscription information, but the production org is usually where billing actions are managed.

Production orgs can authorise selected sandbox and scratch orgs to inherit the production subscription.

Use Environment Access to add or remove authorised environments.

In a sandbox or scratch org, Billing may show instructions to authorise the org from production. Copy the org id from the sandbox and add it in the production org's Billing tab.

Paid entitlements apply after the authorised environment's next successful subscription check. If the sandbox still looks unverified, refresh subscription or wait for the next service run.

Payloads stores subscription state locally so the app can make runtime decisions without calling the Hub on every action.

The local state includes plan name, usage counts, last checked time, subscription status, failure counts, grace period information, and the production org id where relevant.

Do not edit subscription state records manually unless Payloads Support specifically asks you to. Manual edits can make Billing look temporarily different without fixing the underlying subscription check.

When reviewing Billing, check that:

If billing information looks wrong after refresh, capture the visible error and contact Payloads Support.