fix(x402): pass V1 payment payloads through to CDP unchanged (payment_invalid on all real x402 payments)

[Deesmo]

The bug (live, revenue-critical)

Every real x402 payment against the live API fails with payment_invalid. A real $0.01 EIP-3009 payment was made today (2026-07-27 12:27Z) with a spec-compliant V1 client (@x402/core + @x402/evm) — CDP rejected verify with:

400 — 'paymentPayload' is invalid: must match one of [x402V2PaymentPayload, x402V1PaymentPayload].
x402V1PaymentPayload requires 'scheme'  (correlationId a21ba425dc9c5ed7-IAD)

Root cause: verifyPayment/settlePayment re-wrap the client's V1 payload into a v2 shape that drops the top-level scheme/network V1 requires, so CDP matches neither schema. All prior end-to-end testing exercised the API-key/credits path, never a settled x402 payment — this never had coverage.

The fix

Detect a V1 payload (x402Version===1 + scheme + payload) and forward it unchanged with x402Version: 1 and canonical V1 PaymentRequirements — the identical pass-through shape @x402/core's HTTPFacilitatorClient sends. Genuine v2/Solana payloads keep the existing wrap. No changes to the credits/API-key path (code only runs when a payment header is present).

Verification plan

After merge + deploy: re-run the same real $0.01 payment against generate-hash and confirm 200 + on-chain settlement tx (receipts will be posted). This also unblocks the Bazaar seeding run Brad funded today.

🤖 Generated with Claude Code

---

Note

High Risk
Touches revenue-critical payment verification and settlement against CDP; incorrect branching could still reject valid payments or regress v2/Solana flows.

Overview
Fixes live payment_invalid failures for real EIP-3009 / @x402/core clients paying against V1 402 responses.

verifyPayment and settlePayment no longer always re-wrap CDP-bound bodies as x402 v2. When the decoded header is a V1 payload (x402Version === 1, top-level scheme, and payload), the middleware forwards the client payload unchanged, sends x402Version: 1, and maps requirements through new toV1Requirements (spec-only fields, maxAmountRequired without duplicate amount). Genuine v2/Solana CDP paths keep the existing v2 wrap and accepted shape.

Logging now distinguishes evm-v1-passthrough vs evm-v2 for verify/settle.

^{Reviewed by Cursor Bugbot for commit 116cdfd. Configure here.}

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[Deesmo]

Council review round applied (Brad-ordered triple check, 2026-07-27):

• Docs verified: request shape re-checked against the official spec — coinbase/x402 specs/x402-specification-v1.md §7.1 (POST /verify; /settle same shape). The pass-through now emits exactly the spec's fields.
• 3-model adversarial review (GPT-5.6 Sol, Gemini 2.5 Pro, Grok 4.5): all three initially returned BLOCK with fixable findings; every blocking item is now in the diff:
  1. outputSchema + duplicate amount stripped from V1 requirements (strict-union 400 risk)
  2. x402Version numeric-coerced (string "1" clients)
  3. pass-through payload sanitized to {x402Version, scheme, network, payload} only — no client extensions reach CDP
  4. fail-closed on malformed V1 / scheme-network desync (no fall-through into the v2 wrap)
  5. Solana pinned to the v2 wrap; payloadFormat log matches real control flow
  6. 11 unit fixtures covering each finding, wired into npm test
• Post-merge verification: real $0.01 EIP-3009 payment against generate-hash on production; receipts (tx hash + Render log) will be posted here.