Potential x402 header mismatch in agentic seller 402 response

[chenshj73]

Hi, I noticed a possible x402 transport mismatch in the agentic seller Lambda.

In agentic/lambda/seller.js, the /generate_image middleware checks for PAYMENT-SIGNATURE first, with X-PAYMENT as a legacy fallback:

sample-agentic-serverless-payments/agentic/lambda/seller.js

Lines 184 to 185 in f067a6c

	// Check for PAYMENT-SIGNATURE header (x402 v2 standard) or X-PAYMENT (legacy)
	const paymentHeader = c.req.header('PAYMENT-SIGNATURE') || c.req.header('X-PAYMENT');

When no payment header is present, it builds a response with x402Version: 1 and returns it as a JSON 402 body:

sample-agentic-serverless-payments/agentic/lambda/seller.js

Lines 206 to 213 in f067a6c

	const x402Response = {
	x402Version: 1,
	accepts: [paymentRequirements],
	error: 'Payment required'
	};
	console.log('=== 402 RESPONSE ===');
	console.log(JSON.stringify(x402Response, null, 2));
	return c.json(x402Response, 402);

However, unlike the serverless seller implementation, this response does not set a PAYMENT-REQUIRED response header:

sample-agentic-serverless-payments/serverless/lambda/seller/seller.js

Lines 296 to 298 in f067a6c

	// x402 spec: PAYMENT-REQUIRED header with Base64-encoded requirements
	c.header('PAYMENT-REQUIRED', Buffer.from(JSON.stringify(paymentRequirements)).toString('base64'));
	return c.json(paymentRequirements, 402);

This seems potentially inconsistent with the rest of the agentic flow and docs, which describe the x402 client receiving the 402, signing, and retrying with PAYMENT-SIGNATURE:

sample-agentic-serverless-payments/README.md

Lines 76 to 82 in f067a6c

	7. **Initial x402 Request:** The agent calls `generate_image` again. The tool finds `auth:true` and creates an x402 HTTP client that signs with the CDP AgentKit wallet through CDP APIs (no private key export). The client sends a POST request to Amazon API Gateway without an `PAYMENT-SIGNATURE` header.
	8. **402 Payment Required:** AWS Lambda receives the request and returns `HTTP 402` with payment requirements. The response includes the USDC amount in wei, seller wallet address, USDC contract address, and `EIP-712` domain parameters (name: 'USDC', version: '2', chainId: 84532).
	9. **EIP-712 Signature Generation:** The x402 client receives the 402 response and constructs `EIP-712` typed data. It requests a signature from the CDP-managed wallet, base64-encodes the signature payload, and retries the POST request with the signature in the `PAYMENT-SIGNATURE` header.
	10. **Payment Verification:** Lambda extracts the payment payload from the `PAYMENT-SIGNATURE` header. Lambda sends the signature to the x402.org facilitator's `/verify` endpoint, which validates the `EIP-712` signature against the USDC contract domain on Base Sepolia.

If the x402 client expects payment requirements from the PAYMENT-REQUIRED response header, it may not be able to automatically handle the 402 response from the agentic endpoint.

Should the agentic /generate_image 402 response also set PAYMENT-REQUIRED, similar to the serverless implementation?

c.header('PAYMENT-REQUIRED', Buffer.from(JSON.stringify(paymentRequirements)).toString('base64'));
return c.json(paymentRequirements, 402);

Or is the agentic path intentionally pinned to a body-based x402 v1 client contract?

I have not tested this against a live deployment; this is based on the current main branch source.

[chopmob-cloud]

Real catch, and the answer is yes -- the agentic 402 should set PAYMENT-REQUIRED too. From running x402 in production: clients genuinely diverge on where they read payment requirements. Some parse accepts[] from the JSON body, others read it from a response header, so a body-only 402 silently breaks the header-reading clients -- exactly the inconsistency you spotted between the two sellers.

The robust shape is belt-and-suspenders: put the requirements in both places, the JSON body as the canonical payload and a base64 PAYMENT-REQUIRED header carrying the same {x402Version, accepts} object, byte-consistent so a client reading either path gets the same thing.

One more that bites browser and agent clients specifically and is easy to miss: if the client runs in a browser or any CORS context, setting the header is not enough -- you also need Access-Control-Expose-Headers: PAYMENT-REQUIRED, X-PAYMENT-REQUIRED, or the browser strips it and the client sees a 402 with no requirements even though you sent them.

If a live reference helps, AlgoVoi's x402 402 returns the payload in the body, in PAYMENT-REQUIRED + X-PAYMENT-REQUIRED headers, and CORS-exposes them:

curl -sD - https://agent-trust-bench.algovoi.co.uk/cheap -o /dev/null | grep -io '[a-z-]*payment-required'

(Separately, the request side is the next thing to pin: PAYMENT-SIGNATURE vs the legacy X-PAYMENT is its own source of drift, but that is the retry leg, not this issue.)

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/substrate-2

[chopmob-cloud]

Took a look at this against current main (71ed633). The inconsistency you spotted was real when filed, but the restructure since May appears to have resolved it, so this may be closeable as obsolete.

What changed:

1. The two divergent files are gone. agentic/lambda/seller.js and serverless/lambda/seller/seller.js no longer exist on main (both 404). Seller 402 emission is now delegated to the official x402 library: backend/lambdas/sellers/image-gen/index.js imports paymentMiddlewareFromHTTPServer from @x402/hono and returns mw(c, next) (its only hand-built responses are 400/503/502/500, never a hand-rolled 402), and backend/lambdas/sellers/storefront/x402.mjs runs the flow through @x402/core/server's processHTTPRequest. The hand-written path that omitted the header is no longer there, so both seller surfaces emit the same library-constructed response.

2. The buyer normalizes both wire forms. payment-agent/tools.py reads the payment-required header first and falls back to the JSON body (_parse_payment_required), and its marker path guarantees an x402Version "regardless of seller framing." So a seller emitting either form is handled.

On the underlying question you raised (body-based vs header, and whether the body approach was intentional): both are legitimate x402, just different protocol versions. Body-based (x402Version: 1 + accepts in the body) is x402 v1; the base64 PAYMENT-REQUIRED header with an empty body is v2. So the original mismatch was an internal-consistency issue between two implementations, not a protocol violation in either.

Net: with the sellers consolidated onto the shared library and the buyer accepting both forms, the interop risk here is addressed. Might be worth closing with a pointer to the consolidation and the format-agnostic parser for anyone who finds this later.

[chopmob-cloud]

Thanks for the careful cross-check — the asymmetry you flagged was real at the time.

For anyone landing here: this has since been refactored and the specific mismatch is gone. agentic/lambda/seller.js and serverless/lambda/seller/seller.js no longer exist; the seller-side x402 logic now lives in backend/lambdas/sellers/storefront/x402.mjs, which delegates the wire format to the official @x402/* packages, and the client is payment-agent/ on the official x402 Python SDK.

On current main both sides handle both protocol versions:

• Seller (x402.mjs): the library builds the 402 carrying accepts and the base64 PAYMENT-REQUIRED header, and reads inbound payment from payment-signature or x-payment.
• Client (payment-agent/tools.py): reads the payment-required header first, falls back to the body accepts (x402Version 1 vs 2), and submits payment in both X-PAYMENT and Payment-Signature.

So the case you raised (a 402 without PAYMENT-REQUIRED) no longer applies — the shared handler always emits both. Looks resolvable as fixed-by-refactor.