PaymentRequirements (402 Response)
Server sends this to request payment:accepts[] entry with different assetTransferMethod values so clients can pick the method matching their token approvals.
Signing the payload (client)
Clients do not hand-build these payloads. The client half of the scheme ships in the x402 monorepo asAuthCaptureEvmScheme on the @x402/evm/auth-capture/client subpath. Register it on an x402Client and it reads the extra fields, reconstructs the PaymentInfo struct, derives the payer-agnostic nonce, and emits the ERC-3009 (default) or Permit2 payload shown below.
address and signTypedData, so a bare viem LocalAccount works with no PublicClient. The scheme selects ERC-3009 or Permit2 from extra.assetTransferMethod.
PaymentPayload: EIP-3009 (default)
Client sends this with a signed ERC-3009 authorization:PaymentPayload: Permit2
Whenextra.assetTransferMethod === "permit2", the client signs a Permit2 PermitTransferFrom:
Field Reference
Required Extra Fields
Optional Extra Fields
Fee Configuration: The escrow enforces fees on-chain via the
PaymentInfo struct. The escrow rejects captures/charges that fall outside [minFeeBps, maxFeeBps]. If feeRecipient is non-zero, the actual fee recipient at capture/charge must match.Nonce Derivation
The signature nonce is the payer-agnosticPaymentInfo hash. The encoding zeros out the payer; every other field carries the value that will appear on-chain.
salt field enforces freshness: each signing call generates a fresh bytes32 salt, so two payers signing concurrently produce distinct nonces with no collision risk.
Next Steps
Verification and Settlement
The 13-step verification flow and error codes.
PaymentInfo Struct
How wire fields map to the on-chain struct.
