Saltar al contenido principal
AprenderGuíasAgrega pagos a tu agente de IA
GUÍA

Cómo agregar pagos a tu agente de IA.

10 minutes
RESPUESTA CORTA

Cree un agente con createClient de @blockchain0x/node (o el cliente de Python), envíe un pago de USDC con payments.create y verifique el webhook firmado con webhooks.verify. Los controles de gasto se establecen en el panel y son de solo lectura a través de la API. El agente nunca toca las claves privadas directamente. Menos de diez minutos desde el registro hasta su primer pago de USDC en Base, en TypeScript o Python.

REQUISITOS PREVIOS

Antes de comenzar.

  • Una cuenta de Blockchain0x (registro gratuito).
  • Una clave de API del panel de control (usa una clave sk_test_ para esta guía; cambiarás a sk_live_ más tarde).
  • Node.js 20+ o Python 3.11+ en el tiempo de ejecución de tu agente.
  • Un agente construido en cualquier marco - LangChain, CrewAI, AutoGen, LlamaIndex, OpenAI Agents SDK, MCP, o código SDK simple. Las instrucciones son independientes del marco.
  • Un endpoint HTTPS accesible desde internet público para recibir webhooks (ngrok o una vista previa de implementación está bien para desarrollo).
PASO 1 DE 5

Crea el perfil del agente.

El perfil del agente es la identidad direccionable detrás de cada pago que tu agente envía o recibe. Lleva la dirección de la billetera, la página pública, las insignias de verificación y (más adelante) la política de gasto. Crea uno por agente lógico.

TypeScript
import { createClient } from "@blockchain0x/node";

const client = createClient({ apiKey: process.env.BLOCKCHAIN0X_API_KEY! }); // sk_test_ / sk_live_

const agent = await client.agents.create({ name: "research-bot" });

console.log(agent.id); // "agt_..."
// Public page: https://wallet.blockchain0x.com/a/{slug}
Python
from blockchain0x import Client

client = Client()  # reads BLOCKCHAIN0X_API_KEY from the environment

agent = client.agents.create(body={"name": "research-bot"})

print(agent["id"])  # "agt_..."
# Public page: https://wallet.blockchain0x.com/a/{slug}

After this call, the agent has a public page at https://wallet.blockchain0x.com/a/<slug> that any counterparty (human or agent) can hover for verification info. See the agent payment identity glossary entry for what that page exposes.

PASO 2 DE 5

Enviar un pago.

payments.create sends USDC from the agent wallet. amountWei is base units (USDC has 6 decimals), so 0.01 USDC is the string "10000". The SDK auto-stamps an Idempotency-Key, and the call can return 503 until the chain adapter is wired for your network. To RECEIVE instead, settle an invoice you created in the dashboard with paymentRequests.settle - see the payment API page.

TypeScript
// Send a USDC payment from the agent wallet. amountWei is base units
// (USDC has 6 decimals): "10000" is 0.01 USDC. payments.create auto-stamps an
// Idempotency-Key and can return 503 until the chain adapter is wired.
const tx = await client.payments.create({
  agentId: agent.id,
  to: "0xRecipient",
  amountWei: "10000",
});

console.log(tx); // the submitted transfer
Python
# amountWei is USDC base units (6 decimals): "10000" is 0.01 USDC.
tx = client.payments.create(body={
    "agentId": agent["id"],
    "to": "0xRecipient",
    "amountWei": "10000",
})

print(tx)  # the submitted transfer
PASO 3 DE 5

Maneja el webhook.

Los webhooks son cómo descubres que un pago se ha liquidado. En Node, webhooks.verify de @blockchain0x/node realiza la verificación HMAC y devuelve una unión discriminada; en otros lenguajes, calcula el mismo HMAC sobre el cuerpo RAW. Ramifica según el tipo de evento (payment.received para entrante), responde 2xx rápidamente y coloca cualquier cosa más pesada detrás del 2xx para que la entrega no se agote.

TypeScript (Express)
import express from "express";
import { webhooks } from "@blockchain0x/node";

const app = express();
// Capture the RAW body. The HMAC is over the exact bytes on the wire.
app.use(express.raw({ type: "application/json" }));

app.post("/webhooks/payment", (req, res) => {
  const result = webhooks.verify({
    headers: req.headers,
    rawBody: req.body, // Buffer, raw bytes
    secret: process.env.BLOCKCHAIN0X_WEBHOOK_SECRET!,
  });
  if (!result.ok) return res.status(400).json({ code: result.code });

  if (result.eventType === "payment.received") {
    // USDC landed - deliver the work, fulfil the order, etc.
    void deliver(result.eventId);
  }
  res.status(200).send("ok");
});
Python (Flask)
import hmac, hashlib, os, time
from flask import Flask, request, abort

app = Flask(__name__)
SECRET = os.environ["BLOCKCHAIN0X_WEBHOOK_SECRET"].encode()

@app.post("/webhooks/payment")
def webhook():
    raw = request.get_data()  # RAW bytes - do not parse first
    sig = request.headers.get("X-Blockchain0x-Signature", "")
    ts = request.headers.get("X-Blockchain0x-Timestamp", "")
    parts = dict(p.split("=", 1) for p in sig.split(",") if "=" in p)
    t, v1 = parts.get("t", ts), parts.get("v1", sig)
    want = hmac.new(SECRET, t.encode() + b"." + raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(want, v1) or abs(time.time() - int(t)) > 300:
        abort(401)
    if request.headers.get("X-Blockchain0x-Event-Type") == "payment.received":
        deliver(request.get_json())  # USDC landed
    return ("ok", 200)
PASO 4 DE 5

Establece controles de gasto en el panel.

Si tu agente solo recibe, puedes omitir esto. Si también paga, establece un permiso de gasto - una asignación por período y un límite por transacción - en el panel. Se aplica desde el backend en cada pago, por lo que sobrevive a la inyección de comandos de una manera que las reglas del lado del agente nunca pueden. No hay ninguna llamada de API o SDK que muta un permiso (la propia clave del agente no puede ampliar su límite); la API es de solo lectura, por lo que tu código puede obtener los valores actuales para mostrar o planificar.

Leer (curl)
curl https://api.blockchain0x.com/v1/agents/agt_123/spend-permissions \
  -H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY"
Respuesta
{
  "allowance_wei": "5000000",
  "per_tx_wei": "1000000",
  "period_seconds": 86400,
  "revoked_at": null
}
PASO 5 DE 5

Prueba todo el flujo en Base Sepolia.

Antes de cambiar a claves sk_live_, ejecuta el camino completo de extremo a extremo con sk_test_. Una clave de prueba mantiene todo en Base Sepolia, donde financias la billetera desde el grifo público y las formas de respuesta coinciden con las de producción. El prefijo de la clave elige la red, así que una clave de prueba no puede mover fondos de la red principal.

Ejercita tres escenarios: un pago en el camino correcto que activa payment.received, una entrega fallida (apunta el webhook a una URL muerta, luego concilia obteniendo la transacción con transactions.get), y un reintento de webhook (devuelve un 500 la primera vez, 200 la segunda, y confirma que tu manejador es idempotente). Cuando los tres pasen la prueba, cambia la clave y envía.

ERRORES COMUNES

Cinco errores que le cuestan a los equipos una semana.

Omitiendo la verificación de firma del webhook

Si aceptas cualquier POST a /webhooks/payment como autoritativo, un atacante puede crear eventos de pago falsos y engañar a tu agente para que entregue trabajo gratis. Siempre verifica HMAC con el secreto del webhook, utilizando una comparación en tiempo constante. La primera vulnerabilidad es casi siempre la verificación faltante.

Asumiendo un evento de confirmación separado

Los eventos enviados son payment.received, payment.sent, wallet.deployed y webhook.test - no hay un evento de confirmación separado. payment.received se activa cuando la transferencia está en un bloque. Para la mayoría de los trabajos, esa es tu señal para entregar. Para algo costoso o irreversible, consulta la transacción con transactions.get y aplica tu propio umbral de confirmación antes de actuar; no esperes un evento que no existe.

Sin idempotencia en los controladores de webhook

Los webhooks reintentan en respuestas no-2xx, y el mismo evento llegará varias veces bajo carga. Tu manejador debe ser idempotente: mantén una pequeña tabla de IDs de eventos que ya has procesado y omite duplicados. De lo contrario, un pequeño parpadeo entregará el mismo trabajo dos veces y pasarás horas depurando cumplimientos dobles.

Mezclando claves de API de prueba y en vivo

Las claves de prueba (sk_test_) acceden al sandbox y utilizan Base Sepolia; las claves en vivo (sk_live_) acceden a producción y utilizan la red principal de Base. Mezclarlas en las configuraciones de entorno es la causa de la mayoría de los tickets de 'funciona en desarrollo, falla en producción'. Falla de forma crítica al inicio si tu entorno de ejecución y el prefijo de la clave no coinciden.

Tratando un webhook faltante como un pago fallido

No hay evento de fallo, y un webhook puede ser perdido (tu endpoint estaba caído, se perdió una entrega). No dejes al agente atascado en un bucle de 'esperando fondos'. Reconciliar: obtener la transacción con transactions.get para conocer el estado real, y poner un tiempo de espera en cualquier flujo de espera para que un pago abandonado libere recursos retenidos en lugar de quedarse colgado para siempre.

PRÓXIMOS PASOS

Una vez que tengas tu primer pago.

Con los pagos básicos funcionando, los seguimientos que más valen la pena son los controles de gasto (para que el agente no se lleve el presupuesto), la robustez de los webhooks (para que los pagos no se caigan silenciosamente bajo carga) y la verificación de identidad (para que las contrapartes confíen en la página pública del agente).

La referencia completa de la API se encuentra en docs.blockchain0x.com. Superficie de producto para las mismas APIs: API de Pagos.

Última revisión: 2026-05-15. Publicado bajo CC BY 4.0.

Una POST y tu agente está recibiendo el pago.

Gratis para comenzar. Claves de prueba incluidas. Primer pago confirmado en menos de diez minutos.