Refunds, credits and payouts are where most automation stops, because someone has to answer for them. Lyhnis runs them on your rules, hands the calls that matter to a named person, and keeps the evidence for every decision.
One run carries every step: code, AI agents and the people who approve.Simulation · illustrative data · fictional people and companies
02One run
Code, agents and people, in one run.
Scroll through the same claim. Each kind of step does one job, and the run keeps every one of them on the record.
01Code
Your rules run as code.
The repeat of a claim is recognised, and nothing runs a second time. Steps that move money refuse unsafe retries.
02AI agent
Agents work inside four budgets.
Iterations, tokens, wall-clock and cost. Budgets live in the engine, not the prompt.
03Person
The call goes to a named person.
By email, Slack or Teams, with a deadline. A run waiting for a person doesn’t take up a place.
04Record
Every step lands in one record.
The claim, the evidence, how it was sorted, the rule, who decided and what was paid, filed together and exportable.
03Tests
Try to break it.
Anyone can draw a refund workflow. These are the five things that go wrong in real life. Run each one and watch what Lyhnis does.
Each behaviour is enforced by the engine rather than by convention, and locked in by regression tests.
Shops and payment systems resend things. The repeat is recognised, and nothing runs a second time.
A partial unique index on (tenant_id, schedule_id, trigger_dedup_key) makes the redelivery an inert replay: 200, duplicate: true, no dispatch, no audit event. Money steps are replay-unsafe, and each Stripe call carries a key derived from its inputs.
If nobody decides in time, the customer isn’t told they were declined. The case goes to your operations team with everything attached.
Every approval records how it was resolved: resolution_source is HUMAN or TIMEOUT, and workflows branch on it, so a lapsed approval can never pass for a human rejection. A waiting claim releases its concurrency slot.
People can see a case without being able to approve it. Only the roles you allow can release a refund, and every decision is recorded against a named person.
One pure permission check, can(principal, permission, resource), sits behind every route, and a route that declares no check fails the test suite. Five roles, 57 permissions; approvals go to Operators and Admins.
Many businesses run on the same platform. Each one’s claims, people, credentials and records are invisible to the rest.
Every database read passes one session-level tenant filter; a read with no tenant bound raises instead of returning rows. Cross-tenant requests get 404, not 403. Tenants share one database; row-level security is on the roadmap.
The claim, the evidence, how it was sorted, the rule that applied, who decided and what was paid, filed together and exportable.
Each run freezes a snapshot of the workflow version it started with. All audit events pass through one front door that owns attribution and redaction. Approval history exports to CSV; the case packet is archived with on_error: FAIL.
Your shop, helpdesk or AI agent sends the work. Lyhnis applies your rules, gets the right person’s decision, acts in Stripe and your other systems, and keeps the record.
Webhooks and a REST API described by one OpenAPI spec, an MCP server for agents, and 77 activities across email, Slack, Teams, HTTP, databases, storage, OCR, LLMs and Stripe.
Sends the work
Your storefrontwebhook
Your helpdeskwebhook
Your own appsREST API
AI agentsMCP
LyhnisOne run, four stages
01
Your rules
What happens, and when
Work arrives from your storefront, helpdesk, apps or AI agents, and meets your rules.
Webhook triggers with idempotency keys, and HMAC verification when a secret is set. A REST API from one OpenAPI spec. An MCP server, so agents call workflows as tools.
02
Named people
Who decides
Decisions go to the named person who owns them, by email, Slack or Teams.
human.approval with role assignment and magic-link resolution; notifications on email, Slack and Teams; every resolution records its source.
03
Actions
What gets done
Approved work is carried out in Stripe and in your own systems.
77 activities, including Stripe, HTTP, SQL and cloud storage. Outbound URLs are checked on every request and every redirect hop.
04
The record
What you can prove
Every step lands in one record you can export and hand to an auditor.
One audit front door owns attribution and redaction; each run keeps a snapshot of its workflow version; approval history exports to CSV.
Where it acts
Email
Slack and Teams
Striperefunds
Your database or ERPHTTP, SQL
Cloud storagecase files
05Status
Where things stand.
Early and live. Here is exactly which is which.
Every figure on the board comes from one dated source.
As of September 2026
Live
Platform on Azure
Workflows, AI steps, human approvals and the audit trail, on production infrastructure.
Live
Refund claims, end to end
The film above: evidence, AI sorting, your rule, a named approver, the Stripe refund and the case file.
In development
Next module, with a retailer
An online retailer is building it with us, and sees it working on their own data first.
In development
Marketing that knows margin
The same engine pointed at ad budgets, with changes going through the approval gate. Not available yet.
5,863Automated tests
77Activities
57Permissions
5Roles
4Default-deny guards
06Security
Security claims you can check.
Everything marked live is in the product today. Everything else says roadmap.
One default-deny chokepoint per axis: tenant scope, permissions, outbound requests and audit, each locked in by regression tests.
Other companies can’t see your datatenant scope: one session-level filter, fails closedA read without a tenant raises an error instead of returning data.Live
One permission check behind every routecan(principal, permission, resource) on every routeA route with no declared check fails the tests.Live
Workflows can’t reach your internal networkegress guard on every request and every redirect hopUser-supplied URLs are checked each time.Live
One front door for the audit trailsingle audit entry point owns attribution and redactionEvery event is attributed and redacted in one place.Live
Multi-factor sign-inTOTP with single-use recovery codesAuthenticator-app codes on top of your password.Live
Encrypted credential vaultFernet-encrypted, never returned by the APISecrets are decrypted only when a step runs.Live
Single sign-on with Entra IDSSO (Entra ID)Roadmap
Row-level security as a second isolation layerPostgres RLS backstopRoadmap