Each protocol from this seat
Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.
Builds the agent, writes its registration file and registers it in the Identity Registry. Source [1, 2, 3, 4]
Goals
- Make the agent discoverable by other agents and explorers
- Advertise MCP, A2A and web endpoints in one place
- Keep the payee address correct after key changes
Pains
- No JSON Schema for the registration file, so required fields are a reading of an example
- Tutorials written before 2026-01-25 still use endpoints and score
- The agentId is known only after minting, so the file must be published twice
Implements
- A registration file with type, services, x402Support, active, registrations and supportedTrust
- register and setAgentURI calls, or an SDK such as agent0-sdk
- The /.well-known/agent-registration.json domain proof
Must trust
- The file host to serve the file (or IPFS content addressing)
- The registry owner not to upgrade the contracts against them
- Explorers to read the file the same way they do
Questions they ask
- Which fields do explorers actually require?
- Should the file be on IPFS or in a data URI?
- How do I keep agentWallet set after a transfer?
First three steps
- Read the Identity Registry section of the Draft text
- Register a test agent on Ethereum Sepolia or Base Sepolia
- Check how 8004scan renders the file
Metrics they care about
- Whether the agent shows as reachable in explorers
- Feedback count from trusted clients
- Time to rebind the wallet after a change
A day in the life. Ana ships a weather agent with an MCP server. She writes a registration file, pins it to IPFS and calls register on Base Sepolia. The Registered event gives her agent id 812, so she adds it to the registrations list, pins the new file and calls setAgentURI. Her MCP server lives on another domain, so she serves the well-known file there too. An old tutorial told her to add an agentWallet endpoint; she deletes it and asks her payment wallet to sign the AgentWalletSet message instead, within the five-minute window. Before mainnet she checks that explorers show her services and the x402Support flag.
Steps in the responsibility table
- OwnsWrite and host the registration file
- OwnsRegister the agent (register)
- ImplementsBind the payment wallet (setAgentWallet)
- ImplementsProve domain control (/.well-known)
- ImplementsAppend responses to feedback
- Relies onAnswer validation requests (specified only)
Builds the client side: an agent or app that meets 402 responses, chooses an option, signs and retries. Source [5, 6, 7, 8, 9]
Goals
- Let an agent pay for data and tools without a sign-up per vendor
- Keep the agent inside a budget
- Keep receipts for every payment
Pains
- Two wire formats (V1 and V2) in the wild
- Deciding which accepts entry to pick across networks and assets
- Spending limits that exist only in the SDK, not in the protocol
Implements
- wrapFetchWithPaymentFromConfig from @x402/fetch with a registered scheme
- spendControls and payment policies
- Storage of PAYMENT-RESPONSE transaction hashes
Must trust
- The server's PAYMENT-REQUIRED header, especially payTo
- The wallet key store
- The server to deliver after a settle
Questions they ask
- Is this server on V1 or V2?
- What cap should my agent have per payment and per day?
- Can I get a refund if the response is useless?
First three steps
- Wrap fetch with @x402/fetch and call a testnet endpoint
- Set spendControls to a cap below $1 and test a refusal
- Log every PAYMENT-RESPONSE hash with the request it paid for
Metrics they care about
- Spend per task
- Payments refused by policy
- Failed or unpaid deliveries
- Latency added by the 402 round trip
A day in the life. Dev builds a research agent that buys market data from five APIs. He wraps fetch with the x402 client and registers the exact EVM scheme for Base. The SDK already refuses unknown assets and anything above $1, so he lowers the cap to ten cents and adds a policy that skips Solana entries for now. One API still speaks V1 and answers with a JSON body; he registers the V1 client for that host. Every PAYMENT-RESPONSE hash goes into the task log next to the URL. When one provider returns empty data after payment, he finds there is no refund path under exact and moves that provider to a manual allowlist.
Steps in the responsibility table
- Relies onPublish payment requirements (402 with PAYMENT-REQUIRED)
- ImplementsChoose an accepts entry
- ImplementsEnforce spend caps and payTo allowlists
- ImplementsSign the authorization (EIP-712)
- ImplementsReturn and store the PAYMENT-RESPONSE receipt
- ObservesMonitor spend and anomalies
Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.
Builds an agent or app that calls ACP merchants over REST or MCP, or a ChatGPT app with the payment sheet. Source [10, 11, 12]
Goals
- Use one client for many merchants
- Choose between REST and MCP transports
- Handle every message and status
Pains
- MCP binding and REST differ on idempotency
- The Apps SDK complete_checkout tool is not the ACP tool
- No official SDK
Implements
- REST or MCP client for the five checkout operations
- Message handling by resolution
- Retry logic with the same Idempotency-Key
Must trust
- Merchants to follow the version they advertise in acp.json
Questions they ask
- Is complete_checkout the same as complete_checkout_session?
- Which statuses are terminal?
- Can I use an unofficial SDK?
First three steps
- Read docs/mcp-binding.md and the OpenRPC file
- Generate types from the 2026-04-17 JSON Schema
- Write tests for 400, 409 and 422 idempotency answers
Metrics they care about
- Successful completions per merchant
- Retries and replays
- Unknown status values seen
A day in the life. Ana writes an agent that shops across merchants and prefers MCP. She maps the five ACP tools, passes api_version and an idempotency key in meta, and treats JSON-RPC error -32000 as an ACP error object. Her first bug comes from the ChatGPT payment sheet docs: their complete_checkout tool is an Apps SDK tool, not the ACP binding's complete_checkout_session, so her merchant mock never answered. She also finds that the binding still lets the idempotency key be optional, while REST requires it, so she always sends one. Unknown statuses such as pending_approval go to a holding screen.
Steps in the responsibility table
- Relies onPublish /.well-known/acp.json
- ImplementsCreate and update the checkout session
- Relies onReturn authoritative totals and messages
- ImplementsConfirm the purchase
- ImplementsSet the allowance (max_amount, merchant, session, expiry)
- ImplementsSign and verify order webhooks
The developer who builds a platform or business integration with the SDKs, samples and conformance tests. Source [13, 14, 15, 16, 17]
Goals
- Get a working checkout against the samples in a day
- Validate payloads against the release schemas
- Pass the conformance suite
Pains
- main is a draft and differs from the latest release
- The conformance README still targets 2026-04-08
- Examples spell some names differently from the schemas
Implements
- @ucp-js/sdk or ucp-sdk models pinned to schema 2026-08-25
- RFC 9421 signing with an ES256 key
- Idempotency and lost-response handling
Must trust
- The SDK version table
- The schemas at the release tag
- The sample server's behavior
Questions they ask
- Which SDK version matches the release we target?
- Do I sign requests or use OAuth?
- How do I test escalation and 3DS paths?
First three steps
- Install @ucp-js/sdk 0.5.x or ucp-sdk 0.5.x
- Run the Python sample server and the happy path client
- Validate a checkout response with the SDK schema
Metrics they care about
- Conformance tests passed
- Schema validation errors
- Time to first completed checkout
A day in the life. Lee is building a UCP integration for a mid-size retailer. He installs ucp-sdk 0.5.0 because its table says it matches schema 2026-08-25, starts the sample server and runs the happy path client, which signs every request with a throwaway ES256 key. Everything works until he reads the spec on main and finds draft capabilities that are not in any release. He pins his schema URLs to the tag. The conformance suite's example config still says 2026-04-08, so he edits it and records the difference in his notes. By Friday his server returns valid checkouts and passes the idempotency tests.
Steps in the responsibility table
- ImplementsPublish /.well-known/ucp with keys
- ImplementsAdvertise UCP-Agent and verify the platform profile
- ImplementsCompute the capability intersection
- ImplementsFill the checkout (full-replacement updates)
- ImplementsSign the checkout and verify the AP2 mandate
- ImplementsSend signed order webhooks
Builds the client or agent that receives challenges, decides whether to pay and produces credentials. Source [18, 19, 20]
Goals
- Pay any MPP server on the first request
- Keep keys and limits out of the model's reach
- Support both MPP and x402 without two code paths
Pains
- Bearer credentials that anyone can spend if they leak
- Channels that never expire unless the client closes them
- Method support that differs by SDK
Implements
- mppx client wrapping fetch, with Accept-Payment preferences
- Checks on amount, recipient, currency and expires before signing
- Session bookkeeping: open, voucher, close, forced-close fallback
Must trust
- The server to deliver after payment
- The rail to cap loss (deposit, SPT limits)
- Its own policy hook to reject bad challenges
Questions they ask
- How much can this agent lose in the worst case?
- Which channels are still open and how do I close them?
- What happens if the server never answers my close?
First three steps
- Run the mppx client quick start against the mpp.dev paid ping on testnet
- Add a policy extension that rejects unknown recipients
- List and close retained sessions with the mppx CLI
Metrics they care about
- Spend per task
- Open channel count and locked deposit
- Rejected challenges by reason
A day in the life. Marco ships a research agent that buys search results and model tokens. He wires mppx into fetch and adds a policy hook that refuses any challenge whose recipient is not on an allowlist or whose amount exceeds two cents. For a model provider the agent opens a Tempo session with a five dollar deposit, so the worst case is five dollars. At the end of each task his code sends a close; a nightly job lists retained channels and force-closes any the server ignored, waiting the full grace period. He never logs credentials, because whoever copies one can spend it.
Steps in the responsibility table
- Relies onIssue the bound challenge (402 with WWW-Authenticate: Payment)
- ImplementsState preferences with Accept-Payment
- ImplementsCheck amount, recipient, currency and expires
- ImplementsEnforce budgets and allowlists
- ImplementsPay through the method (sign, mint SPT, get card token)
- ImplementsReturn and store the Payment-Receipt
- ImplementsClose or force-close session channels
Shopping Agent developer: builds Mandate Content, gets it signed, presents mandates, and handles receipts and fallbacks. Source [21, 22, 23, 24]
Goals
- Complete purchases without asking the user each time
- Pass every verifier on the first try
- Keep the LLM away from keys
Pains
- Selecting the right open mandate is left to the agent
- Overlapping presentations are forbidden until a rejection arrives
- The SDK is not on PyPI
Implements
- Mandate Content assembly
- Key-binding JWTs signed with the key in cnf
- Selective disclosure choices
- Receipt storage and scope reduction
Must trust
- The Trusted Surface to sign what it showed
- Its own deterministic signer to stay out of the model's reach
- Verifiers to return signed receipts
Questions they ask
- Which disclosures does this verifier need?
- How do I reduce an open mandate after success?
- What do I do on unresolved_constraint?
First three steps
- Clone the AP2 repository and run the human-not-present Python sample
- Read the SDK README for MandateClient create, present and verify
- Put signing behind a deterministic service with no LLM access
Metrics they care about
- Purchases completed without fallback
- Error receipts by code
- Average disclosures per presentation
A day in the life. Aiko builds a grocery agent. Her signer is a small service the model cannot call directly: the model proposes a basket, deterministic code checks it against the open mandates and only then signs a closed mandate with the key in cnf. Today a store returned unresolved_constraint because a substitute brand was not in acceptable_items. Her code stored the error receipt, asked the user's phone for approval of the exact basket, and finished. She is also adding scope reduction: after each success the agent records the open, closed and receipt tuple, so the weekly budget is never presented twice.
Steps in the responsibility table
- Relies onApprove Mandate Content on the Trusted Surface
- Relies onSign the checkout (checkout_jwt)
- OwnsSign closed mandates in human-not-present mode
- Relies onVerify the Payment Mandate and issue a token
- Relies onVerify the Checkout Mandate and constraints
- ImplementsTrack budget and recurrence state
- Relies onReturn signed receipts
- OwnsStore the open, closed and receipt tuple
Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.