Billing, Credits & Payments

This page is the commercial reference for understanding how a WebsDocs subscription moves from purchase to active service, how included capacity is applied, how product usage can reduce that capacity, how additional capacity can be purchased where supported, and what happens when a payment, renewal, cancellation, or service-delivery issue needs attention. It is intentionally written as documentation rather than as a marketing page. When money, service access, and usage capacity are involved, clarity is more useful than decoration.

The four public product families covered here are RTD Business Agent, RTC Business Automation, ASG Sales Gateway, and Business Automation. RTD has its own isolated billing system. RTC, ASG, and Business Automation use parts of the shared WebsDocs AI Billing architecture, although ASG also maintains its own gateway credit wallet and Business Automation continues to use the Industry billing lane internally. Those internal differences matter because they determine which system is authoritative when a payment is accepted, a credit grant is created, usage is debited, or a subscription state changes.

Current plan prices should always come from the applicable product pricing or checkout path. This documentation should not become a second copy of every price. A duplicated price list is easy to make and easy to forget, and a forgotten price list becomes a source of confusion. The purpose of this page is therefore to explain the commercial rules around the current price: what the plan represents, what capacity may be included, how usage is measured, when capacity may refresh, and what responsibility remains with WebsDocs or with the client after a service has been made available.

A payment record and a usage record are related but are not the same thing. Payment confirms that the applicable commercial transaction has been accepted by the payment path. The product billing authority then determines the resulting subscription, entitlement, allowance, wallet, or top-up state. The product runtime or gateway can report actual billable activity, and the billing authority applies the corresponding debit or grant according to the active product rules. This separation is deliberate: checkout should not invent usage, and runtime should not invent commercial prices.

This page does not replace the product page, checkout confirmation, dashboard, signed commercial agreement, or verified billing record. It also does not create a universal promise that every WebsDocs product has the same trial, the same annual structure, the same cancellation option, or the same credit expiry behavior. Where a product has a specific rule, the product-specific rule is described in its own section. Where the backend does not establish one universal rule, this page says so instead of filling the gap with an assumption.

The RTD Voice checkout worker is a payment gate. It creates supported provider checkout sessions, verifies provider payment events, and reports verified payment facts to the next authority. It does not own the RTD subscription account, the customer wallet, monthly allowance decisions, or paid top-up grants. Those responsibilities belong to RTD Billing, with the first applicable setup grant owned by the RTD setup path. This separation prevents a successful checkout from independently inventing credits or subscription state.

Current RTD provider catalog data is read from the RTD billing database for the active product key and pricing version. That catalog can contain provider, plan, billing cycle, pricing mode, regular amount, introductory amount, currency, and provider configuration state. This is important for the public payment page because it means RTD pricing can evolve without requiring this documentation page to copy and preserve every price forever.

RTD plan allowance logic is also product specific. The billing system resolves the applicable plan allowance and can use the active plan/pricing-version configuration to determine recurring voice credits. RTD also has separate authority for supported extension usage such as Chat and Human Inbox resolution. Those extension rates are read from active RTD rate records, rather than being assumed from RTC or ASG credit formulas.

The RTD architecture distinguishes the first grant from later recurring grants. Setup owns the first applicable grant. After the subscription is established, RTD Billing owns qualifying recurring grants after successful paid renewal events. This distinction is useful when a client is checking why a first-period allowance and a later renewal allowance entered the account through different operational events.

Annual RTD subscriptions can require monthly allowance handling during an annual service period rather than one uncontrolled annual credit dump. The billing worker has logic for annual monthly allowance periods and can apply recurring allowance grants with a defined start and end window. The practical customer message is simple: the amount paid and the way capacity becomes available are related, but they do not always have to occur as one single event.

RTD supports prepaid credit top-ups. The checkout code contains compatibility fallbacks, while the authoritative top-up packages are intended to come from the RTD billing database. Current top-up data can include the package amount, credits awarded, bonus credits, bonus percentage, validity days, pricing version, and provider configuration. Purchased RTD top-up credits follow the WebsDocs one-year credit validity rule: 365 days from the applicable grant date.

RTD top-ups are additional capacity for an existing service. They do not replace the underlying subscription lifecycle. A top-up payment is verified by checkout and the resulting grant is controlled through RTD Billing and the RTD runtime grant path. This prevents a browser-supplied quantity from becoming authoritative merely because it was sent with a request.

RTC checkout does not carry an old hardcoded plan price list. Current subscription prices are loaded from the active billing database plan rules. The same principle is used for RTC purchased credit top-ups: the packages are loaded from billing rules, browser-supplied prices and credit quantities are not trusted, and successful purchased top-up grants are applied by the AI Billing worker. This makes the billing system, not the page markup, authoritative for the commercial values.

RTC live usage is measured from actual AI activity. Runtime reports the actual provider/model, selected operating mode, and token counts. Billing validates the entitlement and wallet, resolves the applicable active mode rate, applies the authoritative debit, and writes usage and ledger records. The wallet stores exact equivalent token units so proportional fractional charging can be performed without relying on coarse whole-credit rounding for every request.

The conceptual RTC formula is therefore based on billable usage and the active mode multiplier. The public page does not need to expose database columns or internal calculation code, but it should make one thing clear: two interactions that perform different amounts or modes of AI work do not have to consume exactly the same number of credits.

RTC has an explicit Pro trial checkout path. Normal paid Pro and the Pro trial are separate checkout actions. Selecting the paid Pro plan does not silently mean “trial.” The trial begins through the explicit trial route or trial access selection. Checkout collects a payment method and the selected recurring price is charged after the trial if the trial is not cancelled before conversion.

This distinction matters for both client expectations and support. A person who chose the explicit trial should be able to identify the trial state. A person who selected the normal paid plan should not assume a trial merely because a trial is available to another checkout path.

RTC currently defines a 12-month service commitment. The monthly option is structured as 12 monthly installments under that 12-month commitment. The annual option is one prepaid annual payment that provides 12 months of service at an amount equivalent to 10 monthly payments, giving two months free within the annual structure. Payment cadence and commitment duration are therefore separate concepts.

The commitment also affects cancellation. During an active paid RTC term, client cancellation does not operate as an immediate escape from the remaining contracted installments. The RTC billing policy can disable future renewal while the contracted installments continue, and provider cancellation is timed after the final contracted installment or commitment period. Trial cancellation is different because the paid commitment has not yet begun.

ASG checkout creates recurring subscription sessions and separate top-up checkout sessions. It can also provide billing recovery and billing portal routes for existing clients. The checkout health contract makes the division of responsibility explicit: checkout owns the payment door, while the billing worker is the authoritative subscription and lifecycle path for verified Stripe events, payment recovery, top-up accounting, and related lifecycle decisions.

ASG credit usage is not described as one flat credit for every visitor request. The current ASG text-credit formula is based on successful billable text tokens and supports fractional debit. The shared billing worker exposes an ASG-specific formula of one credit per 1,000 successful billable text tokens for that text-credit model. The ASG gateway remains the operational authority for its credit wallet, while Billing remains involved in the subscription and commercial account state.

ASG therefore has two closely related but different truths: the customer must have the correct commercial entitlement, and the gateway must have the correct usage balance. When both are healthy, ASG can serve billable activity and reduce the applicable balance according to measured usage. When a top-up is purchased, the payment path and the credit grant path remain separate controlled events.

ASG checkout supports configured trial behavior. The current checkout describes the flow as collecting the card at checkout and allowing Stripe to attempt the first recurring subscription invoice after the configured billing trial period. The actual number of displayed or billing trial days is configuration-driven, so this page should not freeze a number that can later change independently.

Existing ASG clients can use a separate top-up checkout lane. The client identity or slug is required so the additional capacity is associated with the correct existing service. The checkout can accept a package key and verified customer information, but the final grant is not created merely because a browser claims a credit quantity.

ASG also contains an internal subscription cancellation path that supports a cancellation mode such as period-end or immediate at the payment-provider layer. That technical capability should not be confused with a universal public promise that every active ASG subscription can always be ended immediately without commercial consequences. The applicable active subscription state and terms remain relevant to the client-facing action.

The active Business Automation checkout is the Industry plan route inside Commerce Checkout. The worker currently contains an Industry plan catalog for Essential, Pro, and Business levels and a separate top-up catalog. Stripe is the active commerce payment provider in this path. The product page sends the plan key and billing cycle, while Stripe Checkout collects customer information needed for the transaction.

Internally, this product continues to use the “industry” or “industry_automation” naming in billing data. Publicly, this documentation uses Business Automation. That distinction avoids exposing old or internal naming to clients while still respecting the actual backend authority. If a support or admin record contains an Industry identifier, it can still refer to the current Business Automation commercial lane.

WebsDocs AI Billing owns the Industry credit operations used by Business Automation. It has routes for quota checking, usage debit, included grants, top-up grants, and credit expiry. Credit capacity is held in batches, which allows the system to track where capacity came from, how much remains, when it becomes active, and when it expires.

Included capacity can be issued as a first-period grant, a monthly renewal grant, or annual included windows. For monthly handling, an included batch can default to a one-month validity window. For annual handling, the billing system can create scheduled included-capacity windows in three-month periods, activating each window as its validity period begins. This means “annual payment” does not necessarily mean all annual usage capacity must be delivered as one permanent, unrestricted batch on the first day.

When Business Automation usage is debited, the billing system can consume eligible active batches in an ordered way and can mark batches consumed or expired. This creates a clearer ledger than a single number with no history. It also allows included capacity and purchased top-up capacity to remain distinguishable.

Commerce Checkout provides a dedicated Industry top-up route. The current catalog contains multiple additional-capacity packages, and Billing records purchased top-ups as purchased credit batches. Publicly, purchased Business Automation credits follow the WebsDocs one-year validity rule: one year (365 days). The active checkout package and resulting billing record remain the final reference for the specific purchase and grant.

As with the other products, a top-up should be understood as additional usage capacity for an existing supported service. It does not replace the recurring service plan, and a top-up purchase should be associated with the correct client/site so that the capacity is added to the correct wallet.

WebsDocs uses credits and capacity to connect a paid product plan with measurable operation. The important principle is that usage should be tied to actual work performed by the relevant product system. The way that work is measured differs by product because voice, real-time chat, buyer-facing answers, and workflow automation are not technically identical activities.

RTC is the clearest example of proportional charging. Runtime reports actual token counts and the selected operating mode; Billing applies the active mode rate and performs the debit. ASG has its own text-credit formulation based on successful billable text usage. RTD has separate voice and extension rules. Business Automation can use Industry usage categories and credit batches. A customer should therefore read the product-specific dashboard rather than comparing raw credit balances across products as if they were interchangeable.

Credits can enter an account from different sources. An included plan allowance can be granted after setup or renewal. An annual plan can create scheduled allowance windows. A top-up can add purchased capacity. Because the source and validity can differ, the billing ledger may distinguish multiple batches or grant events even when the dashboard presents a simpler overall balance to the client.

When more than one eligible credit balance exists, WebsDocs uses older eligible capacity before newer capacity. In practical terms, the system works from the capacity that should be consumed first—normally the earlier-expiring or earlier-created eligible balance—before moving to newer credits. This helps prevent an older valid balance from sitting unused while newer capacity is consumed.

Included plan capacity and purchased top-up capacity can still be recorded as different grant types. Their grant source and plan-period rules remain visible in the billing record, but the customer-facing principle is simple: old eligible credits are used first; newer eligible credits are used later.

Fractional charging allows a billing system to represent actual usage more accurately. A small AI operation does not have to be rounded up to the same charge as a much larger operation merely because both occurred once. This is especially relevant to RTC and ASG, where token-based formulas can preserve proportionality. The client sees the resulting balance while the backend keeps the detailed usage and ledger records needed to explain the debit.

When a plan includes capacity, the billing system needs to know how much to grant, when to grant it, which service/site/account receives it, and how long the grant remains valid. Different products answer those questions differently. RTD resolves plan allowance through its own billing data. RTC stores plan and credit rules in the shared billing system. Business Automation can create monthly or scheduled annual Industry credit batches. ASG synchronizes its commercial state with the gateway credit system.

An included allowance is part of the service model, but the existence of a plan on a webpage is not enough to prove that a grant was applied. The actual billing record, wallet, grant ledger, or product dashboard should be used to confirm whether a capacity grant has been created successfully.

The period also matters. Some included capacity is intended for the current service period and can expire when that period ends. Annual payment can still be paired with scheduled capacity windows rather than an unlimited carry-forward balance. This protects both the client and the billing system from ambiguity about which period a usage allowance belongs to.

Top-ups are intentionally separate from the recurring subscription. A recurring plan establishes the service relationship and can provide included capacity. A top-up adds more capacity without creating a second subscription. RTD, RTC, ASG, and Business Automation all have product-specific top-up paths or grant logic, but the same principle applies: the top-up amount and quantity should come from an authoritative product package, not from an arbitrary value submitted by a browser.

A successful payment also does not mean the browser itself can update the wallet. Checkout verifies the payment and passes the appropriate payment fact to the billing or credit authority. The authority applies the grant idempotently so the same verified payment cannot be used repeatedly to create duplicate capacity.

Purchased/top-up credits follow a one-year validity rule: 365 days from the applicable grant or purchase date. Included plan capacity is different: included credits or allowance windows can expire or refresh with the applicable plan period. A client should therefore distinguish purchased credits from recurring included capacity when reviewing an expiry date.

A trial is a temporary access state, not a universal WebsDocs-wide billing rule. Product checkout determines whether a trial exists, which plan is eligible, how long it lasts, whether a payment method is collected, and what happens when the trial ends. The trial shown at the time of checkout is therefore more authoritative than an old screenshot, social post, or cached price card.

RTC provides a useful explicit model: the Pro trial is a separate checkout action from normal paid Pro. The payment method is collected during trial checkout, and the paid recurring period begins after the trial unless the client cancels before conversion. The paid 12-month RTC commitment begins with the first paid period after the trial, not merely because the user opened the trial checkout.

ASG also supports configured trial timing. Its checkout can collect the card now and allow the first recurring invoice after the configured trial period. The actual day count can be configuration-driven. RTD exposes trial configuration through its current checkout controls. Business Automation trial terms, if offered in the active commercial path, should likewise be taken from that current checkout rather than generalized from RTC or ASG.

A monthly option can mean a recurring payment every month, but it does not always mean that the client can end every commercial obligation after any single month. RTC specifically separates payment cadence from commitment duration: the monthly payment option is 12 monthly installments under a 12-month service commitment. This is why the documentation must use precise words rather than casually treating “monthly” as a synonym for “month-to-month.”

Annual billing commonly reduces the number of payment events by collecting a larger amount in advance. RTC currently defines the annual option as one prepaid annual payment for 12 months of service, billed at the equivalent of 10 monthly payments. The result is two months free within the annual commercial structure. Other products can have different annual pricing or allowance behavior and should be read from their own current checkout.

Capacity refresh can also be different from payment cadence. RTD Billing contains annual monthly allowance logic. Business Automation can schedule annual included capacity in three-month windows. That means an annual invoice does not necessarily require the whole year's usage balance to be available permanently on day one. The commercial payment covers the service period; the product capacity policy determines how usage availability is distributed through that period.

Renewal processing updates the subscription or service period after an accepted recurring payment. Depending on the product, the successful renewal can then trigger the next included-capacity grant. RTD Billing explicitly owns later recurring grants after qualifying paid renewal events. RTC Billing likewise treats recurring grants as a controlled billing action rather than something the public checkout can perform on its own.

If a payment succeeds but a capacity grant is not visible where expected, support should check the payment record and the billing/grant record separately. The correct fix is to reconcile the authoritative events, not to assume the absence of a visible balance means the payment never occurred or to create an uncontrolled duplicate grant.

Renewal should also be distinguished from top-up. Renewal continues the subscription period and can refresh included plan capacity. A top-up is an additional one-time capacity purchase. Both can increase available usage, but they do so for different commercial reasons and should remain distinguishable in the billing history.

RTD Billing provides a concrete example: a failed invoice can move an RTD subscription to a past-due state and place access into a grace state with a configured grace end. Other product families have their own recovery mechanisms and should be read from the current dashboard or billing portal.

A failed payment does not automatically mean the service history is deleted. Billing needs to preserve enough state to recover the correct subscription after payment is corrected. The appropriate action is therefore to use the product's billing recovery or support route, identify the account and payment, and allow the billing system to reconcile the state.

Clients should never send full card numbers, CVV/CVC, one-time banking codes, passwords, API keys, or access tokens to resolve a failed payment. Payment-method correction should occur through the approved payment-provider or billing portal path.

An upgrade, downgrade, billing-cycle change, model change, or capacity-related change can have an immediate effective date, a future effective date, or a provider-specific transition depending on the product. The public interface can collect a request, but the billing system remains authoritative for when the change actually becomes active.

This matters when a client requests a change close to renewal. The old plan can remain commercially active until the new state has been accepted and recorded. Usage during that period follows the active billing state, not the requested future state. The dashboard or billing record should therefore show pending and completed changes separately where the product supports them.

RTC commitment rules can further limit certain cancellation-like changes during an active paid term. RTD owns provider-neutral plan-change operations in its own billing system. ASG and Business Automation likewise need to apply changes through their correct commercial path rather than by manually editing a public page or a client-side value.

The first distinction is between trial cancellation, disabling future renewal, ending at the current paid period, and attempting an immediate cancellation. Products can support more than one technical action, but the commercial state determines which action is appropriate. A client should not assume that pressing “cancel” erases a service period that has already been charged or removes remaining installments from a contractual term.

RTC has a particularly explicit rule. During trial, cancellation can prevent the paid term from beginning. During an active paid commitment, immediate client cancellation is blocked by the commitment policy. The system can disable future renewal while contracted installments continue, and the provider subscription is cancelled after the final contracted installment or commitment period. This is why RTC documentation must say “12-month commitment paid monthly” instead of simply “monthly subscription.”

Other products can support period-end or provider cancellation actions, but those technical routes do not create a universal WebsDocs rule that every active paid service can be terminated immediately with no remaining commercial effect. The product's current terms, paid period, account state, and any applicable agreement remain relevant.

The central billing distinction is between service delivery and client usage. WebsDocs must provide the paid service that the subscription or commercial agreement requires. Once the service has been provisioned, enabled, or otherwise made available for the client to use, the service is not treated as undelivered merely because the client has not yet completed its own activation steps or has chosen not to use the available agent.

This rule is especially important for recurring subscriptions. Billing cannot depend on whether a client happened to interact with the service during a particular month. If the service remains active and available, the recurring commercial obligation continues according to the applicable subscription terms. A client who delays launch, pauses internal adoption, does not complete a client-side configuration step, or simply leaves an available agent unused has not created a WebsDocs service-delivery failure by that inactivity alone.

The same distinction helps support teams investigate real problems. If a client says “I did not use the agent,” support should first determine whether the service was actually unavailable because WebsDocs failed to provide it, or whether the service was available but not activated or used by the client. Those are materially different billing situations. The first can create refund eligibility for the affected paid service period when the failure is ours. The second does not.

This policy is intentionally narrower and clearer than a generic “refunds available” statement. A recurring subscription pays for the availability and operation of the subscribed service during the applicable paid period. It is not a pay-only-when-the- client-remembers-to-use-it arrangement. If WebsDocs has fulfilled our service responsibility and the service is active or available, the client cannot convert voluntary non-use into a service-delivery failure.

The refund question therefore starts with evidence of delivery. Support should identify the product, client account, payment, billing period, service status, and relevant provisioning or activation record. If the service was provided and available, the payment remains valid under this policy even if the client never completed its own activation or never used the agent. If the service was not provided because of our failure, the payment for the affected service period becomes eligible for refund review.

Cancellation after a valid paid period does not automatically create a refund for that period. Cancellation controls the future subscription state according to the product's applicable rules. Refund eligibility asks a different question: did WebsDocs provide the paid service for the payment being challenged? If yes, non-use alone is not a refund basis. If no, and the failure is ours, the affected payment can be refunded after review.

This section specifically establishes the recurring subscription principle described above. Other payment types—such as a top-up, a custom commercial payment, or a payment governed by a separate signed agreement—should be reviewed against their applicable payment record and terms rather than having a new universal refund promise invented here.

A payment-provider confirmation proves a payment event, but it does not by itself explain every downstream service state. A subscription record shows the commercial lifecycle. A wallet or credit batch shows available capacity. A usage ledger explains debit history. A provisioning or service state helps establish whether the paid service was actually made available. Support can need several of these records to resolve a disputed charge accurately.

The separation is useful when something partially succeeds. For example, a checkout can be paid while a later grant requires repair, or a subscription can be active while the client has not completed activation. The correct response is to reconcile the missing operational event rather than to collapse every state into “paid” or “unpaid.”

Clients should provide identifiers that help locate the correct record: product, account or site, client email, invoice/order/payment reference, approximate payment date, and a concise description of the issue. Sensitive card or account security data is not needed. Existing clients should use their verified dashboard or support ticket route whenever possible so the message stays attached to the correct service history.