Payment retries · Dunning sequences · KYC pipelines · Billing automation
A duplicate charge costs you a customer. Orch8 is a Rust-based durable workflow engine with crash recovery, memoized step outputs, and per-provider rate limiting — so payment retries, dunning sequences, and KYC pipelines run exactly as designed, even through crashes and deploys.
The problem
Your Stripe integration is 200 lines. The retry logic, dunning state machine, idempotency layer, and crash recovery code around it is 20,000 lines of fragile custom infrastructure.
Your payment service crashes after charging a card but before recording the result. Without memoization, the retry charges the customer again. Chargebacks, refunds, and lost trust follow.
Failed payment? Someone wrote a cron job that retries once, then gives up. There is no escalation, no payment method switching, no grace period logic. Involuntary churn climbs silently.
Identity verification, sanctions screening, document review, and manual approval are stitched together with queues and hope. One service goes down and the whole pipeline stalls with no recovery path.
Stripe, Adyen, and Plaid all enforce per-second limits. A burst of subscription renewals at midnight exhausts your quota and fails legitimate charges at the worst possible moment.
Regulators ask who approved what, when, and why. Your payment decisions are scattered across application logs, database tables, and Slack threads. Reconstructing the trail takes days.
Retry logic, state machines, idempotency layers, dead letter queues, monitoring dashboards. Your team spends half the year building plumbing instead of the product your customers pay for.
Use cases
Orch8 is a general-purpose durable workflow engine. These are the fintech and payments workloads teams reach for it most.
Payment retry & dunning
Charge fails? Wait 3 days and retry. Still failing? Try the backup payment method. Send a soft reminder after 7 days. Downgrade the account after 30 days. All durable, all configurable, all crash-safe. No involuntary churn from lost retries.
Subscription lifecycle
Manage the full subscription lifecycle: trial start, conversion reminder, first charge, recurring renewal, failed payment dunning, cancellation with grace period, and win-back sequences. Each transition is a durable step that survives restarts.
KYC/AML compliance
Chain identity verification, sanctions screening, document review, and manual approval into a single durable pipeline. If the sanctions API is down, the step retries with backoff. If a human reviewer is needed, the pipeline waits. Full audit trail for every decision.
Invoice processing
Receive an invoice via webhook or email. Extract line items with an LLM. Validate against purchase orders. Route to the right approver based on amount thresholds. Execute payment on approval. Reconcile with the general ledger. Crash-safe across every step.
Refund & chargeback handling
Chargeback received? Pull transaction details, check fraud signals, route to the right team based on dispute reason. If auto-resolvable, process the refund and notify the customer. If manual review is needed, pause and wait for a human signal. Every step is auditable.
Payout orchestration
Calculate payouts for merchants or creators. Route large amounts through human approval gates. Batch transactions to minimize fees. Submit to banking rails with per-provider rate limits. Reconcile settlements against expected amounts. Resume from any step after failures.
How it works
Describe the steps, delays, conditions, and retry logic in a JSON sequence definition. No SDK required. No new programming model. Your handlers are plain HTTP endpoints in any language.
{
"id": "payment_dunning",
"blocks": [
{
"type": "step",
"handler": "charge_payment_method",
"retry": { "max_attempts": 2, "backoff": "5s" },
"rate_limit_key": "stripe:charges",
"rate_limit": { "max": 95, "window_seconds": 1 }
},
{
"type": "router",
"routes": [
{
"condition": "{{outputs.charge_payment_method.status == 'succeeded'}}",
"blocks": [
{ "type": "step", "handler": "activate_subscription" }
]
},
{
"default": true,
"blocks": [
{
"type": "step",
"handler": "wait",
"delay": { "duration": 259200000 }
},
{
"type": "step",
"handler": "retry_with_backup_method"
},
{
"type": "step",
"handler": "wait",
"delay": { "duration": 604800000 }
},
{
"type": "step",
"handler": "send_payment_reminder"
},
{
"type": "step",
"handler": "wait",
"delay": { "duration": 2592000000 }
},
{
"type": "step",
"handler": "downgrade_account"
}
]
}
]
}
]
}Workers are plain HTTP handlers. Orch8 calls them via a pull-based REST API. Write them in TypeScript with the Stripe SDK, Python, Go, Ruby -- anything that can respond to a POST request.
// TypeScript worker — charge a payment method via Stripe
app.post('/workers/charge_payment_method', async (req, res) => {
const { context } = req.body;
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const charge = await stripe.paymentIntents.create({
amount: context.data.amount_cents,
currency: context.data.currency,
customer: context.data.stripe_customer_id,
payment_method: context.data.payment_method_id,
confirm: true,
idempotency_key: context.data.idempotency_key,
});
// Output is memoized — if engine crashes after this,
// Persist the result and reconcile unknown provider outcomes before retry.
res.json({
status: charge.status,
charge_id: charge.id,
amount: charge.amount,
});
});Start a dunning sequence from a failed charge webhook, a subscription renewal event, or a manual trigger. Orch8 schedules and tracks execution from start to finish. Idempotency keys prevent duplicate pipeline creation.
POST /sequences/payment_dunning/instances
{
"context": {
"data": {
"stripe_customer_id": "cus_R8x2kLm9nPq4vT",
"payment_method_id": "pm_1Nq2xY2eZvKYlo2C",
"amount_cents": 9900,
"currency": "usd",
"subscription_id": "sub_8kT3mW",
"idempotency_key": "charge-sub_8kT3mW-2026-04"
}
},
"idempotency_key": "dunning-sub_8kT3mW-2026-04"
}Why Orch8 for fintech
When a step completes, its output is persisted before the next step begins. If the engine crashes and recovers, it returns the cached result instead of re-executing. Your charge_payment_method handler uses a stable provider idempotency key. Effect receipts and reconciliation make retries observable across crashes, deploys, and restarts.
Payment retry sequence — simplified
{
"id": "invoice_retry",
"blocks": [
{
"type": "step",
"handler": "charge_payment_method",
"retry": { "max_attempts": 2, "backoff": "3s" },
"rate_limit_key": "stripe:charges",
"rate_limit": { "max": 95, "window_seconds": 1 }
},
{
"type": "step",
"handler": "wait",
"delay": { "duration": 259200000 }
},
{
"type": "step",
"handler": "retry_with_backup_method"
},
{
"type": "step",
"handler": "wait",
"delay": { "duration": 604800000 }
},
{
"type": "step",
"handler": "send_payment_reminder"
},
{
"type": "step",
"handler": "wait",
"delay": { "duration": 2592000000 }
},
{
"type": "step",
"handler": "downgrade_account"
}
]
}What happens on crash
What you don't build
Every fintech team that handles payments eventually builds all of these. With Orch8, none of them are your problem.
Persist receipts for completed steps. If a crash or timeout leaves the provider outcome unknown, reconcile it and reuse the same provider idempotency key before retrying.
No custom code tracking which retry attempt the customer is on, which payment method to try next, or when to downgrade. Define the flow as JSON. Orch8 manages the state.
No Redis-backed counters per provider. Set a rate_limit_key and a limit on any step. Orch8 tracks usage with a sliding window and defers overages automatically.
No exponential backoff implementation, no dead letter queue wiring, no cron-based retry jobs. Each step configures its own retry behavior and delay inline.
No separate logging pipeline for regulatory compliance. Every step execution, output, retry, and signal is persisted in PostgreSQL. Query it directly for audit reports.
No hand-rolled state machine for trial, active, past_due, canceled, and grace_period states. Define lifecycle transitions as sequence steps. Orch8 tracks position across restarts.
Tell us what you're building. We'll reach out within 24 hours to walk you through a working example for your payment workflow — dunning sequences, subscription lifecycle, KYC pipelines, or payout orchestration.
No credit card required. Self-host free with no feature gates.