Usage, automatic top-ups and limits

Find the active allowance#

Read the used/allowed figure as the current paid pool, including any credited top-ups. For example, a Core period with one paid 100-unit purchase can show a capacity of 600 rather than the original 500. That additional capacity belongs to the same monthly usage period. Billing's annual renewal date does not extend it across the whole year. If the workspace has multiple websites, review their combined demand; the automatic purchase is for the workspace, not a private allowance for whichever site reached the boundary first. Manually granted access is not automatically eligible for the subscription's off-session purchase flow.

When a top-up is purchased#

Each top-up has a $10 USD subtotal for 100 conversation units, plus applicable tax. The actual payment and history amount can therefore be higher than ten dollars. The service needs a usable billing customer, active subscription and reusable payment method; the On setting alone cannot supply those. Capacity is credited only after the payment is verified, once for that purchase. A worker restart, duplicate payment event or a delayed response must not independently credit another hundred units. If a payment completes after its intended usage period is no longer active, it must not silently move that credit into a different month.

Turn automatic purchasing on or off#

Review the switch before a campaign, integration test or unexpected traffic increase. Automatic purchases are enabled by default for the ordinary billing experience. Turning them Off prevents creation of a new automatic purchase after the change is applied, but an already initiated purchase can still finish. This timing matters if the counter reached its boundary just before the change. Off does not cancel the subscription or erase existing paid capacity. New base windows and extra answer groups still require available capacity; the switch is purchase authorisation, not permission to serve an unlimited unpaid overage while a payment is pending.

Understand the payment history#

Use the status to decide the next action. Paid means the payment was verified and its credit was processed; Pending means you should investigate or wait for that existing purchase rather than create another one. Requires action needs the legitimate payment-authentication path. Failed provides no paid capacity. After reviewing the payment method, explicitly re-enabling automatic top-ups can authorise an eligible failed attempt to retry; the system does not treat every page refresh as a new purchase authorisation. An uncertain payment outcome needs reconciliation first, because starting a fresh charge when the original may have succeeded can duplicate the customer's spend.

Recover when capacity has not been added#

Start by recording the existing purchase reference and status. Check the payment method in Manage in Stripe and resolve any provider-authentication request through the official hosted interface. Then refresh Billing. If an eligible failed attempt needs a retry, reviewing and re-enabling the top-up setting is an explicit action; do not rapidly toggle it as a diagnostic experiment. If the state remains pending or the outcome is uncertain, contact support with the safe reference, approximate time and displayed amount. A reusable method missing from the billing account is a payment configuration problem, not something fixed by reinstalling the website widget.

Use alerts alongside the live counter#

Use notifications as an early prompt to assess demand. At 80%, estimate whether the current pool will last until the displayed monthly period end; at 95%, review the top-up setting and payment method before exhaustion. Email delivery can be delayed or fail, and traffic can consume the remaining units faster than someone reads a notification. A notified owner should know who is authorised to change billing controls. Keep a business contact fallback available on the public website in case capacity or payment problems interrupt support. The live counter is the useful operational check, rather than waiting for an alert email before looking at Billing.

Assign a spending owner before increasing traffic#

Before a campaign, agree who may authorise automatic purchases and what expected demand would trigger a review. Record the current pool, period end and anticipated busy interval. For example, a short campaign with an expected extra two hundred units has a different spending profile from an unresolved integration that keeps submitting new support windows all week. Reesponder's purchase setting does not create a customer-defined monthly monetary cap. If your business needs a strict expenditure ceiling, use deliberate monitoring and the supported purchasing control, with a clear fallback when paid capacity is exhausted.

Give the billing owner a useful review routine: look at current usage, recent purchases and whether the increase matches a known activity. Investigate unexpected traffic with the relevant operational views without assuming every extra unit is fraud. A person changing the switch should tell the support team whether new paid capacity is expected to become available. The public website should retain a business contact path for an interruption. Do not delegate the billing account password or card details merely to let a colleague watch demand. Use authorised account access and keep a short business decision record instead.

Treat a month-end payment as a dated transaction#

A top-up is associated with an intended usage period, so compare its initiation and successful payment times with that period's end. If the month rolls over during a delayed payment, the old purchase is not automatically a grant for the new pool. Likewise, an annual renewal date is not the expiry date of every monthly top-up. Use the workspace's actual anchored boundaries. A charge near midnight on the last calendar day can still belong to a period whose anchor is another date; the calendar month alone does not identify it.

For an apparent mismatch, keep the existing purchase reference, the previous period end, the new period start and the provider's settled time. Report that this is a boundary case so support can reconcile the intended period and payment outcome. Do not issue a second charge, manually edit a browser counter or presume a refund before that review. A provider receipt describes the payment; the service counter describes current capacity. They need to agree through the verified crediting path, and a stale-period payment requires its own investigation rather than an undocumented transfer of credit into a different month.

Investigate one purchase instead of recreating it#

Build the report around one transaction. State its displayed status, amount including tax, safe reference, approximate initiation time and the workspace period it was meant to extend. Note whether the reusable payment method was updated and whether an authentication request was completed. A screenshot showing no remaining capacity is useful context, but it does not reveal whether the payment is pending, failed or successfully settled elsewhere. The history entry and provider reference let support investigate the actual transaction rather than guess from a visitor's fallback message.

Once reconciliation is complete, verify the resulting capacity and retain the safe reference in the billing notes. If the outcome is an eligible verified failure, deliberately re-enabling purchasing can authorise the supported retry path after the method is reviewed. An unknown result should be resolved before such a retry because a timeout is not proof that the provider charged nothing. Avoid rapid switch toggling, repeated visitor questions or a new subscription checkout as troubleshooting steps. None settles the original payment, and each can complicate the timeline. Separate financial resolution from the final controlled test that customer support can admit work again.

Example: reaching the paid boundary#

Suppose the active period includes 500 units and has used 499. One new admitted window consumes the last available unit. If the configured automatic purchase is eligible, it can begin a 100-unit top-up, but another new billable request is not admitted merely because that payment is Pending. After verified credit, capacity becomes 600 and future eligible work can use it. If the payment needs authentication, resolve that existing attempt instead of starting a second independent purchase. When the monthly period ends, unused capacity from that period does not roll forward. A yearly subscription still receives its next monthly plan allowance on the correct anchor.

Verify the outcome and keep safe evidence#

For a suspected crediting problem, collect the period end, used/allowed figure, purchase status, actual payment amount and a safe payment or top-up reference. Explain whether this is the current period or an earlier one. A Stripe receipt can support the investigation but is not a reason to manually mark local capacity paid in the browser. Support needs to reconcile the verified transaction with the intended period. Do not submit full card details or authentication screenshots. After recovery, verify the credit once and test one controlled customer question rather than running repeated traffic to see whether the count keeps changing.