> ## Content Index > Fetch the complete content index at: https://stablecoininsider.org/llms.txt > Use this file to discover other available public pages before exploring further. # Best Infrastructure for Agentic Commerce in 2026 - URL: https://stablecoininsider.org/best-infrastructure-agentic-commerce-2026/ - Published: 2026-10-21T11:02:02.000Z - Updated: 2026-10-21T11:02:02.000Z - Description: Nobody sells the whole stack. A layer map of agentic commerce in 2026, who occupies each layer, and what breaks when you skip one. - Author: Milos Djukanovic - Tags: Analysis, AI There is no best platform for agentic commerce in 2026, because nobody sells the thing. What exists is a stack of seven layers, each with its own vendors, standards and failure modes. Teams that treat it as one purchase discover the gaps in production. A wallet with excellent policy controls still cannot prove a human approved anything. A facilitator settling in seconds does nothing about whether the counterparty is who it claims to be. So this is a layer map rather than a leaderboard. What each layer does, who occupies it today, and what specifically breaks if you leave it out. > The useful question is not which platform to buy. It is which of the seven layers you have covered, and which one your first incident will come from. ### Key Takeaways - Agentic commerce is seven layers, and no vendor covers all of them. - Every authorisation standard converges on a capped, expiring permission. - OpenAI is explicitly not the merchant of record under ACP. - Agent identity is now cryptographic, signed under RFC 9421. - Non-fraud agent disputes still have no liability shift. --- ## The Seven Layers Each layer answers one question, and the order below is roughly the order in which a transaction passes through them. Identity answers who the agent is and who is accountable for it. Authorisation answers whether this specific purchase was permitted. Wallet and policy answer what the agent may do with the money it can reach, and settlement answers how value actually moves. Facilitation answers who verifies and broadcasts the payment, discovery answers how the agent found the service at all, and records answer what you can prove afterwards. Skip any one and the others keep working right up until the moment they matter. **What to note:** map your current build against these seven before evaluating any vendor, because the gaps are usually in identity and records rather than in payments. --- ## Layer 1, Identity and Accountability This layer stopped being theoretical during 2026, which is the most useful development of the year. Agents can now sign their requests using HTTP Message Signatures under RFC 9421, giving a verifiable identity rather than a claimed one, with Ed25519 signatures checked against directories that Visa and Mastercard each maintain for agents registered with them. The signature carries a tag distinguishing an agent that is browsing from one that is paying, plus a nonce against replay. The accountability half is separate. An agent cannot hold an obligation, so the Agent Commerce Kit's identity half builds an auditable cryptographic link from an accountable legal entity to the agent acting for it, using W3C decentralised identifiers and verifiable credentials under an MIT licence. **What to note:** without this layer your fraud stack cannot distinguish a paying customer's agent from a scraper, so blanket bot blocking starts costing you revenue. --- ## Layer 2, Authorisation and Intent Three standard families occupy this layer and, read together, they have quietly converged on the same primitive. Google's AP2 records intent as mandates, a Checkout Mandate for the items and a Payment Mandate for the instrument, each with an open stage capturing constraints and a closed stage authorising a finalised amount, chained into an audit trail under Apache 2.0 with standardisation moving into FIDO Alliance working groups. OpenAI's ACP delegates payment by having a one-time request sent to the merchant's trusted payment service provider, setting a maximum chargeable amount and an expiry, with the provider returning a token that is passed to the merchant. The x402 ceiling scheme does the same thing on chain, authorising a maximum that the seller settles below. Different words, one idea. A capped, expiring, single-purpose permission is now the agreed shape of letting software spend, which is the argument our analysis of [**payments for AI agents**](https://stablecoininsider.org/stablecoin-payments-for-ai-agents/) makes from first principles. **What to note:** design your own authorisation around a cap plus an expiry even where no standard requires it, because every standard is landing there. [![Stablecoin Payments for AI Agents Need Enforceable Limits](https://storage.ghost.io/c/73/6a/736af0e4-2274-4543-a329-2952b2b52abc/content/images/2026/10/Screenshot-2026-10-21-at-12.28.35.png)](https://stablecoininsider.org/stablecoin-payments-for-ai-agents/) --- ## Layer 3, Wallet and Policy This is the most crowded layer and the one where the marketing is least reliable. The real differences are where a rule is enforced and what can override it. Crossmint installs signer permissions on chain in the wallet contract, Privy and Turnkey evaluate policies inside a trusted execution environment before signing, and Fireblocks is the only widely used option built on threshold signing where funds cannot move without quorum approval. Custody labels are close to useless here. An enclave-backed wallet is genuinely non-custodial when a user holds the authorising passkey and custodial in substance when your backend holds an API credential, so the question to ask is what happens when that credential leaks. **What to note:** check the override path, since a root quorum or a recovery method that can add signers sits above every policy you write. --- ## Layer 4, Settlement Two rails coexist and the choice is per product rather than per company. Cards carry the dispute machinery and the consumer protections, which is why agentic retail runs there, with the networks having built acceptance programmes for it. Stablecoins carry the per-request economics, because removing the fixed fee is what makes a payment of a fraction of a cent possible at all. The purpose-built networks are the development worth tracking. Tempo positions itself as a blockchain for stablecoin financial products with a machine payments protocol for agents paying for API services, and lists Stripe, Visa, Shopify, DoorDash and UBS among partners and customers, with Stripe's chief executive quoted calling it Stripe's default blockchain for new features. **What to note:** keep genuinely new counterparties on a reversible rail, since a first payment to an unknown party is exactly where dispute rights earn their fee. --- ## Layer 5, Facilitation The facilitator verifies a payment signature and puts the settlement on chain for your server, and it is the layer most teams inherit by accident from a tutorial. The field is wider than the one name everyone knows. The official documentation lists fifteen facilitators and says the list is not exhaustive, several of them free or gasless and chain-specific, with self-hosting and in-process self-facilitation both explicitly supported. One trap is worth repeating because it is so easy to ship. The convenient public endpoint at x402.org is documented as being for testnet development only rather than mainnet, despite appearing throughout sample code, and the production economics are covered in our report on [**USDC agent payments**](https://stablecoininsider.org/coinbase-usdc-payments-ai-agents-x402/). **What to note:** ask whether a quoted per-transaction fee applies per payment or per settlement, because batching makes those numbers differ by orders of magnitude. [![Coinbase USDC AI Agents: x402 Payments](https://storage.ghost.io/c/73/6a/736af0e4-2274-4543-a329-2952b2b52abc/content/images/2026/10/Screenshot-2026-10-21-at-12.29.06.png)](https://stablecoininsider.org/coinbase-usdc-payments-ai-agents-x402/) --- ## Layer 6, Discovery The least discussed layer is the one that decides whether anyone finds your service, and it is becoming a distribution business. Circle runs a curated marketplace of services priced in USDC that agents can discover and pay per request without subscriptions or API keys. Tempo pairs its machine payments protocol with a discovery and tool-routing layer for agentic workflows, and the x402 ecosystem has its own resource catalogues. Treat catalogues as a supply chain rather than a directory. A listing your agent trusts is a counterparty you did not vet, which is exactly how poisoned destinations reach otherwise well-built systems. **What to note:** allowlist the services an agent may pay even when it discovers them through a reputable catalogue. --- ## Layer 7, Records and Compliance This layer carries the obligations that do not care whether a person or a program initiated the payment. Sanctions screening has no de minimis amount and must reflect the current list state at the moment value moves, which an overnight batch cannot do for a continuously settling rail. Travel Rule thresholds depend entirely on jurisdiction, with the FATF baseline at USD or EUR 1,000, the long-standing US wire requirement above USD 3,000 with crypto under active rulemaking, and the EU applying full data sharing to all crypto transfers at a zero threshold. The record itself is the deliverable. Receipts issued as verifiable credentials make a metered agent payment auditable after the fact, and the business-side foundations are the same risk tiers and limits set out in our guide to [**onboarding merchants**](https://stablecoininsider.org/onboard-merchants-for-stablecoin-payments/). **What to note:** screen counterparties at an allowlist rather than per transaction, which turns an impossible per-payment obligation into a periodic one. [![Onboard Merchants for Stablecoin Payments: KYB and Limits](https://storage.ghost.io/c/73/6a/736af0e4-2274-4543-a329-2952b2b52abc/content/images/2026/10/Screenshot-2026-10-21-at-12.30.30.png)](https://stablecoininsider.org/onboard-merchants-for-stablecoin-payments/) --- ## The Stack at a Glance | Layer | Answers | Who occupies it | What breaks without it | | ----------------- | ---------------------------------------- | -------------------------------------------------- | ------------------------------------------- | | Identity | Who is this agent and who is accountable | Web Bot Auth, network directories, ACK-ID | You cannot separate customers from scrapers | | Authorisation | Was this purchase permitted | AP2 mandates, ACP delegated payment, x402 ceiling | Disputes resolve against you | | Wallet and policy | What may the agent do with funds | Crossmint, Privy, Turnkey, Fireblocks, CDP, Circle | One bug spends the balance | | Settlement | How value moves | Cards, stablecoins on Base, Solana, Arc, Tempo | Small payments are uneconomic | | Facilitation | Who verifies and broadcasts | Fifteen listed facilitators, or self-hosted | You run chain infrastructure yourself | | Discovery | How the service was found | Circle marketplace, Mercator, x402 catalogues | Nobody finds what you sell | | Records | What you can prove | Verifiable credential receipts, screening tooling | Examinations and disputes go badly | Read the final column and the priorities reorder themselves. The layers that fail quietly, identity and records, are the ones most builds leave for later. **What to note:** the liability position across all of this is unresolved, since fraud follows tokenised transaction rules while non-fraud agent disputes have no liability shift at all. --- ## What to Build First ### 1\. Settlement and facilitation, because nothing works without them Pick a rail per product and a facilitator you chose deliberately. Confirm the endpoint in your code is not a testnet-only public service. ### 2\. Wallet policy, enforced outside the model Caps per hour, per day and per transaction, plus a destination allowlist the agent cannot edit. A prompt instruction is not a control. ### 3\. Records, captured automatically from the first payment Amount, counterparty, hash, chain, timestamp and the authorisation behind it. Retrofitting this across thousands of micro-payments is the expensive version. ### 4\. Identity, before you open anything to the public Verify signed agents rather than blocking automation wholesale, and establish the chain from your own agents back to your legal entity. ### 5\. Discovery last, once there is something worth finding Listing in catalogues is a growth activity. It should follow the controls rather than precede them. **What to note:** this order is deliberately the reverse of how most teams sequence it, which is why identity and records are the usual gaps. --- ## Risks and Limitations - Standards in the authorisation layer are young, and naming and headers have already changed once. - Vendor security and capability claims here are published statements rather than independently verified facts. - Free facilitators and sponsored gas are growth subsidies that can be repriced. - Liability for non-fraud agent disputes remains unallocated, so contracts carry the weight. - Compliance thresholds differ sharply by jurisdiction and some crypto rules are still in rulemaking. --- ## Conclusion The best infrastructure for agentic commerce in 2026 is an assembled stack rather than a product. Cards and stablecoins both settle, a facilitator you chose on purpose verifies, a wallet with policy enforced outside the model constrains, and a capped expiring permission authorises. The convergence is the most useful signal in the whole landscape. AP2 mandates, ACP's delegated payment token with a maximum amount and an expiry, and the x402 ceiling scheme are three expressions of one primitive, so building around that shape is safe even before the standards settle. What remains genuinely unfinished is liability. Fraud is broadly allocated, the loss from an agent that simply buys the wrong thing is not, and under ACP the agent platform is explicitly not the merchant of record. Until that changes, identity and records are not paperwork, they are the layers that decide who absorbs the loss. ***Read Next:*** - [**Payments for AI Agents**](https://stablecoininsider.org/stablecoin-payments-for-ai-agents/) - [**USDC Agent Payments**](https://stablecoininsider.org/coinbase-usdc-payments-ai-agents-x402/) - [**Onboarding Merchants**](https://stablecoininsider.org/onboard-merchants-for-stablecoin-payments/) --- ## FAQs: ### 1\. What are the layers of an agentic commerce stack? Identity, authorisation, wallet and policy, settlement, facilitation, discovery, and records with compliance. No single vendor covers all seven, which is why the practical question is which layers your build currently leaves empty. ### 2\. Do the competing payment standards actually conflict? Less than their marketing suggests. AP2 records intent as chained mandates, ACP delegates a one-time payment capped by a maximum amount and an expiry, and the x402 ceiling scheme authorises a maximum settled below, which are three expressions of the same capped expiring permission. ### 3\. Who is the merchant of record in ChatGPT checkout? The merchant, not OpenAI. Under ACP the merchant validates the order, calculates tax, assesses risk, accepts or declines and charges through its existing processor, while OpenAI acts as the customer's agent and passes a payment token issued by the merchant's provider. ### 4\. Can merchants verify that an AI agent is legitimate? Increasingly yes. Agents can sign requests using HTTP Message Signatures under RFC 9421, and Visa and Mastercard each publish directories of registered agents so a signature can be checked against the network's own record rather than a user-agent string. ### 5\. Which layer do teams most often skip? Records, followed by identity. Both fail silently until an examination, a dispute or a poisoned counterparty arrives, by which point reconstructing who authorised what across thousands of micro-payments is far more expensive than capturing it from the start. --- ***Disclaimer:*** This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional. Protocol specifications, platform capabilities, network claims, fees and compliance thresholds are drawn from each organisation's own published documentation at the time of writing, are not independently verified here, and are changing quickly; confirm current details with the relevant provider and with qualified counsel before building on them.