DFNS outlines 2026 x402 agent payment flow

DFNS will handle x402 agent payments in 2026 with a two‑wallet pattern: a payer wallet that signs ERC‑3009 ReceiveWithAuthorization messages using EIP‑712 and a merchant wallet that broadcasts the on‑chain receiveWithAuthorization call and pays native gas.

Under the protocol, a merchant returns an HTTP 402 Payment Required response that includes a PaymentRequirement: the USDC amount in base units, the recipient address (which must equal the merchant address), the USDC contract address, the chain ID, a validity window, and a fresh 32‑byte nonce. The agent requests an EIP‑712 authorization from the DFNS‑backed payer wallet. The payer wallet calls wallets.generateSignature with kind: ‘Eip712’, supplying the ReceiveWithAuthorization types and a domain that pins the USDC verifyingContract and chainId. Implementations should perform in‑process checks, such as per‑payment caps, recipient and asset allowlists, and time‑windowed spend budgets, before calling the signer API.

After the signer produces a signature and its status reaches Signed, the agent retries the original request and includes the ERC‑3009 authorization in an X‑PAYMENT header. The merchant verifies the typed data (for example with ethers.verifyTypedData), encodes receiveWithAuthorization with selector 0xef55bec6 and the parameters (from, to, value, validAfter, validBefore, nonce, v, r, s), and calls wallets.signAndBroadcastTransaction from the merchant wallet. The merchant wallet requires Wallets:BroadcastTransaction permission and must pay native gas for settlement. DFNS demo parameters use gasLimit 200000, maxFeePerGas 5_000_000_000 wei and maxPriorityFeePerGas 1_000_000_000 wei.

Security controls include refusing duplicate nonces, pinning the verifyingContract and chain ID, and minting a fresh random nonce for each 402 request. DFNS Wallets:Sign policies act as a non‑bypassable safety net on the payer wallet; in‑process checks provide a fast user experience gate. The reference demo caps each payment at 5,000,000 base units (5.00 USDC) as an example of an in‑process cap.

Operational prerequisites include a DFNS organization and service account with Wallets:GenerateSignature on the payer wallet, Wallets:BroadcastTransaction on the merchant wallet, and Wallets:Read on both wallets. Teams must provision two DFNS wallets on the target chain, fund the payer with USDC and the merchant with native ETH for gas, and set environment variables such as DFNS_API_URL, DFNS_ORG_ID, DFNS_AUTH_TOKEN, wallet IDs, MERCHANT_ADDRESS, USDC_CONTRACT_ADDRESS, and CHAIN_ID. The DFNS reference stack uses @dfns/sdk, ethers v6, and Node.js v22+; the documentation example uses Ethereum Sepolia (chain ID 11155111) and a Sepolia USDC contract address.

Implementers should follow DFNS documentation for exact API shapes, permissions, and demo values, and adopt conservative per‑payment caps and contract pinning in production to reduce replay or redirection risks. Operational tasks include running two DFNS wallets, maintaining a merchant settle path, monitoring merchant gas balances, and configuring on‑wallet policies for spend limits and approval thresholds.