Recommended Free Tools
AI agents can choose products, call merchant APIs and initiate payments without a person clicking through checkout. A safe agent payment architecture therefore needs more than a payment button: it must make the agent’s authority verifiable, bind that authority to the transaction, protect payment credentials and connect authorization to settlement and fulfillment.
How will AI agents pay for things?
An agent can act on a user’s behalf, but a merchant still needs to answer two questions: who is making this request, and did the user authorize this particular purchase under these conditions? A conventional checkout often relies on a person reviewing the merchant’s page and confirming the order at that moment. Autonomous transactions may have no such contemporaneous click.
As an Amazon Associate I earn from qualifying purchases.
The architecture must preserve a verifiable chain from delegated intent to the payment and the thing purchased. That does not mean one protocol handles every step. Discovery, cart construction, authorization, payment processing, settlement, dispute handling and fulfillment may be handled by different systems. The AP2 announcement identifies user authorization and intent as central challenges; the protocol landscape addresses different parts of them.
What has to change beyond human checkout?
Make the agent and its principal identifiable
A merchant needs a way to distinguish a recognized agent from an arbitrary automated request, and—where appropriate—to associate that agent with a consumer or account. Visa’s Trusted Agent Protocol describes agent-specific cryptographic signatures and linked consumer and device identity. Its specifications also describe signed requests with fields such as the target authority and path, creation and expiry times, key identifier, algorithm, interaction tag and nonce. These controls help validate a request and detect manipulation or replay; they do not establish that the user’s original intent was captured correctly. Visa’s announcement and technical specifications describe Visa’s approach.
#1 Best Overall
Record what the user delegated
“Buy this item” is not the same authorization as “find a suitable replacement under $100 and order it if the delivery date is before Friday.” The authorization record should preserve the user’s goal and meaningful constraints, then let the merchant or payment system check whether the final transaction fits them. Constraints might include an amount ceiling, a merchant, a purpose, a time window or a transaction count, depending on what the protocol and implementation support.
Bind approval to the actual transaction
Broad permission should not silently become approval for a different cart. A robust design links the delegated constraints to a specific checkout and payment authorization, and uses protections such as signed messages, expiry and nonces to limit tampering and replay. The signature supports verification of the message and its key under the protocol’s assumptions; by itself, it cannot prove that an agent interpreted the user correctly or that a merchant delivered the purchase.
Protect credentials and personal data
Giving an agent a raw payment credential by default expands the damage a compromised or misbehaving agent could cause. AP2 describes a role-based design intended to protect sensitive payment and personal information. Visa’s specifications describe presenting signed payment information in a container suited to the merchant and payment flow. The implementation should make clear which party holds credentials and what information each actor receives. AP2 documentation and the Visa specifications describe those respective designs.
Connect payment to settlement and fulfillment
Authorization, settlement and service delivery are related but distinct events. A valid authorization record does not show that funds settled, that an order was accepted, or that a service or data product was delivered. A 2026 formal analysis of x402, MPP, ACP and AP2 focuses on keeping delegated authorization consistent with economic and service effects across actors, states and protocol stages. The analysis is an August 30, 2026 preprint, not proof that the industry has settled liability or dispute outcomes.
How the architecture fits together
A useful way to design or evaluate an agent-commerce system is to separate its responsibilities into layers. One product may combine several layers, but a protocol that covers one should not be mistaken for a complete commerce stack.
- Commerce: discovery, catalog access, cart construction and checkout updates.
- Delegated authorization: a record of who granted authority, what the agent may do and what constraints apply.
- Identity and trust: mechanisms for counterparties to recognize an agent, associate it with a principal and verify signed messages.
- Payment: the payment credential or instrument, authorization decision and protections for sensitive information.
- Settlement and service: records of whether funds settled and whether the purchased item, data or service was provided or accepted.
AP2 v0.2 is explicit about this boundary: it operates as a security feature within a commerce protocol, is designed to work with UCP, and leaves catalog, checkout-update and role-communication API details outside its scope. Its documentation describes verifiable digital credentials and a cryptographic audit trail, but those features do not replace the surrounding commerce and payment systems. Read the AP2 v0.2 specification.
Which protocols address which parts?
These efforts are not interchangeable products in a single category. The table distinguishes their described role and scope; announcements and specifications should be read as claims about the named system, not evidence of universal merchant acceptance or broad deployment.
| Approach | What it addresses | Scope and qualification |
|---|---|---|
| AP2 | Delegated intent and checkout authorization using open and closed mandates, verifiable credentials and an audit trail. | AP2 v0.2 describes a security feature within a commerce protocol, designed to work with UCP; catalog and checkout-update APIs are outside its stated scope. Documentation · v0.2 specification |
| Visa Trusted Agent Protocol | Agent recognition, signed request integrity, consumer recognition and optional payment information. | Visa says the initial specifications apply to its network in this phase and calls for ecosystem-wide work; this is not universal merchant acceptance. Announcement · Specifications |
| x402 and MPP | Machine-native payment approaches for API or service transactions; Visa also describes extending MPP to card payments with a card specification and SDK. | Visa reports on these approaches and their activity; the figures it publishes for x402 are not a measure of agent commerce as a whole. Visa research summary · MPP card announcement |
| Mastercard Agent Pay for Machines (AP4M) | Permissioning, orchestration and settlement for continuous, machine-driven payments, with announced controls across card and stablecoin payment types. | Mastercard’s June 10, 2026 announcement describes the service and more than 30 initial participants and supporters; it does not establish that each participant has launched a generally available product. Announcement |
For AP2, an open checkout mandate captures a user’s goals and constraints before a cart is finalized; a closed mandate captures authorization for a specific checkout. In the autonomous flow described by AP2, the user approves constraints, then the agent assembles the specific checkout and payment mandate. Treat these as AP2 v0.2 design details, not a settled industry-wide standard. AP2 v0.2 specification.
Visa’s 2026 account reports roughly $15.0 million in adjusted x402 volume across 109.6 million transactions since x402’s May 2025 launch. The page does not give a precise measurement cutoff for those figures in the cited account, so they should be treated as Visa-attributed reported activity, not real-time totals or independently audited industry-wide usage. Visa’s account says x402 was incubated by Coinbase and Cloudflare and is stewarded by the Linux Foundation; it describes MPP as built by Stripe and Tempo with Visa contributions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should a team choose a payment architecture?
Start with the transaction and the trust boundary, not a search for one protocol that supposedly solves agent commerce. Compare candidate designs against the specific responsibilities they cover.
- Delegation: Does a person approve each checkout, or approve a constraint set that permits later autonomous action?
- Identity: How does a merchant verify an agent, and how is it linked to the person or account represented?
- Authorization scope: Can permission be limited by amount, merchant, item, purpose, time or number of transactions? What should happen when a request falls outside those boundaries?
- Credential and data handling: Which party holds payment credentials, and what user or payment data is exposed to the agent, merchant and other services?
- Transaction economics: Is this a normal merchant checkout or a very small, frequent API or machine-service payment where fixed fees could outweigh the transaction?
- Settlement and reversibility: Which rail settles the transaction, when can the service be granted, and what happens if settlement fails or a payment is disputed?
- Accountability: Can the system connect authorization to what was paid for and whether it was delivered or accepted?
- Interoperability: Is the proposed protocol an identity layer, authorization mechanism, checkout interface, payment rail or orchestration service—and what must another system provide?
Payment-rail fit depends on context. Visa’s 2026 account suggests cards for proxy or larger purchases in current merchant networks and stablecoins for machine-native micropayments; it also notes that some tasks may combine both. Visa reports x402’s average payment was a fraction of a cent and says a fixed card fee would cost more than such a payment. That is Visa’s characterization of the transactions it analyzed, not a universal benchmark or rule for every merchant. Mastercard’s AP4M announcement describes support across card and stablecoin payment types, another example of an architecture that may span rails. Visa’s account · Mastercard’s announcement.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhat an authorization record cannot guarantee
Cryptographic verification helps establish that a message was signed by a particular key and has not been altered in ways the protocol detects. It does not alone prove that the key holder is trustworthy, that the user’s goals were encoded faithfully, that the agent made a sensible choice, or that the merchant fulfilled the order. Those questions require controls outside message signing, including sound agent behavior, payment risk decisions, operational records, fulfillment evidence and dispute processes.
Likewise, an authorization protocol does not by itself define liability or guarantee that different merchants and payment networks will accept the same credentials. Visa describes its Trusted Agent Protocol’s initial scope as its network in this phase, while AP2 v0.2 explicitly leaves important commerce APIs to other systems. Published activity figures are also attributed to their publishers and may not be directly comparable across protocols. A production design needs to assign these responsibilities explicitly rather than treating a signed mandate as proof that every later stage succeeded.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
