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 and the skill manifest both source from one SDK constant; this page mirrors it.

​
What works

Legend: ✅ verified end-to-end · ⚠️ partial / specific workaround · ❌ doesn’t work today · n/a 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).
  • 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

Email support@agentscore.com with the client and the rails it supports. We run the smoke ourselves and add the entry once it passes. We don’t accept self-reported entries; the matrix only lists what we’ve directly run.