Enruta

Docs Start

Overview

LiveUpdated

View as Markdown

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

Agent side

  • a policy the user signed
  • request_payment
  • decision · mandate · credential
  • request_reversal

↓ request↑ mandate

Enruta

  • decision + risk assessment
  • mandate + ledger
  • reversal · dispute packet
  • settlement · reconciliation

↓ verify↑ report

Merchant side

  • Accept middleware
  • labels: agent · mandate · policy
  • adjustments → reversal
  • dispute packet · badge

One record, both sides

  • rec_… buyer side
  • payment · reversal_of · settlement_of

⇅ chains by hash · verifies offline, no account

  • rec_… seller side
  • agent_order · merchant_view_of

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.

ObjectWhat it isWho holds it
PolicySigned, versioned rules: caps, payees, categories, approvers, mode, refill policy, and what a request must say and prove.Enruta, on the user’s signature
MandateOne single-use authorization for one payment, bound to the request, with a ledger of what it consumed.Enruta, until it is consumed
Decisionallow, 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 RecordOne 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 orderThe merchant’s view of the same purchase: labels, risk signal, the buyer record’s hash.The seller. It chains to the buyer’s record.
FundsThe 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.

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, dispute packet, reconciliation line and weekly report, settlement record, consent record and KYA attestation, and recurrence for repeated payments. The risk assessment is made with every decision and goes to the merchant as a risk_signals entry, and the money split 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 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, the Sellers pages and the Platforms pages.

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), 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.