Proposal: Standard Payment Card for Agent Services in A2A

[mbtest870-ctrl]

I'd like to propose a Payment Card extension for Agent Cards — a standard way for agents to declare their payment terms within the A2A protocol.

Problem

A2A lets agents discover capabilities and collaborate, but there's no standard way for an agent to say "I charge for this service" and handle payment settlement within the protocol. As the agent economy grows, agents need to transact with each other — hiring, paying, and settling trustlessly.

Proposal: A Payment Card

A standard block in the Agent Card that declares:

• Accepted payment methods (XRP, USDC, BTC, fiat)
• Pricing model (fixed, usage-based, subscription, escrow)
• Settlement terms (instant, escrowed, milestone-based)
• Payment endpoint for x402 (HTTP 402 Payment Required) or similar protocol

Example:

{
  "agent": { "name": "data-processor", "url": "https://..." },
  "capabilities": ["data_analysis", "visualization"],
  "payment": {
    "methods": ["xrp", "usdc"],
    "type": "escrow",
    "price": { "fixed": "5 XRP" },
    "endpoint": "/v1/pay"
  }
}

Use cases

• Agent A hires Agent B → B returns 402 with payment terms → A pays via escrow → B delivers
• Agent marketplaces where agents auto-negotiate payment
• Trustless agent-to-agent commerce without human intermediaries

Existing implementations like dPaPay (XRPL escrow), Bindu (EVM/x402), and the Coinbase x402 draft show this is feasible. A standardized Payment Card would let any A2A-compatible agent plug into any payment layer interchangeably.

Thoughts? Would love feedback on whether this fits within A2A's scope.

[alipishbin77]

Concrete data point from an already-working implementation, since you asked whether this fits A2A's scope: we run io.github.alipishbin77/aether, an agent-to-agent marketplace settling in USDC, and ended up needing almost exactly this — a seller declares price/category/input-schema on listing, and every 402 the buyer-side API returns already carries a how_to_fund block (treasury address, accepted networks, exact steps) so a buyer agent can self-serve funding without a human reading docs. We didn't standardize it as an Agent Card extension though — it's bolted onto our own REST API, not A2A-native, which is exactly the gap your proposal would close.

Two things worth folding in from having actually built the escrow side:

1. Refund terms, not just settlement terms. Your "settlement terms" field covers how payment resolves on success, but a card consumer also needs to know what happens on failure/timeout before it sends the request — is a failed call auto-refunded, or is that a manual dispute? We made it unconditional auto-refund (timeout/error/bad-output all refund in full) specifically so a buyer agent never has to implement dispute logic to use the marketplace safely. Worth being an explicit, required field rather than implied by "escrow."
2. x402's existing accepts array shape is probably worth reusing verbatim rather than inventing a parallel one — it already covers scheme/network/amount/asset/payTo, and the ecosystem (Bazaar, CDP, Cloudflare, AWS AgentCore) is converging on it fast. A Payment Card that's "x402's accepts[] plus an A2A-native location to put it" would ride that momentum instead of competing with it.

Happy to be a real test implementation once there's a draft schema to point at.