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.
Sells an API or agent service, registers it so buyers can find it, and receives payments at agentWallet. Source [1, 2, 3, 4]
Goals
- Be found by agent buyers
- Show a payment-backed track record
- Keep the payee address safe
Pains
- Competitors and spammers can rate it from fresh addresses
- Responses do not change a low score
- x402 payments look like ordinary transfers to indexers
Implements
- x402Support true and an agentWallet bound by signature
- appendResponse to answer complaints, for example with refund evidence
- revenues feedback through its facilitator, as best practices suggest
Must trust
- Readers to filter reviewers sensibly
- The facilitator that publishes revenues feedback
- The registry owner
Questions they ask
- How do I get feedback from real customers counted?
- What happens to my reputation if I sell the agent token?
- Is my wallet binding replayable?
First three steps
- Register the service with x402Support true
- Bind a dedicated payment wallet
- Ask paying clients to include proofOfPayment
Metrics they care about
- Feedback from paying clients
- Revenue tracked by revenues feedback
- Responses posted to complaints
A day in the life. Omar sells a pricing API to agents and already takes x402 payments. He registers it with x402Support true and binds a cold wallet as agentWallet. A week later a burst of zero scores arrives from addresses that never paid him. He cannot delete them, so he appends responses that link to his payment logs and asks his facilitator to publish revenues feedback, as the best-practices guide suggests. His larger buyers already pass a trusted reviewer list to getSummary, and the burst never shows up in their numbers.
Steps in the responsibility table
- ImplementsWrite and host the registration file
- ImplementsRegister the agent (register)
- OwnsBind the payment wallet (setAgentWallet)
- OwnsProve domain control (/.well-known)
- Relies onPay the agent (outside ERC-8004)
- Relies onWrite feedback with proofOfPayment
- OwnsAppend responses to feedback
Runs the resource server: prices routes, answers 402, and asks a facilitator to verify and settle. Source [4, 5, 6, 7, 8, 9]
Goals
- Charge per call without accounts or invoices
- Get paid in the same request that serves the data
- Keep chain work out of the API team's code
Pains
- Picking a facilitator for production because the x402.org default serves testnets only
- Handler work that is lost when a settle fails under the authorization flow
- Timeouts on /settle that leave the outcome unknown
Implements
- Payment middleware such as @x402/express with a route map of accepts entries
- An x402ResourceServer wired to an HTTPFacilitatorClient
- Reconciliation for settlement_pending results
Must trust
- The facilitator to verify honestly and broadcast promptly
- The asset contract to enforce the nonce and the window
- Its own route matching (past releases fixed encoded-path bypasses)
Questions they ask
- Which facilitator supports my network and scheme, and what does it charge?
- Do I need exact, upto or auth-capture for this endpoint?
- What happens to my handler output if the settle fails?
First three steps
- Run the @x402/express quick start against Base Sepolia with the x402.org facilitator
- Price one route at $0.01 and watch the PAYMENT-REQUIRED header
- Choose a production facilitator and compare its fees and networks
Metrics they care about
- Paid requests per day
- Verify and settle latency
- Settle failure and settlement_pending rate
- Revenue net of facilitator fees
A day in the life. Maya runs a weather API that used to sell monthly keys. She adds the Express middleware, prices the forecast route at one cent in USDC on Base, and points it at a facilitator. The first agent request gets a 402 with the price in a header; the retry carries a signature, the facilitator says it is valid, her handler runs, and the settle returns a transaction hash. On Friday a facilitator outage turns into a burst of 502 answers, and two settles time out. She checks both hashes on chain before retrying, finds one already confirmed, and writes a small reconciliation job so it never needs a person again.
Steps in the responsibility table
- OwnsPublish payment requirements (402 with PAYMENT-REQUIRED)
- Relies onVerify the payload (POST /verify)
- OwnsRun the handler
- Relies onScreen for sanctions (KYT, OFAC)
- Relies onSettle on chain and pay gas (POST /settle)
- OwnsReconcile settlement_pending
- 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.
Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.
Not one of the main personas on the UCP page. The responsibility table gives this persona no step.
Runs the resource server: prices routes, issues bound challenges, verifies credentials and returns receipts, usually through mppx middleware. Source [10, 11, 12, 13]
Goals
- Charge per call or per token without accounts or invoices
- Accept stablecoins and cards from the same 402 response
- Get paid before any side effect runs
Pains
- Managing the HMAC secret that every challenge id depends on
- Choosing between charge and a session for streaming endpoints
- Keeping up with SDK advisories (four mppx advisories in 2026)
Implements
- mppx server with one or more methods and a secretKey
- Cache-Control no-store on 402 and private on receipts
- Atomic consumption of challenge ids
Must trust
- The rail to settle what it confirms
- Its SDK version to enforce replay and close rules
- Discovery crawlers to list it accurately (advisory only)
Questions they ask
- Which methods do my buyers actually hold?
- Do I sponsor Tempo fees with feePayer or hostedFeePayer?
- How do I refund a stablecoin charge if delivery fails?
First three steps
- Run the mppx server quick start on the Moderato testnet
- Add a second method (stripe) to the same route and read both challenges
- Pin mppx to 0.8.2 or later and subscribe to the repository advisories
Metrics they care about
- Paid requests per route
- Share of 402s that convert to 200
- Fee payer spend per day
A day in the life. Priya sells a weather API by the call. Her route answers unpaid requests with a Tempo challenge and a Stripe challenge, both bound with the HMAC secret she rotated last week. Overnight an agent fleet pays 40,000 times at one cent each; the receipts carry transaction hashes she reconciles each morning. A partner wants to stream forecasts per minute, so she adds a session route and caps the suggested deposit. When an advisory about fee payer draining appears, she upgrades mppx, checks her fee wallet balance, and adds a daily ceiling. Her one open worry: refunds on stablecoin charges are her own policy.
Steps in the responsibility table
- OwnsIssue the bound challenge (402 with WWW-Authenticate: Payment)
- OwnsVerify binding, expiry and proof
- ImplementsSettle on the rail
- OwnsReturn and store the Payment-Receipt
- ImplementsClose or force-close session channels
- OwnsHandle disputes and refunds
Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.
Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.