Passer au contenu principal
PERSONA 2 VARIANT - FOURNISSEURS D'API

Vendez votre API aux agents IA.

Les agents IA ne peuvent pas remplir un formulaire de carte de crédit. Ils peuvent vous payer en USDC. Blockchain0x effectue cet appel API.

LA DOULEUR

Votre API a été conçue pour les humains. Vos appelants sont maintenant des agents.

La prochaine décennie de revenus API ne viendra pas des inscriptions humaines. Elle viendra des agents AI appelant des API au nom de leurs utilisateurs, souvent de manière programmatique et sans aucune intervention humaine. Ces agents ne peuvent pas utiliser votre processus de paiement existant. Ils ne peuvent pas remplir un formulaire de carte de crédit, ne peuvent pas créer un compte, ne peuvent pas cliquer sur un e-mail de confirmation, ne peuvent pas se souvenir d'un mot de passe.

Ce qu'ils peuvent faire, c'est lire une réponse 402 Payment Required, extraire le montant USDC et le destinataire du corps JSON, payer sur Base et réémettre l'appel avec preuve de paiement. C'est toute la forme du commerce API piloté par les agents. Le modèle de coût (facturation par appel en stablecoin) s'adapte également beaucoup mieux à la forme d'utilisation des agents que les abonnements basés sur des cartes : les cartes échouent pour des transactions inférieures à 1 $ ; USDC sur Base coûte des centimes en frais ; les rétrofacturations ne se produisent pas entre machines.

Blockchain0x est le pont. Listez les routes pour lesquelles vous souhaitez facturer dans un tableau de prix et montez l'adaptateur x402. Lorsqu'un appel non payé atteint une route tarifée, l'adaptateur renvoie un 402 décrivant exactement ce qu'il faut payer. L'agent paie sur Base et réessaie avec un en-tête X-Payment ; l'adaptateur le vérifie et votre gestionnaire s'exécute. Vous collectez USDC et exécutez votre API comme auparavant. Rien dans votre logique commerciale ne change ; la couche de facturation fonctionne en parallèle.

402 PAIEMENT REQUIS

Le code d'état HTTP a enfin une utilisation.

HTTP 402 was reserved in the original spec for "future use" and never standardized. For thirty years it sat unused while the internet built per-account subscription billing on top of 200/401/403. With Coinbase's x402 protocol, 402 finally has a standard implementation: any API that needs payment-before-it-runs can return a structured 402, and any client that understands the spec can pay and retry.

VOTRE API RETOURNE CE CORPS 402 LORSQU'UN APPEL N'A PAS ÉTÉ PAYÉ
HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "resource": "POST /api/expensive-operation",
  "accepts": [
    {
      "scheme": "exact-usdc",
      "network": "mainnet",
      "chainId": "eip155:8453",
      "payToAddress": "0xYourAgentWalletAddress",
      "amountWeiUsdc": "500000",
      "paymentRequestId": "pr_demo",
      "maxAgeSeconds": 60
    }
  ]
}

Ce que signifie l'exigence accepts[]

  • scheme - le schéma de paiement. exact-usdc signifie un montant exact en USDC sur une chaîne EVM. Le client correspond à cela avant de payer.
  • network / chainId - la chaîne sur laquelle régler (la chaîne principale est Base, CAIP-2 eip155:8453). Une migration peut citer les deux réseaux en énumérant deux exigences dans accepts.
  • payToAddress / amountWeiUsdc - le portefeuille du destinataire et le montant exact en unités de base USDC (500000 = 0,50 USDC, 6 décimales). Le client vérifie les deux avant de payer.
  • paymentRequestId - lie le paiement à cette citation. L'adaptateur rejette un X-Payment qui fait référence à un paymentRequestId différent de la route citée.
  • maxAgeSeconds - combien le paiement doit être frais. Un paiement plus ancien que cette fenêtre est rejeté et l'appelant doit payer à nouveau.

x402 est machine-à-machine : un client conscient de x402 lit accepts, paie l'exigence choisie on-chain, puis réémet la demande avec un en-tête X-Payment que l'adaptateur vérifie. Un client qui ne parle pas x402 reçoit simplement le 402 et n'obtient aucun résultat, ce qui est le bon résultat (l'appel n'a pas été payé). Il n'y a pas de page de paiement hébergée dans ce flux ; le paiement est réglé de manière programmatique par le portefeuille de l'appelant.

PATTERN D'ADAPTATEUR

Une table de prix. Trois langues. Même forme.

Vous montez un adaptateur et lui donnez une table de prix indexée par METHOD plus chemin. Il contrôle uniquement les routes que vous listez ; votre gestionnaire ne voit jamais un appel non payé, car lorsque cela s'exécute, l'en-tête X-Payment a déjà été vérifié. La forme est identique à travers Python, TypeScript et Go - le format de transmission X-Payment est le même, donc un serveur Go accepte les en-têtes construits par un client Python.

PYTHON (FLASK)
from flask import Flask
from blockchain0x import Client
from blockchain0x_x402.server import x402_before_request_factory, PricingEntry

sdk = Client()  # reads BLOCKCHAIN0X_API_KEY
app = Flask(__name__)

# Only routes named in the pricing table are gated.
app.before_request(x402_before_request_factory(
    sdk=sdk,
    pricing={
        "POST /api/expensive-operation": PricingEntry(
            amount_usdc="0.50",
            pay_to_address="0xYourAgentWalletAddress",
            payment_request_id="pr_demo",
        ),
    },
))

@app.route("/api/expensive-operation", methods=["POST"])
def expensive_operation():
    return run_the_work()  # only runs after X-Payment verifies
TYPESCRIPT (EXPRESS)
import express from "express";
import { createClient } from "@blockchain0x/node";
import { createX402Middleware } from "@blockchain0x/x402/server/express";

const sdk = createClient({ apiKey: process.env.BLOCKCHAIN0X_API_KEY! });
const app = express();

// Only routes named in the pricing table are gated.
app.use(createX402Middleware({
  sdk,
  pricing: {
    "POST /api/expensive-operation": {
      amountUsdc: "0.50",
      payToAddress: "0xYourAgentWalletAddress",
      paymentRequestId: "pr_demo",
    },
  },
}));

app.post("/api/expensive-operation", async (req, res) => {
  res.json(await runTheWork());  // req.x402Payment holds the verified payment
});
GO (NET/HTTP)
import (
  "net/http"
  x402 "tosh-labs/blockchain0x-x402-go"
)

func main() {
  pricing := map[string]x402.PricingEntry{
    "POST /api/expensive-operation": {
      AmountUSDC:       "0.50",
      PayToAddress:     "0xYourAgentWalletAddress",
      PaymentRequestID: "pr_demo",
    },
  }

  // serverSdk is your Blockchain0x Go SDK client.
  h := x402.Middleware(x402.ServerOptions{Sdk: serverSdk, Pricing: pricing})(
    http.HandlerFunc(expensiveOperation))
  http.Handle("/api/expensive-operation", h)
  http.ListenAndServe(":8080", nil)
}

Nous expédions des adaptateurs de serveur pour Express et Fastify (Node), ASGI (Starlette et FastAPI) et Flask (Python), ainsi que le net/http de Go. Pour d'autres frameworks, le corps 402 et l'en-tête X-Payment sont du HTTP brut que les helpers de wire dans @blockchain0x/x402 construisent et analysent - écrivez la vérification dans l'idiome de votre pile. Des packages x402 Ruby et JVM sont publiés pour le côté client.

VS STRIPE CHECKOUT

Quand atteindre chaque outil.

Stripe est le bon outil pour le paiement humain. Blockchain0x est le bon outil pour le paiement des agents. Ils résolvent des problèmes différents et se trouvent souvent côte à côte sur la même API.

DimensionBlockchain0xStripe Checkout
AcheteurTout client HTTP (humain ou agent IA)Humain devant un navigateur
Auth requis avant le paiementNon - le premier appel renvoie 402 avec les exigences de paiementOui - e-mail + formulaire de carte
Vitesse de règlement5 secondes (USDC sur Base)2-7 jours (réseaux de cartes)
Risque de rétrofacturationAucun (USDC est final)Jusqu'à 120 jours de fenêtre de rétrofacturation
Économie des coûts par transactionFonctionne à $0.01-$0.10 par appel (gaz Base + notre frais)Les frais de carte rendent les transactions inférieures à 1 $ non rentables
RemboursementsManuel - votre code renvoie USDC à l'adresse du payeurAutomatisé via le tableau de bord Stripe
Support internationalMême portefeuille, n'importe quel pays, pas de configuration supplémentaireLicences par pays, conversion de devises, règles régionales
Meilleur pourConsommation d'API pilotée par des agents programmatiquesPaiement piloté par un humain (inscription SaaS, e-commerce)

Le modèle sur lequel la plupart des fournisseurs d'API se basent : garder Stripe pour le flux d'inscription humain (votre tableau de bord, votre page produit d'abonnement) ; ajouter Blockchain0x à la limite de l'API pour un accès programmatique des agents. L'adaptateur x402 ne contrôle que les routes que vous mettez dans sa table de tarification, donc vos routes humaines authentifiées par Stripe restent intactes. Pointez les agents vers les routes tarifées et les humains vers le reste, et les deux audiences sont servies par le même code API.

QUEL PLAN CONVIENT

Pro pour le trafic précoce. Business lorsque les journaux d'audit deviennent une exigence.

Les fournisseurs d'API commencent presque toujours par le plan Pro dès le premier jour : le plan Gratuit est en lecture seule, et l'adaptateur x402 a besoin d'un accès API pour vérifier et régler les paiements ainsi que des webhooks pour les suivre. Les API à fort trafic passent dans le territoire Business à mesure que le volume mensuel augmente. Consultez la page de tarification pour le coût exact par agent et où se situent les niveaux.

  • Free : utile uniquement pour le dashboard et l'exploration des métadonnées. Lecture seule, donc l'adaptateur ne peut pas régler les paiements.
  • Pro: la formule par défaut pour la monétisation d'une API en production. Accès API complet, webhooks, exports.
  • Business : lorsque vous avez besoin de journaux d'audit pour la conformité, ou de limites de débit API plus élevées.
Voir les tarifs complets
QUESTIONS FRÉQUEMMENT POSÉES

Cinq questions pour les fournisseurs d'API.

Puis-je exécuter Stripe aux côtés de Blockchain0x pour la même API ?

Oui, et de nombreux fournisseurs d'API le font. Le modèle : conservez votre flux d'inscription humain basé sur Stripe existant et listez uniquement les routes orientées agent dans le tableau des prix x402. L'adaptateur filtre exactement ces routes ; tout ce qui n'est pas dans le tableau (y compris les routes que vos clients authentifiés Stripe appellent) passe directement, sans être affecté. Si vous souhaitez une seule route pour servir les deux, vérifiez votre propre clé API dans le gestionnaire et ignorez le chemin tarifé pour les appelants authentifiés. Les deux publics obtiennent ce qu'ils veulent sans qu'un chemin ne bloque l'autre.

Que se passe-t-il si un agent IA paie puis sort avant de réessayer l'appel ?

Le paiement est toujours valide sur la chaîne ; il reste simplement inutilisé. Le portefeuille de l'agent montre un transfert USDC réussi vers votre adresse. Du point de vue de l'agent, il a perdu l'USDC ; du vôtre, vous avez été payé pour un appel qui n'a jamais été exécuté. Cela est rare en pratique (le client x402 réessaie immédiatement après avoir payé), mais si vous voulez être défensif, vous pouvez suivre les paiements vérifiés qui n'ont jamais produit un appel complet et renvoyer l'USDC vous-même avec payments.create, en payant l'adresse du payeur d'origine. Il n'y a pas de point de terminaison de remboursement séparé - un remboursement est simplement un paiement dans l'autre direction.

Comment versionner mon API et les changements de prix?

Chaque entrée dans le tableau des prix est par route, donc différentes routes peuvent facturer des prix différents. Pour le versionnage, le modèle recommandé est d'exposer les points de terminaison v2 aux côtés de v1 avec les nouveaux prix comme nouvelles entrées dans le tableau des prix ; les clients voient le nouveau montant dans leur première réponse 402 sur la route v2 et paient en conséquence. Des augmentations de prix soudaines sur des routes stables sont une mauvaise citoyenneté de protocole ; nous recommandons de déprécier l'ancienne route et de servir un 410 Gone qui pointe vers la nouvelle route au nouveau prix.

À quoi ressemble l'observabilité - journaux, métriques, alertes ?

Chaque paiement apparaît dans le tableau de bord Blockchain0x avec le portefeuille du payeur, le montant et l'horodatage, et les mêmes données arrivent sur votre webhook payment.received afin que vous puissiez les diffuser dans Datadog, Splunk ou votre propre pile de journaux. L'adaptateur s'exécute à l'intérieur de votre serveur, donc les signaux au niveau de la requête (quelle route a été citée, chaque 402 que vous avez retourné, chaque X-Payment que vous avez vérifié) sont à vous de les enregistrer et de les émettre comme métriques dans le format que votre pile utilise. Configurez des alertes sur les évidentes : une augmentation soudaine des réponses 402, ou une baisse du taux de paiement vérifié.

Qu'en est-il des questions réglementaires - suis-je une entreprise de services monétaires si je fais cela ?

Probablement pas, mais cela dépend de la juridiction et nous ne sommes pas vos avocats. La raison : vous recevez un paiement pour des services que vous fournissez, pas pour transmettre de l'argent entre des tiers (ce qui déclenche le statut MSB aux États-Unis). USDC est reconnu comme une stablecoin de paiement dans la plupart des juridictions. Vous devez payer des impôts sur les revenus équivalents en USD ; nous générons les enregistrements dont vous avez besoin pour cela. Si vous opérez dans un contexte B2B à fort volume ou dans une juridiction avec des règles crypto strictes (Allemagne, Singapour pour certaines formes), obtenez des conseils juridiques spécifiques avant de passer au trafic de production. Nous pouvons vous référer à des entreprises qui ont effectué ce travail pour des clients précédents.

Laissez les agents payer pour votre API.

Ajoutez une route à la table des prix et montez l'adaptateur. Stripe reste pour les humains. Les deux publics sont servis.