# Overview

The payment stack for agent commerce: the agent side, the merchant side, and one record both can verify.

Status: Live · Updated: 2026-10-23
Source: https://enruta.ai/docs

Enruta sits between an agent that wants to pay and the merchant that receives the order. On the agent side it holds the policy, decides, issues a single-use mandate and executes the payment. On the merchant side it recognizes the agent order at the edge, labels it, and turns refunds, disputes and reconciliation into evidence. Both sides read the same sealed record.

> These pages describe what is callable today. Every page carries a status (live, preview or planned) and the date it last changed. Use the tabs at the top of the docs to order them for agents, sellers or platforms.

## The shape of it

(Figure: two-sided)

One purchase, two views. The agent calls `request_payment`; Enruta decides against the policy the user signed, compiles the mandate into a control on the user’s rail, and seals the record. The merchant’s edge middleware verifies the same mandate, labels the order with `agent_id`, `mandate_ref` and `policy_version`, and reports it; the merchant-side record chains to the buyer-side one by hash.

| Object | What it is | Who holds it |
|---|---|---|
| Policy | Signed, versioned rules: caps, payees, categories, approvers, mode, refill policy, and what a request must say and prove. | Enruta, on the user’s signature |
| Mandate | One single-use authorization for one payment, bound to the request, with a ledger of what it consumed. | Enruta, until it is consumed |
| Decision | `allow`, `step_up` or `deny`, with reasons, every input, how the intent was judged and a signed risk assessment; `observe` in shadow mode, `clarify` while a question is open. | Enruta |
| Evidence Record | One sealed file per payment attempt, and one per reversal, dispute packet, settlement, reconciliation line, consent, attestation and pause, chained together. | You. It verifies without Enruta. |
| Agent order | The merchant’s view of the same purchase: labels, risk signal, the buyer record’s hash. | The seller. It chains to the buyer’s record. |
| Funds | The money. | Your rail and your PSP, always |

## Identity and intent

Two questions decide whether an agent may pay: which agent this is, and whether the payment is what the person meant. Enruta checks identity in both directions, the merchant checking the agent and the agent’s side checking the merchant, and judges intent on the user’s side only, turning the person’s words into slots, rules, an optional model, and questions for whatever is missing. See the [trust model](https://enruta.ai/docs/trust-model).

## Supporting objects

Everything that happens after the payment has its own object, each sealed as a linked record on the same chain as the payment it refers to: [reversal](https://enruta.ai/docs/reversal), [dispute packet](https://enruta.ai/docs/dispute-packet), [reconciliation line and weekly report](https://enruta.ai/docs/reconciliation), [settlement record](https://enruta.ai/docs/settlement), [consent record and KYA attestation](https://enruta.ai/docs/consent-and-kya), and [recurrence](https://enruta.ai/docs/recurrence) for repeated payments. The [risk assessment](https://enruta.ai/docs/risk-assessment) is made with every decision and goes to the merchant as a `risk_signals` entry, and the [money split](https://enruta.ai/docs/economics) shows who paid, received and earned on each payment.

## Where it runs

The same fifteen 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 or a refund without a custom integration. A REST API, TypeScript and Python [SDKs](https://enruta.ai/docs/sdks) and a CLI cover everything else. Merchants add one edge middleware or a hosted storefront; platforms act for their customers’ accounts with one key. See the [quickstart](https://enruta.ai/docs/quickstart), the [Sellers pages](https://enruta.ai/docs/accept-middleware) and the [Platforms pages](https://enruta.ai/docs/platform-accounts).

## What Enruta is not

- Not a processor or a wallet. Execution runs on the rail the user already has, such as Stripe Issuing, Mercury, Ramp, Stripe Shared Payment Tokens or x402 ([Rails](https://enruta.ai/docs/rails)), and the merchant keeps its PSP and its merchant of record.
- Not a card vault. Enruta stores mandates, token references and metadata. Never a card number.
- Not a cut of the payment. Nothing is added to what the buyer pays and no fee is deducted from a payment: each successful payment carries one fee of 0.1% + $0.03 (at least $0.05, at most $0.50), invoiced monthly, and platforms pay per record.

## Read next

- [Quickstart](https://enruta.ai/docs/quickstart) for agents; [Accept middleware](https://enruta.ai/docs/accept-middleware) for sellers; [Platform accounts](https://enruta.ai/docs/platform-accounts) for platforms
- [Trust model](https://enruta.ai/docs/trust-model), [Policy](https://enruta.ai/docs/policy), [Mandate](https://enruta.ai/docs/mandate), [Decision](https://enruta.ai/docs/decision), [Evidence Record](https://enruta.ai/docs/evidence-record)
- [Signed policy](https://enruta.ai/docs/signed-policy), the controls every user has; [Who pays whom](https://enruta.ai/docs/who-pays-whom)
- [Evidence Record schema](https://enruta.ai/docs/schema) and [Verification](https://enruta.ai/docs/verification); [What Enruta does not cover](https://enruta.ai/docs/what-enruta-does-not-cover)