Docs · Guides
What Enruta does not cover
LiveUpdated
A record that survives scrutiny needs a product page that does too. This is the list of things Enruta does not do, either by design or because someone else decides.
By design
| Not covered | Why |
|---|---|
| Holding funds, being the merchant of record, guaranteeing a payment | Enruta holds policies, mandates, decisions and records. It has no balance, no ledger of money and no payout capability. Execution runs on the user’s own rail and the merchant’s own PSP. |
| A fee on the money | No basis points of your flow, no fee on execution. Card, ACH and wire costs stay with the rail you already pay, unmarked. |
| Card numbers | Every interface rejects anything that looks like one; the storage layer has no field for it. |
| A registry of agent identities | Enruta verifies anchors from issuers that already exist and seals them (identity anchors); it does not run a registry. |
| Identity documents and KYC | A legal-entity anchor reads the verification a rail or an organization already has; Enruta never collects documents. |
| Keys and collateral | An x402 payment is signed by the customer’s own signer, and Enruta only limits what may be signed. A collateral anchor reads a contract’s balance on chain. |
| Buyer-side routing sold as a price | Routing is a feature of an adapter, not a line on the price list. |
| A wallet, a stablecoin, a facilitator for machine-to-machine payment protocols | Enruta pays x402 and MPP resources through adapters and seals their receipts; it runs no facilitator, wallet or token. |
| Product feeds and discovery | Catalog syndication is a merchant’s job. Enruta reads the catalog snapshot hash the agent saw, and a Storefront serves only the merchant’s own catalog. |
| Inventory reservation | Stays with the PSP or the platform; a Storefront checkout does not reserve stock. |
| Automating a lender’s or an installment provider’s interface | Lenders require the buyer to act in person. |
| Insurance against an agent’s mistake, certification for sale, digital goods on iOS | Outside what the product can stand behind, or the platform’s rules. |
| Treating a traffic-layer signature as authorization | Web Bot Auth says who sent the request; it says nothing about what the agent may buy. A mandate does. |
Where someone else decides
| Situation | What happens today |
|---|---|
| A merchant completes checkout only on its own page | The agent hands the person the merchant’s continue_url and reports the order afterwards (hand_off_checkout); the record seals with a self-asserted receipt. Whether such a merchant will accept a credential from an agent is the merchant’s decision, not Enruta’s. |
| A host that does not let a connector tool complete a purchase | ChatGPT’s safety monitor blocks purchase completion from a connector today; the mandate is issued and the checkout is handed off. Claude.ai, Claude Code and Codex complete the purchase. |
| Edge protection on a merchant’s site | A CDN or bot manager that blocks agent traffic blocks it before the mandate matters; the record notes the failure_class (captcha, anti_bot_script, cdn_block, waf_block, 3ds_challenge). The Accept middleware is the merchant’s own way to let signed agents through. |
| The issuer’s decision in a dispute | The dispute packet gives the merchant material that verifies; the outcome is the issuer’s. Enruta makes no promise about win rates, and the CE3.0 history element cannot be met before records are 120 days old. |
| Rails, PSPs and dispute services that need your account or an approval | Stripe Issuing, the sandbox, x402 and MPP run without anyone else’s approval. Mercury, Ramp and Bill.com need your account with API access; Stripe Shared Payment Tokens and Link need Stripe’s agent access on your account; Adyen, Checkout.com, Braintree, PayPal and Worldpay need your merchant account; dispute delivery needs your Klarna, Chargeflow or Justt account, and for Shopify an app that Shopify has approved. The rails, PSP connections and dispute delivery pages say which. |
What the boundary buys
Because Enruta never holds the money and never issues the identity, its record can be read by every party to the payment without a conflict of interest: the user, the merchant, the rail, the issuer, the auditor. That neutrality is the reason the verifier is open source and free, and the reason this page exists.