Migrar do Stripe para Blockchain0x para acesso à API dirigido pelo agente.
Não substitua o Stripe; execute-o ao lado. Um único portão protege cada endpoint protegido com dois métodos de autenticação: uma assinatura ativa do Stripe (para humanos), caso contrário, o adaptador do lado de recebimento x402 (para agentes), que emite um desafio 402 e verifica o cabeçalho X-Payment na nova tentativa. A lógica do manipulador não muda.
Antes de você começar.
- Uma integração Stripe funcional com pelo menos um produto/preço ativo (assinatura ou único).
- Um perfil de agente Blockchain0x e chave de API (veja adicionar pagamentos ao agente).
- Uma camada de autenticação/middleware em seu framework web onde você atualmente chama a Stripe para restringir o acesso.
- Um mecanismo de controle de recursos (variável de ambiente, LaunchDarkly, booleano simples - qualquer coisa que permita alternar o comportamento sem reimplantação).
- Compreensão do x402 pattern - o decorador abaixo o implementa.
Escreva o portão de autenticação dupla.
O portão é a única peça de cola. Ele verifica primeiro uma assinatura ativa do Stripe (o caminho humano); se não houver, ele entrega a solicitação ao adaptador do lado de recebimento x402 (o caminho do agente), que emite o desafio 402 e verifica o cabeçalho X-Payment quando o agente tenta novamente. O exemplo Node usa createX402Middleware; um serviço Python fala o mesmo fio manualmente.
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 decoratorAplique-o ao endpoint.
O manipulador em si não muda - o decorador lida com a lógica de autenticação/pagamento, e depois encaminha para a implementação existente apenas se o pagamento estiver liquidado. Isso é o que torna a migração de baixo risco: os fluxos humanos permanecem intocados, você apenas adicionou um caminho alternativo.
// 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()Liberar em shadow, depois em modo ativado.
Não ative os dois caminhos de uma vez para todos. O padrão seguro de rollout tem quatro fases - shadow, habilitação silenciosa de agentes, habilitação pública de agentes, observação. O fluxo do Stripe permanece inalterado durante todo o processo; o tráfego de agentes cresce gradualmente.
# 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.Quatro erros que tornam o sistema dual doloroso.
Tentando substituir o Stripe em vez de aumentá-lo
O Stripe é correto para checkouts humanos únicos e assinaturas humanas. Tentar forçar o tráfego de agentes através do Stripe (faturas por chamada, preços dinâmicos) quebra contra os mínimos da rede de cartões e estruturas de taxas. O padrão de sucesso é a augmentação: mantenha o Stripe fazendo o que ele faz de melhor (humanos pagando com cartões) e adicione pagamentos x402 / de agentes para o tráfego para o qual o Stripe nunca foi projetado. Não escolha um ou outro.
Retornando 401 para agentes em vez de 402
A maioria dos endpoints existentes retorna 401 Unauthorized quando não há sessão Stripe. Os agentes não sabem o que fazer com 401 - eles só entendem 402 Payment Required como o sinal 'pague para prosseguir'. O portão deve distinguir: 'este chamador não está autorizado e não pode pagar' (401 verdadeiro, retorna 401) versus 'este chamador não está autenticado, mas pode pagar' (retorna o desafio x402 402).
Deixando agentes contornarem a precificação do Stripe
Se sua assinatura do Stripe é $20/mês para chamadas ilimitadas e sua cotação x402 é $0,01/chamada, um agente pode tecnicamente pagar $0,01 uma vez e obter uma chamada onde um humano paga $20 por muitas. Isso é aceitável para tráfego de agente de uso ocasional e problemático para tráfego de agente de alto volume. Defina o preço por chamada de forma que um agente pesado atinja naturalmente o limite de assinatura - então ofereça a opção de mudar.
Não registrando qual caminho foi seguido
Uma solicitação de depuração chega: 'este cliente diz que pagou, mas não entregamos'. Se você não registrou qual caminho de autenticação aprovou a chamada, não sabe se deve olhar os registros da Stripe ou os da Blockchain0x. Sempre registre a decisão: qual ramificação correspondeu, o customer_id ou a referência de X-Payment / transação, e um ID de correlação. Sem isso, cada incidente de dupla via leva o dobro do tempo para triagem.
Uma vez que a via dupla está ativa.
Com a arquitetura em funcionamento, o restante é operacional. A robustez do webhook lida com fluxos de eventos tanto do Stripe quanto do Blockchain0x. Os controles de gastos protegem qualquer agente que você opere. A revisão de segurança pré-lançamento se aplica da mesma forma que uma integração de única infraestrutura.
Os padrões de webhook que os desenvolvedores mais perguntam
Configure controles de gastos do agente que sobrevivem à injeção de prompt
Proteja sua carteira de agente antes de ir ao vivo
Referência completa em docs.blockchain0x.com. Superfície de produto relacionada: Payment API. Enquadramento de comparação: Comparações.