Skip to main content
Un payout envía dinero en moneda local a una cuenta bancaria del país destino. El monto se convierte de moneda local a USDT con la tasa de tu cuenta (la de GET /v1/rates) y se debita usdt_amount + fee (el fijo, si está configurado) de tu saldo. Así se ve el ciclo completo, incluido qué pasa con tu saldo en cada paso:

1. Descubre los corredores disponibles

Los países, monedas y métodos disponibles los define CBPay. Consúltalos siempre por catálogo:
Corredores y métodos disponibles: La disponibilidad puede variar; el catálogo (GET /v1/payouts/methods) es siempre la fuente de verdad. Si un país tiene un solo método, method es opcional. Todos los métodos se cobran igual: tu tasa + fijo. Para transferencias bancarias necesitas además el catálogo de bancos (de ahí sale el bank_code del beneficiario):

2. Crea el payout

beneficiary es un objeto de pares clave/valor cuyos campos requeridos dependen del corredor (RUT y banco en Chile, CLABE en México, CCI en Perú, llave PIX en Brasil, etc.). El catálogo de métodos documenta los campos de cada uno.
Cada payout guarda al beneficiario como contacto automáticamente ("save_contact": false para no guardarlo). Para repetirle un pago sin re-tipear sus datos, envía "beneficiary_contact_id" en vez de beneficiary — se usa su beneficiario guardado más reciente para ese país y método (422 no_saved_destination si no tiene).
Respuesta 202 Accepted:
En ese momento tu saldo ya refleja el débito: total_debit pasó de available a held (en el saldo del settlement_asset).
bank_reference — el id propio del banco para la transferencia. En US ACH, wire y SWIFT es la referencia CBF que vuelve de inmediato al crear (el payout sigue processing hasta que el banco confirma). En el resto de corredores queda vacio ("") hasta completed. Mientras el payout está en curso viene vacío (""); cuando el payout queda completed, lleva el id de transacción asignado por el banco/rail de destino. Es el valor que el beneficiario puede usar para cruzar el pago con su banco, y también aparece en el webhook payout_status_changed, el comprobante PDF, el export CSV de payouts y la cartola.

Pagar desde otro saldo (settlement_asset)

Por defecto el débito sale de tu asset de settlement predeterminado (USDT salvo que lo cambies con PUT /v1/settlement). Para pagar una operación puntual desde otro saldo, agrega settlement_asset al request. Ejemplo: un payout de 100.000 CLP pagado desde el saldo BTC pasa por cuatro transformaciones, todas registradas en la respuesta:
  1. CLP → USDT a tu tasa: 100000 / 950.25 = 105.235465 USDT.
  2. + comisión fija: 105.235465 + 0.30 = 105.535465 USDT (total_debit).
  3. USDT → BTC al precio efectivo de settlement (settlement_rate 109029.34070000): 105.535465 / 109029.3407 = 0.00096795 BTC (redondeo hacia arriba al satoshi).
  4. Débito y hold en BTC: settlement_amount 0.00096795 sale de tu saldo BTC; el beneficiario recibe sus 100.000 CLP igual que siempre.
Si el payout falla, se reembolsa el settlement_amount exacto a tu saldo BTC — nunca se re-cotiza. Si el precio de ejecución de BTC/GOLD no está disponible en ese momento recibirás 503 pricing_unavailable, y los assets volátiles tienen un límite por operación (422 settlement_limit_exceeded; consúltalo en GET /v1/settlement).

3. Recibe el estado final

Suscríbete al evento payout_status_changed (webhooks):
  • completed: el dinero llegó; el hold se consume.
  • failed: se reembolsa el débito completo automáticamente (payout_refund en tu ledger).
También puedes consultar en cualquier momento:

Estados del payout

Consulta e historial

Cada payout se puede leer individualmente y el listado acepta filtros:
from/to van en YYYY-MM-DD (zona horaria de tu organización, ambos inclusive); una fecha inválida responde 400 invalid_range.

Ejemplos por país

Cada corredor con su beneficiary exacto, el request completo y la respuesta real. Las tasas (fx_rate) son ilustrativas — siempre aplican las de tu cuenta en GET /v1/rates; el débito es usdt_amount + fee (fijo, si está configurado; aquí 0.30).

Campos del beneficiary por corredor

Transferencia bancaria en CLP. Requiere RUT, banco y cuenta:
El catálogo de bancos (GET /v1/payouts/banks?country=CL) da los bank_code vigentes.

Documento de respaldo obligatorio en transferencias USD

TODA transferencia saliente en USD por rail bancario (ach, wire o swift) exige un documento de respaldo (factura o recibo) adjunto — es un requisito del banco procesador y aplica a cualquier corredor USD, no solo al de EE. UU. (por ejemplo, también a un SWIFT internacional como PY/USD/swift).
1

Sube el documento

Envía el archivo con POST /v1/payouts/documents: binario crudo con su Content-Type (PDF, PNG, JPEG, WEBP, TXT, CSV, DOC(X) o XLS(X), hasta 50 MB) y el nombre del archivo en el query param name.
2

Pásalo al crear el payout

El document_key viaja en options.supporting_document_key. En ach/wire puedes agregar options.document_reference_number (número de factura o referencia del documento) — se envía al banco.
  • Un payout USD por rail bancario creado sin el documento se rechaza al crear con 400 supporting_document_required (sin débito).
  • Una key subida por otra cuenta se rechaza con 400 invalid_document_key.
  • La document_key queda almacenada: si el create falla por otra causa, la reutilizas en el reintento — no necesitas re-subir el archivo.

Payout QR

Pagar un QR de cobro (Bolivia, PIX de Brasil) ahora tiene su propia guía:

Payout QR

Escanea el QR gratis, muestra a tu usuario los datos del destinatario y confirma el pago en una segunda llamada — se cobra como un payout normal.

Errores frecuentes

Rechazo inmediato vs fallo posterior

Si el procesador rechaza el payout al crearlo, recibes 422 con el objeto en status: failed y el reembolso ya aplicado. Si falla después (por ejemplo, cuenta destino inexistente detectada por el banco), te llega el webhook con status: failed y el reembolso automático en ese momento.

Cómo leer status_code en un payout fallido

En todos los casos el reembolso ya está aplicado — verifícalo con la entrada payout_refund en movimientos.
Un payout en processing no se puede cancelar por API: el rail ya lo tiene. Espera el estado final por webhook o GET — llega siempre, con reembolso automático si falla.

FAQ

Al crear: el payout debita y retiene los fondos de inmediato. Si el payout falla, el monto exacto debitado (comisión incluida) se reembolsa automáticamente.
No — una vez despachado al riel se resuelve solo a completed o failed. Suscríbete a payout_status_changed para el estado final.
La tasa cotizada al crear (devuelta como fx_rate), congelada para esa operación. Tu spread acordado ya viene dentro de la tasa.
Sí — fija un default por cuenta (PUT /v1/settlement) o sobreescribe por payout con settlement_asset (USDC, BTC, GOLD). Los reembolsos devuelven el monto liquidado exacto, jamás se re-cotizan.
El beneficiario no pasó el screening de compliance: el payout no se creó y tu idempotency_key no se consumió. Revisa los datos del beneficiario o contacta a tu equipo CBPay.
Reintenta con la misma idempotency_key: recibes el payout original (idempotency_hit: true) — jamás un duplicado. Una clave nueva es un payout nuevo e independiente.
Los payouts del riel bancario US los paga el operador a mano. El create ya trae el CBF en bank_reference y queda processing hasta que el banco confirma. Escucha payout_status_changed para el estado final; un fallo reembolsa el debito solo.
Última modificación el 13 de agosto de 2026