Skip to main content

Qué resuelve este producto

Una cuenta virtual de depósito BOB es un destino fijo de recepción vinculado a una cuenta CBPay. Tu pagador hace una transferencia bancaria normal en bolivianos a ese destino; CBPay detecta el abono, reconcilia la cuenta reportada y acredita tu cuenta mediante el flujo normal de payins. La cuenta es solo de recepción. No es una wallet, no crea una sesión de pago y el pagador no necesita incluir una referencia de anuncio.

1. Confirma el corredor

Usa siempre el catálogo vivo antes de activar una opción de pago:
La fila relevante es:
El catálogo es la fuente de verdad. Tu organización puede tener el corredor apagado aunque exista el contrato de la API.

2. Crea o repara el destino de recepción

Normalmente la cuenta recibe su instrumento BOB durante la provisión inicial. Este endpoint también sirve para reparar un instrumento faltante:
Respuesta 201:
Comparte instrument con el pagador como número de cuenta de recepción. instrument_id es el identificador estable de CBPay; no reemplaces el número de recepción por el UUID. Existe una sola cuenta activa por cuenta/país/moneda/método. Un segundo create no abre otro destino. Una respuesta ausente o ambigua queda visible para conciliación; el sistema no reintenta silenciosamente.

3. Lista los instrumentos

El listado es paginado y oculta los claims de provisión que aún no tienen un número real:

4. Recibe y concilia la transferencia

Este modo no usa el anuncio POST /v1/payins. El pagador transfiere BOB al instrumento indicado. El rail se consulta en una ventana de fechas acotada; los abonos completados se deduplican por la referencia bancaria, la orden ACH o una clave determinística de respaldo. Cuando el abono se concilie, suscríbete a payin_credited y usa el recurso payin para conocer monto y estado finales:
Se aplican la comisión normal y las reglas de conversión de payins. La API pública no expone el objeto específico del proveedor bancario.

Payouts BOB

Los payouts BOB mantienen el contrato provider-agnostic:
La organización define qué versión interna del rail está activa. Esa decisión no es un campo controlado por el cliente y queda guardada en la operación para que el polling posterior consulte el rail correcto. La respuesta y el webhook siguen siendo provider-agnostic.

Estados y recuperación

Después de un timeout, lee primero el listado. El proveedor puede haber aceptado la primera solicitud aunque la respuesta se haya perdido.

Errores

Preguntas frecuentes

No. El destino está vinculado a una cuenta CBPay y a una organización. Comparte solo el instrumento de esa cuenta.
No. Usa el flujo de transferencia de su propio banco. CBPay solo necesita que el destino esté activo y que el banco reporte el abono.
No. El instrumento es inmutable para su corredor. Si el proveedor reporta un problema, contacta a operaciones en vez de crear un reemplazo a ciegas.
El rail se consulta por polling. El tiempo final depende de cuándo el banco registre el movimiento; el webhook se emite después de la conciliación.
Última modificación el 9 de septiembre de 2026