Skip to main content
PayEn vivo

Una llamada gobernada.Cualquier riel.

Tu agente llama pay una vez. El runtime verifica el mandato, elige el riel — USDC vía x402, Pix en Brasil — y sella el recibo. El agente nunca nombra un proveedor; eso lo hace el router.

pay() · rastro de la llamada
Verificación de mandatoFirmadoOK
RouterPixSeleccionado
LiquidaciónR$142.50Asaas
Reciborcpt_9f2c1a4eSellado

Los nombres de los campos y la secuencia son reales — verificación de mandato, luego enrutamiento, luego liquidación, luego un recibo sellado. La fila de liquidación nombra un proveedor de Pix de salida: la línea de Pix de Mercado Pago crea un cobro de entrada, así que el router no la usa para pay.

El problema

Pagarle a un proveedor no debería tomar tres integraciones.

Enrutar dinero a un proveedor, un contratista, o un payout transfronterizo hoy significa conectar un PSP de Pix, un procesador de tarjetas y una wallet de stablecoin — tres SDKs, tres políticas de reintento, tres reportes de conciliación que hay que cuadrar a mano. Pay junta todo eso en una sola llamada.

Integración
Conectar tres SDKs separados — un PSP de Pix, un procesador de tarjetas, una wallet de stablecoin — cada uno con su propia autenticación y configuración.
Una llamada codespar_pay. El router ya habla con cada riel.
Reintentos e idempotencia
Cada riel reintenta y deduplica distinto — un timeout en una integración puede duplicar el pago en otra.
Una llamada gobernada, verificada contra el mandato antes de que nada se mueva.
Elección del riel
Tu código tiene que decidir de antemano qué riel llamar para cada destino.
El agente nunca nombra un riel — el router lo elige a partir del mandato y el destino.
Conciliación
Conciliar el gasto significa cuadrar recibos de tres dashboards distintos a mano.
Cada pago liquidado devuelve un recibo sellado, con la misma forma sin importar qué riel liquidó.
Cómo funciona

El mandato decide qué está permitido. El router decide cómo.

Una llamada, verificada contra el mandato firmado antes de que nada se mueva, y luego enrutada al riel que corresponda: USDC liquidando vía x402, Pix para BRL. USDC/x402 es un slot de la misma wallet; el riel de Pix corre en el mismo runtime, no es una integración aparte.

La llamada, paso a paso
1Tu agente llama pay() una vez — monto, destino, nada más.
2El runtime verifica la llamada contra el mandato firmado antes de que nada se mueva.
3El runtime resuelve el riel: el router elige el proveedor para Pix, tarjeta y USDC vía x402; un boleto liquida por su línea digitable.
4El riel liquida y un recibo sellado vuelve al agente.
En código

La llamada que tu agente realmente hace.

Tu agente llama pay una vez — monto, destino, y la referencia del mandato. No hay parámetro de proveedor que configurar. El runtime verifica la llamada contra el mandato firmado primero, porque el tope tiene que regir antes de que el dinero se mueva, no después — luego resuelve la llamada al proveedor que corresponda.

pay-supplier.ts
const session = await codespar.sessions.create({
  mandate: mandate.id,
});

const payment = await session.execute("codespar_pay", {
  input: {
    amount: 14250,              // R$142.50 in centavos
    currency: "BRL",
    destination: "supplier_8f21a",
    mandateRef: mandate.id,     // cap enforced before the call executes
    // no `rail` field — the router picks Pix, boleto, card, or USDC
  },
});

console.log(payment.result);
// → { receiptId: "rcpt_9f2c1a4e", rail: "pix", status: "settled" }
✓ rcpt_9f2c1a4e · settled via pix

codespar_pay es la misma llamada sin importar qué liquide por debajo — Asaas o Celcoin para Pix hoy, otro proveedor mañana, sin que el código de tu agente cambie.

Qué hace esta cadena de llamadas

  • El mandato se verifica antes de que la llamada se ejecute — gastar más allá del tope simplemente no pasa
  • Sin campo de proveedor — para Pix, tarjeta y USDC solo el router elige quién liquida
  • Vuelve un solo recibo, sin importar cuál rail realmente movió el dinero
Cobertura

Dónde está realmente cada riel.

Una regla para esta lista: lo que el código hace hoy, y hasta dónde se probó cada riel. Los pagos Pix se enrutan a los proveedores de salida de esta superficie, Asaas y Celcoin, y el failover se queda dentro del riel. La línea de Pix de Mercado Pago crea un cobro de entrada, así que el router la rechaza para pay. Boleto no pasa por el router: codespar_pay liquida un boleto existente en su propio camino de consulta y confirmación, ejercitado punta a punta contra el sandbox del proveedor. Tarjeta y USDC vía x402 están nombrados en la misma llamada gobernada. Cada fila dice lo que el código hace con ese riel; cuando un riel solo corrió contra el sandbox del proveedor, la fila dice sandbox.

Pix · Asaas
Transferencia de salida, enrutada por pay
Pix · Mercado Pago
Cobro de entrada, no ruteado por pay
Pix · Celcoin
Probado en sandbox
Boleto
Camino de liquidación, probado en sandbox
DDA
El proveedor no autorizó DDA en nuestras credenciales
Tarjeta
Nombrado en la llamada
USDC · x402
Base mainnet con opt-in del operador, Base Sepolia si no
Misma llamada, dos rieles

Una llamada codespar_pay, dos destinos distintos. El router lee el mandato y elige el riel — la llamada que escribe tu agente no cambia.

pay() · proveedor doméstico
Verificación de mandatoFirmadoOK
RouterPixSeleccionado
LiquidaciónR$3,200.00Asaas
Reciborcpt_7a41c9b0Sellado
pay() · payout transfronterizo
Verificación de mandatoFirmadoOK
RouterUSDCSeleccionado
Liquidación$1,240.00 USDCx402
Reciborcpt_4b7f9d21Sellado
Estado de los rieles
En vivo hoy
  • Pix se enruta a un proveedor de salida, Asaas o Celcoin, elegido por el router
  • Boleto liquida en su propio camino de consulta y confirmación, dentro de la misma llamada gobernada
  • Cada llamada se verifica contra el mandato antes de ejecutarse
  • Cada pago liquidado devuelve un recibo sellado y auditable
  • La facturación ya está activa para las primeras organizaciones, a la tarifa publicada
En camino
  • Pix vía Celcoin pasando de sandbox a liquidación en producción
  • Tarjeta y USDC/x402 confirmados en vivo en producción para cada cuenta
  • Facturación activada para cada organización, no solo el grupo del rollout
Precio

10 bps, piso R$0,05, tope R$2,00 por transacción.

Esa es la tarifa publicada para el dinero movido bajo mandato. La facturación se está activando org por org, todavía no se cobra universalmente — tu página de billing en el dashboard muestra si está activa en tu cuenta.

10bps
Tarifa
Sobre el dinero movido bajo mandato
R$0.05
Piso
Cargo mínimo por transacción
R$2.00
Tope
Cargo máximo por transacción
5
Rieles nombrados
Nombrados en una sola llamada gobernada

En vivoLos pagos Pix se enrutan a los proveedores de salida de esta superficie, Asaas y Celcoin.

FAQ

Pay, respondido

No lo elige. El agente llama pay una vez; el runtime elige el riel según el mandato y lo disponible, y sella el recibo.

No a través de Mercado Pago: su línea de Pix crea un cobro de entrada, así que el router no la usa para pay. codespar_pay enruta Pix a un proveedor de salida, Asaas o Celcoin, y Celcoin está probado en sandbox, todavía sin liquidar tráfico de producción.

Pix, boleto, tarjeta y USDC vía x402 están nombrados en la misma llamada gobernada. Hasta dónde se probó cada uno varía por riel, y la sección de cobertura de esta página dice cuál es cuál.

El mandato — verificado antes de que la llamada se ejecute, no después.

La tarifa publicada es 10 bps, piso R$0,05, tope R$2,00 por transacción. La facturación se está activando cuenta por cuenta.

No. Los agentes nunca nombran un proveedor — eso lo hace el router, y cada decisión queda auditada.

La llamada falla en modo seguro. Nada liquida fuera del mandato, y la falla queda registrada en el recibo igual que quedaría un éxito.

No. CodeSpar mantiene las conexiones con los rieles; tu agente solo llama pay.

Paga cualquier cosa con una llamada gobernada.

El mandato decide qué está permitido; el router decide cómo.

pay: Los pagos Pix se enrutan a los proveedores de salida de esta superficie, Asaas y Celcoin.

Pay — una llamada gobernada que paga cualquier cosa | CodeSpar | CodeSpar