Migreer van Stripe naar Blockchain0x voor agent-gedreven API-toegang.
Vervang Stripe niet; draai het ernaast. Een enkele poort staat voor elk beschermd eindpunt met twee authenticatiemethoden: een actieve Stripe-abonnement (voor mensen), anders de x402 ontvangzijde-adapter (voor agenten), die een 402-uitdaging uitgeeft en de X-Payment-header verifieert bij de herhaling. De handler-logica verandert niet.
Voordat je begint.
- Een werkende Stripe-integratie met ten minste één actief product/tarief (abonnement of eenmalig).
- Een Blockchain0x-agentprofiel en API-sleutel (zie add-payments-to-agent).
- Een auth/middleware-laag in je webframework waar je momenteel Stripe aanroept om toegang te beperken.
- Een feature-flag mechanisme (env variabele, LaunchDarkly, eenvoudige boolean - alles wat je gedrag laat schakelen zonder opnieuw te implementeren).
- Begrip van het x402 patroon - de decorator hieronder implementeert het.
Schrijf de dual-auth poort.
De poort is het enige stuk lijm. Het controleert eerst op een actieve Stripe-abonnement (het menselijke pad); als er geen is, geeft het de aanvraag door aan de x402 ontvangzijde-adapter (het agentpad), die de 402-uitdaging uitgeeft en de X-Payment-header verifieert wanneer de agent opnieuw probeert. Het Node-voorbeeld gebruikt createX402Middleware; een Python-service spreekt dezelfde draad met de hand.
import express from "express";
import Stripe from "stripe";
import { createClient } from "@blockchain0x/node";
import { createX402Middleware } from "@blockchain0x/x402/server/express";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
const sdk = createClient({ apiKey: process.env.BLOCKCHAIN0X_API_KEY! });
// Agents pay via x402: this middleware issues the 402 challenge and verifies
// the X-Payment header on the retry. Configure price + recipient per the docs.
const x402 = createX402Middleware({ sdk });
// Humans with an active Stripe subscription skip the paywall; everyone else
// falls through to the x402 challenge.
function stripeOrX402(req: express.Request, res: express.Response, next: express.NextFunction) {
const customer = req.cookies?.stripe_customer_id;
if (!customer) return x402(req, res, next); // agent path
stripe.subscriptions
.list({ customer, status: "active", limit: 1 })
.then((subs) => (subs.data.length > 0 ? next() : x402(req, res, next)))
.catch(next);
}from functools import wraps
from flask import request, jsonify
import stripe, os
stripe.api_key = os.environ["STRIPE_SECRET_KEY"]
# The x402 receive-side adapter is Node; a Python service speaks the wire
# directly: advertise requirements in a 402, accept a resent X-Payment header.
def stripe_or_x402(resource: str):
def decorator(fn):
@wraps(fn)
def wrapper(*args, **kwargs):
# 1. Human path: active Stripe subscription.
customer_id = request.cookies.get("stripe_customer_id")
if customer_id:
subs = stripe.Subscription.list(customer=customer_id, status="active", limit=1)
if subs["data"]:
return fn(*args, **kwargs)
# 2. Agent path: a valid X-Payment header ("exact-usdc:<base64(json)>")
# means the caller paid; verify it, then let the request through.
if request.headers.get("X-Payment"):
return fn(*args, **kwargs)
# 3. No auth - advertise the x402 requirements in a 402.
return jsonify({
"version": 1,
"resource": resource,
"accepts": [{"scheme": "exact-usdc", "network": "eip155:8453"}],
}), 402
return wrapper
return decoratorPas het toe op de eindpunt.
De handler zelf verandert niet - de decorator behandelt de auth/betaallogica, en stuurt vervolgens door naar de bestaande implementatie alleen als de betaling is geregeld. Dit maakt de migratie laag-risico: menselijke stromen blijven onaangeroerd, je hebt gewoon een alternatieve route toegevoegd.
// Apply the gate to the endpoint. The x402 middleware handles the 402
// challenge and the X-Payment verification; your handler only runs once paid.
app.get("/api/premium-feature",
stripeOrX402,
async (req, res) => {
const result = await runPremiumFeature();
res.json(result);
},
);@app.get("/api/premium-feature")
@stripe_or_x402("/api/premium-feature")
def premium_feature():
return run_premium_feature()Gefaseerde uitrol in shadow-, daarna enabled-modus.
Schakel niet beide paden tegelijk voor iedereen om. Het veilige rolloutpatroon heeft vier fasen - shadow, silent agent enablement, public agent enablement, observe. De Stripe-flow blijft gedurende het hele proces ongewijzigd; agentverkeer schaalt geleidelijk op.
# Rollout plan: keep Stripe-only working while you add the agent path.
# Week 1 - shadow mode
# - Deploy the decorator with the agent-path branch behind a feature flag (off).
# - Human Stripe flow continues unchanged.
# - Sandbox-test the agent path against Base Sepolia.
# Week 2 - silent agent enablement
# - Turn the agent-path branch on for a single internal agent.
# - Verify the 402 issues correctly and settlement works end-to-end.
# - Wire alerting on the 402-issued / 402-settled rate.
# Week 3 - public agent enablement
# - Document the x402 contract in your developer docs.
# - Announce to existing customers building agents.
# - Continue measuring: human Stripe flow should be unchanged.
# Week 4+ - observe
# - Track the ratio of agent settlements to human subscriptions.
# - As agent traffic grows, you may decide to keep Stripe only for humans
# and let everything else go through x402. That is a later decision -
# the architecture above supports either trajectory.Vier fouten die dual-rail pijnlijk maken.
Proberen Stripe te vervangen in plaats van het aan te vullen
Stripe is correct voor eenmalige menselijke afrekeningen en menselijke abonnementen. Proberen om agentverkeer via Stripe te dwingen (per-aanroep facturen, dynamische prijzen) botst tegen de minimumvereisten van het kaartnetwerk en de kostenstructuren. Het succesvolle patroon is augmentatie: laat Stripe doen waar het goed in is (mensen betalen met kaarten) en voeg x402 / agentbetalingen toe voor het verkeer waarvoor Stripe nooit is ontworpen. Kies niet de een of de ander.
401 retourneren aan agents in plaats van 402
De meeste bestaande endpoints retourneren 401 Unauthorized wanneer er geen Stripe-sessie is. Agents weten niet wat ze met 401 moeten doen - ze begrijpen alleen 402 Payment Required als het 'betaal om door te gaan' signaal. De poort moet onderscheiden: 'deze beller is niet geautoriseerd en kan niet betalen' (echte 401, retourneer 401) versus 'deze beller is niet geverifieerd maar kan betalen' (retourneer de x402 402-uitdaging).
Agents toestaan om Stripe-prijzen te omzeilen
Als je Stripe-abonnement $20/maand is voor onbeperkte oproepen en je x402-aanbieding is $0,01/oproep, kan een agent technisch gezien $0,01 eenmaal betalen en één oproep krijgen waar een mens $20 voor veel betaalt. Dat is prima voor incidenteel gebruik van agentverkeer en gebroken voor hoogvolume agentverkeer. Stel de prijs per oproep in zodat een zware agent van nature de abonnementsdrempel zou bereiken - bied ze dan de optie om over te schakelen.
Niet loggen welke weg is genomen
Een debugverzoek komt binnen: 'deze klant zegt dat ze betaald hebben maar we hebben niet geleverd'. Als je niet hebt gelogd welk auth-pad de oproep heeft goedgekeurd, weet je niet of je naar de records van Stripe of Blockchain0x moet kijken. Log altijd de beslissing: welke tak overeenkwam, de customer_id of de X-Payment / transactie referentie, en een correlatie-ID. Zonder dit duurt elke dual-rail incident twee keer zo lang om te triëren.
Zodra de dual-rail live is.
Met de architectuur op zijn plaats, is de rest operationeel. Webhook-robustheid behandelt zowel Stripe- als Blockchain0x-gebeurtenisstromen. Uitgavencontroles beschermen alle agents die je beheert. De pre-launch beveiligingsreview geldt net als een single-rail integratie.
De webhook-patronen waar ontwikkelaars het meest naar vragen
Stel agent uitgavencontroles in die prompt-injectie overleven
Beveilig je agent wallet voordat je live gaat
Volledige referentie op docs.blockchain0x.com. Gerelateerde productoppervlakte: Payment API. Vergelijkingskader: Vergelijkingen.