When a subscription charge fails, the customer didn't decide to leave - their card just expired or a payment bounced. PayPilot turns each failed-payment event into a grounded recovery action: it diagnoses why, picks the right retry strategy, and drafts a warm, ready-to-send dunning email - in a single API call.
Pick a customer and what went wrong, then run the agent. The panel on the right changes with each choice - try each reason to see the plan move.
Run the agent to see the revenue at stake, a diagnosis, a deterministic strategy, and a drafted email appear here.
A failed-payment event flows through a typed LangGraph state machine. Each node enriches a shared state and hands it on.
Loads the customer record, pulls relevant snippets from the dunning playbook (RAG), and scores churn risk from the attempt count and recent failures - then produces a short, grounded diagnosis of why the charge failed: committed templates by default, an LLM only when live drafting is enabled.
The retry action and cadence come from a fixed rules table keyed on the failure code - not an LLM - and tighten automatically when churn risk is high. A schedule node then pins the concrete next-retry time, ready for a scheduler. Stable and unit-testable.
A warm, on-brand dunning email is written the same way - committed copy by default, LLM when enabled, with one clear call to action, grounded in the playbook's tone guidance.
The questions a hiring manager or a curious engineer usually asks.
PayPilot is an AI dunning agent that recovers failed subscription payments. It turns a failed-payment event into a grounded recovery action: a diagnosis of why the charge failed, a churn-risk score, a retry strategy, a scheduled retry, and a drafted dunning email.
The retry action and cadence come from a deterministic rules table keyed on the failure code, not the language model, so the policy is stable and unit-testable. When churn risk is high, the cadence tightens automatically.
No. With no OpenAI key set, PayPilot runs a deterministic mock mode using grounded playbook templates and a lexical retriever, so the demo works offline, free, and with no signup. Adding an API key alone changes nothing: live drafting also needs PAYPILOT_LLM_DRAFT=1.
The dunning agent handles card and subscription charge failures: its tables are card decline codes and Recharge error types. ACH is separate. PayPilot publishes a deterministic decision table for returned ACH debits at /ach-returns, where 17 return codes sort into 5 decisions, and that table is not wired into the dunning agent. Saying PayPilot handles ACH would overstate it; it publishes a decision table for ACH.
Seventeen ACH return codes sorted into five decisions, because there are five answers to the one question that decides what happens next: what has to change before the debit can exist again. Nothing, the account details, their instruction, our own entry, or nothing ever will. Any code the table does not list falls through to the conservative row, where nothing automatic happens, and the answer says it fell through rather than matched.
Yes. The ACH decision table ships as an MCP server with three read-only tools: lookup_return_code, list_decisions and explain. The agent asks, the table decides, and the answer carries which rule fired, so no model sits in the decision path. Nothing writes and nothing reaches the network, declared per tool as read_only_hint and open_world_hint false.
A seven-node LangGraph state machine with retrieval-augmented generation (RAG) over a dunning playbook, served through a FastAPI endpoint. It is written in Python 3.11 and runs its full test and evaluation suite offline.
Every response quantifies the amount at risk, the recovery likelihood, the expected recovered value, and the annual revenue at risk if the customer churns. Recovery likelihood is an illustrative constant, not a measured rate.
Yes, with controls evidenced in code: personal data is masked before the model and is not stored in the ledger, scripted and tested jobs export and erase a customer's data end to end, records auto-expire on a configurable retention window, an append-only audit log records every money and auth event, and webhooks and admin routes are authenticated. It is also EU AI Act limited-risk with a configurable AI-assistance disclosure on generated emails. SOC2-ready means the controls are built and evidenced, not that a certification audit has been run.
PayPilot is a portfolio project. If you want an engineer who ships production-shaped AI systems - agents, RAG, typed APIs, tests, and a live deploy - let's talk.
Want it running on your own Stripe account, or a Shopify store on Recharge? It carries no client traffic yet, so a pilot is the way in. It's also a working product, offered for a platform fee plus a fee per recovered payment. See pricing, delivered via Streamflow Solutions.