Register all single-shot EVM client schemes (exact, upto, auth-capture) in the scan wallet

[A1igator]

At x402r.org, we've been working on refundable payments for x402. This PR wires the scan wallet up to actually pay them — and, while we're here, every other single-shot EVM scheme the SDK supports.

What

Lets the scan wallet pay endpoints advertising any single-shot EVM scheme the SDK supports — exact, upto, and auth-capture (our escrow-backed / refundable payments) — instead of only exact.

Today both EVM payment sites register only the exact scheme, so the wallet can't match a non-exact entry in a 402's accepts:

• apps/scan/src/trpc/routers/user/server-wallet.ts — the custodial server wallet (sendUsdc)
• apps/scan/src/app/(app)/_hooks/x402/evm.ts — the browser wagmi wallet hook

Changes

• apps/scan/src/lib/x402/wrap-fetch.ts — new shared registerEvmSchemes(client, { signer }) that registers:

  • exact (existing registerExactEvmScheme)
  • upto (UptoEvmScheme) — variable-amount / metered
  • auth-capture (AuthCaptureEvmScheme, from @x402/evm/auth-capture/client) — our escrow-backed / refundable scheme

  All three are single-shot and take the same ClientEvmSigner, so one signer wires up every path. Registering a scheme an endpoint doesn't use is harmless — the client routes on each accepts entry's scheme.

• Both EVM call sites switched from registerExactEvmScheme(...) to registerEvmSchemes(...).

• pnpm-workspace.yaml — bump the shared @x402/* catalog ^2.11.0 → ^2.14.0 (the upto/client and auth-capture/client subpaths ship in @x402/evm@2.14.0); lockfile regenerated. All five @x402/* packages publish in lockstep at 2.14.0.

registerExactEvmScheme stays exported for compatibility. This is purely additive — endpoints that only advertise exact behave exactly as before.

Deliberately excluded: batch-settlement

The SDK also exposes a batch-settlement client scheme, but it's intentionally not registered here. Unlike the others it's stateful — per-channel deposits, signed vouchers, on-chain channel recovery — and needs persistent client channel storage. The wallet builds a fresh per-request x402Client, so the scheme's default in-memory storage would silently lose channel state between requests. Wiring it up correctly (durable channel storage + lifecycle) is separate work.

Why now

The auth-capture client scheme landed upstream in x402-foundation/x402#2486 and is published in @x402/evm@2.14.0. This is the wallet-side wiring to consume it (and upto, which the SDK already shipped). AuthCaptureEvmScheme is pure signing — no on-chain reads/calls.

Demand: #663 — our x402r escrow endpoints (36 live in production) that the scan wallet currently can't pay.

Notes

• This is the payment (client) path only. The indexing/registration path from Add "escrow" to AcceptsScheme enum (x402r escrow endpoints fail to register) #663 is already resolved on main — the AcceptsScheme enum was dropped in favor of a free-string scheme (Prisma scheme String, zod z.string().min(1), plus a "accepts non-exact x402 schemes" upsert test), so non-exact schemes already index. This PR doesn't touch that path.
• Scheme naming follows the canonical merged SDK name auth-capture. Endpoints advertising the older escrow name should move to auth-capture to match.

Test plan

• pnpm install resolves @x402/evm@2.14.0 with the upto/client + auth-capture/client subpaths
• Typecheck / build pass
• Server wallet + browser wallet pay an auth-capture (and upto) endpoint end-to-end on Base

🤖 Generated with Claude Code

[vercel]

@A1igator is attempting to deploy a commit to the Merit Systems Team on Vercel.

A member of the Team first needs to authorize it.