BOB, pago por QR) y cuentas a nombre de un cliente en las monedas habilitadas por sus verificaciones. Todos los endpoints de esta página requieren un JWT Bearer.
Endpoints
clientId, subjectId e id deben ser UUID válidos. Para dar de alta un cliente, usa POST /v2/business-clients.
Cuenta del partner en Bolivia
201 contiene una cuenta virtual con owner.type: "business" y paymentMethods: ["qr"]:
409. Un cuerpo inválido responde 400. Las cuentas de clientes se generan a partir de verificaciones aprobadas; no se crean mediante este POST.
Listar y consultar cuentas
Sin filtros, el listado devuelve solo cuentas nominadas de clientes, no la cuenta
BOB del partner. Para incluir esta última, consulta ?currency=BOB. La combinación currency=BOB con clientId devuelve una lista vacía porque la cuenta BOB pertenece al partner. La respuesta siempre tiene la forma { "virtualAccounts": [...] }.
GET /v2/virtual-accounts/{id} devuelve el mismo objeto, pero solo admite cuentas del partner. Si el UUID no corresponde a una cuenta del partner autenticado, responde 404. Para cuentas de clientes, usa el listado con clientId.
Campos de la cuenta
En
coordinates, holder incluye name, type y address; bank es opcional y contiene name y address. Según la moneda y el riel, pueden aparecer iban, accountNumber, swiftCode, taxId y routingNumbers (ach, wire, rtp). Comprueba status y la presencia de los datos requeridos antes de mostrar instrucciones de pago.
Cuentas nominadas de clientes
- Crea el cliente con
POST /v2/business-clients. Puedes elegirsettlementNetwork(EthereumoPolygon) ysettlementAsset(USDCoUSDT); los valores predeterminados sonPolygonyUSDC. - Completa su onboarding y solicita las verificaciones para las monedas en las que cobrará.
- Obtén un enlace para cada sujeto con datos pendientes. Cuando se aprueban las verificaciones, la cuenta nominada se crea automáticamente.
- Consulta
GET /v2/virtual-accounts?clientId={clientId}para recuperar sus instrucciones de cobro. En Sandbox, registra la dirección de retiro para probar la liquidación.
Solicitar y consultar verificaciones
EUR, USD, AED, AUD y GBP. Para acotar la solicitud, envía un arreglo no vacío:
200 con las verificaciones solicitadas y las monedas que no pudieron habilitarse:
GET /v2/business-clients/{clientId}/endorsements devuelve directamente un arreglo de verificaciones con la misma estructura que endorsements. Los estados de verificación son pending, dataRequired, inProgress, inReview, approved y rejected; los del sujeto son pending, inReview, approved y rejected. requestedAt, resolvedAt, rejectionReason, name y linkIssuedAt pueden ser null. Cada subjects[].pending contiene arreglos fields y documents.
Si failed contiene elementos, cada uno incluye currencies y reason: termsNotAccepted, verificationNotApproved, notAvailableForAccountType, alreadyRequested o unavailable. Esa moneda requiere revisar la causa; no avanza automáticamente.
Emitir el enlace de un sujeto
Usa elid del sujeto devuelto por el endpoint de verificaciones:
404 cuando el cliente no existe o no pertenece al partner; el enlace también responde 404 si no existe el sujeto.
Dirección de retiro en Sandbox
0x seguido de 40 caracteres hexadecimales). PUT reemplaza la dirección activa y devuelve 200:
GET /v2/business-clients/{clientId}/withdrawal-address devuelve ese objeto o null si aún no hay dirección. Ambos endpoints están disponibles solo en Sandbox. La red devuelta corresponde a la elección hecha al crear el cliente. Comprueba la dirección antes de registrarla: la validación de formato no demuestra que el cliente la controle.
Ambas rutas responden 404 si el cliente no existe o no pertenece al partner.
Notificaciones de cobro
Los cobros registrados por cuentas virtuales pueden generar una transacción contransactionType: "deposit_virtual_account". Sus cambios de estado se notifican mediante el webhook de transacciones. En details, amount es un string y currency indica la moneda fiat. details.payer aparece solo si existe un detalle de pagador registrado; consulta Datos del pagador.