Skip to main content
If you’re an agent (or a human testing a payment flow) and you want to know which CLI to use to pay an AgentScore-built merchant, this is the canonical list. Every entry has been smoke-tested end-to-end against a @agent-score/commerce–powered merchant. When a new client is verified, it gets added; when a verified client breaks, the row gets a note. Merchants built on @agent-score/commerce emit an agent_instructions.compatible_clients field on every 402 response and the same per-rail matrix in their static /skill.md discovery manifest; agents can read it inline (or fetch the manifest upfront) without ever loading this page. The 402 body, the skill manifest, and this docs page all source from the same SDK constant, so they don’t drift.

​
What works

Legend: ✅ verified end-to-end · ⚠️ partial / specific workaround · ❌ doesn’t work today ·; not applicable to this rail. Tempo MPP
  • tempo request -X POST -H 'X-Operator-Token: opc_...' --json '{...}' <url>
  • agentscore-pay pay POST <url> --chain tempo -H 'X-Operator-Token: opc_...' -d '{...}'
x402 on Base
  • agentscore-pay pay POST <url> --chain base -H 'X-Operator-Token: opc_...' -d '{...}'
  • purl <url> -X POST -H 'X-Operator-Token: opc_...' -H 'Content-Type: application/json' -d '{...}' (no --network flag)
  • x402-proxy fetch -X POST -d '{...}' --evm-key <hex> --network base --protocol x402 <url>
Solana via MPP solana/charge
  • agentscore-pay pay POST <url> --chain solana -H 'X-Operator-Token: opc_...' -d '{...}'
Stripe Shared Payment Token (Link wallet)
  • link-cli mpp pay <url> --spend-request-id <spend_id> --method POST --data '{...}' --header 'X-Operator-Token: opc_...'

​
Why some clients don’t fully work

For the partial entries above, the failures come from client-side assumptions that don’t fit the protocol shape AgentScore-built merchants emit. We share the diagnostics in case other ecosystem players want to reproduce or fix them:
  • purl --network flag: purl’s negotiator compares the flag value (e.g. base) against the CAIP-2 string in the 402’s accepts[] (e.g. eip155:8453) without normalizing aliases. With no flag passed, purl’s filter short-circuits and it correctly picks the first compatible challenge. Workaround: omit the flag.
  • purl Tempo MPP: purl’s MPP parser raises Duplicate parameter: id on multi-Payment WWW-Authenticate headers (one MPP directive per rail, comma-separated, per RFC 7235). Three other independent clients parse the same header correctly.
  • awal: pre-discovers payment requirements via empty-body HEAD/GET/POST/PUT/DELETE/PATCH, then signs against whatever it finds. Variable-priced merchants need the actual request body to compute per-order pricing + per-order deposit addresses, so awal can’t discover anything to sign. Bazaar-registered fixed-price endpoints are awal’s working surface today.

​
Are funds at risk on a failed payment?

No. x402 facilitators (Coinbase’s, primarily) simulate transactions before broadcasting. A simulation failure doesn’t broadcast, doesn’t move USDC, doesn’t consume gas. A signed-but-not-broadcast tx becomes inert when the validBefore window (EVM EIP-3009) expires, typically within minutes. Buyers can switch to a different client and retry without losing anything.

​
How to add your client to this list

Open the AgentScore-Solana / x402 partnership channel and run a smoke. We’ll verify and add the entry. We don’t accept self-reported entries; the matrix only lists what we’ve directly run.

​
Last verified

Most recent full smoke matrix against a multi-rail /purchase (402): agentscore-pay × Base/Solana/Tempo ✅, tempo request × Tempo ✅, x402-proxy × Base/Tempo ✅, purl (no flag) × Base ✅, awal ❌, link-cli × Stripe ✅ (separate flow).