exact: canonical scheme identifier (client sends the wrong one)
Compliant · GET /api/x402/client-scheme-mismatch · Schemes (exact / upto / batch)
A fully compliant exact endpoint. The scheme identifier in the payment payload MUST be the canonical "exact" — a client that instead sends a non-canonical name like "exact-evm" is rejected by the facilitator with invalid_exact_evm_scheme even though its signature recovers a valid payer.
Explanation
The endpoint is fully compliant: it advertises a canonical exact challenge and settles when paid correctly. The pitfall is entirely client-side. The `scheme` field inside the X-PAYMENT payload must be the canonical string "exact"; some client implementations serialize it as "exact-evm" (mixing the scheme name with the EVM namespace). When they do, the facilitator recovers a valid payer from the signature but rejects the payment with invalidReason "invalid_exact_evm_scheme", surfacing as a 402 with an isValid:false PAYMENT-RESPONSE. The server advertises v2/CAIP-2 requirements and needs no change — the client must emit the canonical scheme identifier.
What to watch
Pay with the canonical scheme "exact" and it settles. Send scheme:"exact-evm" and the facilitator returns 402 with PAYMENT-RESPONSE invalidReason "invalid_exact_evm_scheme" and the recovered payer — the fix is on the client.
Facilitator
Settled against the live Radius testnet facilitator (https://facilitator.testnet.radiustech.xyz). A valid payment runs a real /verify and /settle on-chain.
Metadata
- Status: Compliant
- Method: GET
- Price: 0.0001 (100 atomic)
- Responsible party: Client