Features

Sweeps due recovery steps and runs each through its executor. No delay beyond the tick interval from any scheduled step.

The decline is classified first. A quiet retry runs before a customer ever sees a dunning email.

A fraud-category decline gets a single email and no retry step at all.

Invoices the prior month's matured (30+ day) recoveries at 20%. Baseline recoveries Stripe would have gotten anyway are never billed.

Health scores, predictions, alerts, and a structurally grounded AI narrative are computed nightly for every customer.

MRR and the movement waterfall (new, expansion, reactivation, contraction, churn) are computed from Stripe subscription data.

Prior charges, recovery history, and Stripe signals are assembled into a draft automatically, before you open the dispute.

Engagement events, email sends, webhook events, health-score history, cron history, and AI call logs are pruned on a schedule so operational tables stay bounded.

Demo accounts are reseeded nightly and never touch live Stripe data.

Each cron takes a Durable Object lock before it runs. Overlapping runs are blocked, not queued, and every run is logged.

MRR and movements come free the moment Recovery connects. Not a trial, no separate signup.

A paid layer on top of the free analytics that scores customers by churn risk before it happens.

Every Stripe decline code maps to soft declines, network errors, expired cards, suspected fraud, revoked authorizations, or declines nothing has mapped. Timing and retry strategy differ by category.

An unknown decline code defaults to a dedicated non-retryable category instead of silently auto-retrying.

Every drafted claim is grounded in real charge, email, and Stripe-signal data. Nothing is invented to strengthen a case.

Recovery emails read as your brand voice, not Foxhound's. Every generated email is read in full before a template ships.

Outbound email goes through Cloudflare's Email Service behind one thin send module business logic never bypasses.

Engagement comes from Foxhound's own tracking routes, not a vendor webhook.

Email Service events flow through a queue consumer that updates the suppression list automatically.

CAN-SPAM-compliant, token-based, no login required.

A no-login page a customer reaches from a recovery email to update an expiring or failed card.

Every fee renders its chain: the Foxhound action, the recovered payment, the 20%. Baseline recoveries appear in the same ledger marked free.

The full evidence draft, an edit affordance, and an explicit approve-and-submit action with the fee, capped at $500, stated on the button.

One headline lift number, three bands beneath it: Stripe recovered, still dying, Foxhound adds.

Every customer scored, sorted by MRR at risk, each score expandable to its evidence.

Sparkline, line and area, bar and waterfall, meter, and cohort grid. Server-rendered, no client-only measurement container, no hydration flash.

D1 cap telemetry, deploy state, and a live cron-status table.

From the payment detail page, along with triggering an immediate retry at any time.

Any drafted field can be edited before approval. The draft is a starting point, not a constraint.

Rate limits are enforced through a dedicated Durable Object, not a third-party rate-limit service.

Dark by default, light as a first-class mode, cookie-persisted with no flash.

Connects in under a minute, and never touches your billing configuration.

Foxhound bills merchants directly as its own Stripe customer. This is not a Connect application fee.

The database layer, reached through native Workers bindings, never over HTTP.

Error tracking with source maps across the Worker and its cron jobs.

Foxhound requests read and write Stripe Connect access, because retrying a failed invoice is a write. It writes in three places: retrying an invoice that already failed, setting a customer default payment method after a card update, and submitting dispute evidence you approved. It never changes your prices, products, or subscription plans, and never reaches your payouts.

Stripe access tokens are encrypted at rest with Web Crypto, decrypted only in memory during execution.

Every webhook is verified with constructEvent signature checking, with a Durable-Object-serialized claim so an event can't double-process.

Response headers and a content-security policy are enforced on every request.

A real middleware guard, not a UI-only check, controls whether /admin is reachable at all.

Signed unsubscribe tokens, a suppression list, and one-click unsubscribe on every commercial email.

Reduced-motion, increased-contrast, and forced-colors modes are implemented, not just targeted.