Docs · preview
Overview
Enruta is the payment layer between an agent that wants to pay and the rail that moves the money. It holds the policy, issues the mandate, executes on your own rail, and seals the record. It does not hold funds.
The shape of it
Four verbs, one object. An agent calls request_payment with a payee, an amount, a purpose and whatever evidence it has. Enruta decides against the policy your controller signed, executes on your own rail, proves the outcome in one Evidence Record, and reconciles the record against what the rail posted.
| Object | What it is | Who holds it |
|---|---|---|
| Policy | Signed, versioned rules: caps, payees, categories, approvers. | Enruta, on the controller’s signature |
| Mandate | One single-use authorization for one payment, bound to the request. | Enruta, until it is consumed |
| Decision | allow, step_up or deny, with reasons and every input. | Enruta |
| Evidence Record | One sealed file per payment attempt. | You. It verifies without Enruta. |
| Funds | The money. | Your rail, always |
Where it runs
The same five tools are exposed as an MCP server, so an agent in Claude Code, Claude.ai, ChatGPT, Codex or any MCP client can request a payment without a custom integration. A REST API and a CLI cover everything else. See the quickstart.
What Enruta is not
- Not a processor or a wallet. Execution runs on your Stripe Issuing, Ramp, Mercury or Bill.com account, under credentials your administrator scoped.
- Not a card vault. Enruta stores mandates, token references and metadata. Never a card number.
- Not a share of the flow. Enruta is priced per sealed record.