Set up Nevermined x402 USDC payments for AI agents

As of September 30, 2026, Nevermined’s documentation describes the steps to enable HTTP 402 USDC payments for AI agents using the nvm:erc4337 scheme. The guide covers prerequisites, server integration, buyer flows, settlement mechanics and operational checks.

The process begins with an API key created at nevermined.app (Settings → Global NVM API Keys). Keys use a prefix that selects a backend: sandbox keys target api.sandbox.nevermined.app and live keys target api.live.nevermined.app. The documentation warns that mixing sandbox keys with live plan IDs routes requests to the wrong backend and often triggers confusing 4xx errors.

Developers install the Payments SDK—@nevermined-io/payments for TypeScript or payments-py for Python-and register an agent and a USDC-backed plan by calling payments.agents.registerAgentAndPlan. The example plan in the docs prices 10 USDC (10_000_000 base units with six decimals) and issues 100 fixed credits at one credit per request. The sandbox quickstart uses a Base Sepolia USDC contract at 0x036CbD53842c5426634e7929541eC2318f3dCF7e; the docs advise confirming the live network USDC address before funding production plans.

On the server side, Nevermined supplies paymentMiddleware for Express. The middleware handles the HTTP 402 handshake: it returns a 402 with payment-required when a request lacks a valid payment-signature, calls the facilitator to verify permissions before the handler runs, and calls settle after successful work to burn credits and attach a payment-response receipt. The middleware supports route-level configuration, dynamic credits and an explicit agentId. For non-Express frameworks, the documentation describes a manual flow: return payment-required, call facilitator.verifyPermissions, execute the paid work, then call facilitator.settlePermissions. The docs emphasize that verifyPermissions does not burn credits and settlePermissions does.

Buyer integration requires two steps. Buyers first create a spend-capped delegation with payments.delegation.createDelegation using provider: ‘erc4337’, currency: ‘usdc’, spendingLimitCents and durationSecs. Buyers then mint short-lived x402 access tokens with payments.x402.getX402AccessToken(planId, agentId, { scheme: ‘nvm:erc4337’, delegationConfig: { delegationId } }). Requests that omit delegationConfig receive error code BCK.X402.0030. The intended pattern is to reuse a single delegationId for multiple token mints until the cap or duration expires. The access token is sent in the payment-signature header; the facilitator can top up credits at settle time up to the delegation cap so buyer agents do not need a manual order-before-each-request loop.

The documentation distinguishes Nevermined’s model from direct per-request ERC-20 transfers. Nevermined retains the HTTP 402 exchange but settles using ERC-4337 smart accounts, UserOps, session keys and plan-based credits rather than a direct EIP-3009 transfer per request. The nvm:card-delegation scheme covers card-backed (fiat) plans. A separate MPP wire format exists with a different handshake; the published guide focuses on x402 and nvm:erc4337.

The docs include an operational checklist: confirm the API returns 402 with payment-required when payment-signature is omitted, mint a sandbox delegation and retry with a payment-signature, verify creditsRemaining or billingModel change after settle, revoke delegations and confirm further settlements fail, then switch to a live key and live plan IDs. The documentation lists a common pitfall: using a sandbox key with live plan IDs (or vice versa) routes to the wrong backend and produces confusing errors.

The guide compares Nevermined Payments to other x402 toolkits and facilitators. It presents Nevermined as a path for teams that want to register plans, meter credits and accept spend-capped buyer delegations within the same SDK. Other tools focus on buyer-side clients, facilitator-only URLs, TEE wallet custody or API-specific crediting; the docs reference those alternatives and advise choosing the integration that matches whether the agent is the merchant of record, the buyer, or a third party.