I work on zFinia (https://zfinia.com). This is a narrow interoperability offer, not a listing/endorsement request and not a request for IntentKit to manufacture a purchase.
I checked the current IntentKit x402 path before opening this: x402_pay accepts an arbitrary absolute URL, POST + dict-as-JSON body, a caller-set max_value, and an idempotency key; X402HttpxCompatClient parses v2 PAYMENT-REQUIRED, registers the exact EVM client, emits the payment-signature transport, and rebuilds the retry with the original request.content. That makes it a particularly clean match for a real external JSON-body seller rather than a GET-only demo.
If an independent Base-mainnet regression fixture is useful, this existing deterministic route is live:
POST https://api.zfinia.com/x402/v1/accessibility-contrast-calculator- x402 v2
exact, Base eip155:8453, canonical Base USDC
- amount
1000 atomic ($0.001)
- body:
{"foreground":"#000000","background":"#ffffff","large_text":false}
- unpaid POST returns HTTP 402 with
PAYMENT-REQUIRED
- after an independently funded successful payment/retry, JSON includes
contrast_ratio: 21
- catalog: https://api.zfinia.com/.well-known/x402.json
For x402_pay, the useful check is specifically: preview/limit → v2 challenge parse → exact EVM signature → same JSON body on the one paid retry → settlement response, while keeping max_value=1000 (or another caller-approved cap).
zFinia's MCP endpoint is challenge-handoff only; it does not sign or pay, so the HTTP POST above is the relevant fixture for IntentKit's buyer path.
If your own test hosts already cover this exact Base-v2 POST shape, no action is needed. If this fixture exposes a concrete seller/client incompatibility, I can make the smallest zFinia-side schema/interop correction where that is the correct side to change. Please do not self-fund or reimburse a zFinia test on our behalf.
I work on zFinia (https://zfinia.com). This is a narrow interoperability offer, not a listing/endorsement request and not a request for IntentKit to manufacture a purchase.
I checked the current IntentKit x402 path before opening this:
x402_payaccepts an arbitrary absolute URL, POST + dict-as-JSON body, a caller-setmax_value, and an idempotency key;X402HttpxCompatClientparses v2PAYMENT-REQUIRED, registers the exact EVM client, emits the payment-signature transport, and rebuilds the retry with the originalrequest.content. That makes it a particularly clean match for a real external JSON-body seller rather than a GET-only demo.If an independent Base-mainnet regression fixture is useful, this existing deterministic route is live:
POST https://api.zfinia.com/x402/v1/accessibility-contrast-calculatorexact, Baseeip155:8453, canonical Base USDC1000atomic ($0.001){"foreground":"#000000","background":"#ffffff","large_text":false}PAYMENT-REQUIREDcontrast_ratio: 21For
x402_pay, the useful check is specifically: preview/limit → v2 challenge parse → exact EVM signature → same JSON body on the one paid retry → settlement response, while keepingmax_value=1000(or another caller-approved cap).zFinia's MCP endpoint is challenge-handoff only; it does not sign or pay, so the HTTP POST above is the relevant fixture for IntentKit's buyer path.
If your own test hosts already cover this exact Base-v2 POST shape, no action is needed. If this fixture exposes a concrete seller/client incompatibility, I can make the smallest zFinia-side schema/interop correction where that is the correct side to change. Please do not self-fund or reimburse a zFinia test on our behalf.