Your billing logic
is a state machine.
It loses its place.
Stripe events arrive out of order, twice, and mid-deployStripe documents this directly: event delivery is at-least-once and unordered, and webhook signatures verify only within a 5-minute window. A recovery campaign or trial window that spans weeks has to survive every deploy in between. Source: docs.stripe.com/webhooks.. So your billing logic lives in webhook handlers, cron jobs, and database flags, with no memory of its own. The processes that span days are the ones that break.
Stripe Workflows runs in seconds. Sutyr workflows run for days, classifying, sleeping, and waking on signals.
or try Webhook Lab, our open-source Stripe testing tool
Built on Temporal Cloud, the durable execution engine at Snap, Coinbase, HashiCorp, and Datadog.
This is what
billing state
drift looks like.
Every sphere is a Stripe event that arrived out of order, twice, or mid-deploy. Each one nudges your local state a little further from the truth. No exception fires. Three days later it is a support ticket: charged, but locked out.
1// webhooks.ts: the state machine you didn't mean to build2export async function handleStripeEvent(evt: Stripe.Event) {3 if (seen.has(evt.id)) return // idempotency, by hand4 seen.add(evt.id) // ...in memory. gone on deploy.56 // arrived out of order? fired twice? mid-deploy? we don't know.7 switch (evt.type) {8 case 'invoice.payment_failed':9 await db.update(sub, { status: 'retrying' }) // state in a column10 if (!sub.pendingRetry) await enqueueCron(sub) // added Tuesday, after the incident11 setTimeout(() => retry(sub), 3 * DAY) // dies on next deploy12 break13 }14 // TODO: what if the retry succeeds after we already cancelled?15}All of it, as one durable function.
1// recovery.ts: the same thing, durable2export async function invoiceRecovery(e: FailedEvent) {3 const next = classify(e.declineCode) // not by hand4 await sleep('3 days') // survives every deploy5 return retry(e.invoiceId, next) // idempotent. runs once.6}Not a bug. The model.
A durable workflow
per entity. It holds state,
sleeps, and survives.
Sutyr runs each billing process as a durable workflow keyed to the entity it belongs to. It survives crashes and deploys mid-run, sleeps for days, and wakes the instant something changes upstream. Classifying a decline into wait, pause, or stop is one thing it does, not the whole of it.
Not a retry queue. A workflow that holds state, sleeps for days, and wakes the moment something changes upstream.
From webhook to recovered.
Connect your Stripe account and forward every billing event to Sutyr.
- Stripe OAuth. Connected in 60 seconds
- Zero webhook endpoint changes on your side
- Credentials sealed at rest with KMS-backed envelope encryption
We built the testing tool.
Now we're building the fix.
Webhook Lab fires schema-accurate, signed Stripe events at your endpoint, out of order, twice, and mid-deploy, so you can watch how your billing code behaves when reality does. What the lab exposes, Sutyr makes durable.
Hosted: we proxy the request to your endpoint and never store or log it. Payloads, signing secrets, and target URLs are processed in memory only, for the duration of the request. Prefer zero server involvement? Self-host or run the package, and events are generated, signed, and fired entirely from your own machine, never reaching us.
A billing process should outlive the request that started it.
Sutyr runs each one as a durable workflow: it holds state, sleeps through deploys and long waits, wakes on a signal, and keeps an immutable audit trail end to end. The record below is one such process — a failed payment carried to a recovered account.
State is preserved
Customer, invoice, decline code, strategy, attempt history, and next action stay attached to the recovery.
Waiting is durable
The workflow can sleep through deploys, restarts, webhook delays, and long recovery windows without losing position.
Signals wake the right workflow
A customer card update wakes the recovery path immediately, before a blind retry schedule would run again.
Not another retry.
Durable execution.
What founders ask before they apply.
How is this different from Stripe Workflows?
Stripe Workflows runs sequenced actions, and by Stripe's own FAQ those runs are short, most completing in seconds. Re-runs start from the very beginning rather than the failed step, those re-runs are not idempotent, and long waits are listed as future support that is planned. It is excellent for short action sequences. Sutyr is the durable, resumable runtime underneath: workflows that run for days, survive a deploy mid-run, sleep, and wake on signals like payment_method.attached or charge.dispute.created. Complement, not competitor.
Isn’t this just dunning with extra steps?
No. Dunning tools send emails and SMS. Sutyr decides whether the underlying retry should happen at all, when, and on what schedule. We integrate with your email tool, we don’t replace it. The classification, the signal-driven wake, and the durable execution are the parts no email tool has.
What about Churnkey, Stunning, Butter Payments, Churn Buster?
Those tools optimize recovery timing and sell you an outcome, a recovery percentage, as a black box. Sutyr is a different layer: the recovery logic runs as durable, versioned code you own, branching by decline code, coordinating across a customer's invoices, and surviving a deploy mid-run. We are infrastructure, not an outcome service.
You’re pre-revenue. Why should I trust this?
Webhook Lab is public proof of how we approach correctness: Apache 2.0, 700+ tests, 18 event types, valid HMAC signatures, zero telemetry. The founding cohort is up to ten companies, each with direct founder access through the founding period. Founding pricing is locked through December 31, 2027.
What’s not in scope?
Sutyr is Stripe-only. We don’t route across payment processors. We don’t replace your billing platform. We don’t send dunning emails or SMS. We don’t run cancel-flow surveys. We run durable billing processes that outlive a webhook request — recovery, keyed off decline codes and coordinated on a signal mesh, is the first one. That’s the whole product.
What if Stripe builds this themselves?
Every extensibility surface Stripe ships, Workflows and Scripts alike, runs as a short, synchronous, stateless burst. That is deliberate: their code runs inside Stripe's own invoice path, where a long-running or stateful tenant process would be a liability for Stripe itself. So the constraint is architectural self-protection, not immaturity. What stays outside that fence is exactly Sutyr's lane: long-running, resumable, externally-connected billing processes that span days and cross your own systems. We complement Stripe; we do not bet against it.
Why not Stripe Scripts?
Stripe describes Scripts as synchronous, stateless, and deterministic: one decision at one moment in time, business logic that runs inside Stripe's invoice path at a specific extension point and returns a result. That is a calculator, not an orchestrator. It can change the number Stripe computes; it cannot run the multi-day, resumable recovery process that follows a failure. That process is what Sutyr is.
Doesn’t Stripe’s Payments Foundation Model already recover payments?
Stripe's Foundation Model is strong at the authorization moment, getting more first attempts approved and retrying false declines in real time before the customer sees one. Smart Retries then picks good times to re-attempt a failed invoice. Use both. What neither does is let you express your own recovery strategy across the days after a subscription charge hard-fails: which decline codes you chase, in what order, with what business logic, held durably as code you own. Stripe optimizes the attempt; it does not orchestrate your logic. That layer is Sutyr.
What about security and compliance?
Privacy posture spans 13 jurisdictions including Quebec Law 25, GDPR, and UK GDPR. Ten named sub-processors under Standard Contractual Clauses. Self-hosted analytics; cloud error monitoring with PII masked and email hashed. SOC 2 Type I in progress. Full detail in the sub-processor disclosure.
Pricing?
Founding cohort: $599/month, locked through December 31, 2027. Up to ten companies.
Includes the full Sutyr platform: durable billing workflows, signal-mesh coordination, decline-code recovery, Webhook Lab, DPA on request, and direct founder access through the founding period.
General availability pricing finalizes with founding cohort feedback. Founding members lock their founding rate through their lock period. Enterprise contracts available for Connect platforms and high-volume buyers.
No payment collected at application. Billing begins at platform launch.
Founding cohort open now. Platform launching shortly.
Your billing infrastructure
should never drop a call.
Let us prove it.
We're selecting up to ten founding companies before general availability. Full platform access and direct founder access through the founding period.
Complex billing logic should be stateful, durable, and invisible. That's what I'm building.
Toufic Jrab, McGill Engineering, Montreal
Founding cohort
locked through December 31, 2027
Up to ten founding companies.
The platform
- Durable workflows that survive restarts, deploys, and multi-day waits
- Signal-mesh coordination across a customer’s invoices and disputes
- Recovery policies you tune to your own business logic, as code you own
- Decline-code classification into wait, pause, or stop strategies
- Queryable workflow state with a full audit trail
Founding access
- Direct founder access through the founding period
- Roadmap influence on what ships next
- Cohort Slack and quarterly syncs
- DPA on request
GA pricing finalizes with founding cohort feedback. Founding members lock their founding rate through their lock period.
No payment collected at application. Billing begins at platform launch.
Running at higher volume, or need a custom contract? Reach out at toufic@sutyr.com.
Not ready to apply? Try Webhook Lab first. Our open-source Stripe webhook testing tool.