Your accounts. Your rails.
Enruta connects to the accounts you already have with credentials your administrator scopes on the rail’s side. It never holds the funds.
Per rail
What the mandate becomes.
The mandate becomes
A single-use virtual card on your own 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.
// on allow — on the customer's Stripe account, with a key the administrator scoped
issuing.cards.create({
cardholder: "ich_agent_procurement_02",
type: "virtual",
spending_controls: {
spending_limits: [{ amount: 16840, interval: "per_authorization" }],
allowed_merchant_countries: ["US"],
},
metadata: { mandate: "mnd_7c2a…d1f0", agent: "agt_procurement_02" },
})
// issuing_authorization.request → answered in 41 ms
{ "approved": true, "metadata": { "mandate": "mnd_7c2a…d1f0" } }The mandate becomes
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.
Enruta matches the posted transaction back to the mandate after it lands.
POST /developer/v1/funds
{
"display_name": "mnd_7c2a…d1f0 · office supplies",
"spending_restrictions": {
"limit": { "amount": 16840, "currency_code": "USD" },
"transaction_amount_limit": { "amount": 16840, "currency_code": "USD" },
"allowed_vendors": ["vendor_store_enruta"],
"lock_date": "2026-11-30T18:18:10Z"
}
}The mandate becomes
A virtual card with a spend limit equal to the mandate, on a cardholder your administrator created in Mercury.
Transactions are read back to fill the record’s outcome.
POST /api/v1/cards
{
"userId": "usr_agent_procurement_02",
"type": "virtual",
"kind": "debit",
"spendLimit": { "amountCents": 16840, "interval": "total" },
"nickname": "mnd_7c2a…d1f0"
}The mandate becomes
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.
The approval, the approver and the mandate land in the record; the ACH or check runs on Bill.com as before.
approve(bill = "INV-4471", approver = "enruta-approver",
mandate = "mnd_…", amount = 13200.00)
// everything outside the mandated batch stays human-releasedThe mandate becomes
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.
complete_checkout({
id: "chk_8f3…",
meta: { "idempotency-key": "a3c9…" },
payment: {
ap2: { checkout_mandate: "<signed mandate bound to chk_8f3… at 168.40 USD>" },
handler_id: "com.google.pay" // or dev.shopify.card — never a raw PAN
}
})Your credentials, scoped by you
An administrator creates a restricted key or a limited role on the rail’s side and enters it in the console. Enruta can do what that credential allows and nothing more.
No card numbers
Tokens and references only. The agent-facing tools reject anything that looks like a card number; the storage layer has no field for one.
Two-second answers
Where a rail asks Enruta in real time, as Stripe Issuing does, the answer is a lookup against the mandate: typically under ten milliseconds, recorded with the time it took.
Thin adapters
Each rail is one adapter with three duties: compile the mandate into the rail’s control, answer or observe the authorization, match the posting back to the record.
Protocol checkouts
UCP and AP2 merchants receive the checkout mandate proof they require; x402 and MPP receipts are captured into the record while the payment runs on your own wallet or account.
No fee on execution
Card, ACH and wire costs stay with the rail. A mandated payment is one sealed record whether Enruta executed it or only recorded it.