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.

RTD brings Voice, Chat, Human Inbox and BizDesk into one workspace and wallet. Free Human Inbox has no subscription payment; BizDesk Business and Enterprise are add-ons to eligible paid RTD plans. ASG retains its separate commercial system.

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 included credits are granted monthly on monthly and annual subscriptions. BizDesk draws usage from that shared wallet. The active catalog and billing records determine the allowance and grant timing; ASG retains its separate credit grants.

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.

Free Human Inbox supports human text chat and asynchronous audio messages without a subscription payment. A new workspace receives 300 one-time welcome credits. Each original resolution costs 30 credits on Free and paid plans. Owners top up in Dashboard. Free has no LLM chat, AI voice, RAG or transcription.

New human-support setup uses the shared RTD Studio and Dashboard. Existing agreements and historical invoices remain subject to their recorded terms; Support can confirm the status of a migrated account.

Review current plans · Open Dashboard

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.

BizDesk Business is $109/month or $1,090/year. Eligible monthly Business subscriptions are $65.40 for each of the first 2 paid months, then $109/month. BizDesk Enterprise is $290/month or $2,900/year. Eligible monthly Enterprise subscriptions are $174 for each of the first 2 paid months, then $290/month. Annual prices are billed yearly and do not stack with monthly introductory offers. BizDesk is an add-on to a paid RTD workspace; usage draws from the existing wallet. RTD paid plans and Voice rates retain their approved catalog terms. Final prices, taxes and eligibility are confirmed at checkout.

RTD and BizDesk share the RTD billing authority and wallet. Voice, text generation and Human Inbox resolution retain their applicable usage rates. ASG uses its separate catalog and wallet. Current checkout, subscription records and the usage ledger are authoritative.

RTD and BizDesk share the workspace wallet. Cloudflare text generation uses 1 credit per 2,000 tokens with proportional microcredit accounting. The existing OpenAI chat path retains its current 1 credit per 750 tokens, rounded up with a minimum of 1, until provider cutover. Voice keeps the selected OpenAI model and its existing rates. Knowledge indexing requires client approval of an estimate or platform-admin manual processing. A subscription purchase or saved Studio draft alone does not publish a workflow.

Review current plans · Open Dashboard

RTD and BizDesk share the workspace wallet. Cloudflare text generation uses 1 credit per 2,000 tokens with proportional microcredit accounting. The existing OpenAI chat path retains its current 1 credit per 750 tokens, rounded up with a minimum of 1, until provider cutover. Voice keeps the selected OpenAI model and its existing rates. Knowledge indexing requires client approval of an estimate or platform-admin manual processing. A subscription purchase or saved Studio draft alone does not publish a workflow.

Human Inbox resolution costs 30 credits for Free and paid plans. Voice retains the selected OpenAI model and current Standard/Advanced rates.

RTD included allowances arrive monthly on monthly and annual plans. Credits are valid for one year after grant or purchase; the oldest eligible credits are used first. ASG credits remain a separate product meter.

Review current plans · Open Dashboard

RTD included credits are granted monthly on monthly and annual subscriptions. BizDesk draws usage from that shared wallet. The active catalog and billing records determine the allowance and grant timing; ASG retains its separate credit grants.

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.

RTD and BizDesk use the authenticated RTD Dashboard top-up section. A top-up adds prepaid capacity without starting another subscription. Package amounts and grant quantities come from the active billing catalog. ASG retains its own top-up path.

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.

Payment cadence and contract duration are separate. Current checkout and the recorded agreement state the terms for the selected service. Earlier RTC and Industry agreements retain their recorded obligations; Support can review migration, cancellation and renewal for an existing account.

Free Human Inbox has no subscription charge and does not require a payment method. A paid RTD or ASG trial, where offered, is a separate checkout choice with its stated payment-method and conversion terms. BizDesk add-on offers are shown on the RTD pricing page.

Payment cadence and contract duration are separate. Current checkout and the recorded agreement state the terms for the selected service. Earlier RTC and Industry agreements retain their recorded obligations; Support can review migration, cancellation and renewal for an existing account.

Payment cadence and contract duration are separate. Current checkout and the recorded agreement state the terms for the selected service. Earlier RTC and Industry agreements retain their recorded obligations; Support can review migration, cancellation and renewal for an existing account.

RTD included credits are granted monthly on monthly and annual subscriptions. BizDesk draws usage from that shared wallet. The active catalog and billing records determine the allowance and grant timing; ASG retains its separate credit grants.

RTD included credits are granted monthly on monthly and annual subscriptions. BizDesk draws usage from that shared wallet. The active catalog and billing records determine the allowance and grant timing; ASG retains its separate credit grants.

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.

Payment cadence and contract duration are separate. Current checkout and the recorded agreement state the terms for the selected service. Earlier RTC and Industry agreements retain their recorded obligations; Support can review migration, cancellation and renewal for an existing account.

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.

Payment cadence and contract duration are separate. Current checkout and the recorded agreement state the terms for the selected service. Earlier RTC and Industry agreements retain their recorded obligations; Support can review migration, cancellation and renewal for an existing account.

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.