One mandate, every rail. Enruta compiles each mandate into the rail’s own control and matches what the rail posts back to the record.
What the mandate becomes.
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.
The call that creates it
// 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 44 ms
{ "approved": true, "metadata": { "mandate": "mnd_7c2a…d1f0" } }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.
The call that creates it
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"
}
}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.
The call that creates it
POST /api/v1/cards
{
"userId": "usr_agent_procurement_02",
"type": "virtual",
"kind": "debit",
"spendLimit": { "amountCents": 16840, "interval": "total" },
"nickname": "mnd_7c2a…d1f0"
}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.
The call that creates it
approve(bill = "INV-4471", approver = "enruta-approver",
mandate = "mnd_…", amount = 13200.00)
// everything outside the mandated batch stays human-releasedA 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.
The call that creates it
POST /v1/shared_payment/issued_tokens
payment_method=pm_…
seller_details[network_business_profile]=profile_…
usage_limits[currency]=usd
usage_limits[max_amount]=16840
usage_limits[expires_at]=1796062690An 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.
The call that creates it
// 402 Payment Required → the exact scheme on Base
transferWithAuthorization({
from: "0x…", // your wallet, through your signer
to: "0x…", // the payee from the 402 offer
value: 50000, // 0.05 USDC, held to the mandate
validAfter: 1796061790,
validBefore: 1796062690, // the mandate's expiry
nonce: "0x…"
})
// the PAYMENT-RESPONSE is sealed into the recordFor 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.
The call that creates it
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
}
})Scoped credentials
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 that adds under 10 ms (44 ms end to end, measured on Stripe Issuing), 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 payments are made by adapters that seal their receipts.
No fee on execution
Enruta adds no fee on execution. A mandated payment is one sealed record whether Enruta executed it or only recorded it.