Start here: need to register a service and create a plan first? Follow the
5-minute setup.
The x402 Payment Flow
When using x402, the client typically doesn’t start with a token. Instead, the server advertises payment requirements via402 Payment Required, and the client retries with a payment proof.
Implementation Steps
1) Read the payment proof from the request Nevermined x402 clients retry requests with aPAYMENT-SIGNATURE header:
- TypeScript
- Python
HTTP Response Codes
| Code | Meaning | When to Use |
|---|---|---|
200 | Success | Valid payment proof, request processed |
402 | Payment Required | Missing/invalid payment proof, insufficient credits |
500 | Server Error | Validation system failure |
Language-Specific Examples
Go
Rust (Axum)
Ruby (Sinatra)
PHP
REST API Validation
If you can’t use the SDK, call the Nevermined REST API directly:Best Practices
Cache Validation Results
Cache Validation Results
For high-traffic endpoints, consider caching validation results briefly (5-30 seconds) to reduce API calls.
Handle Timeouts
Handle Timeouts
Set reasonable timeouts for validation calls (5-10 seconds) and have a fallback strategy.
Log Payment Events
Log Payment Events
Log all payment validations for debugging and analytics:
- Token hash (not full token)
- Validation result
- Credits consumed
- Timestamp
Return Helpful 402 Responses
Return Helpful 402 Responses
Always include plan information in 402 responses so clients know how to get access.
Security Considerations
- Never log full tokens - Hash them if you need to identify requests
- Use HTTPS - Tokens should only travel over encrypted connections
- Validate on server - Never trust client-side validation
- Set token expiration - Accept reasonable token ages