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
Supported Schemes
Nevermined supports two x402 payment schemes:| Scheme | Network | Use Case | Settlement |
|---|---|---|---|
nvm:erc4337 | eip155:84532 | Crypto payments | ERC-4337 UserOps + session keys |
nvm:card-delegation | stripe | Fiat/credit card | Stripe PaymentIntent + credit burn |
isCrypto: false use nvm:card-delegation; all others use nvm:erc4337. The SDK auto-detects the scheme via resolve_scheme().
Generate Payment Permissions
From Nevermined App
The easiest way to generate permissions is through the Nevermined App Permissions page:- Navigate to the permissions page
- Select your plan and agent
- Configure limits (optional)
- Generate the access token
From SDK
Card-Delegation Token Generation
For fiat plans usingnvm:card-delegation, pass X402TokenOptions with a CardDelegationConfig:
Auto Scheme Resolution
Useresolve_scheme() to auto-detect the correct scheme from plan metadata:
DelegationAPI
List enrolled payment methods for card delegation:PaymentMethodSummary fields:
| Field | Type | Description |
|---|---|---|
id | str | Payment method ID (e.g., pm_...) |
brand | str | Card brand (e.g., visa, mastercard) |
last4 | str | Last 4 digits of the card number |
exp_month | int | Card expiration month |
exp_year | int | Card expiration year |
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
| Field | Type | Description |
|---|---|---|
is_valid | bool | Whether verification passed |
invalid_reason | str | Reason for invalidity (if is_valid is false) |
payer | str | Payer’s wallet address |
agent_request_id | str | Agent request ID for observability tracking |
Settle Payment Permissions
Settlement burns credits after successfully processing a request:Settlement Response
| Field | Type | Description |
|---|---|---|
success | bool | Whether settlement succeeded |
error_reason | str | Reason for failure (if success is false) |
payer | str | Payer’s wallet address |
transaction | str | Blockchain transaction hash |
credits_redeemed | str | Credits that were burned |
remaining_balance | str | Credits remaining |
Payment Required Object
TheX402PaymentRequired object specifies what payment is required. The scheme and network fields vary by payment type:
Using the Helpers
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
- Always verify before processing: Don’t do expensive work without verification
- Only settle on success: Don’t burn credits if processing fails
- Use agent_request_id: Include request IDs for tracking and debugging
- Handle 402 responses: Return proper payment required responses with scheme info
- Cache verifications carefully: Tokens can be used multiple times until limits are reached
Error Codes
| Error | Description | Resolution |
|---|---|---|
invalid_token | Token is malformed | Generate a new token |
expired_token | Token has expired | Generate a new token |
insufficient_balance | Not enough credits | Order more credits |
invalid_plan | Plan ID mismatch | Use correct plan ID |
invalid_agent | Agent ID mismatch | Use correct agent ID |