Skip to main content
This guide covers the x402 payment protocol for verifying permissions and settling payments.

Overview

x402 is a payment protocol that enables:
  • Permission Generation: Subscribers create access tokens for agents
  • Permission Verification: Agents verify tokens without burning credits
  • Permission Settlement: Agents burn credits after completing work
The protocol is named after HTTP status code 402 (Payment Required).

Supported Schemes

Nevermined supports two x402 payment schemes: The scheme is determined by the plan’s pricing configuration. Plans with isCrypto: false use nvm:card-delegation; all others use nvm:erc4337. The SDK auto-detects the scheme via resolve_scheme(). The network value within nvm:card-delegation is determined by which provider issued the delegation being consumed (stripe, braintree, or visa).

Visa support

Visa delegations use the same nvm:card-delegation scheme and SDK surface as Stripe and Braintree, but two steps must happen in a browser before the SDK can consume them:
  1. Card enrolment — the cardholder enrols a Visa card through VGS Collect (PCI-compliant iframe) in the Nevermined webapp. The card is bound to a Visa Agentic Token via the VGS Credential Management Platform.
  2. Delegation creation — the cardholder approves a delegation via a WebAuthn/passkey (FIDO) device-binding ceremony embedded by Visa VTS. This produces a single-use assuranceData blob bound to the spending limit + duration + merchant context.
Both steps require a real DOM and a user gesture, so the SDK cannot perform them programmatically. Once a Visa delegation exists, the SDK consumes it identically to Stripe/Braintree — pass delegation_id to DelegationConfig and call get_x402_access_token as usual:
delegation_id reuse is the only supported pattern for Visa — create_delegation(provider="visa", ...) is rejected by the backend without the browser-only consumer_prompt + assurance_data blobs the SDK has no way to produce. When a Visa creation call fails this way, PaymentsError.code carries the backend BCK.VISA.0014 so consumers can branch programmatically.

Generate Payment Permissions

From Nevermined App

The easiest way to generate permissions is through the Nevermined App Permissions page:
  1. Navigate to the permissions page
  2. Select your plan and agent
  3. Configure limits (optional)
  4. Generate the access token

From SDK

Deprecated: passing spending_limit_cents / duration_secs directly to get_x402_access_token (inline create-on-the-fly, a DelegationConfig with no delegation_id) emits a DeprecationWarning and will be removed in a future release. Create the delegation first as shown above, then pass only delegation_id.

Card-Delegation Token Generation

For fiat plans using nvm:card-delegation, create the card delegation once (currency is required), then request the token by delegation_id:

Auto Scheme Resolution

Use resolve_scheme() to auto-detect the correct scheme from plan metadata:

DelegationAPI

Create delegations and list enrolled payment methods:
list_payment_methods() accepts an optional provider keyword argument ('stripe' | 'braintree' | 'visa' | 'erc4337'). When set, it is forwarded as a ?provider= query string and only methods backed by that provider are returned. Omit it (the default) to return methods from every provider. PaymentMethodSummary fields:

Token Structure

The x402 token is a base64-encoded JSON document:

Verify Payment Permissions

Verification checks if a subscriber has valid permissions without burning credits:

Verification Response

Settle Payment Permissions

Settlement burns credits after successfully processing a request:

Settlement Response

Payment Required Object

The X402PaymentRequired object specifies what payment is required. The scheme and network fields vary by payment type:

Using the Helpers

For a single plan, build_payment_required_for_plans delegates to build_payment_required internally. When scheme is omitted, the network defaults to eip155:84532 (Base Sepolia). When scheme="nvm:card-delegation", the network is automatically set to stripe.

Complete Workflow Example

HTTP Flow

Best Practices

  1. Always verify before processing: Don’t do expensive work without verification
  2. Only settle on success: Don’t burn credits if processing fails
  3. Use agent_request_id: Include request IDs for tracking and debugging
  4. Handle 402 responses: Return proper payment required responses with scheme info
  5. Cache verifications carefully: Tokens can be used multiple times until limits are reached

Error Codes

Next Steps

Request Validation

More validation patterns

MCP Integration

x402 with MCP servers

OAuth 401 vs. payment-required

In-band x402 v2 MCP signaling