01
Three questions that share one word
Applies to marketplace onlyown storefronthybrid
The word authorization covers three different questions in discussions of agent purchasing, and the published documents address them separately.
The first is consent: whether a person asked for the purchase, and what object records that they did. The second is acceptance: whether a processor, a network, and a merchant will admit the resulting transaction. The third is loss: when a buyer states they never wanted the item, whose money is gone.
| Question | What a published document can establish | What it leaves to the parties involved |
|---|---|---|
| Consent | The structure, contents, and cryptographic integrity of the evidence | Whether the person understood what they were instructing |
| Acceptance | The mechanics of verification and the conditions under which a request is valid | Whether a given provider or network participates |
| Loss | Nothing stated in the current source set | Card network rules and any private agreement between the parties |
The third row reflects what the sources consulted for this lesson contain. It is a statement about the documents, not a claim that no arrangement exists anywhere between particular commercial parties.
02
What a mandate records
Applies to marketplace onlyown storefronthybrid
AP2 defines two mandate types, each of which exists in two states.5 A checkout mandate captures a purchase while it is still being worked out and then, in its second state, pins the exact transaction that was finalized. A payment mandate does the same for the payment side. The distinction the two states carry is between limits a person set in advance and a specific completed transaction.
Both are carried as verifiable digital credentials: signed, structured objects in which any later alteration is detectable. The specification defines separate flows for the case where a person is present at the moment of purchase and the case where they are not.5 Google’s guide to agent protocols describes the same model as typed evidence of user intent that travels alongside a transaction rather than being reconstructed afterward.1
| Mandate state | What it holds | When it is created |
|---|---|---|
| A checkout mandate in its open state | The bounds a person set while the purchase was still being assembled | Before the item and price are fixed |
| A checkout mandate in its finalized state | The single transaction that was actually agreed | At the point the purchase is settled on |
| A payment mandate in its open state | The payment terms available under the person’s instruction | Before the charge is made |
| A payment mandate in its finalized state | The one charge that was made | At capture |
One practical note about reading on this subject: the mandate names in wide circulation in secondary write-ups are not the names the current specification uses.5 Terminology in this area has been revised, so an article and the specification can describe the same mechanism under different words. Reading the specification directly and recording its version avoids the mismatch.
03
How a merchant verifies an incoming agent request
Applies to marketplace onlyown storefronthybrid
The Visa Trusted Agent Protocol describes what a merchant does when a request arrives claiming to come from an agent. The merchant validates an HTTP message signature under RFC 9421, carried in two fields on the request, and retrieves the public key needed to check it from a network-operated key directory using the identifier named in the signature.3 No prior key exchange between the merchant and the agent operator is required, which is what allows a merchant to verify a request from an agent it has never encountered before.
Two controls bound the verification. A signature is valid only inside an eight-minute window, and the merchant is required to retain nonces so that a previously seen signed request is not accepted a second time.3 The first limits how long a captured request remains usable; the second addresses replay of a request within that window.
Three signed objects travel in the message body: a statement about whether the shopper is known, the payment material, and a payment-required response. All three are signed with the same key and tied together by a shared nonce, so they are verified as one set rather than individually.3
What all of this establishes is that a request came from a particular piece of software and has not been altered. It is separate from the mandate, which is where a person’s instruction is recorded.
04
What the Trusted Agent Protocol states it does not cover
Applies to marketplace onlyown storefronthybrid
The specification is explicit about its own boundaries, which makes it unusually easy to describe accurately. It covers two merchant interactions: browsing, where availability and price are established, and processing a payment. It states that merchants are not obliged to use it. And it excludes two things by name — how an agent came to be approved in the first place, and any private agreement between a merchant and an agent operator.3
Those two exclusions sit on either side of the mechanism. Approval happens before a request is ever signed; a private commercial agreement governs terms the specification does not attempt to set. Both are named as out of scope in the document itself.
05
What kind of statement each current source is
Applies to marketplace onlyown storefronthybrid
The sources in this area fall into recognizable kinds, and identifying the kind is the fastest way to know what a given item establishes.
| Source | Kind of statement | What it establishes |
|---|---|---|
| The AP2 specification5 | Technical specification | The structure and states of the consent objects |
| The agent-protocol guide1 | Explanatory documentation | How the mandate model is intended to be read |
| The Trusted Agent Protocol3 | Technical specification with stated scope limits | The verification mechanics and what the document excludes |
| The Mastercard Agent Pay announcement2 | Program announcement with named initial collaborators | That a program was announced and who was named in it |
| The FIDO Alliance announcement4 | Announcement of standards work | That work on trusted agent interactions was announced |
| The x402 Foundation launch6 | Governance announcement | That a foundation launched under named governance with named founding contributors |
These kinds overlap rather than sorting each source into one box. A governance announcement is also an announcement; publishing a specification is both a technical document and an event with a date. What the classification does is name what a source supports on its own: a program announcement records that a program was announced, and a specification records how a mechanism is defined. Neither establishes that a particular seller can use the thing described.
On the last row specifically: the operational launch of the x402 Foundation under Linux Foundation governance, with named founding contributors, is documented.6 That establishes governance and participation. It is separate from any statement about implementation.
06
Evidence at each step of a delegated purchase
Applies to marketplace onlyown storefronthybrid
Walking one order through the steps shows which artifact exists where, and which party holds it. The table below traces the Meridian camera from instruction to dispute.
| Step | Evidence described in the sources | Who holds it |
|---|---|---|
| A person instructs an agent to buy | A checkout mandate in its open state, recording the bounds set5 | The agent platform |
| The agent settles on this specific item and price | A checkout mandate in its finalized state5 | The agent platform |
| The request arrives at the merchant | A signature validated against a network key directory, inside an eight-minute window, with the nonce retained3 | The merchant |
| Payment material is presented | Three linked signed objects sharing one nonce3 | The merchant, at the moment of the request |
| The charge is made | A payment mandate in its finalized state5 | The agent platform and the payment provider |
| The buyer disputes the charge weeks later | Not addressed in the current sources | Not established |
The third column carries a pattern. The merchant directly holds the verification evidence from the request itself. The consent evidence — the part that records what a person actually asked for — sits with the agent platform. A seller retrieving it at dispute time would be requesting it from another party.
07
Loss allocation in the current sources
Applies to marketplace onlyown storefronthybrid
No document in the current source set states who bears the loss when a delegated charge is contested. The specifications describe consent objects and verification mechanics; the announcements describe programs, standards work, and governance. None of them allocate a disputed charge.
That is a description of what these sources contain. Card network rules and commercial agreements between the parties exist outside this set, and this lesson does not report on their contents. A seller who needs the answer for their own situation would put the question to their payment provider and to whichever agent platform is involved, and record the reply in writing.
Two questions are separated when asking. Whether a transaction is accepted at the time of purchase and how a dispute is resolved afterward are answered by different parties, and an answer to the first does not carry information about the second.
08
Recording the position for one order path
Applies to marketplace onlyown storefronthybrid
The record for this lesson names, for a single order path, what evidence exists, who holds it, and which questions have no answer yet. Unanswered rows stay in the table.
| Item to record | Entry for this path | Source of the entry |
|---|---|---|
| Which agent surfaces can currently reach this store | To be filled from the hosting platform’s written reply | The platform |
| Whether signature verification is performed and by whom | To be filled — the specification places it on the merchant side, which for a hosted store means the platform3 | The platform |
| Where the consent evidence is held | The agent platform, per the mandate model1 | The specification and guide |
| What the payment provider states about a contested delegated charge | To be filled from the provider’s written reply | The payment provider |
| Date each answer was received | Recorded per row | Your own record |
Rows left to be filled are the useful part of this table rather than a defect in it. They identify which supplier to ask and what specifically to ask them, and the date column makes it visible when an answer is old enough to need confirming again.
09
Where the record stands today
Applies to marketplace onlyown storefronthybrid
AP2 defines checkout and payment mandates, each existing in an open state that records the bounds a person set and a finalized state that pins one transaction, carried as signed credentials in which alteration is detectable, with separate flows for whether a person is present.5 The Trusted Agent Protocol describes signature validation under RFC 9421 against a network-operated key directory, an eight-minute validity window, merchant-side nonce retention, and three linked signed objects sharing one nonce; it covers browsing and payment processing, states that merchants are not obliged to use it, and excludes agent approval and private commercial agreements.3
Mastercard announced Agent Pay as a program with named initial collaborators.2 The FIDO Alliance announced standards work on trusted agent interactions.4 Each records that work was announced.
The sources do not state how loss is allocated on a contested delegated charge, and they do not document a specific small seller processing a delegated purchase end to end. Where a row in your own record has no entry, it reflects what the sources consulted contained on the date they were read.
10
Practice
Exercise
Build the record for one order path
- Write down which of the three questions — consent, acceptance, or loss — each thing you currently believe about agent payments actually answers.
- Ask your payment provider, in writing, what happens to a chargeback on a purchase placed by software on a buyer’s behalf, and record the reply with its date.
- Ask your hosting platform whether signature verification is performed for incoming agent requests and where the result is logged.
- Fill in the five-row record, leaving unanswered rows visibly unanswered and dated as of the day you asked.
Check yourself
A signature on an incoming request validates. What does that establish?
That the request came from the software identified by the key in the directory and has not been altered. It does not establish what a person instructed; that is recorded in the mandate, which is a separate object held by the agent platform.
Why do the two states of a mandate matter?
One records the bounds a person set while the purchase was still open, the other pins the single transaction that was finalized. Together they distinguish what was permitted from what was actually done.
What does the eight-minute window do?
It bounds how long a signature remains valid. Combined with the requirement that the merchant retain nonces, it limits reuse of a captured signed request.
What does the Trusted Agent Protocol state it does not cover?
How an agent came to be approved, and any private agreement between a merchant and an agent operator. It also states that merchants are not obliged to use it, and it covers two interactions: browsing and payment processing.
What do the current sources say about who absorbs a disputed delegated charge?
They do not address it. The specifications cover consent objects and verification mechanics; the announcements cover programs, standards work, and governance. The answer for a particular business would come from its payment provider and the agent platform involved.
Progress is saved in this browser only. No account, nothing sent anywhere.
11
Common questions
Is a signed agent request the same as proof the buyer consented?
No. The signature establishes the identity of the sending software and the integrity of the request. Consent is recorded separately in a mandate, which is held by the agent platform rather than by the merchant.
Do these specifications require a merchant to change payment providers?
Nothing in them states that. The Trusted Agent Protocol describes verification of an incoming request and states that merchants are not obliged to use it; how a charge is subsequently processed is a question for the existing provider.
Why do articles about AP2 use terms the specification does not?
The terminology has been revised, and secondary write-ups reflect the vocabulary in use when they were written. Reading the specification directly and noting its version resolves which terms currently apply.
Does the x402 Foundation launch mean this is in production?
The announcement documents an operational launch under named governance with named founding contributors. That establishes governance and participation; implementation in a given business is a separate question the announcement does not address.
What should a seller do about the unanswered loss question?
Put it to the payment provider and to any agent platform involved, in writing, and keep the reply with its date. The published specifications do not contain the answer, so the record of what those parties state is the only entry available.
12
Research and sources
Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.
Claim evidence
- Google’s AP2 guide describes mandates for purchase authorization and audit evidence.
- current external fact. Supported by Developer’s Guide to AI Agent Protocols: AP2 .
- Mastercard Agent Pay, Visa Trusted Agent Protocol, and FIDO’s agent-interaction work have different owners, publication states, and scopes; their names do not establish interoperability.
- current external fact. Supported by Mastercard unveils Agent Pay , Visa Trusted Agent Protocol merchant specifications , FIDO Alliance to develop standards for trusted AI agent interactions .
- AP2 defines a checkout mandate and a payment mandate, and each exists in two states: an open state recording the constraints a user set before anything was finalized, and a closed state authorizing one specific finalized transaction.
- technical requirement. Supported by Agent Payments Protocol specification and documentation .
- Mandates are carried as verifiable digital credentials, described as tamper-evident cryptographically signed objects, and the specification separates human-present flows from human-not-present ones.
- technical requirement. Supported by Agent Payments Protocol specification and documentation .
- The mandate names in wide circulation are not the names the current specification uses, so a summary of this protocol can be confidently wrong about its central vocabulary while remaining internally consistent.
- current external fact. Supported by Agent Payments Protocol specification and documentation , Developer’s Guide to AI Agent Protocols: AP2 .
- Visa’s Trusted Agent Protocol has a merchant validate HTTP message signatures under RFC 9421, carried in a signature input field and a signature field, with the verifying public key retrieved from a network-operated well-known key endpoint using the key identifier named in the request.
- technical requirement. Supported by Visa Trusted Agent Protocol merchant specifications .
- Validation requires the creation timestamp to sit in the past and the expiry in the future within an eight-minute window, and requires the merchant to track nonces so a captured request cannot be replayed.
- technical requirement. Supported by Visa Trusted Agent Protocol merchant specifications .
- Three objects travel in the message body — a consumer recognition object, a payment container, and a browsing acknowledgement used when a merchant answers with a payment-required response — all signed with the same key and tied together by a shared nonce.
- technical requirement. Supported by Visa Trusted Agent Protocol merchant specifications .
- The specification addresses only two merchant interactions, browsing for availability and pricing and processing a payment, states plainly that merchants are not required to use it, and does not cover agent onboarding beforehand or any bilateral agreement between a merchant and an agent operator.
- current external fact. Supported by Visa Trusted Agent Protocol merchant specifications .
- The x402 Foundation announced its operational launch under Linux Foundation governance; that announcement does not establish merchant adoption or production interoperability.
- current external fact. Supported by Operational launch of the x402 Foundation .
- Developer’s Guide to AI Agent Protocols: AP2 Google · Tier D · official technical guide · AP2 v0.1 described
Google’s description of AP2 mandates, authorization, and protocol boundaries. Limit: An official Google guide describes intended AP2 behavior; it is not independent evidence of adoption or transaction outcomes.
- Mastercard unveils Agent Pay Mastercard · Tier D · official announcement · announcement dated 2025-04-29
Mastercard’s stated Agent Pay program and initial collaborators. Limit: An issuer announcement establishes the program’s stated intent, not an open standard, general merchant availability, interoperability, or observed outcomes.
- Visa Trusted Agent Protocol merchant specifications Visa · Tier A · published merchant specification · live specification reviewed 2026-07-30
Recognition and signed-message model for approved agents interacting with merchants. Limit: The specification describes an optional mechanism and Visa implementation details; it does not prove merchant adoption or grant consumer authority.
- FIDO Alliance to develop standards for trusted AI agent interactions FIDO Alliance · Tier D · working-group announcement · announcement dated 2026-04-28
FIDO’s announced working-group scope and contributed agent-authorization material. Limit: Standards work in progress is not a completed FIDO standard, implementation certification, or proof of production interoperability.
- Agent Payments Protocol specification and documentation Google · Tier A · published specification under active revision · live documentation reviewed 2026-08-01
Mandate types and their states, the credential format carrying them, and the human-present and human-not-present transaction flows. Limit: The named mandate types have changed since the protocol was first announced, so secondary coverage of it is frequently out of date; the specification describes an authorization model and establishes nothing about processor acceptance, merchant adoption, or how a contested charge is allocated.
- Operational launch of the x402 Foundation Linux Foundation · Tier D · official launch announcement · announcement dated 2026-07-14
Linux Foundation governance and stated scope for the x402 Foundation. Limit: Establishes the foundation’s operational launch and stated governance scope, not merchant adoption, production interoperability, settlement finality, or liability allocation.