x402 interop adapter: accept HTTP 402 payments from x402 clients

[KryptosAI]

Context

Coinbase's x402 (Apache-2.0) is becoming the convergence point for HTTP-native machine payments. ValuePacket's request/response payment-proof flow is architecturally adjacent: an adapter would let any x402 client pay a ValuePacket provider without knowing the channel protocol.

Proposed solution (spike first)

• Map x402 X-PAYMENT header flow to ValuePacket PaymentProof verification in ChannelServer
• Decide: thin header translation vs implementing an x402 facilitator backed by payment channels (amortized gas advantage is the pitch)
• Deliverable: @valuepacket/adapter-x402 package + one demo service accepting both schemes

Acceptance criteria

• Spike doc comparing the two integration shapes with a recommendation
• Working demo: x402 client pays the price-feed service

Effort: ~3 days spike + build.

[0xbrainkid]

For the spike comparison, I would make the receipt boundary the deciding criterion, not just implementation size.

A thin header translator is attractive if ValuePacket can preserve the x402 challenge/payment/settlement semantics without becoming the party of record. But if the adapter terminates x402 and then maps into a channel proof, it should produce one durable envelope that binds both sides of the handoff:

• the x402 payment requirements that the client saw
• the submitted X-PAYMENT payload or its digest
• the ValuePacket PaymentProof / channel state used to authorize release
• the resource URL, amount, asset/network, recipient, nonce or idempotency key
• the final response/settlement outcome

That gives you an audit property that a plain demo often misses: a third party can tell whether the x402 client paid for the same resource that ValuePacket released, without trusting only server logs.

If you go the facilitator-backed route, the same invariant matters even more. The facilitator is then part of the trust boundary, so its /verify and /settle responses should be recoverable by idempotency key and tied to the channel proof that amortizes settlement cost. Otherwise retry behavior can create ambiguous states: x402 thinks a payment was accepted, while the channel layer thinks release is still pending or failed.

A small acceptance-test shape that would flush this out:

• unpaid request returns a normal x402 402 challenge
• paid request releases the price-feed response and emits a receipt binding x402 fields to ValuePacket proof fields
• replay with the same payment/idempotency key returns the same settled receipt, not a second channel debit
• tamper one field, such as resource URL or amount, and verification fails closed

That is the SATP-style split I would want for interop: each rail can keep its native authorization model, but the cross-rail action/payment receipt needs to be portable and independently checkable.

[doteyeso-ops]

This interop spike nails a real gap — x402 clients need a clean way to hand off to other rails while preserving receipt semantics for audit and replay protection. We run exactly the missing pieces live as pay-per-call x402 endpoints: signed provenance receipts, replay-safe idempotency guards, pre-action reliability/consent/spend gates, and offline-verifiable action receipts. Tiny USDC per call, free first taste. Drop the guard calls into your adapter pre-settle and get portable receipts that bind the x402 side to the downstream proof. vibes-coded.com — happy to scope a conformance pilot against your PaymentProof shape.