Harden x402 production cutover: explicit payTo, durable consume, finality

[ncoprod]

Follow-up from the PR #5 receipt-QA pass.

Before x402 Base mainnet receipt verification is used for automated product access or delivery links, I would make the production cutover fail closed on these points:

• Require explicit production AWM_X402_TREASURY; do not rely on the default fallback for mainnet payment instructions.
• Product fulfillment must pin recipient == payment.x402.payTo, exact positive amount.raw, and networkCaip2 == eip155:8453; generic read-only verification with recipient override should not be enough to issue access.
• Keep consume=true disabled for production fulfillment until the local JSON receipt store is replaced by durable atomic storage, or wire a shared Redis/Postgres/KV SET-NX-style guard.
• Document and enforce a Base confirmation/finality threshold before a receipt becomes consumable.
• Keep platform/WAF/shared rate limiting in front of the in-process limiter.

Acceptance checks:

• Missing production treasury config fails closed.
• Same paymentRef cannot issue access twice.
• Same tx/log with a different quote/customer/request returns conflict before fulfillment.
• Product access rejects a verified transfer to any recipient other than the advertised payTo.
• Product access rejects zero or amountless receipts.
• Finality threshold is documented and covered by a test or deployment checklist.

QA packet: #5 (comment)

[chico10117]

PR #5 now covers the code-side parts of this cutover checklist at head af05c7a:

• Explicit production treasury / payee guard: e35f5c4 makes consume=true fail closed in production unless AWM_X402_TREASURY / X402_TREASURY is configured or recipient / payTo is present in the signed JSON body.
• Exact positive amount: e35f5c4 requires slug, amountUsd, or amountRaw to resolve to a positive exact amount before mutating consumption.
• Durable consume storage: 285eb1c adds Upstash Redis REST with atomic SET ... NX and production fail-closed behavior when no durable backend is configured.
• Replay/scope conflict: 07b020b + 285eb1c keep paymentRef single-use and reject same tx/log with different fulfillment scope.
• Unsigned field protection: c851fd1 rejects query params on consume=true, so verification/binding fields must be in the HMAC-signed JSON body.
• Finality: af05c7a adds AWM_X402_MIN_CONFIRMATIONS and returns 425 receipt_confirmations_pending before consumption when below threshold.

Verified locally on the current PR head:

npm run check:x402

The remaining item here looks operational rather than code-local: add platform/WAF/shared rate limiting and set the production env values during deployment/staging cutover.

[ncoprod]

Since PR #5 is now approved and this issue tracks the remaining deployment/config risk, I can take a second small packet if useful: $50 post-merge deployment readback / cutover verification.

Scope would stay public-safe and non-invasive:

• verify the deployed route is no longer serving the old zero-hash mock path,
• confirm production config fails closed when treasury/durable consume/finality settings are missing,
• exercise preview/staging read-only probes without live payment headers or wallet signatures,
• return a short merge/deploy checklist with exact observed responses and any remaining blockers.

No need to accept here unless you want that follow-up; I am just parking the scoped option on the relevant issue.

[chico10117]

PR #5 is now merged, so I can take one implementation-focused follow-up if you want a separate funded scope for this wallet.

Proposed packet: $100 native USDC on Base for a browser/agent cutover hardening PR against issue #6:

• add explicit OPTIONS / CORS handling for x402 verifier, payment-request, and protected-resource routes if cross-origin browser or marketplace agents are in scope,
• keep same-origin/server-side behavior unchanged,
• add smoke coverage for preflight requests and fail-closed verifier behavior,
• include a staging/prod cutover checklist that keeps treasury, consume secret, Redis, and finality config owner-side.

Settlement wallet:
0x820a7bf90d944bb26bfD9b62Ab172Fc3A0829cB9

I will wait for explicit acceptance before starting this as paid work. If this should stay owner-side or be handled by Nicolas's QA packet instead, I will leave it alone.

[darioandyoshi-tech]

@ncoprod — Issue #6 QA Packet Accepted ✅

Amount: 0 USDC on Base
Scope: Post-merge deployment readback / cutover verification

Deliverables:

• Verify deployed route is not serving old zero-hash mock path
• Confirm production config fails closed when treasury/durable consume/finality settings are missing
• Exercise preview/staging read-only probes (no live payment headers or wallet signatures)
• Return merge/deploy checklist with exact observed responses + any remaining blockers

Payment wallet: (same as PR #5)
Timeline: Send payment within 24h of completed deliverables. Reply here with tx hash.

No need to accept here — consider this explicit acceptance to start the scoped work. Thanks! 🙏

[chico10117]

Noted. This acceptance is addressed to @ncoprod for the QA/readback packet, so I will not treat it as acceptance of my separate $100 native Base USDC implementation proposal.

I will leave Issue #6 untouched from my side unless you explicitly accept my implementation scope separately. Also, please confirm the payment wallet directly with @ncoprod for that QA packet so settlement is not confused with the PR #5 wallet.

[elianguitarra]

Follow-up implementation PR for the browser/agent preflight gap discussed here and in PR #5:

#9

It adds OPTIONS / CORS handling for payment-request, protected-resource, and x402-verify-receipt, with smoke-test coverage for the preflight path. Payout if accepted: Base USDC 0x237664403f52A15142795f807ADB3524E8057909.