One stack for both sides of the purchase. Enruta checks the agent and the intent, decides against the policy, pays the merchant and seals one record both sides can verify.
Five stages, one evidence ledger.
- 01Discovery
- Catalog serving
- GEO and AI visibility
- Recommendations (planned)
- Price matching (planned)
- AI assistant integrations
- 02Order
- Agent checkout protocols
- Mandates
- Closed-loop checkout
- Inventory sync (planned)
- Cross-protocol support
- 03Risk
- KYA interoperability
- Agent-native risk control
- Immutable order records
- 04Payment
- Rail execution
- Cross-border settlement (planned)
- Reconciliation
- Compliance evidence
- 05Post-purchase
- Disputes and chargebacks
- Refunds and returns
- Buyer and merchant protection (planned)
Planned, not running yet
One payment and what follows it. Click through, or use the arrow keys.
Step 1 of 8: The agent asks
The agent asks
One tool call with the payee, the amount, the purpose and the evidence it has. No card number anywhere.
Enruta decides
The policy the user signed runs in order: payee, category, window, cap, budget, duplicates, screening. The budget is reserved atomically.
A person signs
The person who approves sees the cart and the agent’s reason on their phone and signs with a passkey. The signature binds the request hash.
The rail moves the money
A single-use card for the exact amount is minted on the customer’s connected Stripe Issuing account. The issuer’s real-time authorization is answered against the mandate.
The record is sealed
Everything above becomes one Evidence Record: canonicalized, hashed, chained to the previous record, time-stamped. It verifies offline, without Enruta.
The merchant refunds
Three days later the stapler goes back and the merchant refunds $9.99. The adjustment becomes a reversal: decided against the same policy, matched to the rail’s refund, sealed as a new record chained to the payment.
A dispute arrives
Months later the cardholder disputes the charge. From the same record, one call produces the packet: the login id, the device, the IP, the mandate, the approval chain and the authorization, in the formats the merchant’s dispute tools accept.
The week reconciles
Every Monday the mandate, the rail’s authorization and settlement, the merchant’s order and both refund entries are joined into one line. The person who approves signs the week with a passkey; the lines and the report seal as records.
The calls behind this step
> request_payment
agent=agt_procurement_02 payee=reamandrule.com (verified)
amount=168.40 USD purpose="20 reams A4 paper, 1 stapler"
checkout=ucp:chk_8f3… evidence=[quote sha256:…] idempotency=a3c9…Two questions, checked separately: who the agent is, and whether this is what the person meant.
Intent decided on the user’s side
User → asks → Agent → request → Enruta
↓ signed mandate → Merchant
Identity checked both ways
The merchant checks the agent
The agent’s side checks the merchant
Rail · PSP the payment executes here
Intent, on the user’s side. The person’s words become slots the policy checks. Rules decide first. If the policy allows, a separate model judges the rest, and its inputs are hashed into the record. A gap becomes a question, not a guess.
Identity, both ways. The merchant checks the agent’s anchors and gets an assurance level, A0 to A3. Before paying, the agent’s side checks the merchant’s domain, keys and checkout signature.
A policy the user signed, evaluated in order, reserved atomically.
Try the sample policy. Change the payee, the amount or the category and watch the decision, the reasons and what would be compiled onto the card.
Decision
Step-up
approval_requiredAbove $150: a named person must sign
- Approval
- Asked of the approver
- Method
- Passkey, bound to the request hash
- Expires
- In 15 minutes
- Mandate
- Issued after the signature
Every user also gets shadow mode, approvals from phone or Slack, scoped delegation, a one-click pause and a signed weekly report.
The mandate becomes the rail’s own control.
Enruta decides first, then compiles the decision into each rail’s control: a card limit, a spend limit, a bill approval or a checkout proof.
A single-use virtual card on the connected Stripe account: amount equal to the mandate, the payee as the allowed merchant, expiry equal to the mandate’s. The real-time authorization request is answered against the mandate inside the two-second window.
The card token reaches the payee. The card number never reaches the agent and is never stored by Enruta.
A spend limit for the mandate’s amount and purpose, with the merchant and category restrictions the policy allows; the virtual card is issued against it.
Needs your Ramp account with API access. Enruta matches the posted transaction back to the mandate after it lands.
A virtual card with a spend limit equal to the mandate, on a cardholder your administrator created in Mercury.
Needs your Mercury account with API access. Transactions are read back to fill the record’s outcome.
For invoices, an approval scoped to one bill from an approver identity your administrator assigned to Enruta. Enruta reads with an auditor-role user and writes only the approval.
Needs your Bill.com account with API access. The approval, the approver and the mandate land in the record; the ACH or check runs on Bill.com.
A Shared Payment Token for the named seller, whose usage limits are the mandate’s: the currency, the maximum amount and the expiry. The seller charges it.
Needs Stripe’s agent access on your Stripe account. The token is scoped to one seller and expires with the mandate.
An EIP-3009 authorization for the exact amount in USDC on Base, signed by your signer, with the value, the recipient and the deadline taken from the mandate.
An x402 payment cannot be reversed, so the policy’s lower cap for irreversible rails applies.
For merchants on the Universal Commerce Protocol, the mandate is the ap2.checkout_mandate proof the merchant requires before it completes the checkout. The merchant’s consent object is kept in the record by digest.
The same record fields fill from a UCP checkout as from a card authorization.
One file per payment. Verifiable in 2033 without us.
Sealed bytes
- rec_…VZ sha256 e91a…0c3d
- prev …
↓ prev hash
- rec_…W6 sha256 b0d4…71c9
- prev e91a…0c3d
↓ prev hash
- rec_…X1 sha256 4c2f…a9e0
- prev b0d4…71c9
↓ rolled into
- daily root
- signed checkpoint
Each record has a bundle outside its bytes: RFC 3161 time-stamps, proofs and keys. Renewals never change the record hash.
Sixteen core fields that AP2, ACP, UCP, x402, MPP, card authorizations and accounting exports all map into, six more for B2B rails, and since enruta/0.3 the intent, the judgement and both parties’ identity.
Canonicalized, hashed, chained, rolled into a daily root and time-stamped. Later proofs live in a companion bundle, so the record itself never changes.
Joined per payment, exceptions surfaced weekly.
- credential→
- authorization→
- posted transaction→
- receipt→
- ledger
One line per mandate joins the agent, the rail, the merchant’s order and every adjustment. Nine exception codes each suggest an action. Every Monday the approver signs last week’s report, and it seals as a record.
Every payment shows where its money went, and what Enruta earned.
The user pays for the goods. The merchant pays its PSP a fee, shared by the issuer, the network, the acquirer and the PSP. The agent platform earns from its own fees. Enruta is paid one fee per payment, invoiced monthly. Every line is marked actual, estimate or plan.
- The user
- Pays the price of the goods and receives the goods.
- The merchant
- Pays its PSP’s fee and receives the price, less that fee. Earns its margin on the goods.
- The PSP and acquirer
- Receives the fee and pays interchange and network fees out of it. Earns what is left of the fee.
- The card issuer
- Receives interchange and earns from it.
- The card network
- Receives network fees and earns from them.
- The agent platform
- Receives nothing from the payment. Earns its subscription, or its own fee to the merchant.
- Enruta
- Receives nothing from the payment. No plan: 0.1% + $0.03 a successful payment, at least $0.05; the sandbox is free. The merchant pays when it is on Enruta; otherwise the agent account that started the payment pays the same fee.
The merchant recognizes the agent order and keeps the evidence.
One edge middleware, or a hosted storefront, recognizes the agent, verifies the mandate, labels the order and seals a record chained to the buyer’s. Refunds, disputes and reconciliation use the same objects.
The agent recognized, the mandate verified, the order labelled with
agent_id,mandate_refandpolicy_version, a signed risk signal, a sealed record of its ownA storefront: hosted UCP endpoints and an ACP shim for the merchant’s catalog, paid by mandate or PSP token
The merchant’s adjustment, or its PSP’s refund webhook, becomes a reversal on the buyer’s side, and comes back in the UCP, ACP, Adyen and Shopify shapes
One call produces the dispute packet: login id, device, IP, mandate, approval chain, authorization, and a one-page PDF, which can be delivered into Stripe, Shopify, Adyen, Klarna, Chargeflow or Justt
The merchant’s slice of the reconciliation: order, mandate, authorization, settlement, adjustments, on one line
One key runs Enruta for every customer of a PSP, a dispute service or an agent platform.
A platform creates an Enruta account for each of its customers and calls the same API for them, naming the account in a header. Each customer keeps its own policies, budgets, keys and records. Priced by the record.
An Enruta account per customer, created and keyed through one platform key, with usage per account
Every API call made for a customer with the
Enruta-Accountheader, under that customer’s own policyA verification page and a web component in the platform’s brand; records checked in the browser
Dispute packets, records and reversals pushed as they happen, in Enruta, Chargeflow, Justt or Visa CE3.0 shape
Where the agent labels go in nine PSPs’ and orchestrators’ own payment objects
All five are live.
The same fifteen tools in every host.
The plugin bundles the MCP server, the enruta-pay skill and a hook that blocks checkout calls without a mandate.
/plugin marketplace add enruta-ai/claude-plugin
/plugin install enruta@enrutaSettings → Connectors → Add custom connector, then sign in with your Enruta account and pick the agent the connector acts as. No key to paste.
https://mcp.enruta.ai/mcpDeveloper mode under Settings → Security and login, then add a connector pointing at the MCP server with OAuth; sign in with your Enruta account and pick the agent. ChatGPT hands the final checkout to the person. Plus, Pro, Business or Enterprise.
https://mcp.enruta.ai/mcpOne command. The agent key comes from an environment variable, never from the config file.
codex mcp add enruta --url https://mcp.enruta.ai/mcp --bearer-token-env-var ENRUTA_AGENT_KEYStreamable HTTP with a bearer header.
{
"mcpServers": { "enruta": { "url": "https://mcp.enruta.ai/mcp",
"headers": { "Authorization": "Bearer ${ENRUTA_AGENT_KEY}" } } }
}Working with the first design partners.
A few companies, agent builders and merchants are shaping the first records with us. If your agents pay, or you sell to agents, write to us.