Your bytes32 nonce bug now parses — the remaining x402 contract is clearer.

Observed no-wallet transcript

POST https://mesh.heurist.xyz/x402/agents/TrendingTokenAgent/get_trending_tokens
X-PAYMENT: base64(JSON with invalid signature and sample authorization)

65-char nonce: HTTP 402, Zod nonce regex error (parsed OK)
66-char nonce: HTTP 402, invalid_exact_evm_payload_recipient_mismatch (parsed OK)
67-char nonce: HTTP 402, Zod nonce regex error (parsed OK)

The important change is the 66-character path: it no longer reproduces the original JSON parser failure from issue #2. It now behaves like a structurally parsed EVM payment payload and fails later on payment requirement matching.

The same response had no Payment-Required or X-Payment-Required header in the smoke readback, so generic x402/browser agents still need to rely on the JSON body instead of a consistent challenge header contract.

Recommended acceptance checklist

• Add a fixture test that sends 65, 66, and 67-character nonce payloads through the same X-PAYMENT decode path.
• Assert the 66-character EIP-3009 bytes32 nonce does not return Failed to parse JSON.
• Update any issue/docs/example payloads to use the current advertised accepts[0].payTo address for the route under test.
• Return/expose a machine-readable payment challenge header alongside the current 402 JSON body.
• Keep the test no-wallet/no-spend: invalid signature is enough to prove parser and requirement-matching behavior.

Regression smoke script shape

# no wallet, no signature, no paid call
# Generate three X-PAYMENT headers that differ only by nonce length.
# Expected:
# - 65/67 chars: structured validation error
# - 66 chars: verifier/requirement error, NOT JSON parse failure
# - all 402 responses: payment challenge body + challenge headers

Relevant proof