kordio.

Use case · Refunds and payouts

Your refund service has no spending limit.

Support tooling issues credits. Marketplace operations releases payouts. Batch jobs retry. None of it asks anyone, and the ceiling is whatever the API allows. Kordio puts a rule in front of every release and asigned record behind it, without touching the money.
Gate a refund in test modeSee the call
  • No rail needed
  • Works with no AI at all
  • We never hold your funds
POST /v1/agent/actionsthe refund service asks
{
  "action_type": "refund.issue",
  "resource": "order_88213",
  "cost_cents": 48000,
  "currency": "USD",
  "metadata": { "queue": "support-tier-1" }
}

Kordio answers

{
  "decision": {
    "outcome": "requires_approval",
    "rule": "tier1_daily_refund_ceiling",
    "headroom": { "window_remaining_cents": 12000 }
  }
}

The reservation is held while a person decides. Nothing moved, and the reason has a name.

Inside Kordio

Review the exceptions. Keep work moving.

See the policy, available budget, and decision together in the Kordio console.
Kordio workspaceProduct preview
Review the exceptions. Keep work moving.

The shape of the leak

Four things that are standing in for a policy.

Refund and payout leakage is rarely fraud. It is usually a threshold that stopped being right, and a system that cannot say who decided.
The threshold everyone knows
Refunds under a number go through automatically. Everyone learns the number, including the automation, and the number stops meaning anything the day volumes double.
The approval channel
A Slack message nobody reads at 4pm on a Friday. It records that somebody clicked, not what they were approving or what the policy was.
The service account with no ceiling
The refund service holds the same credential it held two years ago, and nothing in the stack has an opinion about how much it may release this week.
Nobody can answer afterwards
When Legal or Finance asks who authorized a release, the honest answer is a log line saying the API call succeeded.

How it runs

One call, in the path you already have.

Four steps, none of which move your money or change your rail.

01

Name the action
An action type is a dotted string. refund.issue and payout.release are just strings, so nothing here needs a card or a rail.

02

Write the ceiling once
Per action, per day, per queue, per counterparty. Held outside the service, so changing it is not a deploy and every caller inherits it.

03

Route the exceptions
Above the threshold becomes an approval over a webhook, with the reservation held meanwhile so the budget cannot be spent twice while somebody thinks.

04

Require the signature
Make your executor verify the cosignature before it releases anything. Now a caller that skipped the check cannot act, and the audit trail names the rule months later.

Why this one first

It is the only place the number already exists.

Most control problems are hypothetical until something goes wrong. This one is not. Refund and payout leakage is usually already measured by somebody in finance, there is a named person accountable for it, and no new payment rail has to be adopted to fix it. That combination is rare, and it is why we suggest starting here rather than with the most exciting agent in your stack.

The other place teams start iscapping what an agent may spend on paid tools. If you want the record underneath all of it, that isthe ledger.

Questions

What teams ask first.

Want us to help model it against your own numbers?sales@kordio.io.
We do not use AI agents. Is this still for us?

Yes, and this is the most common misunderstanding. Anything non-human that starts a money movement has the same problem: a refund service, a payout run, a batch job, an ops tool, a support macro. Agents make it louder, not different.

Does Kordio issue the refund?

No. Kordio never executes anything and holds no funds. Your existing refund path still does the work. Kordio decides whether it may, and signs the yes so the executor can verify the authority rather than trusting the caller.

What stops someone calling the refund API directly and skipping Kordio?

Nothing, unless your executor requires a signature. That is the design: make the cosignature a precondition of executing, and a caller that skipped the check has nothing to present. A control layer only binds the paths you route through it, and we say so plainly.

How is this different from our approval workflow tool?

Those are built for humans holding cards. There is no card here and often no human. This runs in the API path, holds budget state across runs, and returns something verifiable.

What does this cost to try?

Nothing. Test mode is the full engine with no card. Model last quarter policy against test-mode agents and see what it would have stopped before you decide.

Model last quarter, then decide.

Write the ceiling you wish had been running, replay the refunds you actually issued against it in test mode, and see what it would have caught. No card, no call.
Get sandbox keysRead the API docs