Billing, Cancellation & Refund Policy

TEST billing only

This is a staging draft. The application accepts Stripe TEST keys and uses simulated payments. Do not enter real card details for staging checks. The implemented TEST catalog and accounting behavior below are evaluation settings, not final live-payment terms. The operator, taxes and customer contract terms still require approval before commercial launch.

Plans and credit accounting

The TEST catalog displays monthly Starter at USD 49 with 7,500 credits, Growth at USD 149 with 30,000 credits, and Agency at USD 399 with 100,000 credits. One-time TEST top-ups are USD 25 for 3,000 credits, USD 75 for 10,000 credits, and USD 199 for 30,000 credits. Confirm the configured offer shown before checkout. Historical grants and previously recorded price versions are preserved; the new catalog does not rewrite an earlier purchase.

Eligible paid subscription invoices and confirmed top-up payments grant integer credits once under a stable payment identity. Duplicate events must not grant a second allowance. A zero-dollar invoice is not collected revenue and does not create a payment-funded grant; a separately approved account allowance is a different record. Credits are application units, not cash or the provider invoice currency.

New subscription credits issued under the current TEST policy expire at the billing-period end recorded on their source invoice. A late-paid invoice for a period that has already ended does not start a fresh credit period. Earlier non-expiring grants keep their recorded treatment. TEST top-up credits have no automatic expiry under this implementation; this is not a finalized perpetual commercial guarantee.

Credits reserved for work remain available to settle that work after their source expiry. If an expired reservation is later released, those units do not become available for new work. Refund reversals and adjustments remain separate from expiry, and historical ledger entries are not erased.

A scan plan displays its retail credit requirement separately from estimated provider cost. Credits can be reserved when a run starts and settled as work is processed. An uncertain provider submission stays reserved for reconciliation instead of being blindly purchased again. The application does not automatically charge overages.

Provider spending and recurring work

A subscription or positive credit balance does not enable paid provider work. Paid scanning requires the deployment spending gate, a permitted request and an enforced authorized limit. Credentials alone never provide spending approval. A separately authorized bounded pilot is distinct from permission for recurring scans.

Recurring work, when separately enabled, uses standing monthly and per-run limits and the configured timezone. Pausing prevents new eligible work; already submitted external tasks can still complete and incur provider cost. Outstanding unknown outcomes continue to hold budget. Closing the browser does not stop background work.

Cancellation

The TEST billing controls and configured Stripe portal request cancellation at the current subscription-period end. The application reconciles the effective date and subscription state from Stripe. The in-app cancellation request uses no proration and does not itself issue a refund. Check the displayed canonical state and date before treating a request as completed.

Cancellation does not erase the credit ledger or account data. Credits keep their recorded expiry treatment, and new work remains subject to account access and spending controls. A deletion request, cancellation, a refund and stopping already submitted provider work are separate operations.

Refunds and disputes require a decision

No final commercial refund entitlement, window or non-refundable rule has been selected. The TEST application provides a reviewed refund workflow; this engineering capability is not a promise that a live purchase qualifies for a refund.

An explicitly assigned platform owner with recent authenticator verification can request a refund against a canonical TEST payment. The request records a reason and a durable operation identity. Available credits from that payment are adjusted through compensating records. Held or already consumed source credits require a separate review of the exact deficit before a supported refund can proceed; they are not silently erased.

A pending or unknown refund outcome is not shown as completed and must be reconciled before another payment request. A known failed refund restores the affected credit hold through a compensating grant with its original expiry treatment. Canonical refunds and chargebacks update payment and credit reversal records without rewriting historical consumption.

Before live payments, the owner and reviewing lawyer must approve applicable cancellation/refund rights, failed-task credits, taxes, renewal notices, proration, credit expiration, disputes and treatment of prior purchases. The product and notices must implement the approved choices together.