Plans, quotas, payment lifecycle and Stripe configuration.

Billing and subscriptions

GetRatchet provides execution control, not tool compute. Bring your own workers. No compute markup. Customers own their hosting account, code and destination credentials.

The executable catalog is lib/plans.ts. All plans include built-in retry presets, per-error decisions, idempotency, inspection, search and single-step replay. BASIC adds custom retry policies, email alerts, contracts, synthetic tests and bulk recovery. PRO adds provider-backed AI advisory, per-alert recipient routing, audit/run exports and priority email support. Included seats have no additional charge.

Retries count as attempts. Counters reset at the UTC calendar month boundary, independently of subscription renewal. Synthetic runs retain their separate existing counter. There are no automatic overage charges. Admission checks reject new runs/steps at the allowance or unfinished-work limit; accepted jobs, retries, reports and cancellation continue. Resource creation uses an organization lock to prevent concurrent requests exceeding limits. Pending invitations reserve seats. Security key rotation remains available; an old/new key overlap is temporary.

BILLING_ENFORCEMENT_ENABLED=true enables restrictions. Leave it unset/false during rollout to retain legacy API behavior. Billing status and webhooks remain available while enforcement is disabled. Do not advertise enforced limits until rollout is complete.

Payment lifecycle

Choose a plan on Pricing. Signed-out visitors retain a non-secret plan preference in their browser during registration and verification; after login, Settings → Billing offers Continue. Changing browsers loses this preference; select the plan again. Only verified workspace owners may start Checkout or open the Customer Portal. Browser inputs cannot select an organization, customer, price ID or return URL.

Stripe hosts Checkout and handles all card details. The return page polls billing status for up to a minute, but never grants access. Signed webhooks retrieve the canonical subscription while holding the organization lock and record each event ID transactionally. Duplicate and out-of-order delivery cannot apply stale event payloads. Failed processing returns 500 for Stripe retries. Audit records contain outcomes, never Stripe payloads.

The portal handles payment methods, invoices, plan switching and cancellation. Configure downgrades at period end. Cancellations retain access through the paid period. Past-due/unpaid subscriptions get seven days of grace, beginning with the first observed failure. Repeated failures do not extend it. After grace or paid access ends, effective entitlements are Free, even if maintenance is delayed.

Lower retention waits 14 days. Billing shows the exact UTC date, previous history remains protected during grace, and exports stay available. Existing organizations receive a 30-day card-free PRO trial at migration time; new organizations start Free. Trial expiration also gets retention/export grace. A downgrade never deletes history in the webhook; the bounded retention worker handles deletion after grace. Reads, security/account actions, and already accepted durable work remain available. Existing resources above a lower plan's limits remain readable; further additions are blocked. Existing advanced alert routes are suppressed on BASIC until an administrator saves one common recipient group.

Operator setup (manual; do not run against live Stripe during development)

1. In Stripe test mode, create products GetRatchet Basic and GetRatchet Pro, each with two recurring USD prices: Basic monthly 2900 cents, yearly 29000; Pro monthly 9900, yearly 99000. Each subscription has quantity one; no metered prices or automatic overages.
2. Copy the four price IDs into STRIPE_PRICE_BASIC_MONTHLY, STRIPE_PRICE_BASIC_YEARLY, STRIPE_PRICE_PRO_MONTHLY, STRIPE_PRICE_PRO_YEARLY. Set STRIPE_SECRET_KEY to the test secret key. Never use public-prefixed names for these secrets.
3. Configure Stripe Customer Portal: enable payment method updates, invoice history, cancellation at period end, and switching among exactly those four prices. Keep quantity changes disabled. Configure payment/proration collection for upgrades; schedule downgrades at period end. Do not enable arbitrary products. Avoid Stripe dunning cancellation before the application's seven-day grace finishes.
4. Set NEXT_PUBLIC_APP_URL to the canonical HTTPS origin (localhost is allowed for tests). The Checkout success URL is /settings?checkout=returned#billing; portal return is /settings#billing.
5. For local testing, run stripe listen --forward-to localhost:3000/api/billing/webhook. Put its whsec_... value in local STRIPE_WEBHOOK_SECRET. Complete a test Checkout using Stripe's test payment methods. Test portal switches/cancellation and payment failure with Stripe test clocks. Re-send a delivered event with Stripe CLI to verify deduplication. Do not print secrets or event payloads into application logs.
6. Register an HTTPS webhook endpoint /api/billing/webhook subscribing to checkout.session.completed, customer.subscription.created, customer.subscription.updated, customer.subscription.deleted, invoice.paid, invoice.payment_failed. Use the API version pinned by the installed Stripe SDK (see node_modules/stripe/esm/apiVersion.js); invoice subscription relationships and item period dates must match that version. Set the endpoint's signing secret separately from the CLI secret.
7. Apply the additive migration with the reviewed migration credential, deploy the application and platform worker, then test in an isolated environment with test-mode keys. Check billing status, trial dates, warnings, duplicate delivery and retention grace. Enable BILLING_ENFORCEMENT_ENABLED=true on both processes only after validation.
8. For a reviewed production release, manually create the equivalent live products/prices and portal configuration, use live environment-specific secrets, register the live webhook, and verify delivery monitoring. Never share production Stripe secrets with preview deployments or customer workers.

Managed-worker requests store one record per workspace, a timestamp and an optional 500-character use case. They do not create compute or grant hosted execution. Owners should not submit credentials or payloads.