Skip to main content

PaymentRequirements (402 Response)

Server sends this to request payment:
A server MAY list more than one 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 as AuthCaptureEvmScheme 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.
The signer only needs 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

When extra.assetTransferMethod === "permit2", the client signs a Permit2 PermitTransferFrom:
The deterministic nonce binds the merchant address (no witness struct).

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-agnostic PaymentInfo hash. The encoding zeros out the payer; every other field carries the value that will appear on-chain.
The 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.