Novedades

​

v2.166

• Los payouts US/USD ach, wire y swift ahora exigen un valor explícito del catálogo de propósito, con purpose_detail solo para Other; wire también exige beneficiary.account_type. Se agregan errores accionables pre-débito y se documenta la eliminación incompatible del default al crear.
• Los pagos de gastos aceptan el propósito al pagar y las exportaciones de gastos soportan XLSX auditado y brandeado por organización, con los mismos filtros del listado. Corregido
• Las fallas conocidas de beneficiario, monto, mínimo, país y propósito ya no salen como invalid_payload opaco: usan códigos estables y mensajes con el campo.

​

v2.165

• La detección de payins BO/BOB/bank_transfer ahora es push-first: las notificaciones de transferencia confirman los abonos al llegar, con el sondeo de extractos como respaldo idempotente. GET /v1/payins/methods reporta delivery: "push+polling" en este corredor. No cambió ningún endpoint, campo, error ni webhook — las integraciones siguen recibiendo el mismo evento payin_credited.

​

v2.164

• Las lecturas de vIBAN y wallets de empresa ahora conservan un last_error accionable y agnóstico del proveedor cuando existe de forma segura una causa upstream de autorización. No cambian el status HTTP, el código, la forma de la respuesta ni las reglas de reintento y reconciliación.

​

v2.163

• Multi-banking empresa para cuentas de depósito BO/BOB, MX/MXN y AR/ARS, con labels, tope blando de 50 por corredor, lecturas exactas de saldo y movimientos, e intents banking para KYC/KYB de terceros.
• Selección explícita de source_instrument_id para payouts y confirmaciones QR BO/BOB, con errores fail-closed de ownership y ambigüedad. Cambiado
• Las CVU empresa AR pueden diferir el alias; las lecturas operativas quedan bloqueadas con alias_pending hasta definirlo.

​

v2.162

• Los swaps BTC de USD 1.000 o más ahora usan un price guard antes de ejecutar. Una divergencia responde 422 guard_diverged; si el mercado no está disponible, la operación sigue con alerta y conserva las protecciones del precio de ejecución.
• Se documentó el guard y su error en la guía y el catálogo de errores. Las conversiones internas de checkout/payin y los flujos OTC quedan fuera.

​

v2.161

• Se agregó la recuperación de contraseña de members iniciada por el admin: POST /v1/auth/password/reset-link canjea un link de un solo uso de 60 minutos, verifica el email, limpia el registro pendiente y revoca todas las sesiones. El trigger admin devuelve link_sent con el portal configurado y conserva el fallback honesto code_sent cuando no lo está.
• El registro ahora devuelve pending_verification sin sesión; confirma el email con POST /v1/auth/register/confirm. Se documentaron también los límites por cuenta de login y recuperación.

​

v2.160

• Nuevos corredores públicos provider-agnostic para PY/PYG, CO/COP y EC/USD: payouts bancarios y payins hosted o wallet; COP es entero y se documentan los campos de identidad del pagador.
• Las descargas PDF de sobres aceptan ?lang=es|en; el detalle expone available_langs, las contrapartidas se renderizan desde el snapshot congelado sin hash aparte, el ingl?s exige counsel y se documentan filenames seg?n idioma y errores fail-closed de storage.

​

v2.159

• La confirmación de recepción de payins manuales EC/USD push bank_transfer ahora es maker-checker de dos pasos: POST /v1/payins/{payinID}/confirm-received abre una solicitud pendiente sin acreditar, POST /v1/payins/{payinID}/confirm-approve la aprueba (god distinto del maker) y acredita, y POST /v1/payins/{payinID}/confirm-cancel la descarta; nuevos códigos confirm_request_conflict y confirm_account_mismatch (HTTP 409).

​

v2.158

• POST /v1/otp/challenges acepta el campo opcional channel (sms, whatsapp, email o totp). Si se omite, el servidor lo resuelve desde tu preferencia OTP, el default de la organización o SMS. La respuesta devuelve el channel resuelto más el destino enmascarado en phone (email enmascara la dirección; TOTP devuelve el literal authenticator_app).
• La creación del challenge ahora puede responder 400 invalid_channel para valores desconocidos y 403 channel_locked_by_org cuando el canal explícito es más débil que el piso de la org para la acción (el piso solo eleva el canal, nunca lo baja). Elegir channel explícito además desactiva el fallback automático a otro canal.

​

v2.157

• Se agregó soporte para payouts manuales EC/USD/bank_transfer. Los payouts elegibles nacen en processing con status_code=manual_dispatch; el operador confirma la liquidación bancaria mediante POST /v1/org/treasury/manual-payouts/{payoutID}/confirm-manual-paid, enviando bank_reference, paid_amount, reason e idempotency_key. El monto pagado debe coincidir exactamente y el replay con la misma clave es seguro.
• Se agregó soporte para payins anunciados EC/USD/bank_transfer. Operaciones puede confirmar la recepción mediante POST /v1/payins/{payinID}/confirm-received, enviando la referencia bancaria y el monto recibido; solo se confirman payins anunciados pendientes elegibles y un replay equivalente devuelve idempotency_hit: true.

​

v2.156

• Se agregó protección provider-agnostic ante rechazos recientes del destino: un rechazo bancario devuelve 422 destination_recently_rejected antes de crear o debitar; un reintento deliberado usa una clave nueva y options.destination_retry_ack.
• Verificación pública de contratos: GET /verify/contracts/{code} devuelve una declaración de autenticidad firmada para un contrato marco de Grupo CB (JSON por defecto, página HTML humana con Accept: text/html). Sin credenciales; los códigos inválidos responden un 404 genérico; limitado por IP. Ver /es/guides/contract-agreement.
• El JSON del sobre del contrato (detalle de cuenta y de org) ahora expone verify_code: el código público impreso en el bloque de verificación del PDF final (QR + caption con el hash corto del documento).

​

v2.154

• Nuevo hub de Fondeo: una guía para cada cuenta de fondeo por moneda (ARS, BOB, MXN, EUR), con la separación fondeo-vs-banking, creación y lectura. Cambiado
• Contenido de depósito de cuentas virtuales BO fusionado al hub de Fondeo; la sección de payouts BOB se movió a la guía de payouts. Removidas las guías standalone de BO y de company-wallets; los redirects apuntan a los nuevos hogares. Solo docs: ningún cambio de comportamiento en la API.

​

v2.153

• Reestructurada la guía Banking alrededor de los dos tipos de destino fiat local: cuentas de fondeo (purpose fondeo, conversión automática a tu saldo principal) versus cuentas Banking (purpose banking, que conservan saldos BOB, MXN y ARS para payouts), seguida de una sección por moneda (USD, EUR, BOB, MXN, ARS) con enlaces a payins, payouts, SEPA, vIBANs y las vistas de cuenta. USD se documenta en todas partes como el saldo principal, cambiable cuando quieras con PUT /v1/settlement. Solo docs: ningún cambio de comportamiento en la API.
• Corregidas guías y specs contra el comportamiento implementado: el estado de cuenta solo se pide con el parámetro format (sin header Accept); una conversión fallida conserva los fondos en el asset recibido; los cobros con tarjeta aprobados se liquidan en USD; y el tope de sesiones de tarjeta abiertas es 10.000. Solo docs: ningún cambio de comportamiento en la API.

​

v2.152

• Reescritura del modelo de dinero y guías relacionadas en torno a USD como moneda principal: las cuentas nuevas liquidan en USD, las legacy conservan USDT, y los diez assets del ledger (USD, USDT, USDC, BTC, GOLD, SILVER, PLATINUM, BOB, MXN, ARS) se listan en orden canónico con sus decimales reales. Transfers, payins, checkout, refunds, swaps, cartola, fondeo banking, analytics y el FAQ describen ahora el comportamiento que implementa la API. Solo documentación: sin cambios de comportamiento de la API.
• Toda la temática euro consolidada en una sola sección Banking EUR: IBAN virtuales de fondeo (funding_usdt) y de banca (banking_eur), cómo solicitarlos y leerlos, solicitudes de terceros, el saldo BANK_EUR, envío y recepción SEPA, errores y FAQ. La página de payouts SEPA y la sección de saldo de company-wallets ahora apuntan a esa fuente única en vez de repetirla. Solo documentación: sin cambios de comportamiento de la API.

​

v2.151

• Índice de errores público ampliado con handoffs de ambiente (invalid_handoff, handoff_replayed), 2FA y passkeys (channel_locked_by_org, passkey_exists, totp_already_enrolled) y documentos de checkout/payouts (materializing, invalid_file_name, unsupported_media_type), cada uno con su status HTTP y solución. Solo documentación: sin cambios de comportamiento de la API.

​

v2.150

• Se agregaron firmas manuscritas del cliente a los sobres contractuales. El endpoint de firma acepta el PNG Base64 requerido signature_png, con prefijo opcional data:image/png;base64,, y devuelve 422 invalid_signature_image para imágenes inválidas o en blanco y para incumplimientos de tamaño, dimensiones o píxeles con tinta. Las firmas válidas se incrustan en el bloque Cliente del PDF final; el detalle del sobre solo expone el booleano has_client_signature y los sobres legacy conservan su render textual.

​

v2.149

• Se incorporó la plantilla v13.4 del Contrato Marco Grupo CB al flujo de contratos de cuenta. La versión en español es la vigente; la versión en inglés sigue como draft pendiente de revisión externa.
• El detalle del contrato expone template_version congelado y los events append-only del ciclo de vida. Firmar falla cerrado con 422 contract_template_superseded si el sobre nació con una plantilla anterior; se debe anular y emitir un sobre nuevo, no firmarlo.

• El contrato legal en español elimina Colombia, agrega la fila PIX, documenta la latencia p95/p99 del acuse de recepción de instrucciones vía API y fija el corte diario en 00:00 UTC para el día siguiente.

​

v2.148

• Los payouts por transferencia bancaria CL/CLP ahora rechazan los montos no enteros con HTTP 400, código invalid_amount y el mensaje amount must be a whole number of CLP (this currency has no minor unit) antes de cualquier débito, retención, recurso payout o despacho. Los montos enteros como 30000 y 30000.00 siguen siendo aceptados. Esto reemplaza el resultado anterior core_rejected / invalid payload posterior al débito para este caso de validación.

​

v2.147

• Se agregaron actualizaciones del banking intent para submissions KYC/KYB administradas por la organización.
• Se agregaron los errores públicos unsupported_document_type e invalid_document_file para cargas de documentos bancarios.

​

v2.146

• Se agregó idempotencia opcional para payins QR: la misma clave con un payload equivalente repite el cobro original con idempotency_hit: true, mientras que un payload distinto devuelve 409 idempotency_conflict.
• Se documentaron 400 invalid_idempotency_key, la precedencia entre body y header, y la consulta del estado vivo al repetir un cobro.

​

v2.145

• Se agregó la vista del Contrato Marco para empresas verificadas en el portal: las listas de sobres usan la colección existente items y el detalle expone la colección append-only events, con el nombre de cada evento en event.
• El email de notificación del sobre ahora incluye el botón Ir a firmar y el enlace del portal en texto plano /contracts/{envelopeID}; el PDF prefirmado sigue adjunto.

• Se rediseñaron los PDFs contractuales con branding de la organización, portada de página completa, badge de estado y pies de página.
• El Contrato Marco Grupo CB ahora usa la plantilla v13.3. El cuerpo ya no presenta una tabla plana de precios fijos; el Anexo A apunta al Programa de Comisiones vigente del Cliente y agrupa las entradas aplicables con labels localizados como Pagos fiat, Compliance, Tarjetas, Banking, Wallets y Otros.
• No cambiaron las rutas API, llaves de respuesta, códigos de error ni tipos de webhook.

​

v2.144

• Se actualizó el Contrato Marco Grupo CB a la plantilla v13.2. La emisión org-admin falla cerrado con 422 contract_unfillable y un array missing cuando falta cobertura de precios efectiva; el snapshot visible para la cuenta y el apéndice de precios del PDF omiten los spreads internos, mientras que la vista org-admin conserva el snapshot completo. Al completar la ceremonia del cliente también se registra automáticamente el hito contract_signed.

​

v2.143

• Se agregó la ceremonia del Contrato Marco Grupo CB para cuentas empresa verificadas: lista/detalle/PDF/firma de sobres, sesión humana, consentimiento, OTP de un solo uso en X-OTP-Token, evento contract_envelope_completed y errores accionables.

​

v2.142

• Se agregó metadata del instrumento de depósito dedicado (instrument_id e instrument) en las respuestas de lista/detalle de payins, el filtro de listado instrument_id y los webhooks payin_credited. Los nuevos pushes acreditados también pueden exponer la identidad payer reportada por el banco; los campos ausentes se mantienen honestamente omitidos. La identidad de una cuenta dedicada pasa por el flujo de screening existente y puede quedar en revisión.

​

v2.141

• Se documentó el bank_alias argentino elegido por el usuario y obligatorio al crear cuentas AR/ARS en la plataforma, la ruta de rename PUT /v1/payins/deposit-accounts/bank-alias, su formato y el 422 alias_taken accionable, además del alias de perfil derivado del nombre verificado.

​

v2.140

• Se documentaron direct y batched como variantes de despacho con scope de organización para el corredor CL/CLP/bank_transfer en el schema público de variantes. direct sigue siendo el default efectivo cuando no existe una fila de selector; batched queda sujeto al gate global de ambiente.

​

v2.139

• Se documentó que un payin QR de Bolivia pagado puede exponer la identidad del pagador reportada por el banco en GET /v1/payins/{payinID} mediante payer_source: bank_event y los campos opcionales de payer. No se agregaron endpoints, códigos de error ni webhooks.

​

v2.138

• Los payouts ARS y USD aceptan un alias bancario en beneficiary.account_number; la plataforma lo resuelve antes de despachar y mantiene USD solo para CBU.
• Las respuestas de cuentas de depósito AR/ARS pueden incluir el campo opcional details.bank_alias junto al CVU de 22 dígitos.

​

v2.137

• La documentación de emisión de tarjetas ahora incluye los overrides opcionales cardholder.first_name y cardholder.last_name para el nombre impreso. Si se omiten, los completa el perfil KYC/KYB aprobado; los valores explícitos ganan y su longitud UTF-8 combinada está limitada a 22 bytes.

​

v2.136

• Se actualizó el esquema público de configuración de comisiones para incluir banking_monthly y eliminar el valor obsoleto compliance_transaction. El detalle del pricing de organizaciones sigue en la API privada de admin.
• El modelo de pricing admin ahora cobra banking_return tras la conciliación exitosa, con idempotencia por operación.

​

v2.135

• Se aclaró que las operaciones de Client Journey pertenecen a la documentación privada de administradores de organizaciones; esta versión pública no agrega endpoints ni flujos para cuentas.

​

v2.134

• Los payouts SEPA y los retiros EUR Banking ahora debitan desde el vIBAN seleccionado del cliente; la cuenta de tesorería ya no se usa como origen.

​

v2.133

• Banking EUR ahora usa el flujo directo de vIBAN. Las cuentas pueden solicitar un vIBAN banking_eur sin crear primero un customer Banking genérico.
• El onboarding genérico de Banking es solo para USD; enviar currency: "EUR" devuelve banking_eur_requires_viban y dirige al integrador a Operar EUR.

​

v2.132

• Las cuentas nuevas son USD-principal: settlement_asset y payin_settlement_asset usan USD por defecto. Las cuentas legacy con una configuración explícita en USDT no cambian y las operaciones en vuelo no se vuelven a cotizar.
• Se agregó USD a las superficies de settlement, payin, swap, checkout/POS y tarjetas donde el campo lo acepta. Los montos USD del ledger usan dos decimales y los swaps USD↔USDT usan paridad 1:1.
• Las respuestas de controversias distinguen el activo retenido de sus equivalentes normalizados mediante hold_asset, disputed, held, disputed_usdt y held_usdt.

​

v2.131

• Se documentaron los errores de validación de payouts argentinos invalid_cuit e invalid_cbu (HTTP 400). Envía un CUIT/CUIL de 11 dígitos en beneficiary.tax_id y un CBU/CVU de 22 dígitos en beneficiary.account_number; para USD se exige CBU. Consulta los errores de payouts.

​

v2.130

• Los retiros EUR Banking por SEPA ahora aceptan los campos estructurados de nivel superior beneficiary_type, beneficiary_given_name, beneficiary_first_surname, beneficiary_middle_name opcional y beneficiary_name para empresas. La plataforma los reenvía como parte del request de la operación para resolver la identidad del beneficiario antes del despacho; los demás rieles bancarios pueden omitirlos.

​

v2.129

• Los destinos de depósito ahora exponen purpose: fondeo (por defecto, convierte el fiat a USDT) o banking (conserva el fiat local para payouts). Banking se limita a BO/BOB, MX/MXN y AR/ARS bank_transfer; los valores inválidos devuelven invalid_purpose.

​

v2.128

• Los payouts fiat en BOB, MXN y ARS ahora pueden debitar el saldo fiat local de la misma moneda. El settlement de la misma moneda usa tasa 1 y spread cero. El settlement cross-fiat responde pricing_unavailable y los montos con más de dos decimales fiat responden invalid_amount. GET /v1/rates marca estos assets con same_currency_only: true.

​

v2.127

• Se documentaron los errores públicos de límites money-out: amount_below_minimum, amount_above_maximum y velocity_limit_exceeded. La organización configura estos controles; sin límites no hay restricciones nuevas.

​

v2.126

• Se agregaron retenciones de payins en fiat local por cuenta para BOB, MXN y ARS, con payloads conscientes del activo.

​

v2.125

• Se agregaron BOB, MXN y ARS como activos fiat del ledger con dos decimales. Balances, history y analytics los exponen; las transferencias del mismo asset siguen soportadas y swaps, tarjetas, checkout y POS mantienen sus rechazos explícitos de v1.

​

v2.124

• Las organizaciones ahora pueden habilitar, mediante su operador de plataforma, un nuevo riel interno de cobros QR BOB. El request público POST /v1/payins, la respuesta opaca charge y el webhook existente payin_received no cambian; la disponibilidad se controla por organización y el integrador no selecciona el riel.

​

v2.123

• Se aclaró que este follow-up del OTC Desk es exclusivo para administradores de organización. No cambió ninguna guía pública de integración, contrato de endpoint ni comportamiento de webhook para clientes; la guía pública OTC Desk queda N/A.

​

v2.122

• Se agregó en la referencia API el callback del OTC Desk de Telegram (POST /v1/public/telegram/otc-desk/{orgID}/webhook). Lo llama Telegram; no es un webhook de integración para clientes y el Desk no emite un evento webhook nuevo.

​

v2.121

• Corregida la puerta de origen SEPA: los payouts de clientes requieren un IBAN virtual funding_usdt asignado y activo, mientras los retiros EUR Banking usan banking_eur.
• Documentadas la selección determinista, la identidad ordenante server-side desde el registrant del vIBAN, el fallback de perfil legacy y los resultados funding_account_unavailable / registrant_incomplete.

​

v2.120

• La documentación de tasas payin ahora expone payin_rate_source (lot o spot) y el rate_source opcional en create/detail de payin. El inventario FIFO USDT se consume al acreditar; un faltante cae a spot sin cambiar el crédito cotizado.

​

v2.119

• Los payouts SEPA Instant ahora exigen un IBAN virtual funding_usdt asignado y activo para cuentas cliente. Usa el parámetro opcional source_virtual_iban_id cuando existan varias cuentas EUR activas; la identidad ordenante sale del registrant del vIBAN elegido.
• Se documentan los resultados funding_account_required, ambiguous_source_viban y funding_account_unavailable.

​

v2.118

• Flujo deposit-first en el portal: En /payins/new, Bolivia (BO) y México (MX) ahora muestran siempre la cuenta de depósito dedicada, igual que Mis cuentas. Si no existe un instrumento dedicado, el portal muestra un estado vacío honesto con instrucciones para crear la cuenta o completar la verificación; ya no ofrece las opciones de pagador de una transferencia anunciada para estos corredores. Las rutas y los shapes de la API no cambian, y los integradores todavía pueden usar el POST /v1/payins anunciado.

​

v2.117

• La guía de payouts bancarios US/USD ahora exige un documento de respaldo en PDF para los flujos ach, wire y swift. La acción de liberación manual es exclusiva del operador y no forma parte de la API pública del integrador; la creación y el ciclo existente de estados/webhooks no cambian.

​

v2.116

• Se aclaró el contenido de los packs de evidencia de disputas generados por la organización: incluyen detalles de la operación de tarjeta para payins card, destinos de gastos FIFO e identidad KYB/KYC verificada completa del comercio; el pagador permanece enmascarado y se excluyen payloads crudos/ campos adyacentes al PAN.

​

v2.115

• Etiquetas y orientación de Mis cuentas: la pestaña Fiat ahora se llama Fiat a Crypto; conserva el slug ?tab=fiat. Las pestañas Crypto, Fiat a Crypto y Banking ahora incluyen intros breves y una línea que indica que las cuentas receptoras son únicas de la cuenta y no compartidas. Cuando un icono representa una red, TRON y Ethereum usan sus iconos de red en vez del icono del activo. No cambian las rutas ni los shapes de la API.

​

v2.114

• Recuperación de verificación controlada por administrador: POST /v1/me/verification/link ahora responde 403 account_blocked si un administrador desactivó o cerró la cuenta, y 403 verification_rejected_requires_admin si un administrador rechazó su KYC/KYB. El titular debe contactar al administrador para restaurar la cuenta o reabrir la verificación; las cuentas que aún esperan verificación (none o pending) no se ven afectadas, y las cuentas approved siguen respondiendo 409 already_verified.

​

v2.113

• La guía de payout QR ahora documenta el contrato sincronizado de dos pasos: lectura sin débito, confirmación idempotente, settlement_asset opcional y reconciliación por el payout existente cuando el estado queda transitorio.

​

v2.112

• Operaciones de disputas solo con payins acreditados: la apertura individual y la vinculación manual de filas importadas ahora responden 409 payin_not_credited si el payin no está credited; no se crea una retención. Batch e importación reportan la condición por ítem o fila.

​

v2.111

• Los administradores de la organización pueden previsualizar y confirmar la apertura de disputas desde una lista pegada de identificadores de payin. El flujo resuelve coincidencias exactas, muestra ambigüedades antes de retener, abre solo payins acreditados y devuelve resultados idempotentes por ítem.

​

v2.110

• Se agregó el panel de fraude y disputas: rutas de cuenta de solo lectura, operaciones org-admin, retenciones preventivas, cierres maker-checker, importación de planillas, packs inmutables y dispute_status_changed.
• Se agregaron analytics disputes, saldo disputed y cartola disputes[]. El worker de deadlines avisa T-7/T-3/expired sin mover dinero al vencer.

​

v2.109

• Mis cuentas F2: la página /accounts ahora usa selectores visuales para Crypto (moneda → red), Fiat (país → ficha de datos para transferir) y Banking (país → cuenta). Las cuentas Banking de Estados Unidos se agrupan en subpestañas ACH, Wire y SWIFT.
• El hero de la cuenta muestra foto/nombre del titular cuando están disponibles, el alias y el QR de la cuenta. Las fichas Crypto y Banking pueden mostrar un QR con el símbolo de branding de la organización; las fichas Fiat no tienen QR por diseño.
• Las fichas Fiat exponen titular, banco, NIT mercantil de BO y número receptor cuando la API los devuelve, con copia por campo y Copiar todo. La pestaña y el destino se pueden enlazar mediante ?tab=&sel=.

• Las respuestas de cuentas de depósito agregan los campos opcionales alias, merchant_nit y bank_name. Solo aparecen cuando los entrega el riel receptor; el cliente no debe inferir valores faltantes.

​

v2.108

• Las integraciones de cuenta agregan GET /v1/integration-status y exigen KYB aprobado para empresas o grant vigente para personas. Se documentan la sesión humana y el OTP correspondiente.
• Registro, creación OAuth con email verificado y cambio de email documentan la política global email_domain_blocked.

​

v2.107

• Las respuestas de payouts, payout_status_changed, CSV y comprobantes ahora exponen uetr e imad como campos aditivos cuando están disponibles.
• La guía de payouts explica su relación con la confirmación bancaria y el tracker público de transacciones.

​

v2.106

• Navegación de Mis cuentas: el hero CBPAY ahora lleva a tres pestañas con deep-link: Crypto para wallets de depósito, Fiat para MX/CLABE, BO/BOB e instrumentos EUR de fondeo, y Banking para cuentas bancarias USD/EUR, vIBANes Banking y wallets de empresa. La pestaña seleccionada se refleja mediante ?tab=.

​

v2.105

• Mis cuentas: el portal ahora tiene una página única /accounts para el QR y alias de la cuenta, destinos receptores locales, cuentas Banking USD, vIBANes y wallets de empresa EUR, y wallets crypto de depósito. Cada sección conserva las acciones existentes de QR, copiar y compartir, y muestra estados vacíos o pendientes honestos.

• La etiqueta Mis wallets del portal ahora es Wallets. Los IDs, direcciones, activos y el comportamiento de solo recepción no cambian.
• Los destinos de depósito MX/CLABE y BO/BOB se provisionan solo después de aprobar el KYC/KYB de la cuenta. Las rutas y shapes de respuesta existentes no cambian.

​

v2.104

• Datos del emisor en la emisión de tarjetas: POST /v1/cards ahora valida códigos de catálogo para occupation en personas, place_of_work y salary_usd no negativo; códigos de catálogo para kind_of_business en empresas; y occupation, place_of_work, salary_usd más pep explícito para personas designadas. El PEP del titular de cuenta se deriva del screening AML, y el contacto, la representación legal y las URLs documentales de empresa pueden completarse desde KYB. Los catálogos de ocupaciones y actividades económicas aceptan búsqueda ?q=.

• Se documentan 422 issuer_data_incomplete, 422 screening_required y 422 cardholder_name_too_long; este último aplica cuando el nombre y apellido impresos de una persona superan juntos 22 caracteres.

​

v2.103

• Seguridad de la verificación self-service: las solicitudes nuevas de links KYC/KYB exigen un TOTP confirmado o un passkey registrado. Los links abiertos se re-sirven antes del gate y la automatización con API key sigue exenta. Un TOTP enrolado también fuerza el flujo OTP normal del login aunque la organización no haya activado OTP para login.

• Se agregó 403 verification_requires_2fa con los pasos de enrolamiento de TOTP o passkeys.

​

v2.102

• Transferencias bancarias CLP en Chile ahora pueden despacharse en ventanas agrupadas breves de aproximadamente cinco minutos. La respuesta de POST /v1/payouts sigue siendo 202 con status: "processing", y cada payout conserva su propio webhook payout_status_changed y estado final.

​

v2.101

• Cambio incompatible en la cartola cliente: GET /v1/reports/statement ya no devuelve el ledger crudo movements, assets[].movements ni summary.counts.movements. Las descargas PDF/XLSX del cliente ya no incluyen la sección ni la hoja Movimientos. La cuadratura se hace por secciones de producto y balance_after; el org-admin conserva la cartola completa y GET /v1/movements sigue siendo la vía de auditoría profunda. Los cargos ahora incluyen su asset, period.timezone informa la zona IANA de la organización y los nombres de hojas XLSX siguen lang.

​

v2.100

• Las cuentas de depósito BOB están disponibles mediante BO/BOB/bank_transfer.

• Las cuentas persona reciben un destino por corredor. Las empresas pueden crear destinos adicionales con un idempotency_key distinto; repetir la misma clave es idempotente.
• La provisión comienza solo después de aprobar KYC/KYB. Los campos de presentación de la cuenta receptora son opcionales y no se infieren; las transferencias AR/ARS usan el bank_alias elegido por el caller y el ruteo de recepción permanece separado del ruteo de payouts.

​

v2.99

• Los uploads de reviews de operaciones de la cuenta aceptan el query param opcional cerrado category y pueden recibir evidencia adicional después de un request-info previo mientras la review siga en in_review. Cada upload queda visible y reinicia la primera aprobación del maker-checker; las categorías desconocidas responden 400 invalid_category. Los emails de request-info enlazan directamente a /reviews/{reviewID} cuando existe la base del portal.

​

v2.98

• Wallets EUR de empresa para negocios verificados: reserva durable, lecturas de cuenta y org-admin, saldo en vivo y operaciones por fecha.
• Rutas core de reserva/estado/wallet/statement y catálogo OTC Europa EU/EUR/sepa.

• El saldo del vIBAN Banking EUR ahora devuelve received_total, no un available inventado por IBAN; las empresas pueden crear más IBANes y las personas mantienen el límite por propósito.
• Los gastos de organización aceptan EUR y tesorería muestra la fuente operativa EUR.

• Se documentan wallet_not_ready, wallet_reservation_failed, wallet_reservation_status_failed, wallet_read_failed, wallet_statement_failed y virtual_iban_limit_reached.

​

v2.97

• Guardas de settlement para metales: las referencias de ejecución de XPT/PLATINUM ahora usan una segunda referencia pública independiente cuando está disponible. Una divergencia superior al 2% deja la cotización fuera de settlement; si la referencia secundaria no está disponible, la guardia existente de frescura de la referencia sigue activa. Las rutas y los shapes de la API no cambian.
• Frescura de tasas más veraz: los timestamps de las tasas respaldadas por la referencia ahora reflejan el payload de origen, y los payloads con más de siete días de antigüedad se rechazan antes de publicarse.
• Defaults de tarjetas para metales: el colchón y el haircut degradado por defecto de SILVER son 3%; BTC se mantiene en 5%, GOLD en 2% y PLATINUM en 2%. Los overrides por organización siguen disponibles.

​

v2.96

• SEPA Instant simplificado a un corredor Europa: sepa ahora usa la única fila de enrutamiento EU/EUR. El país real del beneficiario sale del IBAN; los IBAN GB fallan rápido con HTTP 400 antes del despacho. Configura el pricing del payout con country: "EU".

​

v2.95

• Se agreg? cobertura regional de Brasil: payouts BRL provider-agnostic con pix y bank_transfer, m?s payins hosted BR/BRL/pix con m?nimo de 1 BRL y nombre/documento del pagador obligatorios.
• Se documentaron montos BRL con dos decimales, formatos de llave PIX, campos TED y el selector neutro de riel por organizaci?n.
• Activos ledger de plata y platino: las cuentas ahora admiten SILVER y PLATINUM como saldos de metales finos en gramos, con seis decimales, junto a USDT, USDC, BTC y GOLD. Las superficies existentes de swaps, settlement, gasto con tarjetas, checkout, cartola y analytics reflejan el vocabulario ampliado. asset_prices informa XAG/XPT por onza troy y SILVER/PLATINUM por gramo. No se agrega ningún endpoint ni riel on-chain de metales.

​

v2.94

• Cobros C2P en Venezuela: VE/VES/c2p está disponible mediante los endpoints collect existentes. El pagador entrega la claveDinamica generada por su banco en otp; no llames a /v1/payins/collect/otp para C2P. Los shapes de request y respuesta no cambian. debito_inmediato sigue sin estar disponible.

​

v2.93

• Emisión digital durante el corte temporal de físicas: POST /v1/cards ahora devuelve 400 physical_temporarily_unavailable para solicitudes nuevas con physical: true. Las tarjetas físicas ya emitidas siguen operativas. En cuentas persona, 409 card_limit_reached significa que la cuenta ya tiene una tarjeta viva o una solicitud abierta.

​

v2.92

• Validación de beneficiarios y descripción SEPA Instant: la descripción SEPA se pliega al charset del proveedor, rechaza caracteres no admitidos con 400 invalid_payload y queda limitada a 140 runas en el wire. Los nombres aplican el mapa europeo documentado y las personas deben tener nombre y apellido; los monónimos no se pueden pagar en V1.

​

v2.91

• Payouts SEPA Instant en EUR: el método sepa queda disponible en el catálogo de payouts para 35 países (AT, BE, BG, HR, CY, CZ, DK, EE, FI, FR, DE, GR, HU, IE, IT, LV, LT, LU, MT, NL, PL, PT, RO, SK, SI, ES, SE, IS, LI, NO, CH, MC, SM, AD y VA). El request exige un IBAN SEPA válido y beneficiary_type; el BIC es opcional. Reino Unido queda fuera de V1. El método es solo EUR y reutiliza el webhook payout_status_changed.

​

v2.90

• Vigencia mínima del checkout con tarjeta: ahora la materialización de tarjeta acepta links de checkout con al menos 5 minutos restantes. Si queda menos tiempo, responde 422 checkout_expiring_soon e indica pedir un link nuevo, en vez de fallar después con una validación genérica de la sesión.

​

v2.89

• Origen de la cotización ejecutable de payout: cada país de GET /v1/rates ahora incluye rate_source junto a rate. lot significa que la punta de payout usa el lote FIFO abierto más antiguo; spot indica que usa spot. payin_rate sigue basado en spot y el lot_quote opcional por monto permanece sin cambios e indicativo.

​

v2.88

• Anuncios de organización: las suscripciones webhook de cuenta pueden recibir el nuevo evento account-scoped admin_announcement, con el payload localizado de texto plano {broadcast_id, subject, body}.

​

v2.87

• Origen de tasa FIFO: las respuestas de payout pueden exponer rate_source, y GET /v1/rates?currency=&amount= puede devolver un lot_quote indicativo que muestra si usa lotes, spot o una mezcla.

​

v2.86

• Los fallos de autenticación 3DS devuelven failed_attempt: cuando el banco rechaza la autenticación, la sesión responde failed_attempt con failure_code: authentication_failed (antes: 500 genérico). La página hosted muestra el mensaje amable con los intentos restantes.

​

v2.85

• Clasificación de fallos en tarjetas hosted: las páginas de pago con tarjeta ahora exponen el enum estable failure_code (declined, authentication_failed, provider_unavailable, invalid_data, card_unavailable, expired, needs_review, unknown) y lo traducen para el pagador en EN/ES/ZH. El failure_reason histórico sigue compatible; los resultados ambiguos needs_review no deben reintentarse con un pago nuevo.

​

v2.84

• Filtros en listados de payouts y payins: los listados de payouts aceptan method y search; los listados de payins aceptan method, kind, refund_status y search.

​

v2.83

• Filtro por ciclo de vida en la página pública de status: los corredores desactivados por controles administrativos del operador ya no aparecen en las filas ni en el historial de incidentes, ni afectan el estado general. Los corredores habilitados que están caídos siguen visibles.
• Las señales KYC/KYB severas pasan a revisión humana: el motor de decisión automática ya no emite rejected ante sanciones AML severas (incluidas partes KYB), países prohibidos o señales explícitas de fraude/rechazo del proveedor. Conserva los códigos originales en auto_decision_reasons; un rejected cerrado por el proveedor sigue siendo autoritativo.
• Detalle del estado de verificación propia: GET /v1/me/verification ahora expone dentro de submission los campos opcionales pending_documents, changes_requested_comments, documents_received y documents_gate.

​

v2.82

• Identidad aprobada requerida para crear payins con la cuenta autenticada: las cuentas persona deben tener KYC aprobado y las cuentas empresa KYB aprobado antes de crear payins o usar collect desde la cuenta. POST /v1/payins (QR, card, checkout, bank_transfer y fintoc), OTP/collect, creación de cuentas de depósito dedicadas, cobros con tarjeta guardada y suscripciones ahora responden 403 verification_required hasta la aprobación. Los links públicos existentes, abonos pasivos ya recibidos, asignación operativa de org-admin e instrumentos de depósito creados por el sistema siguen disponibles.

• Las solicitudes de vIBAN de cuenta documentan los overrides opcionales de documento e incorporación (snake_case y camelCase), el autofill KYC/KYB y la respuesta registrant_incomplete (422).

​

v2.81

• Plazo de liquidación de payins con tarjeta: payin_card ahora acepta 0 o múltiplos de 24 horas. Los valores positivos representan días hábiles de EE. UU. en la zona horaria de la organización, excluyendo feriados federales. Por ejemplo, 48 programa la liquidación dos días hábiles después; 27 se rechaza con 400 invalid_settlement_hours. Los valores settle_at existentes y las configuraciones legadas no múltiplo conservan su comportamiento de horas calendario. La regla es independiente del proveedor.

​

v2.80

• Razón de emparejamiento para checkout expirado: los payins recibidos contra un checkout expirado permanecen visibles como unassigned con match_reason=checkout_link_expired; el espejo del pago se cierra en vez de quedar en un estado de error que se reintenta indefinidamente.

​

v2.79

• Eventos de seguridad de miembros: las entregas con alcance de cuenta redactan ip y user_agent; las vistas administrativas de alcance organizacional conservan el user_agent forense y los campos de procedencia del actor.
• Documentación de la firma V2 de webhooks: la guía ahora documenta X-Webhook-Signature-V2, que firma timestamp.event_type.event_id.raw_body con HMAC-SHA256 junto a la firma V1 heredada timestamp.raw_body. V1 sigue siendo válida y se continúa enviando.

​

v2.78

• Los fallos de screening antes del débito quedan explícitos: un payout que falla durante el screening del beneficiario antes de completar el camino de débito puede terminar failed con predebit_failure: true y funds_debited: false. La respuesta y el payload payout_status_changed omiten receipt_url; es distinto de un fallo posterior al débito, cuyo débito exacto se reembolsa.
• Las revisiones de estado del payout son durables: el payout existente puede emitir compliance_dispatch_pending, compliance_dispatching y core_unreachable mientras sigue pending, con funds_debited: true. Conserva la misma clave de idempotencia y deduplica cada entrega por su event ID.
• La disponibilidad del comprobante queda explícita para payouts pre-débito: GET /v1/payouts/{payoutID}/receipt responde 409 receipt_not_available mientras el screening técnico espera o después de un fallo de screening antes del débito; en esos estados no existe un comprobante financiero.
• Las confirmaciones de payins con tarjeta vuelven a completar normalmente: las notificaciones terminales payin_charge_status_changed ahora cierran correctamente el payin con tarjeta asociado, para que los pagos confirmados sigan el flujo normal de acreditación.
• Los payins anunciados vencidos emiten payin_expired de forma confiable: el procesamiento de expiración ahora maneja anuncios que todavía no tienen una cuenta asociada, permitiendo que las integraciones cierren cobros impagos sin depender del polling.

​

v2.77

• Las transiciones de compliance del payout son durables y explícitas: después de que el screening técnico devuelve process, el mismo payout puede seguir en pending con compliance_dispatch_pending, compliance_dispatching o core_unreachable mientras funds_debited: true. Antes de aprobar el screening, funds_debited sigue en false; conserva la misma clave de idempotencia y espera payout_status_changed en vez de crear otro payout.

​

v2.76

• Cola de screening técnico de payouts: cuando el screening del beneficiario está temporalmente no disponible pero la cola sí está disponible, POST /v1/payouts devuelve 202 con status: pending, status_code: compliance_pending, compliance_pending: true y funds_debited: false. Mientras espera no hay hold, asiento en el ledger, despacho al core ni receipt_url. El replay con la misma idempotency key devuelve el mismo payout. process continúa el flujo normal, un hold válido entra al firewall y rejected termina el payout encolado como failed sin débito.

​

v2.75

• Los webhooks de estado de payout ahora incluyen el status_message opcional junto a status y status_code. El valor está normalizado y depurado, puede venir vacío si no hay detalle adicional y nunca expone la identidad de un proveedor upstream.

​

v2.74

• Holds de compliance en collect y checkout hosted ahora ocurren antes del cargo al pagador. Aprobar solo libera la review; reintenta el mismo request de collect con el mismo contexto de idempotencia. Un timeout/5xx ambiguo queda pending para reconciliación por webhook y jamás se reenvía automáticamente. Se agrega el conflicto checkout_not_pending y se documenta el screening separado del pagador solo documental (document_value/idNumber, no name).
• El screening transaccional distingue ahora las categorías AML reconocidas de los candidatos fuzzy: una categoría reconocida sigue siendo accionable con target=true o target=false. Cuando target=false y la categoría AML no es reconocida, el resultado no es accionable y no genera un hold falso ni un error. Las respuestas legacy sin target, al igual que las respuestas incompletas o malformadas, mantienen el comportamiento fail-closed.

​

v2.73

• vIBAN EUR: las cuentas pueden solicitar un vIBAN durable de funding_usdt o banking_eur con idempotencia, aprobación manual, consulta de estado, listado con fechas y ownership. Los ingresos terminales entran ahora al camino financiero según el propósito.
• Returns y recalls: returned, recalled y reversed se reconcilian de forma idempotente. Los chargebacks/refunds de fondeo y los reverse entries de Banking EUR son append-only; un completion posterior no resucita una operación devuelta.

​

v2.72

• Contrato de recovery: se agregaron la ruta durable de estado de idempotencia del core y la reconciliación org-ops para claims ambiguos de cuentas de depósito. El recovery es fail-closed con deposit_account_not_recoverable, idempotency_conflict y fence de lease. La adopción del platform-admin es una acción separada de último recurso, no un replay idempotente; usa la reconciliación para repetir un fence core verificado.

• Múltiples CLABEs para empresas: las cuentas empresa pueden crear múltiples destinos MX/MXN/bank_transfer. Cada destino sigue ligado a la misma cuenta y acredita por instrumento de destino. La creación empresa exige una clave de idempotencia: una clave nueva responde 201, un replay completado responde 200 con

​

v2.71

• La cobertura del buró en fraude e identidad ahora es explícita: un informe puede quedar listo con THIN_FILE cuando no hay evidencia del buró, incluido el caso explícito sin fuente. El PDF declara la frescura de la fuente (live o unavailable) y la cantidad de registros. Las fallas de transporte, autenticación, storage, contrato inválido y sources_failed no vacío siguen fallando cerrado por el recovery/reembolso existente.

​

v2.70

• Semántica final de recuperación bancaria: documentados 400 idempotency_key_mismatch, 401/403 del proveedor sin terminalizar, validación de titularidad por ProviderID, replay completado sin proveedor, locks estables y la clave del body público/plataforma que no se reenvía.
• Informes de fraude e identidad: POST/GET /v1/qscore/fraud/reports, detail y PDF autenticados, cuatro propósitos cerrados, cobro idempotente con reembolso ante falla, webhook firmado risk_fraud_score_ready, email best-effort y verificación pública /verify/qscore-fraud/{code}.
• Qscore Index: snapshots trimestrales públicos y autenticados en /v1/qscore/index y /v1/qscore/index/account, con filtros de país/industria y buckets anónimos de al menos cinco sujetos.

​

v2.69

• Tu idempotency_key vuelve en los webhooks. Los webhooks de cuenta de las operaciones de dinero que creaste con una clave de idempotencia ahora la traen de vuelta como idempotency_key en el payload — concilia la notificación contra tu propia referencia sin un GET extra. Eventos cubiertos: payout_status_changed, payin_credited, payin_settlement_scheduled, payin_expired, payin_refunded, crypto_withdrawal_status_changed y wallet_send_status_changed. El campo es opcional: se omite cuando la operación se creó sin clave, y las claves internas de la plataforma jamás se exponen. transfer_received no la lleva. El recurso payin también la devuelve en GET /v1/payins/{id}. Ver webhooks e idempotencia.

​

v2.68

• El cobro pull de Venezuela (c2p / debito_inmediato) ya no está disponible. Crear un cobro pull en el corredor VE/VES ahora responde que el corredor no está soportado, y la cotización del checkout ya no lista ninguna opción collect: true. Los endpoints de collect se mantienen en la API marcados como deprecated. Los pagos salientes a Venezuela (pago_movil, bank_transfer) no cambian — y pago_movil sigue exigiendo beneficiary.name (sin cambios desde v2.66). Ver payins y checkout.

​

v2.67

• Los cobros de checkout y POS pagados con tarjeta ahora siguen la demora de settlement de tarjeta. Cuando tu fee payin_card configura settlement_hours sobre cero, un link de checkout hosted o un cobro POS pagado con tarjeta se comporta igual que un payin directo con tarjeta: se confirma credited y cierra como pagado al instante, pero el saldo cae al llegar settle_at (settlement_pending: true hasta entonces, con liberación anticipada por un org-admin). Antes esos cobros pagaban el fee de tarjeta pero se acreditaban de inmediato. Los cobros por QR, crypto, app CBPay o fintoc siguen acreditándose al instante. No cambió ningún shape de API ni de webhook. Detalle en comisiones — settlement de payins con tarjeta.

​

v2.66

• Los payouts de Venezuela pago_movil ahora exigen beneficiary.name. El rail exige el nombre + primer apellido del beneficiario (tal como en la cédula) — un solo token es rechazado. La guía de payouts y los ejemplos de la referencia API ahora listan name primero entre los campos requeridos. Venezuela bank_transfer ya documentaba name; sin cambios ahí.

​

v2.65

• Payouts Venezuela: el motivo de fallo del rail (ERR-XXX) ahora llega al GET aunque el payout ya haya nacido failed. Cuando un payout pago_movil / bank_transfer de VE se marca failed de forma síncrona al crearlo y el rail informa después el motivo por webhook, la plataforma lo persiste: el GET del payout muestra status_code / status_message con el código ERR-XXX real (antes el webhook se descartaba al encontrar el payout ya failed). Es un enrich de metadata: no hay segundo refund ni cambio de estado.

​

v2.64

• Pruebas de firma — firma de mensajes con wallets (EIP-191 / TIP-191). Prueba el control de una wallet con una firma criptográfica sobre un sobre estructurado anti-phishing (dominio, propósito, cuenta, nonce y una ventana de validez de 10 minutos — nunca un mensaje libre). Dos flujos: firma server-side de una wallet segregada con POST /v1/segregated-wallets/{walletID}/signatures (con gate de OTP para sesiones de miembro) y vinculación de wallet externa (MetaMask, TronLink) por challenge firmado con POST /v1/wallet-links/challenges + POST /v1/wallet-links/verify. Guía: Pruebas de firma.
• Gestión de proofs. GET /v1/signature-proofs (paginado, filtros from/to/status/purpose), GET /v1/signature-proofs/{proofID} y POST /v1/signature-proofs/{proofID}/revoke. Las wallets vinculadas se listan con GET /v1/wallet-links y se revocan con DELETE /v1/wallet-links/{linkID}.
• Verificación pública. Cada proof lleva un proof_code y una verify_url; cualquiera puede verificarlo sin autenticación en GET /v1/public/signature-proofs/{code} — estado, ventana de validez, red, dirección y (cuando está firmado) la firma y el hash del mensaje.
• Webhooks wallet_signature_created y wallet_linked. Se emiten al crear un proof y al vincular una wallet externa. Referencia: Webhooks.
• Email de seguridad en cada firma server-side. El titular de la cuenta recibe un email brandeado con la wallet, la red, el propósito y la fecha de cada firma.

​

v2.63

• El mensaje de verifications_unavailable ya no afirma que se reembolsó una comisión. Un 503 de verificación de identidad no implica reembolso: el endpoint de documentos de verificación nunca cobra comisión y el onboarding propio no tiene fee. El copy ahora solo pide reintentar más tarde. Referencia: Errores y la guía KYC.

​

v2.62

• El estado/región de facturación ahora es obligatorio en la página hospedada de tarjetas cuando el país de facturación lo exige. Los países cuyas subdivisiones ISO 3166-2 son obligatorias para capturar el cobro (p. ej. Estados Unidos, Canadá, Brasil) ahora muestran al pagador un campo Estado / Región requerido alimentado por el catálogo de subdivisiones; el valor viaja como administrative_area de la dirección de facturación. En los países sin subdivisiones obligatorias el campo sigue opcional. Guía: Pagos con tarjeta.
• Los cargos con tarjeta guardada (MIT) validan la dirección de facturación antes de despachar el cobro. Una tarjeta guardada con dirección completa sigue operando sin cambios. Si la tarjeta guardada no tiene una dirección utilizable en archivo, el cobro se rechaza con 422 core_rejected y un mensaje que pide al pagador guardar la tarjeta de nuevo con save_card: true — sin mover plata. Guía: Tarjetas guardadas y suscripciones.

• Las transacciones con tarjeta autorizadas pero nunca capturadas por falta del estado/región de facturación ya no pueden ocurrir. La dirección de facturación se valida por adelantado — en la página hospedada para el pagador y antes del despacho en los cargos con tarjeta guardada — y los nombres de subdivisión se normalizan al código ISO 3166-2 que el riel exige (p. ej. “California” → CA).

​

v2.61

• Locale de cuenta en / es / zh. GET /v1/me ahora devuelve locale. PATCH /v1/me con { "locale": "en" | "es" | "zh" } lo persiste; el string vacío guarda inglés; cualquier otro valor no vacío responde 400 invalid_locale ("locale must be en, es or zh"). Las cuentas nuevas eligen locale al nacer (body, luego Accept-Language, luego el default_locale de la org, luego inglés). Guía: Idioma y locale.

• Las superficies humanas default a inglés. Páginas hospedadas (checkout, tracker público, comprobantes, status, sello Qscore, informe de verificación), PDF de comprobantes/cartola y encabezados CSV resuelven en salvo que un ?lang= / ?locale= válido, el perfil de la cuenta, el default de la org o Accept-Language digan otra cosa. Un locale de query inválido se ignora (nunca 400). El JSON de la API y los webhooks siguen en inglés.
• Cookie del pagador cbpay_pay_locale (30 días, Secure, SameSite=Lax) en páginas públicas; no traduce el JSON.
• Las cuentas existentes se quedan en español. Un paso one-shot de deploy estampa locale=es en las cuentas que no tenían locale para que los clientes hispanohablantes vivos no pasen a inglés. Las cuentas nuevas siguen naciendo en inglés.

​

v2.60

• US ACH, wire y SWIFT devuelven bank_reference de inmediato. El create queda processing y ya trae la referencia CBF con la que el beneficiario (y tu) cruzan el pago con el banco. El payout completa cuando el banco confirma — escucha payout_status_changed. En el resto de corredores bank_reference sigue vacio hasta que el rail lo reporta.

​

v2.59

• Payouts USD por rail bancario: el beneficiario puede vivir en cualquier país (guía de payouts): en transferencias ach, wire y swift el country_code del beneficiario ya no está fijo en US — por ejemplo, un ACH a una cuenta de banco de EE. UU. para alguien que vive en Alemania. El banco receptor sigue en EE. UU. para ach/wire (bank_country: "US" — los rails domésticos no pagan a bancos del exterior); para swift el banco puede estar en cualquier país. state se exige solo cuando el beneficiario vive en EE. UU. Las jurisdicciones del Anexo B (CU/IR/KP/SY) siguen bloqueadas tanto para el beneficiario como para el país del banco.
• Documento de respaldo obligatorio en toda transferencia USD por rail bancario: los payouts USD por ach, wire y swift siempre exigen un documento de respaldo (factura/recibo) subido primero con POST /v1/payouts/documents, sin importar el país del beneficiario — antes el requisito dependía del país. Si falta el documento, la API responde 400 supporting_document_required.

​

v2.58

• Los payins con tarjeta con liquidación diferida se confirman credited de inmediato (comisiones): con settlement_hours > 0, un cobro con tarjeta pagado ahora pasa a status: credited al momento del pago — el webhook payin_credited se emite de inmediato y un link de checkout pagado con tarjeta cierra como pagado. Lo que espera es solo el saldo: cae en tu ledger al llegar settle_at (el worker de liquidación corre cada minuto) o antes si un org-admin lo libera manualmente. Antes el payin quedaba pending y payin_credited recién se emitía al liquidarse.
• Campos nuevos del payin: mientras el saldo está programado, las respuestas de create/GET/lista llevan settle_at (RFC 3339) y settlement_pending: true; cuando el saldo cae, llevan settled_at en su lugar.
• Payload de payin_settlement_scheduled: el webhook ahora reporta status: "credited" (antes pending), en línea con la confirmación inmediata.

• Nuevo error settlement_pending (422): devolver un cobro con tarjeta cuyo saldo sigue programado para settlement se rechaza hasta que los fondos se liberen (al llegar settle_at, o antes por liberación de un org-admin). Detalle en devoluciones.

​

v2.57

• Nuevo evento de webhook payin_settlement_scheduled: cuando tu organización tiene una liquidación diferida configurada para payins con tarjeta (settlement_hours > 0), un payin con tarjeta pagado queda pending con un settle_at futuro hasta que el worker de liquidación libera los fondos. Desde hoy, en el momento en que el pago se confirma recibes payin_settlement_scheduled exactamente una vez (idempotente — un reintento jamás lo re-emite) con la cotización completa: usdt_gross, fee, usdt_net (el monto que se acreditará al vencimiento), settle_at y receipt_url. Antes la única señal era el payin en pending sin confirmación. Al vencimiento, el worker acredita el saldo y emite payin_credited como siempre. Suscríbete con event_type: "payin_settlement_scheduled" como cualquier evento de cuenta.

​

v2.56

• Resumen neutro de saldo en los balances banking: GET /v1/banking/accounts/{bankAccountID}/balance y GET /v1/banking/third-parties/{thirdPartyID}/accounts/{bankAccountID}/balance ahora devuelven tres campos opcionales de nivel superior junto al objeto balance (que no cambia): available y held como strings decimales planos (ej. "1250.00", "0.00") y currency (ISO 4217, ej. "USD"). Son la forma recomendada de leer el monto — antes el monto solo existía anidado dentro del objeto balance nativo del rail, cuya forma varía por rail. El objeto balance conserva el detalle completo de la cuenta (nombre visible, requisites para recibir fondos).

​

v2.55

• Settlement configurable de payins con tarjeta (comisiones): la configuración de comisión del servicio payin_card ahora acepta settlement_hours (entero ≥ 0, default 0 = acreditación inmediata, exactamente como antes). Con un plazo configurado, un cobro con tarjeta aprobado deja el payin pending con un timestamp nuevo settle_at (RFC 3339) en las respuestas de creación, detalle y lista — la acreditación del saldo, el webhook payin_credited, el cierre del link de checkout y la auto-conversión ocurren todos al settle_at (un worker acredita los payins vencidos cada minuto). Un payin cuyo plazo ya venció al aprobarse o asignarse se acredita de inmediato. Enviar settlement_hours para cualquier otro servicio (o un valor negativo) responde 400 invalid_settlement_hours.
• Comisiones banking por riel (comisiones): cinco servicios de comisión transaccionales nuevos — banking_deposit, banking_transfer_ach, banking_transfer_swift, banking_transfer_wire y banking_transfer_sepa — porcentaje + fijo, cobrados en la moneda de la operación (BANK_USD / BANK_EUR). Los depósitos se cobran al acreditarse (con tope en el monto del depósito: un depósito chico nunca queda en negativo); las transferencias salientes se cobran al despacharse con un chequeo fail-closed balance >= monto + comisión, y la comisión se reembolsa si la transferencia es rechazada en definitivo. Un riel sin configuración específica cae al servicio legacy banking_operation; un riel configurado en 0% + 0 fijo es explícitamente gratis y nunca cae al fallback.

​

v2.54

• Los filtros de fecha ahora usan la zona horaria de tu organización: cada filtro de fecha from/to (YYYY-MM-DD) de los listados de la plataforma (payouts, payins, retiros crypto, transferencias banking, gastos, cartola, analytics, revenue) ahora interpreta el día en la zona horaria de tu organización en vez de UTC. from es la medianoche de ese día en tu zona (inclusive) y to es la medianoche del día siguiente en tu zona (exclusive). La zona es una setting de la organización (timezone, nombre IANA) administrada por la plataforma — el default es America/New_York — y el valor vigente se expone en GET /v1/branding como timezone. Los buckets diarios de analytics y revenue también agrupan por el día civil de tu organización. No cambió ningún shape: solo el día calendario que cubre un filtro YYYY-MM-DD.

​

v2.53

• Sello público verificable Qscore (guía del sello): las cuentas empresa con banda A o B y una evaluación fresca (de no más de 90 días) pueden activar un sello público verificable — POST /v1/qscore/my-seal (idempotente por diseño: un replay responde 200 con el sello vigente), lo consultas con GET /v1/qscore/my-seal, y luego compartes la página pública o embebes el badge SVG en vivo (badge_url). La página y el badge re-evalúan la elegibilidad en cada vista: si el score cae bajo la banda B o la evaluación supera los 90 días, el sello pasa a “no vigente” — jamás revela la razón ni el score numérico (anti-oráculo). El titular puede revocarlo en cualquier momento con DELETE /v1/qscore/my-seal; la revocación es permanente para ese sello y se puede activar uno nuevo de inmediato. Endpoints públicos nuevos: GET /platform/verify/qscore/seal/{code} (JSON, o página HTML brandeada para browsers) y GET /platform/verify/qscore/seal/{code}/badge.svg (badge en vivo embebible). Códigos de error nuevos: seal_companies_only, seal_not_eligible y no_active_seal. Sin webhooks nuevos.

​

v2.52

• Links de consentimiento Qscore (autorización del titular) (guía de links de consentimiento): pídele a un sujeto que autorice el acceso de lectura a sus datos bancarios con un link compartible — POST /v1/qscore/consents (idempotente, con envío opcional del link al correo del titular con tu branding), y luego sigue el estado con GET /v1/qscore/consents y GET /v1/qscore/consents/{id}, o cancélalo con POST /v1/qscore/consents/{id}/revoke. El titular decide en una página pública (sin login): conecta su banco a través del widget seguro y la identidad verificada del titular debe calzar EXACTAMENTE con el documento del sujeto (una cuenta de OTRO documento jamás otorga el consentimiento). Una vez otorgado, CBPay deriva hechos bancarios positivos (cuentas, saldos, actividad de ingresos/gastos de 90 días) hacia la ficha crediticia del sujeto — los informes Qscore los re-derivan en cada generación para mantener la data fresca. Webhooks nuevos: risk_consent_granted y risk_consent_revoked. Códigos de error nuevos: purpose_required, invalid_purpose, invalid_doc_id, invalid_subject_type, invalid_email, already_decided, link_inactive y holder_mismatch.

​

v2.51

• Scoring Qscore por lote (portfolio scoring) (guía Scoring por lote): sube un lote de sujetos con POST /v1/qscore/batches — un array JSON o un string CSV, hasta 5.000 sujetos por lote — y la plataforma emite un informe Qscore completo por sujeto de forma asíncrona. Las filas se validan al crear (los documentos inválidos, los subject_type no soportados y los duplicados dentro del lote se reportan en rejected_items y jamás se procesan); cada ítem cobra el fee standalone del informe al procesarse y se reembolsa automáticamente si falla de forma terminal. Al terminar el lote recibes UN webhook risk_batch_completed y UN email con los contadores — los informes individuales no emiten su propio webhook ni email. Lee los resultados por ítem con GET /v1/qscore/batches/{batchID}/items o descárgalos con GET /v1/qscore/batches/{batchID}/results.csv. Códigos de error nuevos: no_valid_items y too_many_items.

​

v2.50

• Los informes Qscore de empresa ahora pueden incluir el bloque peer_benchmark: la posición del score dentro de su segmento de industria (mismo país, misma industria ISIC). Reporta el código y nombre del segmento (segment_code/segment_label), el número de empresas comparables (peers), el percentile (porcentaje de pares con score menor) y el median_score del segmento. El bloque se publica solo con al menos 5 empresas comparables y únicamente en informes de empresa.

​

v2.49

• Qscore — tu propio informe crediticio, gratis (guía Qscore): el titular de una cuenta verificada ahora puede generar SU PROPIO informe crediticio Qscore — el derecho de acceso ARCO / de protección de datos — con POST /v1/qscore/my-report (opcional {"lang":"es"|"en"|"zh"}), leer el más reciente con GET /v1/qscore/my-report y descargar el PDF brandeado con GET /v1/qscore/my-report/pdf. A diferencia del informe comprado, el informe self es gratuito (sin comisión), la identidad del sujeto sale del tax_id verificado de la cuenta (el request jamás acepta un doc_id — pedir el informe de un tercero por estos endpoints es imposible por diseño), se puede generar UN informe nuevo cada 30 días (dentro de la ventana se devuelve el existente con idempotency_hit: true), y los informes self quedan excluidos del conteo de consultas del sujeto, así que revisar tu propio informe jamás penaliza tu score. El webhook risk_report_ready de un informe self lleva purpose: "self_access". El endpoint comercial POST /v1/qscore/reports ahora rechaza purpose: "self_access" con 400 invalid_purpose. Nuevos códigos de error: kyc_required, no_tax_id, invalid_tax_id (errores).

​

v2.48

• Las solicitudes de banking y tarjetas ahora pueden quedar retenidas para revisión (guía banking, guía de tarjetas, revisiones de operaciones): si tu organización activó la revisión de solicitudes, POST /v1/banking/customer, POST /v1/banking/third-parties y POST /v1/cards pueden responder 202 Accepted con {"status":"in_review","kind":"...","review_id":"..."} en vez de crear el recurso de inmediato — nada se envía a procesamiento hasta que compliance apruebe la revisión. La comisión de apertura/emisión se cobra al retener la solicitud y se reembolsa automáticamente si se rechaza. Un reintento con la misma idempotency_key devuelve la misma revisión (idempotency_hit: true) y jamás cobra dos veces. Sigue el resultado con el webhook txn_review_status_changed o en Revisiones de operaciones (kinds banking_application / card_application).

​

v2.47

• Qscore — monitoreo continuo de sujetos (guía Qscore): cuando ya tienes un informe ready de un sujeto, suscríbelo con PUT /v1/qscore/subjects/{docID}/monitoring y la plataforma lo re-evalúa cada ~5 minutos, emitiendo el nuevo webhook risk_monitoring_alert cuando el score cae bajo tu umbral monitor_since_score (score_drop_below), cuando aparecen registros nuevos en el buró (new_records) o cuando se eliminan registros (records_removed) — con only_material: true solo disparan los triggers materiales. Administra las suscripciones con GET /v1/qscore/subjects/{docID}/monitoring, GET /v1/qscore/monitoring (todos los sujetos monitoreados de la cuenta) y DELETE /v1/qscore/subjects/{docID}/monitoring (desactiva con active: false — la historia jamás se borra). El monitoreo es gratuito pero exige un informe comprado del sujeto: sin él la API responde 403 report_required, la misma respuesta que recibe un sujeto inexistente (por diseño, para que la existencia del sujeto no se pueda sondear). Nuevo código de error: report_required (errores).

​

v2.46

• Referencia bancaria del payout, ahora visible en todas las superficies (guía de payouts): todo payout expone bank_reference — el id de transacción asignado por el banco/rail de destino — en las respuestas de POST /v1/payouts, GET /v1/payouts y GET /v1/payouts/{payoutID}, en el payload del webhook payout_status_changed, en el comprobante PDF, en el export CSV de payouts y en la cartola (JSON y Excel). El campo viene vacío ("") mientras el payout está en tránsito y se completa cuando queda completed — es la referencia con la que el beneficiario puede cruzar el pago con su banco.

​

v2.45

• Qscore — buró de crédito API-first (guía Qscore): compra informes crediticios de personas y empresas (POST /v1/qscore/reports), Chile primero. Cada informe agrega antecedentes negativos, laborales y previsionales, boletas impagas y publicaciones del diario oficial en un score 0–1000 con bandas A–E (SC cuando no hay datos), códigos de razón, un PDF brandeado y un código de verificación pública. GET /v1/qscore/subjects/{docID}/score lee el score vigente de un sujeto sobre el que ya emitiste un informe, GET /v1/qscore/reports/{reportID}/pdf descarga el PDF, y el flujo de rectificación del titular (ARCO) corre por POST /v1/qscore/subjects/{docID}/disputes + GET /v1/qscore/disputes/{disputeID}. Los informes se cobran por tipo de documento (risk_report_person / risk_report_company) y exigen declarar el purpose por la ley de protección de datos. Webhooks nuevos: risk_report_ready y risk_score_changed. Requiere el service flag risk.
• Verificación pública de informes: GET /v1/verify/qscore/{code} valida el código impreso en un informe Qscore y devuelve los hechos no sensibles (clase de sujeto, banda, fecha de emisión) — sin PII.
• Códigos de error nuevos: purpose_required, invalid_purpose, invalid_doc_id, invalid_subject_type, no_score, pdf_not_ready (errores).

​

v2.44

• Los eventos payin_received ya no se generan para reversas bancarias internas de la cuenta de tesorería del operador (la reversa de un envío propio nunca fue un cobro de cliente).

​

v2.43

• Mejora de calidad del catálogo de ciudades (guía de catálogos AML): las ciudades que sirve GET /v1/aml/catalogs/cities?country=<CC> fueron regeneradas con mejor cobertura y escritura correcta. Los nombres conservan su ortografía local (tildes, ñ, ü — “Alhué”, “Coyoacán”, “São Paulo”), los nombres locales reemplazan a los exónimos en inglés (“Ciudad de México”, no “Mexico City”) y las divisiones urbanas quedaron completas: todas las comunas de Santiago, los distritos de Lima, las alcaldías de Ciudad de México, municipios de toda la región. Se eliminó el ruido de los datos (sufijos censales de EE. UU. como “Abanda CDP”, prefijos administrativos residuales, duplicados). Mismo shape de respuesta y mismos códigos de error — sin cambio de integración.

​

v2.42

• Link de seguimiento desde la API (guía de seguimiento): el nuevo endpoint autenticado GET /v1/track-link?kind=<kind>&id=<id> devuelve el link público compartible de cualquier transacción de tu alcance de lectura — { "track_url", "code" } — sin descargar el PDF del comprobante. Es la pieza base de un botón “Compartir link” en tu UI. El code es el mismo código HMAC determinista impreso en cada comprobante, así que el link es siempre el mismo para una transacción dada. Disponible para la propia cuenta, para admins de la organización y para admins de plataforma; una transacción fuera de tu alcance responde un 404 not_found uniforme.

​

v2.41

• Link de seguimiento público para cada transacción (guía de seguimiento): cada comprobante (payout, payin, refund, transferencia interna, swap, retiro o depósito crypto, operación banking, compra con tarjeta) tiene ahora un link público compartible — https://business.cbpayapp.com/t/{code}, con el mismo código firmado impreso en el comprobante — que abre una página de seguimiento estilo Wise con la línea de tiempo en vivo, la descarga del comprobante PDF y selector de idioma (EN/ES/ZH). La página es noindex, nunca se cachea y muestra los estados de revisión como processing (sin tipping-off).
• Endpoints públicos de seguimiento: GET /v1/public/track/{code}?lang= devuelve el estado público de la transacción en JSON y GET /v1/public/track/{code}/receipt.pdf?lang= regenera el comprobante PDF al vuelo. Ambos son sin autenticación, rate-limited por IP y responden un 404 not_found uniforme ante códigos inválidos o alterados.
• Comprobantes en chino: los comprobantes PDF y la página de seguimiento ahora soportan lang=zh por completo.

• Los verify_url de los comprobantes abren el tracker: el verify_url de los comprobantes nuevos y de los correos de comprobante apunta ahora a la página de seguimiento. El legacy GET /v1/verify/receipts/{code} sigue vivo — el navegador se redirige (302) al tracker y los clientes API reciben el mismo JSON de siempre.

​

v2.40

• Lookup del directorio bancario (guía de payouts): el nuevo GET /v1/payouts/bank-directory/lookup autocompleta el banco beneficiario desde un directorio bancario público embebido — pasa exactamente uno de routing_number (9 dígitos, solo US) o swift (8 u 11 caracteres; un sufijo XXX se normaliza a la casa matriz) y resuelve el nombre del banco, ciudad, estado y bloque de dirección, así los formularios de payout y contraparte pueden pre-llenar bank_name y los campos opcionales bank_* mientras el pagador escribe. Un 404 bank_not_found solo significa que el código no está en el directorio: el formulario sigue manual. Data estática con Cache-Control: public, max-age=86400.
• Lookup por código postal (guía AML): el nuevo GET /v1/aml/catalogs/postal-code?country=US&code=33130 resuelve un ZIP de US a su city y state, así los formularios con dirección pueden autocompletar ambos campos mientras el usuario escribe el ZIP. Hoy solo US tiene dataset; un 404 postal_code_not_found significa que el ZIP es desconocido (o el país no tiene dataset) y los campos siguen manuales.

• Limpieza de calidad del catálogo de ciudades: GET /v1/aml/catalogs/cities ahora deduplica ciudades por su forma plegada (sin diacríticos, sin distinción de mayúsculas), unifica el okina hawaiano, elimina dos entradas corruptas pegadas, colapsa los espacios internos y sirve Content-Type: application/json; charset=utf-8.

​

v2.39

• Catálogo de ciudades por país (guía AML): el nuevo GET /v1/aml/catalogs/cities?country=US devuelve las ciudades de un país ISO 3166-1 alpha-2 agrupadas por subdivisión — las claves de states son los mismos códigos ISO 3166-2 de country_subdivisions del catálogo principal, y country_cities lista las ciudades cuya región no pudo mapearse (ningún campo es jamás null). Un país sin cobertura responde 200 con listas vacías (cae a un campo de ciudad de texto libre); un código mal formado recibe 400 invalid_country y uno desconocido 404 country_not_found. Data estática con Cache-Control: public, max-age=86400 — una llamada por país y filtras por estado en el cliente.
• Los payins US/USD ahora publican dos rieles de depósito (guía de payins): el corredor de transferencia anunciada bank_transfer sirve una instrucción de wire doméstico (routing_number ABA) y una SWIFT internacional (BIC + banco corresponsal) lado a lado — el anuncio, las lecturas del payin y el preview GET /v1/payins/deposit-instructions exponen deposit_instructions (doméstico) y deposit_instructions_swift (internacional), cada una con su propio QR para copiar, así el pagador elige el riel que su banco soporta. Ambos bloques llevan los campos nuevos holder_address y notes cuando están configurados (el QR los imprime como líneas “Holder address” y “Note”). Fail-closed: un corredor US/USD sin su variante SWIFT responde 422 deposit_instructions_unavailable al anunciar.

​

v2.38

• Rechazo automático por plazo de revisión (guía de revisiones) — si tu organización configuró un plazo de revisión para el firewall transaccional, una revisión que nadie decide dentro de esa ventana (contada desde su último cambio de estado — subir evidencia reinicia el reloj) es rechazada automáticamente por un barrido horario: la operación se cancela, los fondos retenidos vuelven a tu saldo y recibes el mismo email y webhook txn_review_status_changed (status: "rejected") que con un rechazo manual. El detalle de la revisión lleva el aviso estándar de plazo en decision_note.

​

v2.37

• Nuevo corredor de payin: Estados Unidos (USD) por transferencia bancaria anunciada (ACH / wire). La cuenta anuncia el depósito con POST /v1/payins {method: "bank_transfer", country: "US", currency: "USD", amount, idempotency_key, payer_name?} y la respuesta trae la referencia única CB…, status: "pending" y el bloque deposit_instructions completo — que ahora soporta los campos bancarios de EE.UU. routing_number (ABA), swift (BIC), bank_address, intermediary_bank_name e intermediary_bank_swift. El cliente transfiere desde su banco con la referencia CB… en la glosa/memo; cuando el abono llega a la cuenta de recaudación se matchea por referencia y se acredita en USDT (status: "credited" con usdt_credited y fx_rate). Un abono sin anuncio ni referencia queda unassigned — fail-closed, nunca se acredita solo. Puedes previsualizar la cuenta destino sin anunciar con GET /v1/payins/deposit-instructions?country=US&currency=USD&method= bank_transfer. Estados Unidos se suma a los corredores que EXIGEN que la organización tenga deposit instructions configuradas: anunciar sin ellas falla con 422 deposit_instructions_unavailable. Tab de EE.UU. con ejemplos request/response completos, tabla de estados, errores y FAQ en la guía de Payins; el bloque deposit_instructions y el endpoint de preview quedaron actualizados en la referencia de API.

​

v2.36

• Firewall transaccional: cuando tu organización tiene el firewall transaccional habilitado, las operaciones de dinero (payouts, retiros crypto, payins y transferencias banking) pueden quedar in_review a la espera de una decisión humana — la API responde 202 Accepted con un review_id. Nuevos endpoints de cuenta GET /v1/me/txn-reviews (lista y detalle), POST /v1/me/txn-reviews/{reviewID}/files (sube los documentos solicitados) y GET .../files/{fileID}/download (descarga tus propios archivos), además del nuevo webhook txn_review_status_changed (payload neutro — las razones internas nunca viajan). Nueva guía: Revisiones de operaciones.

​

v2.35

• Nuevo corredor de payouts: Estados Unidos (USD) con tres métodos — ach (ACH al día siguiente a cuentas corrientes o de ahorro), wire (wire doméstico) y swift (wire internacional en USD vía SWIFT). El riel exige la identidad y dirección postal completas del beneficiario en cada transferencia (name, email, account_number, country_code, address, city, postal_code, bank_name y bank_code — routing ABA para ach/wire, BIC SWIFT para swift; account_type CHECKING/SAVING para ach), con el bloque de dirección del banco receptor y bank_phone como opcionales recomendados. wire y swift tienen mínimo USD 25.00. El primer payout a un beneficiario nuevo puede quedar processing con status_code: "pending_aml" mientras el riel revisa al beneficiario, y se ejecuta solo al aprobarse; un rechazo del riel termina el payout failed con status_code: "counterparty_rejected" y reembolso automático. Por operación puedes sobreescribir las declaraciones de propósito del riel en options (purpose, crypto_activity, payment_gateway). Tabla de corredores, tabla de campos por método, ejemplos reales y FAQ en Payouts; ejemplos nombrados us_ach, us_wire y us_swift en la referencia API.

​

v2.34

• La página Servidor MCP ahora menciona el servidor MCP dedicado de la documentación de administración de la organización (mcp-admin.cbpayapp.com, en despliegue), para que los administradores de la organización sepan que existe un feed equivalente para la API org-admin — este servidor público sigue cubriendo la API de nivel cuenta.

​

v2.33

• Más transparencia en las validaciones de documentos: el listado de documentos de una submission (GET /v1/{kyc,kyb}/submissions/{id}/documents) ahora expone en cada validación su id, el effective_outcome (el veredicto vigente, que puede provenir de una revisión manual del operador) y el bloque manual_review con outcome y reviewed_at cuando una validación fue revisada a mano. El detalle de la submission además trae documents_gate, un resumen del estado de las validaciones (ok, matched, total y las categorías aún no resueltas). No cambia ningún flujo: son campos aditivos de solo lectura.

​

v2.32

• Decisiones KYC/KYB automáticas: las submissions de verificación ahora son decididas por un motor automático antes de llegar a un revisor humano. Un expediente 100% limpio (documentos verificados, prueba de vida superada, sin coincidencias de sanciones ni PEP, geografía de bajo riesgo) se aprueba en minutos sin cola manual. Las zonas grises (coincidencias AML por homónimo, señales PEP, lectura parcial de documentos, riesgo medio, países de alto riesgo) van siempre a un revisor humano, y los expedientes claramente inválidos (sanciones severas confirmadas, documentos falsos o vencidos) se rechazan automáticamente. Las decisiones finales ahora incluyen decision_source (auto o admin) en los webhooks kyc_verification_status_changed y kyb_verification_status_changed para que sepas cómo se decidió cada expediente. Detalle en KYC y KYB.
• Nuevo valor mágico HOLDREVIEW en el entorno de pruebas: una submission KYC/KYB cuyo nombre del sujeto contiene HOLDREVIEW queda en revisión humana en vez de ser decidida automáticamente, para que puedas ejercitar la cola manual de punta a punta. El mágico complementario MANUALREVIEW mantiene todas las señales limpias pero jamás resuelve la submission por su cuenta, para probar de forma determinista los caminos automáticos de aprobación/rechazo del motor. Ver entorno de pruebas.

​

v2.31

• Campos enriquecidos en operaciones bancarias: GET /v1/banking/operations y GET /v1/banking/operations/{id} ahora exponen los campos opcionales direction (in / out), amount neto, currency, counterparty y reference cuando el banco los reporta — incluidos los depósitos entrantes y las comisiones descubiertas automáticamente en el listado de operaciones. El webhook banking_operation_status_changed no cambia por diseño (liviano + consulta de detalle). Detalles en banking.

​

v2.30

• Mensajes de error saneados en toda la API. El message de un error nunca expone nombres de proveedores, detalles de infraestructura, URLs, bodies crudos del proveedor (JSON/HTML) ni configuración interna — ni en respuestas de la API, ni en webhooks, ni en los campos de estado persistidos. Los rechazos de negocio del procesador conservan su motivo accionable (por ejemplo, por qué se rechazó un documento o una cuenta); las fallas de infraestructura se reemplazan por el mensaje genérico fijo "the payment provider could not process the request" — reintenta esas operaciones con la misma idempotency_key. Sin cambios de shape: solo cambia el contenido de los mensajes.

​

v2.29

• Comisión por compra con tarjeta: las transacciones de tarjeta ahora pueden llevar una comisión transaccional (porcentaje + fijo) configurada por cuenta a través de dos servicios nuevos — card_purchase_virtual y card_purchase_physical. La comisión se estima en la autorización (incluida en la retención del saldo), se recalcula en la liquidación con la configuración vigente en ese momento, y se devuelve prorrateada en reversas y ajustes parciales o totales. Las transacciones de tarjeta ahora exponen fee_asset, fee_amount y fee_refunded_amount (se omiten cuando no hay comisión configurada — las cuentas sin configuración no ven cambios), el comprobante de compra muestra la línea de comisión, y el ledger registra los movimientos como card_fee / card_fee_refund. Detalles en tarjetas.

​

v2.28

• Tarjetas guardadas con verificación del pagador en la página de pago: toda página de pago con tarjeta (la payment_url de un payin card y la opción tarjeta del checkout universal) ahora pide el correo del pagador como primer campo y, si ese correo tiene tarjetas guardadas contigo, le envía un código de verificación antes de mostrarlas — la lista jamás se revela sin verificar. Con “Recordar este dispositivo” (marcado por defecto) el pagador no repite el código por 30 días en ese navegador. Al elegir una tarjeta paga con 3-D Secure sin re-digitarla. Detalle en tarjetas guardadas.

• El checkout universal ya no pide el correo del pagador: la opción tarjeta materializa y redirige directo a la página de pago, donde vive el discovery de tarjetas guardadas. El endpoint público GET /pay/{token}/saved-cards fue eliminado (responde 404) — la lista de tarjetas ya no sale de ninguna superficie sin verificación. Sin cambios de contrato: POST /v1/payins (card y checkout) sigue igual, y stored_card_id server-to-server no exige código (ya conoces a tu cliente).

​

v2.27

• Desactivar y reactivar suscripciones de webhook: nuevo PATCH /v1/webhooks/subscriptions/{subscriptionID} con { "status": "active" | "disabled" } — una suscripción disabled deja de recibir eventos nuevos sin borrarse (las entregas ya encoladas siguen saliendo) y puedes reactivarla cuando quieras. Idempotente: repetir el estado vigente es un no-op 200. Ver la guía de webhooks.

​

v2.26

• Estado de verificación protegido ante eventos tardíos de intentos anteriores: cuando una cuenta reintenta su verificación de identidad (por ejemplo, tras un rechazo), un evento de estado tardío de un intento anterior ya no puede cambiar el estado de verificación de la cuenta ni disparar el correo de decisión — solo el intento más reciente lo decide. Cada intento conserva su historial completo en el panel de administración.

​

v2.25

• Códigos de error de administración documentados: se agregaron los códigos global_treasury_access_disabled e invalid_value al catálogo de errores. Provienen de superficies de administración de organización (el panel CBPay Admin), no de la API a nivel cuenta — ver la nueva sección “Panel de administración de organización”.

​

v2.24

• Instrucciones de depósito para transferencias anunciadas (guía de payins): crear un payin con method: "bank_transfer" en los corredores soportados ahora devuelve un bloque deposit_instructions con la cuenta de destino exacta — bank_name, account_number, account_type, holder_name, holder_tax_id, holder_email, reference_required, un qr_payload para copiar (texto multilínea con la cuenta, el titular y tu referencia/monto) y un qr_png_base64 brandeado. El mismo bloque se repite en el detalle y el listado del payin. El nuevo GET /v1/payins/deposit-instructions?country=&currency=&method= permite previsualizar la cuenta de destino antes de crear el payin. Revisa el FAQ de la guía para entender por qué el QR bancario es para copiar, no para autocompletar.

​

v2.23

• Emails automáticos de decisión de verificación KYC/KYB (onboarding propio): al quedar tu verificación en aprobada, rechazada o con cambios requeridos, recibes un correo brandeado con la organización avisando el resultado. No aplica a verificaciones de un tercero (por ejemplo, tu empresa verificando a un cliente o proveedor) — ahí sigue el webhook kyc_status_changed/kyb_status_changed que ya integraste. El correo no incluye el motivo detallado de un rechazo por razones de seguridad y privacidad.

​

v2.22

• La prueba de vida ahora admite varias sesiones por sujeto (verificación de identidad): el array liveness[] del informe de verificación puede traer más de una entrada por persona — el check de onboarding gate más una o más recapturas de evidencia media_recapture posteriores. Cada sesión ahora trae su propio session_id y purpose (gate o media_recapture). En un KYB, parties[].liveness (singular) se conserva por compatibilidad y siempre apunta a la sesión gate de esa parte, mientras el nuevo parties[].liveness_sessions[] trae todas las sesiones de esa parte. La metadata de media sigue sin URLs (has_selfie, has_video, frame_gestures, hashes) — sin cambio de contrato ahí.

​

v2.21

• Informe de verificación con portada navegable (verificación de identidad): el PDF abre con un índice de tarjetas clicables (icono, título y número de página) que saltan a su sección. Cada sección lleva su icono y su barra de acento, con el mismo lenguaje visual del informe AML.
• Enlaces clicables: los medios adversos del anexo AML llevan un chip “ver fuente” y la URL de verificación pública del cierre es clicable. Por seguridad, solo se embeben enlaces http y https — cualquier otro esquema se descarta y el texto queda sin enlace.
• Fotos con su proporción real: las fotos del documento y de la prueba de vida se muestran sin deformarse, con su leyenda debajo.
• Sin páginas en blanco ni títulos huérfanos: cada encabezado de sección reserva el alto de su primer bloque, así que nunca queda solo al pie de una página.
• El estado agregado de medios adversos se lee “Review” (antes “In review”) en la versión en inglés.

​

v2.20

• Evidencia visual en el informe de verificación (verificación de identidad): cuando el proveedor publica media de liveness (selfie / frames) o fotos del documento de identidad, el PDF embebe las fotos best-effort. Si no hay media o el enlace expiró, la sección de fotos se omite. El JSON del informe solo declara metadata (has_selfie, gestos, has_video, hashes) — jamás URLs firmadas.
• Anexo AML completo al cierre del PDF: si hubo screening, el informe reutiliza el mismo cierre del informe AML (atribución, estadísticas de cobertura, bloques de fuentes y aviso legal). Sin screening queda el disclaimer genérico.

​

v2.19

• Informe de verificación completo, sin datos descartados (verificación de identidad): el informe KYC/KYB pasó de resumen a expediente. Además de lo que ya traía, el JSON y el PDF ahora incluyen el perfil económico declarado (origen de fondos, propósito de la relación, volúmenes e ingresos esperados, cadenas esperadas), las declaraciones de riesgo (servicios monetarios, fondos de terceros, actividades de alto riesgo, países prohibidos), la cuenta bancaria enmascarada en origen (el número completo jamás entra al informe), la identidad de empresa extendida (constitución, jurisdicción, industria ISIC, sitio web, países de operación, dirección registrada) y el residual del expediente: todo campo verificado que no calce en una sección estructurada sale igual en el bloque de campos.
• Partes relacionadas con su propio screening AML (KYB): cada UBO, persona de control y firmante del expediente sale como una entrada de parties[] con su identidad, su participación, los documentos y la prueba de vida que le corresponden y su propio screening AML con monitoreo continuo activado. Sin costo: es diligencia, no un producto facturable. El par (source, index) es la identidad estable de la parte, así que su screening es siempre el mismo por más veces que descargues el informe. Si una parte todavía no tiene screening al descargar, el informe sale con "partial": ["party_aml_unavailable"] y el faltante se ejecuta en segundo plano.
• Screening AML con el detalle de cada coincidencia: la sección AML del informe completo (terceros y lectura admin) trae ahora indicadores, alias, listas de sanciones con fuente y vigencia, cargos PEP, vínculos RCA y medios adversos — el mismo nivel de detalle del informe AML. En el informe de tu propio onboarding la sección sigue agregada (clear / under_review, sin coincidencias), y lo mismo aplica al screening de tus partes relacionadas.
• Validación documental en el detalle de documentos: cada documento del informe expone validated_at y, cuando corresponde, el motivo de rechazo, junto a categoría, archivo, estado, outcome y score.

​

v2.18

• Montos siempre en decimal plano (payins): el campo local_amount de los payins (y el amount de los eventos de cobro) se devuelve siempre como texto decimal — por ejemplo "5000000" —, nunca en notación científica. En depósitos de montos altos en monedas sin decimales (CLP, PYG, COP) un abono podía quedar registrado como "5e+06": el monto era ilegible para tu integración y el abono no lograba emparejarse con su transferencia anunciada, quedando sin acreditar. La corrección aplica también a los registros históricos: al consultarlos por la API se leen ya normalizados, sin que se altere ningún dato contable.

​

v2.17

• Informe de verificación KYC/KYB descargable (verificación de identidad): cada submission de KYC/KYB tiene ahora su informe de verificación generado por la plataforma, en ?format=pdf|json y ?lang=en|es|zh. Terceros: GET /v1/kyc/submissions/{submissionID}/verification-report y GET /v1/kyb/submissions/{submissionID}/verification-report (cuenta empresa, informe completo: identidad verificada, ciclo de vida, documentos + OCR, liveness y screening AML con matches). Onboarding propio: GET /v1/me/verification/report (misma estructura con la sección AML agregada). Sin costo — es lectura de la verificación ya pagada.
• Código de verificación pública del informe: el PDF imprime un código HMAC + QR y cualquiera puede validar el documento en GET /verify/reports/{code} (JSON o página HTML, sin datos personales: solo tipo, estado vigente de la decisión, fecha y organización emisora).
• Códigos de error nuevos: invalid_format (400, format distinto de pdf/json) y verification_not_found (404, la cuenta aún no envió ninguna verificación); invalid_language aplica también a este informe.

​

v2.16

• Los cobros QR se acreditan siempre solos (payins): un QR pagado podía quedar pending mientras el dinero entraba como depósito sin asignar, porque la transferencia del banco no trae la referencia del cobro y la conciliación por monto está reservada a las transferencias anunciadas. Ahora el abono que liquida un cobro (QR, link de checkout o tarjeta) viaja con el vínculo al cobro pagado y se rutea uno a uno a su payin — sin heurística. El payin acreditado lo declara con match_method: charge_link, la señal de conciliación más fuerte de todas.
• Enum documentado de match_method: la referencia listaba single_candidate y dedicated_instrument, que no existen en la API. Los valores reales son amount_single_candidate y dedicated_clabe; se agregaron charge_link y manual_assign (un admin ruteó el depósito a mano) al spec.

​

v2.15

• Las transferencias anunciadas ya respetan la idempotencia (payins): POST /v1/payins con method: "bank_transfer" aceptaba idempotency_key y la ignoraba, así que un reintento (timeout, doble clic) abría un segundo anuncio. Dos anuncios vivos con el mismo monto son justo el caso que la conciliación se niega a resolver, por lo que el abono real quedaba unassigned. Ahora un reintento con la misma clave — campo del body o header Idempotency-Key — devuelve el anuncio original (misma reference, HTTP 200 con idempotency_hit: true). Un POST sin clave reutiliza un anuncio vivo idéntico (misma cuenta, moneda, monto y pagador) en vez de duplicarlo. Para cobrar dos pagos reales del mismo monto al mismo pagador, manda una clave distinta en cada anuncio. Reutilizar una clave que ya usaste con OTRO método de payin (QR, checkout, tarjeta) responde ahora 409 idempotency_conflict en vez de devolver un objeto que no corresponde.

​

v2.14

• Identificación del pagador en transferencias anunciadas (payins): POST /v1/payins con method: "bank_transfer" acepta los opcionales payer_name, payer_document y payer_account. Si no mandas payer_document y la cuenta es una persona verificada, se usa por defecto el documento del titular, así un depósito que llega sin referencia igual se reconoce por el ordenante que reporta el banco. La respuesta indica qué identidad quedó en juego con payer_source (declared, account_identity o none).
• Auditoría del match en el payin: GET /v1/payins/{id} expone match_method (reference, payer_document, payer_account, payer_name, single_candidate…) y el bloque payer que reportó el riel, para que veas exactamente por qué el depósito cayó en esa cuenta.

• Las transferencias anunciadas ya no matchean “la más antigua” por monto: si dos o más anuncios pendientes comparten monto y moneda y nada identifica al pagador, el depósito queda unassigned en vez de acreditarse a la cuenta equivocada (fail-closed). El match solo por monto sobrevive cuando hay exactamente UN candidato. Documentado en la sección nueva Cómo se concilia una transferencia anunciada.

​

v2.13

• Cuota del handshake del stream de eventos (errores): abrir GET /v1/events demasiadas veces seguidas ahora responde 429 rate_limited. Es un limite distinto de too_many_streams: rate_limited cuenta intentos de conexion por IP (600 por hora, de sobra para reconexiones), mientras too_many_streams limita cuantos streams mantienes abiertos a la vez (5 por cuenta). Los dos se reintentan igual: esperas y reconectas con tu Last-Event-ID, no se pierde nada.

​

v2.12

• Stream de eventos en tiempo real (guía): GET /v1/events abre una conexión Server-Sent Events con todo lo que pasa en tu cuenta — los mismos eventos de los webhooks, entregados al navegador sin esperar un polling. Reconectas con el header Last-Event-ID y el servidor replaya lo que te perdiste, filtras con ?types= y pides el estado actual absoluto con ?snapshot=true.
• Historial de eventos consultable: GET /v1/events/history (con from/to, paginación y filtro por tipo) y GET /v1/events/{eventID} leen el mismo log que alimenta el stream, con retención de 90 días.
• Tres eventos nuevos (webhooks): balance_adjusted (un administrador acreditó o debitó tu saldo), account_status_changed (tu cuenta fue suspendida o reactivada) y member_security_event (inicios de sesión, cambios de contraseña o 2FA, sesiones revocadas). Llegan por webhook y por el stream.
• Códigos de error nuevos (errores): too_many_streams, stream_unavailable y streaming_unsupported.

​

v2.11

• Devoluciones de cobros con tarjeta (guía): POST /v1/payins/{payinID}/refunds devuelve un cobro con tarjeta completo o parcial y descuenta el monto de tu saldo en el momento. La devolución exige clave de idempotencia (el reintento con la misma clave nunca devuelve dos veces) y código OTP cuando la pides con tu sesión. GET /v1/payin-refunds lista tus devoluciones con filtros por cuenta, estado, tipo y rango de fechas, GET /v1/payin-refunds/{id} trae el detalle y GET /v1/payin-refunds/{id}/receipt genera el comprobante PDF con código verificable.
• Estado de devolución en el cobro: los payins devueltos exponen refund_status (partial o full), refunded_amount (USDT acumulado descontado) y refunded_local (monto acumulado devuelto al tarjetahabiente).
• Webhook payin_refunded (webhooks): notifica cada devolución, anulación y contracargo con su tipo, estado, montos y el saldo resultante.

• La comisión y el margen de tasa no se reembolsan: al devolver un cobro se descuenta el bruto acreditado; lo que cobramos por procesar el pago se mantiene. Un contracargo notificado por el emisor se aplica automático y puede dejar tu saldo en negativo hasta que lo fondees.
• Códigos de error nuevos (errores): payin_not_refundable, refund_not_supported, refund_exceeds_payin e invalid_amount.

​

v2.10

• Página pública de estado del servicio rediseñada (guía): la página que entrega status_page_url ahora muestra bandera por país, ícono por método de pago, una barra de disponibilidad día a día de los últimos 90 días, una tarjeta de resumen con el estado general y el uptime promedio, y una línea de tiempo de incidentes con los motivos redactados en lenguaje claro. Toma el logo, los colores y el sitio web de tu organización, sigue sin JavaScript ni recursos externos (se puede embeber o compartir con tus clientes) y el JSON de /v1/status/{token} no cambia.

​

v2.09

• Tarjetas internacionales en dólares (guía): POST /v1/payins con country: "US", currency: "USD" y method: "card" devuelve una payment_url de checkout hosted con 3-D Secure y la marca de tu organización para cobrar con tarjetas Visa, Mastercard, American Express, Discover y Diners emitidas en cualquier país. El contrato es el mismo que el de la página de tarjeta de Bolivia (customer opcional, success_url/failure_url, expires_at, intentos limitados y retry idempotente que devuelve la misma URL) y el guardado de tarjeta también: save_card + payer_reference guardan la tarjeta con el consentimiento del pagador para cobros posteriores y suscripciones. El 3-D Secure se ejecuta dentro de la página (si el emisor pide desafío, el pagador lo completa ahí mismo) y los datos de la tarjeta se ingresan en campos seguros del procesador: nunca pasan por tu integración. El corredor se habilita por cuenta — GET /v1/payins/methods es la fuente de verdad de lo que puedes cobrar hoy.

​

v2.08

• Estado del servicio en tiempo real (guía): cada método de GET /v1/payouts/methods y GET /v1/payins/methods ahora trae el campo aditivo availability (operational / degraded / down), el nuevo webhook broadcast corridor_status_changed notifica cada transición de disponibilidad, y cada organización tiene una página de status pública con su marca (HTML + JSON en /status/{orgToken} y /v1/status/{orgToken}) con uptime de 90 días e historial de incidentes. La URL de la página se expone en GET /v1/branding como status_page_url.

​

v2.07

• Docs Knowledge Pack para IA/MCP: esta documentación ahora se publica también como un paquete estructurado y versionado en /mcp-pack/manifest.json (specs OpenAPI en 3 idiomas, guías por página en Markdown puro, catálogo de errores y webhooks, guía de pruebas con los valores mágicos del simulador, recetas end-to-end y chunks listos para RAG). Es la fuente oficial que alimenta el servidor MCP de la documentación.

• Markdown compilado CBPAY_DOCUMENTACION.md retirado: el documento único en español queda obsoleto — su reemplazo es el Docs Knowledge Pack (trilingüe, con specs completos) y el servidor MCP.

​

v2.06

• FAQ ancla en todas las guías de producto: payouts, payins, checkout, transferencias, crypto, banking, tarjetas, cartola, QR payout y tarjetas guardadas + suscripciones cierran ahora con preguntas frecuentes y el link directo al catálogo de errores.
• Catálogo de errores y webhooks completado: se documentaron códigos de error y eventos de webhook que existían en la API pero faltaban en las páginas de referencia. Sin cambio de contratos.

​

v2.05

• Overhaul de docs, fase 5 (solo referencia de API, sin cambio de código): la referencia de API agrupa las operaciones bajo tres tags nuevos — Checkout (páginas públicas /pay/{token} y cotizaciones), Tarjetas guardadas (/v1/stored-cards y consultas de tarjetas guardadas) y Suscripciones (/v1/subscriptions). Estas operaciones vivían apiladas bajo el tag genérico Payins; ningún path ni contrato cambió.

​

v2.04

• Guías propias por producto, extraídas de los monolitos de payins/payouts: Checkout, Tarjetas guardadas y suscripciones y Payout QR. Las secciones originales conservan sus encabezados y enlazan a las guías nuevas, así los anchors históricos siguen resolviendo.
• Flujos end-to-end nuevos en Flujos de integración: checkout, tarjetas guardadas y suscripciones, cobros QR POS y swaps de saldos, cada uno con su diagrama de secuencia.

• Navegación de Productos reorganizada por familia: Cobrar (money in), Pagar (money out), Saldos y cuenta, Identidad y compliance, y Experiencia — en vez de una lista plana de 17 páginas.
• Perfil y seguridad y Seguridad y 2FA (OTP) ahora se cruzan y declaran sus roles: la guía de perfil es la casa de los factores 2FA del usuario; la página OTP cubre el flujo de desafíos por acción.

​

v2.03

• Ambiente de pruebas visible en todo el sitio: cada guía de producto ahora abre con las URLs base de test y live (snippet compartido), y el FAQ, el inicio rápido y la introducción describen correctamente el ambiente de pruebas (https://cryptobank.qbank.cl/platform, keys pk_test_) — copias anteriores decían, erróneamente, que no había sandbox. Detalle completo en Entorno y pruebas.

• Catálogo de productos de la introducción completado: checkout, tarjetas y suscripciones, QR POS, swaps, wallets segregadas, Bitcoin y analytics ahora aparecen con sus guías.

• Descripciones del spec anteriores a los saldos multi-activo: descripciones de tags realineadas (Swaps, AML screening, Cards) y redacciones antiguas como “se acredita al saldo USDT” corregidas a la semántica de settlement asset (default_payin_asset, settlement_asset).

​

v2.02

• La auto-conversión al default_payin_asset ejecuta al precio real, sin spread de swap (modelo de dinero): el payin ya pagó su comisión y su tasa al acreditar, así que la conversión automática al saldo configurado no cobra un costo adicional — no existe doble conversión. Siguen aplicando los límites por operación/24 h de los assets volátiles (BTC/GOLD). Los swaps manuales (POST /v1/swaps) mantienen su spread normal.

​

v2.01

• Código de error reserved_idempotency_key (400) en POST /v1/swaps (errores): las claves de idempotencia con prefijo payin-convert: o checkout-swap: están reservadas para las auto-conversiones del sistema (saldo predeterminado de payins y checkout) y se rechazan. Usa cualquier otra clave para tus swaps.

​

v2.00

• Saldo predeterminado para payins (default_payin_asset) (modelo de dinero): configura en qué saldo quieres quedarte con tus cobros. PUT /v1/settlement acepta ahora default_payin_asset (USDT, USDC, BTC o GOLD) y GET /v1/settlement lo expone. El payin sigue acreditando en USDT (pricing y comisiones intactos) y el neto se auto-convierte a tu asset con el motor de swaps (mismo spread y límites de un swap). Si la conversión falla queda conversion_status: pending_retry y se reintenta automático. GET /v1/payins, el detalle y el webhook payin_credited exponen settlement_asset y conversion_status cuando hay conversión.

• Un link de checkout creado sin settlement_asset ahora usa el default_payin_asset de la cuenta (antes siempre USDT).

​

v1.99

• Comisión propia para cobros con tarjeta (payin_card) (comisiones): los cobros acreditados con tarjeta (payin directo method: card, links de checkout pagados con tarjeta y cobros recurrentes con tarjeta guardada) pueden llevar una comisión porcentual propia, configurable por moneda (ej. un % para BOB y otro para USD). Si tu cuenta no tiene payin_card configurado, sigue aplicando la comisión payin de siempre — nada cambia sin configuración explícita. Consulta tus comisiones vigentes en GET /v1/fees (las filas ahora incluyen el campo currency).

​

v1.98

• GET /v1/banking/accounts/{bankAccountID} (guía banking): detalle en vivo de una cuenta bancaria — nombre, moneda, estado y los requisitos para recibir fondos (rieles wire y locales) bajo data. Úsalo para mostrar las instrucciones de depósito de una cuenta específica sin recorrer el listado.

• Listado de cuentas bancarias: la API ahora expone solo las cuentas habilitadas para tu operación según la configuración del corredor. Las cuentas no habilitadas dejan de aparecer en GET /v1/banking/accounts y sus consultas por id responden 404.

​

v1.97

• Página de cobro — tarjeta guardada por defecto: con tarjetas guardadas para el correo ingresado, el botón principal ahora paga con la tarjeta guardada (el texto cambia a “Pagar con VISA ···· 1234”) en vez de iniciar un pago con tarjeta nueva. Usar una tarjeta distinta queda como acción explícita (“Usar otra tarjeta”). Antes, presionar el botón principal con la tarjeta listada llevaba a la página de pago pidiendo todos los datos de nuevo.

​

v1.96

• Nuevo corredor: Argentina 🇦🇷 (guía payouts · guía payins):
  • Payouts en ARS y USD por bank_transfer a cualquier CBU o CVU de 22 dígitos (cuentas bancarias y billeteras virtuales; USD solo CBU→CBU). Beneficiario con name, tax_id (CUIT/CUIL) y account_number — sin bank_code.
  • Payins en ARS con cuenta CVU dedicada por cuenta (POST /v1/payins/deposit-accounts con country: "AR"): toda transferencia entrante se acredita automáticamente, sin referencias. Las CVU son receive-only: los intentos de débito directo se rechazan automáticamente.
  • Disponible ya en el ambiente de pruebas (staging) con el simulador; la activación en producción se anunciará al completarse la certificación bancaria — el catálogo (GET /v1/payouts/methods y GET /v1/payins/methods) es siempre la fuente de verdad.

​

v1.95

• Facturación en archivo con la tarjeta guardada (guía payins): los datos de facturación que el pagador ingresa al guardar su tarjeta (nombre, dirección, ciudad, correo, teléfono) quedan guardados junto con la credencial. Al pagar de nuevo con esa tarjeta la página segura los aplica automáticamente — el pagador no re-tipea nada — y muestra solo un resumen enmascarado (nombre, correo parcial y ciudad) con un enlace “usar otros datos” por si quiere cambiarlos. Los datos completos jamás bajan al navegador: el servidor los aplica al autorizar.

• Correo del titular obligatorio con tarjeta guardada: en la página pública del checkout, usar una tarjeta guardada ahora exige presentar el mismo correo del titular con el que se guardó — si no calza, responde 404 (protección anti-enumeración de datos personales).

​

v1.94

• Página de checkout — pago con tarjeta en 1 clic (guía payins): al continuar con tarjeta, la página pública ahora redirige directo a la página segura de pago — se eliminó el botón intermedio que exigía un segundo clic. Elegir una tarjeta guardada de la lista inicia el pago de inmediato.
• Tarjeta guardada en el checkout: elegir una tarjeta guardada ahora llega siempre a la página segura con la credencial aplicada (muestra marca y últimos 4 dígitos, sin pedir el número de nuevo). Antes, la re-validación del correo podía descartar la selección en silencio y la página pedía todos los datos otra vez. Además, cambiar la elección en el mismo link (guardada ↔ tarjeta nueva) regenera la sesión de pago correcta en vez de reusar la anterior.

​

v1.93

• Webhooks de banking para terceros (webhooks, guía banking): el webhook banking_customer_status_changed ahora también se emite cuando cambia la verificación de un tercero registrado por tu cuenta (antes solo llegaba el del perfil propio). El payload agrega customer_kind (self | third_party) y, para terceros, third_party_id (el mismo id de GET /v1/banking/third-parties/{id}).

​

v1.92

• Monto de los cobros checkout en el historial de payins (guía payins): GET /v1/payins y GET /v1/payins/{payin_id} ahora incluyen siempre la denominación de los payins de checkout y QR POS — settlement_asset + asset_amount (y conversion_status cuando aplica) — en todo estado, incluidos pendiente y vencido. Antes el monto solo aparecía al acreditarse y las filas pendientes salían sin monto. Además, un cobro liquidado en crypto o vía la app CBPay expone su usdt_credited aunque no lleve fx_rate. Los exports CSV/XLSX agregan las columnas settlement_asset y asset_amount.

​

v1.91

• Suscripciones (cobros recurrentes agendados) (guía payins): la plataforma lleva el calendario de los cobros sobre una tarjeta guardada. POST /v1/subscriptions (interval daily/weekly/monthly/yearly, start_at opcional para trial, idempotency_key obligatoria) cobra el primer período al crear y dispara los siguientes solos. Recurso completo GET /v1/subscriptions (+/{id}, filtros status/stored_card_id/payer_reference) y ciclo de vida POST .../pause · /resume · /cancel. Dunning ante declines (reintento diario ×3 ⇒ past_due), sin catch-up al reanudar, y cancelación automática al revocar la tarjeta. Cada cobro exitoso acredita como payin de tarjeta (payin_credited con subscription_id). Webhook nuevo subscription_status_changed.

• Tarjetas guardadas y cobros recurrentes (guía payins): el método card ahora soporta credencial almacenada (mandato COF de las marcas). POST /v1/payins acepta save_card (checkbox de consentimiento en la página hosted), payer_reference (tu ID del cliente) y stored_card_id (pagar con una tarjeta guardada sin re-digitar el número; el 3-D Secure corre igual). Recurso nuevo GET /v1/stored-cards (+/{id}, DELETE para revocar) y cobros iniciados por el comercio sin el pagador presente: POST /v1/stored-cards/{id}/charges (recurring para suscripciones; idempotency_key obligatoria — un retry jamás cobra dos veces). El número de tarjeta jamás existe en la plataforma: solo display (marca, últimos 4, expiración). Webhooks nuevos card_stored y stored_card_revoked; error nuevo 422 stored_card_revoked (errores).

​

v1.89

• Controles de cumplimiento en pagos salientes (guía payouts, errores): los payouts, los retiros crypto con nombre de beneficiario y los cobros collect ahora pasan por controles de cumplimiento adicionales antes de mover fondos. Errores documentados: 403 compliance_hold (la operación fue retenida y NO se creó — sin débito; por política no se informa la razón exacta, contacta a soporte con el timestamp) y 503 compliance_check_unavailable (la verificación no se pudo evaluar; la operación NO se creó — reintenta con la misma idempotency_key).

​

v1.88

• Shapes de persona del screening AML (guía): el motor de screening exige date_of_birth como objeto {year, month, day} (el string "YYYY-MM-DD" responde 422), nationality como array de códigos ISO-3166 y personal_identification[] como { "issuing_country", "number" } sin campo type. Guía y ejemplos del spec actualizados con los shapes verificados en vivo.

​

v1.87

• QR Crypto POS — cobros QR crypto con monto para procesadores (guía): las cuentas empresa con POS físicos registran a sus comercios como merchants verificados (KYB/KYC de terceros aprobado) y generan cobros crypto (USDT, USDC, BTC) con dirección exclusiva y QR por venta. Detección temprana del pago para el POS (confirming en segundos), crédito con conversión automática al settlement asset, atribución por merchant en cobros/webhooks, resumen de conciliación (GET /v1/pos/summary) con comisión informativa por merchant y neto a repartir, y devoluciones por el riel de retiro crypto con tope duro (jamás más de lo recibido). Rutas nuevas bajo /v1/pos/* (tag QR Crypto POS del API Reference); pagos parciales acumulan y los pagos tardíos a un cobro expirado se acreditan igual.

​

v1.86

• QR crypto de Bitcoin: el QR del checkout ahora lleva la dirección bech32 cruda (igual que TRON/ETH). Las apps de exchanges como Binance rechazaban el URI BIP-21 (bitcoin:…?amount=…) como “invalid QR”; el monto exacto sigue visible al lado con botón copiar.
• Página de cobro: favicon white-label (símbolo de la org) y el texto del panel ya no parte palabras a mitad (“momento” → “moment”/“o”) — el word-break agresivo quedó solo en las direcciones monospace.

​

v1.85

• CLABE dedicada por link de cobro (México): materializar bank_transfer MX en un link de cobro universal ahora emite (o toma de un pool reciclable) una CLABE exclusiva de ese link. El pagador transfiere el monto exacto sin poner referencia: el abono se detecta y rutea al link automáticamente por la cuenta de destino. El payload de la materialización lleva destination con dedicated: true; si la cuenta dedicada no puede emitirse, degrada al camino clásico (cuenta del comercio + reference obligatoria en la glosa). Las CLABEs se reciclan con período de enfriamiento al resolverse el link (pagado o expirado).

​

v1.84

• Cobros pull en el link de cobro universal (Venezuela): la página del checkout ahora ofrece los métodos que cobran directo en la cuenta del pagador (c2p y debito_inmediato en VE). El pagador completa banco, documento, teléfono o cuenta y la clave OTP en la misma página; el monto siempre es el congelado en la cotización. Endpoints públicos nuevos: POST /pay/{token}/collect/otp (solicita la clave cuando el rail la envía a demanda) y POST /pay/{token}/collect (ejecuta el cobro; si el rail confirma síncrono el link queda pagado en la misma llamada). En el catálogo de GET /pay/{token}/quote estos métodos llegan con collect: true.
• Fiat multi-moneda por país: cada país del quote lista sus corredores en options[] — una fila por método+moneda (ej. Bolivia con QR en BOB y en USD) con su local_amount en country_quote. Materializar un método ofrecido en varias monedas exige &currency=YYY (el error 400 currency_required ahora aplica a cualquier método, no solo tarjetas).
• Cuenta de destino en transferencias bancarias: cuando el corredor usa una cuenta de depósito dedicada (la CLABE en México), la materialización de bank_transfer incluye destination (tipo, número de cuenta y beneficiario) además de la referencia — el pagador ya sabe adónde transferir sin salir de la página.

• Banderas SVG en la página de pago: las banderas de países y monedas ahora son imágenes SVG (se ven igual en Windows, macOS y móviles; antes algunos sistemas mostraban el código del país en texto). En la pestaña Tarjeta, la bandera se deriva de la moneda del cargo (USD → bandera de Estados Unidos, aunque el adquirente sea de otro país).

• La página del checkout ya no responde 429 too_many_attempts por el solo hecho de estar abierta: los límites de tráfico de lectura, materialización, OTP y cobro ahora son independientes entre sí.

​

v1.83

• Pestaña Tarjeta en el link de cobro universal: el pago con tarjeta sale de la pestaña Fiat y ahora tiene su propia pestaña, listada por moneda de cargo (hoy BOB y USD; monedas de adquirentes futuros aparecen solas). GET /pay/{token}/quote responde el catálogo nuevo cards[] (país, moneda y local_amount por opción) y countries[] deja de listar card entre los métodos. Materializar una tarjeta exige la moneda: POST /pay/{token}/methods/card?country=XX&currency=YYY — sin ella responde el error nuevo 400 currency_required. Cada moneda es una materialización independiente con su propia página de pago hosted.

• Página de pago con identidad visual reforzada: logos de los assets (USDT, USDC, BTC, GOLD) junto al monto y en los grupos crypto, banderas por país en el selector Fiat y en las filas de tarjeta, íconos por método, y un timer de expiración prominente (pill con reloj; bajo 1 hora muestra cuenta regresiva y bajo 10 minutos cambia a rojo).

• La página del checkout ya no se desplaza sola hacia el panel activo cada pocos segundos: el refresco automático re-renderiza solo cuando cambia la data y nunca mueve el scroll (solo la selección manual de un método lleva la vista al detalle).

​

v1.82

• Página de pago del checkout universal rediseñada: las opciones ahora se organizan en tres pestañas — CBPay (QR + alias del comercio, con botón de copiar), Crypto (monedas agrupadas por red; las redes nuevas aparecen solas al habilitarse) y Fiat (selector de país + métodos con el monto local cotizado). Botones de copiar en alias, direcciones, montos y referencias. Sin cambios de API: la URL, el contrato de creación y los endpoints públicos (/state, /quote, /methods/{method}) son los mismos.

​

v1.81

• Payout QR — validación antes de crear el payout: un POST /v1/payouts/qr/scan con un QR ilegible o dinámico ahora responde 400 invalid_qr_payload con el motivo concreto (antes devolvía un 502 genérico). En el confirm de Brasil, un monto que no coincide con un QR PIX de monto fijo responde 422 con el payout failed y el reembolso ya aplicado — y el QR queda intacto para reintentarlo con el monto correcto y una clave nueva.
• QR PIX estático reutilizable: el guard “un QR = un pago” ya no aplica a los QR PIX estáticos de Brasil (se pagan muchas veces por diseño); la protección por pago es tu idempotency_key, que en Brasil es obligatoria en cada confirm.

​

v1.80

• Payout por QR PIX en Brasil (BR/BRL): el flujo de dos pasos POST /v1/payouts/qr/scan → POST /v1/payouts/qr/confirm ahora acepta QR PIX estáticos de Brasil (incluido el código “copia e cola”) — envía country: "BR" y currency: "BRL". El scan decodifica el BR Code localmente (sin costo) y devuelve nombre del comercio, llave PIX y monto; el confirm paga por PIX con el mismo pricing de un payout normal. amount es siempre obligatorio: los QR de monto fijo exigen coincidencia exacta (un mismatch responde 422 con el payout failed y reembolso automático — el QR no se inutiliza). Un QR PIX estático es reutilizable: cada pago lleva su propia idempotency_key. Los QR dinámicos o corruptos responden 400 invalid_qr_payload — usa el método pix con la llave del beneficiario. Disponible en el ambiente de pruebas con QRs de ejemplo y valores mágicos (montos .99 fallan) — ver Entorno y pruebas. Detalle en la guía de payouts.

​

v1.79

• Link de cobro universal v2 — multi-país + liquidación en el saldo elegido (Breaking sobre el shape v1 de ayer): el cobro ahora se denomina en cualquiera de tus 4 saldos virtuales con settlement_asset (USDT default, USDC, BTC, GOLD) y amount EN ese asset (“50” USDT, “0.001” BTC, “2” g de oro); enviar currency responde 400 (los links v1 existentes siguen operando). El pagador ve todos los países con corredor de payin vivo (elige país → métodos con el monto local cotizado y congelado al materializar), las 4 opciones crypto con QR escaneable (qr_payload + qr_png_base64; BIP-21 en BTC, dirección cruda en tokens TRON/ETH — legible por Trust Wallet, MetaMask, Binance y wallets externas), y el QR + alias CBPay del comercio para pagar al instante desde la app (deeplink cbpay:pay?to=…&checkout=…; POST /v1/transfers acepta checkout_token y valida el due server-side). Todo pago se auto-convierte al settlement_asset al acreditar (mismo asset no convierte); conversion_status visible en /state. Endpoint público nuevo GET {checkout_url}/quote con el catálogo de países, dues crypto y dues CBPay. Errores nuevos country_required, country_unavailable, settlement_asset_disabled y checkout_amount_mismatch. Detalle en la guía de payins.

​

v1.78

• Detalle del rechazo en cobros activos fallidos: cuando un cobro activo (collect, C2P o débito inmediato) queda failed, el payin ahora incluye un objeto failure con el origen del rechazo (provider = el banco del pagador, core = la validación previa al cobro), el código y el mensaje concretos — visible en la respuesta síncrona del POST, en GET /v1/payins/{id} y en el webhook. Antes solo se veía el estado failed genérico. Detalle en la guía de payins.

​

v1.77

• Link de cobro universal (checkout): POST /v1/payins acepta method: "checkout" y devuelve checkout_url — una página pública brandeada donde el pagador elige cómo pagar: QR, tarjeta, transferencia bancaria o crypto (USDT en TRON, USDT/USDC en Ethereum y BTC) con una dirección de depósito exclusiva de ese cobro y acumulación de pagos parciales. Un link = un cobro: el primer método que completa el pago gana. Estado consultable sin auth en GET {checkout_url}/state; el payin_credited de un pago crypto agrega settled_via y crypto_amount. Soporta success_url, failure_url, expires_in (10 minutos a 7 días) e idempotencia (el retry devuelve el mismo link). Errores nuevos already_paid, checkout_expired y method_unavailable. Detalle en la guía de payins.

​

v1.76

• Filtro de autenticación previo a la captura en pagos con tarjeta: los cargos con tarjeta solo se envían al procesador cuando la verificación 3-D Secure terminó con autenticación exitosa o intentada y con los datos de autenticación completos; un intento sin autenticación real se rechaza antes de mover fondos y el pagador puede reintentar. La página de pago además extendió la recolección de datos del dispositivo (~11 s) para mejorar la tasa de aprobación de los bancos emisores. En el ambiente de test, el monto terminado en .44 simula un intento rechazado por este filtro (tabla completa en Ambiente de pruebas).

​

v1.75

• Pago con tarjeta (card) en payins: POST /v1/payins acepta method: "card" (Bolivia, BOB o USD) y devuelve payment_url — una página de pago alojada con el branding de tu organización donde el pagador ingresa su tarjeta en campos seguros y pasa la verificación 3-D Secure de su banco. Campos opcionales customer, success_url, failure_url y expires_at. El pago confirmado llega por el webhook payin_received y acredita el saldo como cualquier payin; si nadie paga, payin_expired cierra el cobro. Detalle en la guía de payins.

​

v1.74

• account_id en swaps y address screenings: las respuestas de POST/GET /v1/swaps y POST/GET /v1/screenings/addresses ahora incluyen account_id (la cuenta dueña de la operación). Para integraciones de una sola cuenta es informativo; en vistas administrativas permite atribuir cada registro.

​

v1.73

• Bitcoin on-chain (btc/btc): cuarta red soportada del producto crypto. Toda cuenta nace ahora con cuatro wallets de depósito (se suma la de Bitcoin, dirección bech32 bc1q…); los depósitos BTC acreditan el saldo BTC (confirmación ~30 min, 3 bloques) y los retiros on-chain aceptan chain: "btc" (destinos bech32, taproot y legacy; el fee de red lo cubre la operación, el destinatario recibe el monto exacto). Las wallets segregadas también soportan el par btc/btc (sin gas: el fee sale del saldo de la wallet). Travel Rule aplica igual que en las demás redes, valorando el monto a USD. Detalle en la guía crypto.

​

v1.72

• El login en dos pasos también respeta el cooldown del teléfono: con 2FA de login por SMS/WhatsApp y un número recién enlazado sin verificar, el código del login se emite por un factor más fuerte (app autenticadora, luego email de login) en vez del teléfono — el channel efectivo llega en la respuesta del login. Sin factor alternativo el login responde 403 phone_binding_cooldown hasta que venza el cooldown. El código jamás viaja a un número enlazado desde la propia sesión. Detalle en la guía de seguridad y 2FA.

​

v1.71

• Desafíos OTP con teléfono en cooldown caen a un factor más fuerte: con el número recién enlazado (cooldown de 24 h), POST /v1/otp/challenges ya no bloquea si tienes la app autenticadora enrolada o tu email verificado — el desafío se emite automáticamente por ese canal (jerarquía totp > email) y la respuesta indica el canal efectivo. El 403 phone_binding_cooldown queda solo para cuentas sin factor alternativo. Antes, el cooldown bloqueaba toda relajación del 2FA (incluso desactivar el canal email) aunque tuvieras factores más fuertes disponibles. Detalle en la guía de seguridad y 2FA.

​

v1.70

• Identidad verificada como fuente de verdad del perfil: al aprobarse tu onboarding KYC/KYB, display_name (persona = nombre + apellido; empresa = razón social), tax_id y country se rellenan automáticamente desde la identidad verificada. Documentado en la guía de KYC y la guía de perfil.

• PATCH /v1/me bloquea los campos de identidad tras verificar: con kyc_status: approved, cambiar display_name, tax_id o country responde 409 identity_locked (código nuevo en la página de errores). phone sigue editable con su propio flujo de verificación.

​

v1.69

• Informe PDF del screening AML: GET /v1/aml/screenings/{screeningID}/report descarga cada screening de tu historial como informe PDF ejecutivo con tu branding — portada con la decisión y su semáforo de riesgo, indicadores (sanciones, watchlists, PEP, prensa adversa…), coincidencias consolidadas, alias, glosario y sección final de respaldo con las fuentes internacionales consultadas. Trilingüe vía lang=en|es|zh (default inglés). Lectura pura, sin comisión. Sección nueva en la guía AML.
• Nuevo código de error invalid_language (HTTP 400): el lang del informe PDF no es en, es ni zh. Documentado en la página de errores.

• Campos de empresa en el AML screening: los ejemplos y el spec documentaban tax_id/registration_number/country_of_incorporation como campos planos de customer.company, pero el motor de screening los rechaza con 422. El identificador va en registration_authority_identification, el país en place_of_registration y incorporation_date es un objeto {year, month, day}. Guía y spec corregidos (verificado en producción).

​

v1.68

• Nuevo corredor: Ecuador (USD) con cuatro métodos de payout — bank_transfer (transferencia bancaria), deuna (billetera DeUna), cash_pickup (retiro en ventanilla sin cuenta) y cnb (corresponsal no bancario). El beneficiario acepta nombres estructurados (given_name/first_surname/…) o el split automático desde name, y un bloque opcional de remitente (sender_name o sus campos estructurados). Ejemplos por método en la guía de payouts y en el spec.
• Nuevo código de error channel_unavailable (HTTP 503): el canal de pago del corredor no está disponible temporalmente. Reintenta más tarde con la misma idempotency_key. Documentado en la página de errores.

​

v1.67

• Las cuentas de test nacen pobladas: toda cuenta nueva del ambiente de test nace con ~6 meses de historia demo realista de todos los productos (payouts, payins, transfers, crypto, swaps, tarjetas, banking, contactos…), con saldos de juego, cartola conciliada y analytics listos para explorar. Aplica a todo camino de creación (registro, login social, creación por admin y el switch test/live del dashboard).

• Ambientes 100% independientes: los datos de test ya no se refrescan desde un snapshot de producción — nada se copia entre ambientes. Guía de entornos y pruebas actualizada.

​

v1.66

• Servidor MCP oficial en https://mcp.cbpayapp.com: conecta tu editor o asistente de IA (Cursor, VS Code, Claude, ChatGPT y cualquier cliente MCP) a esta documentación — búsqueda, endpoints con ejemplos reales y catálogo de errores, sin salir del editor. Solo lectura, sin autenticación. Página nueva Servidor MCP con instalación de un click e instrucciones por cliente.

​

v1.65

• Ambiente de test: las cuentas nuevas ahora nacen con kyc_status: approved — puedes probar todos los productos de inmediato, sin pasar por el onboarding. Aplica a todo camino de creación (registro, login social, creación por admin y el switch test/live del dashboard); las cuentas de test existentes fueron aprobadas retroactivamente. En live nada cambia: las cuentas nacen sin verificar y el KYC/KYB sigue siendo obligatorio antes de que salga dinero. Para probar el flujo de verificación en test, usa las verificaciones KYC/KYB de terceros.

​

v1.64

• PUT /v1/otp/preferences: activar el 2FA de la acción login por canal telefónico (sms/whatsapp) ahora exige el teléfono de la cuenta ya verificado (completa cualquier desafío OTP por SMS/WhatsApp antes). Si el número no está verificado, la API responde 409 phone_verification_required. Este candado evita que un número mal escrito te deje fuera de tu cuenta al activar el 2FA de login.

​

v1.63

• POST /v1/me/passkeys/register/begin y DELETE /v1/me/passkeys/{passkeyID} ahora aceptan un request sin body, tal como lo documenta el spec (body opcional). Antes respondían 400 invalid_json. La contraseña actual sigue siendo obligatoria para las cuentas que tienen contraseña (403 invalid_password si falta o es incorrecta); las cuentas que solo usan login social pasan con su sesión.

​

v1.62

• POST /v1/me/totp/enroll ahora acepta un request sin body, tal como lo documenta el spec (body opcional). Antes respondía 400 invalid_json. La contraseña actual sigue siendo obligatoria para las cuentas que tienen contraseña (403 invalid_password si falta o es incorrecta); las cuentas que solo usan login social pasan con su sesión.
• PUT /v1/otp/preferences con canal email o totp respondía un error 500; corregido — los cuatro canales (sms, whatsapp, email, totp) se guardan correctamente.

• Cartola PDF: los estados de las operaciones ahora aparecen coloreados (verde completado, ámbar pendiente, rojo fallido) para lectura rápida.

​

v1.61

• Los listados de movements, payouts, payins y transfers aceptan ahora el parámetro format=csv o format=xlsx para descargar las filas como archivo listo para contabilidad (hasta 10.000 filas por descarga; los filtros from/to, status y demás aplican igual).

curl -o movimientos.xlsx "https://api.qbank.cl/platform/v1/movements?from=2026-07-01&to=2026-07-13&format=xlsx" \
  -H "Authorization: Bearer pk_…"

• Sin format la respuesta sigue siendo el JSON paginado de siempre — no hay cambios de compatibilidad.

​

v1.60

• Todas las rutas de wallets segregadas se renombran de /v1/wallets* a /v1/segregated-wallets*. Mismos métodos, parámetros, shapes de respuesta, comisiones y webhooks — solo cambia el prefijo del path. No hay alias de compatibilidad: las rutas viejas /v1/wallets* ahora responden 404.
• Mapeo (las 15 rutas siguen el mismo patrón):

• El receipt_url de respuestas, webhooks y emails de comprobantes de envíos/depósitos de wallets ahora apunta al path nuevo.
• Por qué: el prefijo genérico /v1/wallets se confundía constantemente con las wallets de depósito del producto crypto. Esas no cambian y siguen viviendo en /v1/crypto/wallets.

• Las wallets de depósito (/v1/crypto/wallets) ahora incluyen type: "deposit" y receive_only: true.
• Las wallets segregadas incluyen type: "segregated".
• Úsalo para distinguir los dos productos de forma defensiva — nunca solo por la ruta.

​

v1.59

• Cuando un cobro activo (QR o checkout hosteado) vence o falla sin recibir el pago, el payin ahora pasa automáticamente de pending a expired (o failed) — antes podía quedar pendiente indefinidamente.
• Nuevo evento de webhook payin_expired con el payin_id, el estado final, el corredor y la referencia, para que cierres el cobro en tu sistema sin polling. Suscribible en POST /v1/webhooks/subscriptions.
• No se mueve dinero en ningún caso: para reintentar el cobro se crea un payin nuevo.

​

v1.58

• Todos los comprobantes PDF (GET .../receipt) estrenan un diseño de nivel bancario: encabezado con logo y N° de comprobante, icono del producto, monto destacado, detalle en dos columnas, franja “Documento verificable” con QR y pie institucional. El símbolo de la marca aparece como marca de agua sutil; las operaciones no completadas conservan la marca de agua de estado.
• La cartola PDF (GET /v1/reports/statement?format=pdf) suma tarjetas de resumen con iconos, sello de cuadratura verificada e iconos por sección; el Excel mantiene su estructura.
• Los emails (comprobantes, códigos de verificación y avisos de seguridad) comparten ahora una plantilla brandeada con encabezado y pie institucionales de tu organización.
• En los comprobantes de envíos fiat el banco del beneficiario se muestra SIEMPRE por nombre: si la operación se creó con el bank_code del catálogo, se resuelve automáticamente al nombre del banco.
• Sin cambios de API: mismas rutas, mismos shapes. Solo cambia el diseño de los documentos y correos.

​

v1.57

• Todo login (contraseña, OTP, social, passkey, handoff y registro) ahora devuelve, junto al access_token de 24 horas, un refresh_token (rt_…) de un solo uso para renovar la sesión sin re-login: POST /v1/auth/refresh entrega un par nuevo y rota el token (30 días por rotación, tope absoluto de 90 días desde el login original). Detalle y reglas de seguridad en Autenticación → Renovación de sesión.
• Rotación estricta y detección de robo: canjear revoca el access token anterior del dispositivo; presentar un refresh token ya canjeado revoca la cadena completa y registra el evento refresh_token_reuse en GET /v1/me/security/events. Cerrar sesión, revocar sesiones o cambiar la contraseña también invalida los refresh tokens.
• Código de error nuevo: 401 invalid_refresh_token. Las API keys pk_ no cambian: no expiran ni usan refresh.

​

v1.56

• Nuevo ambiente de test en https://cryptobank.qbank.cl/platform: la misma API, con todos los corredores atendidos por un simulador propio determinista — siempre disponible, sin depender de terceros. Las operaciones completan solas en segundos y los valores mágicos (montos .99/.77, beneficiario REJECT, OTP 000000, etc.) fuerzan cada resultado alternativo. Guía completa en Ambientes y pruebas.
• API keys por ambiente: test emite y acepta solo keys pk_test_; live solo pk_. Una key del otro ambiente devuelve 401 — imposible cruzar ambientes por error.
• Toda respuesta lleva el header CBPay-Environment (test | live) y GET /healthz expone livemode.
• Switch test/live de un click: POST /v1/auth/environment-handoff (live) emite un token de un solo uso (60s) que se canjea en POST /v1/auth/handoff (test) por una sesión del ambiente de test, con auto-provisión de la cuenta espejo si no existe.

​

v1.55

• GET /v1/aml/screenings y GET /v1/aml/screenings/{screeningID} listan y consultan cada screening AML (persona, empresa y rescreen) guardado localmente para auditoría — sujeto, riesgo, comisión y resultado completo.
• POST /v1/aml/screenings y POST /v1/aml/rescreen ahora exigen idempotency_key (las operaciones cobran comisión). Repetir con la misma clave devuelve el registro original con idempotency_hit: true sin cobrar dos veces.
• PATCH /v1/aml/monitoring guarda cada activación/desactivación en el mismo historial (kind: monitoring); idempotency_key es obligatoria cuando el estado cambia (habilitar cobra comisión).

​

v1.54

• Los retiros crypto sobre el umbral configurado (default 1.000 USD) ahora exigen declarar el beneficiario antes de mover fondos: wallet_type: "self_hosted" + beneficiary_name para wallets propias, o travel_address + beneficiary_name para destinos en otra institución (el intercambio de datos ocurre en línea y la dirección de pago la entrega la institución receptora). Bajo el umbral nada cambia.
• La respuesta del retiro incluye travel_rule_status (not_required / self_hosted_attested / approved).
• Códigos de error nuevos: travel_rule_required, travel_rule_beneficiary_required, travel_rule_address_mismatch, travel_rule_rejected, travel_rule_pending, travel_rule_incomplete_approval, travel_rule_unavailable. Detalle en la guía crypto y la página de errores.

​

v1.53

• GET /v1/balances/history ahora incluye en assets las series diarias de las cuentas banking (BANK_USD, BANK_EUR), cada una en su propia moneda (2 decimales), listas para graficarlas como un filtro más junto a USDT/USDC/BTC/GOLD. Siguen fuera del agregado total_usd, que cubre solo los saldos operativos. Guía de analytics actualizada.

​

v1.52

• GET /v1/payouts y GET /v1/payins aceptan el filtro country (ISO 3166-1 alfa-2, ej. ?country=MX), combinable con status, from/to y la paginación. Guías de payouts y payins actualizadas.
• El bloque fees de GET /v1/rates ahora devuelve la configuración de comisiones efectiva (defaults de la organización resueltos contra los overrides de la cuenta). Antes una cuenta sin overrides veía fees: [] aunque sus operaciones tuvieran costo; usa este bloque para cotizar la comisión exacta antes de crear la operación.

​

v1.51

• Wallets de depósito: toda cuenta — persona y empresa — mantiene exactamente una wallet de depósito por par soportado (tron/usdt, eth/usdt, eth/usdc), creadas gratis al registrarse. POST /v1/crypto/wallets queda solo para restaurar un par faltante; con el par ya creado responde 422 wallet_limit_reached para cualquier tipo de cuenta (antes las empresas podían crear más).
• Wallets segregadas: ahora también disponibles para cuentas persona, con límite de 1 por par red/activo (la segunda responde 422 wallet_limit_reached). Las empresas siguen sin límite. El error 403 company_required ya no aplica a wallets segregadas.
• Guías de crypto y wallets segregadas, página de personas y empresas y errores actualizadas.

​

v1.50

• La plataforma ahora monitorea todas las operaciones en tiempo real con controles de cumplimiento de estándar bancario. Para la gran mayoría de los clientes esto es invisible: no cambia ningún flujo ni agrega latencia perceptible.
• Códigos de error nuevos documentados en errores: 403 compliance_hold (operación retenida por cumplimiento), 403 geo_restricted (jurisdicción no soportada) y 503 compliance_check_unavailable (verificación temporalmente no disponible — la operación no salió; reintenta con la misma clave de idempotencia).

​

v1.49

• Esta documentación ahora está disponible completa en inglés (idioma por defecto), español y chino simplificado. Cambia de idioma con el selector en la parte superior del sitio.
• La API Reference también existe en los tres idiomas (mismos endpoints y ejemplos; solo cambian las descripciones).
• La colección Postman y la guía compilada en Markdown se mantienen al día desde cualquier idioma del sitio.

​

v1.48

• Producto nuevo: POST /v1/screenings/addresses evalúa cualquier dirección blockchain contra inteligencia on-chain global — sanciones, exposición a fondos ilícitos — y devuelve un nivel de riesgo Low/Medium/High/ Severe con la evidencia completa. Comisión fija por scan (address_screening, con reembolso automático si falla) e idempotencia obligatoria. Historial con GET /v1/screenings/addresses (+/{id}).
• Protección automática gratis: los retiros on-chain evalúan el destino antes de firmar (riesgo severo ⇒ rechazo con reembolso completo) y los depósitos entrantes evalúan al remitente antes de acreditar (severo ⇒ retenido en revisión de compliance; alto ⇒ se acredita con alerta).
• Webhooks nuevos: crypto_deposit_held y crypto_deposit_alert.
• Guía nueva: Screening de wallets.

​

v1.47

• Avatares por CDN: avatar_url (en PUT /v1/me/avatar, GET /v1/resolve y contactos) ahora es una URL pública absoluta que carga sin autenticación cuando la imagen está publicada en el CDN; GET /v1/avatars/{accountID} responde con un 302 hacia esa URL (los avatares legados se siguen sirviendo directo).
• Branding con URLs: GET /v1/branding suma logo_url y symbol_url — URLs públicas de CDN de los logos, para tematizar el front sin decodificar base64 (los campos *_png_base64 se mantienen).
• QR de payins: los cobros QR (POST /v1/payins, método qr) exponen qr_image_url, el PNG del QR publicado en el CDN, además del base64 qr_image de siempre. Ideal para mostrarlo con un <img> directo.

​

v1.46

• Nuevo GET /v1/aml/catalogs: todos los catálogos para construir formularios de compliance y verificación (géneros, formas jurídicas por país, fuentes de ingreso/patrimonio, estándares de industria, países y subdivisiones ISO-3166). Antes esta data no estaba disponible en la API.

• El bloque asset_prices de GET /v1/rates y GET /v1/rates/history ya no incluye el campo interno source; usa settlement_grade y updated_at para saber si un precio es ejecutable y qué tan fresco está.

​

v1.45

• Al crear una cuenta (persona o empresa) se aprovisionan automáticamente y sin costo sus tres wallets de depósito crypto: tron/usdt, eth/usdt y eth/usdc. Apenas registrada, GET /v1/crypto/wallets ya devuelve las tres direcciones (la provisión corre en segundo plano; si consultas en el mismo segundo puede tardar unos instantes).
• POST /v1/crypto/wallets queda para wallets adicionales (empresas); las personas ya tienen ocupado el cupo de cada combinación desde el registro. Las cuentas creadas antes de este cambio fueron completadas con las wallets que les faltaban.

• El registro público de cuentas ahora tiene límite de velocidad por IP (429 too_many_attempts).

​

v1.44

• Cartola más completa: nuevas secciones card_transactions (compras con tarjeta), swaps (conversiones de saldo) y banking_operations (operaciones bancarias). Si usas Banking, tus cuentas bancarias cuadran como saldos espejo BANK_USD/BANK_EUR en la sección assets.
• Comisiones desglosadas: payouts, payins y retiros crypto ahora separan la comisión en fee_percent y fee_fixed (suman exacto el fee); los cargos standalone llevan fee_model: "fixed" y se etiquetan Fixed Com en el PDF/Excel.
• Comprobantes nuevos: GET /v1/banking/operations/{id}/receipt, GET /v1/wallets/{walletID}/sends/{sendID}/receipt y GET /v1/wallets/{walletID}/deposits/{depositID}/receipt. El webhook banking_operation_status_changed ahora incluye receipt_url.
• Custodia de wallets segregadas: campo custody (cbpay | client) en cada wallet; la plataforma sincroniza la actividad on-chain completa y emite los webhooks wallet_external_movement (movimiento firmado por fuera, esperable en custodia client) y wallet_key_compromise_suspected (alarma crítica).
• Analytics: sections.banking.volume (dinero movido por tus cuentas bancarias, que también suma al gross_volume), sections.verifications.fees_by_kind (gasto KYC vs KYB por separado), sections.adjustments y deposits.wallet_fees_usd.
• Contabilidad garantizada por wallet (custodia cbpay): cuadratura de vida completa en la cartola y funding_sources (atribución FIFO depósito→envío) en el detalle de cada envío. Los saldos espejo BANK_* también aparecen en GET /v1/balances con custody: "banking".

​

v1.43

• GET /v1/rates/history: la evolución de las tasas de cambio de tu cuenta (punta payout y payin por punto), con granularidad day u hour, y change_pct con signo por moneda — listo para el gráfico de tasas con su badge “+3.4% / −3.0%”. Incluye las series de referencia USD de BTC y GOLD.
• GET /v1/balances/history: la evolución diaria de tus saldos — una serie por asset con el saldo de cierre de cada día (sin huecos), la serie agregada en USD valorizada al precio histórico de cada día, las entradas/salidas del período y el snapshot actual — todo lo necesario para la tarjeta de saldo con gráfico.
• El historial de tasas nace con un backfill de ~90 días de tasas diarias y se registra continuamente hacia adelante.

​

v1.42

• Todo producto transaccional tiene su comprobante PDF brandeado: GET .../receipt en payouts, payins, transferencias, retiros y depósitos crypto (deposit_id nuevo en GET /v1/crypto/transactions), swaps y compras con tarjeta. Idiomas ?lang=es|en.
• receipt_url en toda respuesta de esos productos y en los webhooks de estados finales: el front nunca construye la URL a mano.
• Verificación pública de autenticidad: cada PDF lleva un código firmado con QR que abre GET /verify/receipts/{code} (sin credenciales) — JSON para APIs y página web brandeada para navegadores, siempre con el estado y monto reales y vigentes, sin datos personales del beneficiario.
• Los comprobantes de operaciones no completadas llevan marca de agua diagonal (“EN PROCESO” / “FALLIDA”): un PDF en tránsito jamás pasa por prueba de pago.
• Email automático con el PDF adjunto al llegar la operación a estado final, con opt-out por cuenta (PATCH /v1/me con receipt_emails: false).

• GET /v1/branding: el branding efectivo de la plataforma (logo, colores, nombre) para que el front white-label se auto-tematice desde la API.

• La cartola PDF ahora sale con el logo real de la marca y tipografía Inter (antes wordmark tipográfico), y el Excel incluye el logo en la hoja resumen.

​

v1.41

• Wallets on-chain con saldo propio (fuera del ledger): crear (POST /v1/wallets), listar y ver detalle, importar una wallet externa con su llave (POST /v1/wallets/import), exportar la llave privada (POST /v1/wallets/{id}/export, custodia compartida) y enviar crypto directo desde la wallet (POST /v1/wallets/{id}/sends).
• Consulta on-chain en vivo: GET .../balance (incluye gas), .../deposits y .../transactions; auto-forward configurable (GET/POST .../auto-forward).
• El gas de los envíos corre por el cliente: sin gas el envío responde 422 insufficient_gas. Import y export exigen sesión de usuario con 2FA.
• Fees nuevos: wallet_import, wallet_export, wallet_send.
• Webhooks nuevos: wallet_deposit_received, wallet_send_status_changed, wallet_key_exported. Service flag nuevo: wallets.
• La cartola y el dashboard incluyen una sección de wallets segregadas.

​

v1.40

• Contraseña: cambio self-service (POST /v1/me/password, revoca las demás sesiones) y recuperación por código (POST /v1/auth/password/forgot → POST /v1/auth/password/reset) al email o al teléfono verificado. Forgot siempre responde 200 (no revela si la cuenta existe).
• Email de login: cambio verificado (POST /v1/me/email/change → confirm con el código enviado al email nuevo) y verificación del actual (POST /v1/me/email/verify).
• Alias permanente (PUT /v1/me/alias) y QR de perfil (GET /v1/me/qr): identifican tu cuenta para recibir transferencias. Las transferencias aceptan to_alias y to_qr_token; GET /v1/resolve muestra una vista previa del destinatario antes de enviar.
• Foto de perfil: PUT/DELETE /v1/me/avatar y GET /v1/avatars/{id}.
• 2FA self-service (GET/PUT /v1/otp/preferences): activa y elige el canal por acción — ahora también email y app autenticadora (TOTP) además de SMS/WhatsApp. Puedes endurecer libremente; relajar exige verificación.
• App autenticadora (TOTP): POST /v1/me/totp/enroll (QR) → confirm (entrega 10 códigos de respaldo de un solo uso), DELETE, y POST /v1/me/totp/recovery-codes para regenerarlos.
• Passkeys (WebAuthn): inicio de sesión sin contraseña con la biometría del dispositivo (Face ID, Touch ID, Windows Hello, llaves). Registro (/v1/me/passkeys/register/begin|finish), gestión (GET, DELETE) y login (/v1/auth/passkey/login/begin|finish).
• Sesiones y actividad: GET /v1/me/sessions + revocar una o todas, y GET /v1/me/security/events (historial de seguridad de la cuenta).
• Avisos por email ante eventos sensibles (cambio de contraseña o email, alta/baja de un factor).

​

v1.39

• La verificación KYC/KYB aprobada de un cliente pasa a ser su identidad única dentro de CBPay: sus datos y documentos se reutilizan en los demás productos sin volver a tipearlos ni re-subirlos. Guía: identidad reutilizable.
• Tarjetas: la primera emisión de tu cuenta completa la identidad y los documentos del titular desde tu verificación aprobada — solo envías occupation y salary_usd. Los campos explícitos siguen ganando.
• Informe de compliance (KYB): GET /v1/kyb/submissions/{id}/report descarga el informe de compliance firmado (PDF) de la verificación.

• POST /v1/banking/third-parties ahora exige verification_id de una verificación aprobada del tercero. El type sale del kind (KYC ⇒ INDIVIDUAL, KYB ⇒ COMPANY), la identidad se completa sola y los documentos ya validados se re-entregan al proveedor bancario (documents_synced). Los terceros existentes siguen operando.
• POST /v1/cards para personas designadas (cuentas empresa) ahora exige cardholder.verification_id del KYC aprobado de esa persona; su identidad y documentos salen de la verificación.
• Errores nuevos: 422 verification_required, 422 verification_not_approved, 422 verification_kind_mismatch, 422 verification_invalid.

​

v1.38

• GET /v1/analytics/summary: en una sola llamada, todas las series y estadísticas de tu cuenta para armar tu dashboard — volumen bruto (in/out), transacciones y usuarios nuevos por período (día/semana/mes, con comparativa vs el período anterior), vista global por país, y una sección por CADA servicio (payouts, payins, depósitos, retiros, transferencias, swaps, tarjetas, banking, KYC/KYB, AML, contactos) con sus dimensiones (país, moneda, método, estado, chain, comercio). Además spending (lo que consumiste en fees por servicio) y balances valorizados en USD. Guía nueva: Resumen de tu cuenta.
• Usuarios banking de terceros (solo empresas): POST/GET /v1/banking/third-parties (+documentos, submit, cuentas, saldo) para dar de alta a tus clientes finales como usuarios banking separados, con su identidad/KYC y cuentas a su nombre. Aislados por cuenta.
• Límite nuevo: las cuentas persona pueden tener máximo 1 cuenta bancaria (409 banking_account_limit).

​

v1.37

• Las tasas USD→BOB y USD→VES de GET /v1/rates ahora reflejan el mercado con el que realmente operamos tus pagos (antes se publicaba una tasa de referencia que no correspondía al valor aplicado).
• Si en algún momento una de esas tasas no está disponible, el país no aparece en GET /v1/rates y las operaciones en esa moneda responden 422 currency_not_supported hasta que vuelva — nunca cotizamos con una tasa incorrecta. Te recomendamos consultar GET /v1/rates (o suscribirte al webhook de tasas) antes de cotizar pagos en BOB o VES.

​

v1.36

• Nuevo producto swaps: convierte entre USDT, USDC, BTC y GOLD al instante y sin que la plata salga de tu cuenta — cualquier par, incluido BTC ↔ GOLD directo. POST /v1/swaps (síncrono, con idempotency_key), GET /v1/swaps/quote (cotización indicativa gratis) y GET /v1/swaps (+/{id}) para el historial.
• La tasa cotizada es la tasa de ejecución de tu cuenta: cotizado = recibido, sin comisiones aparte. Precios de BTC/GOLD en vivo (si el precio no está fresco, el swap se rechaza con 503 pricing_unavailable).
• Las conversiones que tocan BTC/GOLD comparten los límites por operación y de volumen 24 h con payouts y compras con tarjeta (GET /v1/settlement). Guía nueva: Swaps.

​

v1.35

• Libreta de contactos (/v1/contacts): CRUD completo con búsqueda y favoritos. Cada envío (transferencia, payout, retiro crypto) guarda su destino como contacto automáticamente — deduplicado; opt-out con "save_contact": false.
• Import de la agenda del celular (POST /v1/contacts/import, hasta 1.000 por request): normaliza los teléfonos a E.164 y te dice qué contactos ya tienen CBPay (has_cbpay, match solo dentro de tu operador).
• Transferir por teléfono: POST /v1/transfers acepta to_phone (solo cuentas con teléfono verificado por OTP; ambigüedad responde 422 recipient_ambiguous) y to_contact_id.
• Envío rápido a contactos: beneficiary_contact_id en payouts (usa el beneficiario guardado del contacto) y to_contact_id en retiros crypto (usa su dirección guardada). Guía nueva: Contactos.

​

v1.34

• Onboarding obligatorio: toda cuenta nueva debe aprobar su verificación de identidad (persona ⇒ KYC, empresa ⇒ KYB) antes de operar. Hasta entonces solo puede fondear (payins, depósitos crypto, transferencias entrantes) y leer; el resto responde 403 verification_required. Pide tu link con POST /v1/me/verification/link y consulta tu estado con GET /v1/me/verification — la aprobación actualiza tu kyc_status automáticamente. Las cuentas existentes quedaron aprobadas.
• Verificación de terceros (solo cuentas empresa): genera links hosteados (POST /v1/kyc/links, POST /v1/kyb/links) o envía los datos por API (POST /v1/{kyc,kyb}/submissions), sube documentos con presign + OCR y cierra la prueba de vida con liveness links. Comisiones fijas nuevas kyc_verification / kyb_verification cobradas al crear (con idempotency_key obligatoria y reembolso automático si falla).
• 7 webhooks nuevos: kyc/kyb_verification_status_changed, kyc/kyb_link_completed, kyc/kyb_document_validated, kyc_liveness_completed. Guía completa en Verificación KYC y KYB.

• POST /v1/kyc, POST /v1/kyc/rescreen y PATCH /v1/kyc/monitoring se eliminaron: el screening contra listas ahora vive en POST /v1/aml/screenings, POST /v1/aml/rescreen y PATCH /v1/aml/monitoring (misma semántica y comisiones compliance_*). El error no_kyc pasa a no_screening y el screening ya no toca tu kyc_status. Nuevo webhook aml_screening_updated y nuevo service flag aml (el flag kyc ahora gatea la verificación de identidad). Guía: AML screening.

​

v1.33

• GET /v1/payouts/banks?country=VE respondía 400 pidiendo method, y ?country=BO respondía 400 payout_corridor_unsupported. Ahora el catálogo sin method devuelve la unión de los bancos de todos los métodos del país (deduplicada por código), como promete esta documentación; con method se acota al canal específico (parámetro documentado en la referencia).

​

v1.32

• spending_asset ahora acepta también BTC y GOLD: las compras se convierten con el precio efectivo del momento de cada evento (el mismo del bloque settlement de GET /v1/rates).
• Autorización: se reserva el equivalente más un pequeño colchón (no es un cobro; se devuelve al liquidar). Si el precio de ejecución no está disponible, la compra se declina con pricing_unavailable — nunca se convierte con un precio no confiable.
• Liquidación: el monto final se re-cotiza al precio del momento de la captura y el sobrante del colchón vuelve solo. Anulación de una autorización: devolución del monto exacto, sin conversión. Devoluciones/ajustes posteriores: re-convertidos al precio del momento del evento (tu saldo asume la variación del precio).
• Las compras BTC/GOLD comparten los límites de assets volátiles de la cuenta con los payouts: por operación (settlement_limit_exceeded) y volumen 24 h (settlement_daily_limit_exceeded).

​

v1.31

• Cada tarjeta ahora tiene un asset de gasto (spending_asset): sus compras se debitan del saldo USDT o USDC de la cuenta, 1:1 con el USD y sin comisión de conversión. USDT por defecto (comportamiento idéntico al histórico).
• Defínelo al crear la tarjeta (spending_asset en POST /v1/cards) o cámbialo cuando quieras con PATCH /v1/cards/{cardID}. El cambio aplica solo a compras futuras: las autorizaciones en vuelo conservan (y devuelven a) el asset con el que debitaron.
• Las transacciones de tarjeta ahora exponen spend_asset y spend_amount (el saldo y monto realmente debitados); amount_usd / amount_usdt siguen siendo el valor USD de referencia. Los límites por tarjeta siguen midiéndose en USD.
• Errores nuevos: 400 spending_asset_unavailable (BTC/GOLD no están disponibles para compras con tarjeta) y rechazos de autorización spending_asset_disabled si tu operador deshabilita el asset.

​

v1.30

• Los pagos desde BTC/GOLD ahora tienen, además del límite por operación, un tope de volumen en 24 h móviles por cuenta (422 settlement_daily_limit_exceeded). Lo ves en GET /v1/settlement como volatile_daily_limit_usdt.
• Las comisiones de tarjetas (emisión, cancelación y mensualidad) ahora también se debitan desde tu saldo de settlement predeterminado, igual que el resto de los servicios. Las compras con tarjeta siguen liquidando en USDT.

​

v1.29

• Los payouts y las comisiones de servicios (KYC, creación de wallets, banking) ahora pueden debitarse desde cualquiera de tus cuatro saldos (USDT, USDC, BTC, GOLD). El pricing sigue cotizándose en USDT; el total se traduce al asset elegido con el precio efectivo de settlement del momento. Detalle en el modelo de dinero.
• Nuevo GET/PUT /v1/settlement: define el saldo predeterminado de tu cuenta (default_settlement_asset). Override puntual por operación con settlement_asset en POST /v1/payouts y en el confirm de QR.
• La respuesta del payout ahora registra settlement_asset, settlement_amount (el monto exacto debitado, que es también el que se reembolsa si falla — nunca se re-cotiza) y settlement_rate.
• GET /v1/rates suma un bloque settlement con el precio efectivo por asset habilitado, y asset_prices ahora trae source, updated_at y settlement_grade (si el precio está apto para ejecutar).
• Errores nuevos: 503 pricing_unavailable (precio de ejecución de BTC/GOLD no disponible), 400 settlement_asset_disabled, 400 invalid_settlement_asset y 422 settlement_limit_exceeded (límite por operación de los assets volátiles).

​

v1.28

• POST /v1/payins con method: "bank_transfer" ahora devuelve una reference corta de 12 caracteres alfanuméricos (ej. CBW4N8R2T6P9) en vez del UUID: los conceptos bancarios tienen límites duros (en Paraguay/SIPAP el máximo es 20 caracteres sin caracteres especiales) y el UUID no cabía.
• El match automático acepta la referencia nueva y sigue aceptando el UUID de los anuncios antiguos — los payins pending existentes no se ven afectados. El respaldo por monto+moneda no cambia.
• GET /v1/payins y el detalle muestran la referencia de anuncio en reference mientras el payin está pending.

​

v1.27

• Nuevo corredor de cobro PY/PYG/bank_transfer: anuncia el depósito con POST /v1/payins, tu pagador transfiere (SIPAP o transferencia interna del banco receptor) con la reference en el concepto, y el abono llega automático en USDT a tu payin_rate, como en todos los países. Guía en payins.
• Los guaraníes no usan decimales: anuncia el monto entero exacto (ej. "596000"). El match de respaldo por monto+moneda aplica igual.
• El corredor aparece en GET /v1/payins/methods con delivery: polling.

​

v1.26

• Cada cuenta ahora mantiene cuatro saldos virtuales independientes: USDT (la moneda operativa), USDC, BTC (8 decimales, satoshis) y GOLD (gramos de oro fino, 6 decimales, con respaldo en custodio). Nunca se mezclan ni se convierten automáticamente. Detalle en modelo de dinero.
• GET /v1/balances devuelve siempre los cuatro saldos (con ceros si no has operado esa moneda) y GET /v1/movements filtra por moneda con ?asset=.
• Transferencias internas multi-moneda: POST /v1/transfers acepta asset (USDT default, USDC, BTC, GOLD) — siempre entre saldos de la misma moneda, sin conversión y sin comisión.
• USDC on-chain: crea wallets eth/usdc, deposita y retira USDC por Ethereum. Cada depósito acredita el saldo de su propio activo. Guía en crypto.
• Precios de referencia: GET /v1/rates incluye asset_prices con el precio USD referencial de cada moneda (BTC por unidad, GOLD por gramo) — solo para valorizar, sin conversión ni spread.
• Cartola multi-moneda: nueva sección assets con la conciliación independiente de cada saldo no-USDT (inicial/entradas/salidas/final y su flag balanced), también en el PDF y el Excel.
• Los payouts, payins, tarjetas y comisiones de servicios siguen operando exclusivamente contra el saldo USDT.

​

v1.25

• Registro e inicio de sesión sin contraseña con Google, Apple, Microsoft y Facebook por token exchange: tu front obtiene la credencial con el SDK del proveedor y la intercambias en POST /v1/auth/oauth por la sesión CBPay. Guía completa en login social.
• Endpoints nuevos: POST /v1/auth/oauth (login + registro unificado), GET /v1/auth/oauth/providers (proveedores habilitados, público), GET/POST /v1/me/identities y DELETE /v1/me/identities/{provider} (vincular/desvincular proveedores desde la sesión).
• Integra el 2FA: si la cuenta exige OTP en login, el login social también devuelve otp_required + pending_token.
• Multi-método: una misma cuenta puede tener contraseña y varios proveedores; el auto-vínculo por email solo ocurre si el proveedor lo entrega verificado.
• Códigos de error nuevos en el catálogo: invalid_provider, provider_not_configured, invalid_credential, email_conflict, identity_taken, last_login_method.

• El sello de “Colección actualizada” en la página de Postman ahora muestra correctamente hace cuánto se actualizó (antes quedaba un indicador vacío).

​

v1.24

• Verificación en dos pasos para acciones sensibles: tu operador puede exigir un código de un solo uso (por SMS o WhatsApp) antes de login, payouts, retiros crypto, transferencias, pagos bancarios, revelar una tarjeta, emitir API keys, agregar miembros o cambiar el teléfono. Guía completa en seguridad y 2FA.
• Endpoints nuevos: POST /v1/otp/challenges (envía el código), POST /v1/otp/challenges/{id}/verify (devuelve el otp_token de un solo uso para el header X-OTP-Token), GET /v1/otp/challenges (+ detalle) y GET /v1/otp/settings (tu política efectiva).
• Login en dos pasos: con OTP activo en login, POST /v1/auth/login devuelve otp_required: true + pending_token, y la sesión se emite en POST /v1/auth/login/otp.
• Solo sesiones de usuario: las API keys pk_ quedan exentas — tus integraciones server-to-server no cambian.
• Códigos de error nuevos en el catálogo: otp_required, otp_invalid, phone_required, phone_binding_cooldown, too_many_attempts y más.

​

v1.23

• Nueva página personas y empresas: TODAS las diferencias entre los dos tipos de cuenta (wallets, tarjetas, miembros, KYC/KYB) en una sola tabla, con los errores que delata cada límite.
• Guía de tarjetas reorganizada por tipo de cuenta: pestañas “Cuenta persona” y “Cuenta empresa”, cada una con su flujo completo (primera tarjeta, siguientes, y para empresas la emisión corporativa y para empleados) — ya no hay que armar el flujo leyendo notas sueltas.
• Ejemplos por país de vuelta en sus guías: los requests/responses por corredor de payouts y payins viven otra vez DENTRO de la guía de cada producto (una sola página por producto, sin saltar a una referencia aparte). Las URLs antiguas redirigen.
• Postman con frescura en vivo: la página Postman ahora muestra hace cuánto se actualizó la colección (segundos/minutos/días), además de la fecha y la versión.
• El MD compilado incluye ahora la referencia completa de endpoints y la versión de la documentación.

​

v1.22

• Navegación nueva: Comenzar → Conceptos → Flujos de integración → Productos → Integración → Recursos, con icono por página y breadcrumbs.
• Páginas nuevas: ambiente y pruebas (túnel para webhooks en local + checklist de go-live), servicios habilitados, estados y ciclo de vida (incluye el catálogo de status_code de payouts fallidos), movimientos y conciliación y flujos de integración con diagramas end-to-end.
• Payouts y payins divididos: guía general + referencia por país con el request y response real de cada corredor.
• Guías ampliadas: quickstart cierra el ciclo con webhooks; perfil (PATCH /v1/me) y miembros con roles; tabla completa de endpoints con idempotencia; schedule de reintentos de webhooks; tiempos de confirmación on-chain; cuentas banking en EUR; errores de banking en el catálogo; FAQ con límites, cancelaciones y conciliación.
• Tarjetas: cuándo se envía el cardholder, aclarado. La guía y el spec ahora explican que la primera emisión de una cuenta crea y verifica al titular (datos completos + documentos obligatorios) y que las tarjetas siguientes lo reutilizan sin pedir datos — antes el ejemplo mínimo daba a entender que nunca se pedían.

​

v1.21

• payin_rate en GET /v1/rates: cada país ahora entrega tus dos tasas — rate para payouts (dispersiones) y payin_rate para payins (cobros/depósitos fiat). Cotizado = acreditado, siempre.

• Pricing de payins igual que payouts: el pricing FX de un payin vive en tu payin_rate (la conversión del abono se hace exactamente a esa tasa) y la comisión de payin pasa a ser un fijo por operación — sin porcentajes aparte. El campo fx_rate de cada payin registra la tasa aplicada. Ver comisiones y la guía de payins.
• La conversión de abonos redondea hacia abajo al micro-USDT (los débitos siguen redondeando hacia arriba), con diferencia máxima de 1 micro-USDT.

• KYC/KYB: referencia completa de campos de identidad. El objeto customer siempre aceptó muchos más campos opcionales de los que mostraban los ejemplos (fecha de nacimiento, nacionalidades, documentos con país emisor, alias, domicilios, datos registrales de empresa…) y enviarlos hace el screening más preciso. La guía de KYC ahora documenta todos los campos, con ejemplos de identidad completa y la regla de deduplicación.

​

v1.20

• Catálogo de tarjetas: GET /v1/cards/catalog/occupations y GET /v1/cards/catalog/business-activities (buscables con ?q=) para poblar selectores. Al designar una persona, occupation debe ser un código del catálogo; para empresa, kind_of_business también. Un valor fuera de catálogo se rechaza con 400 invalid_occupation / 400 invalid_kind_of_business antes de tocar el emisor. Ver la guía de tarjetas.

​

v1.19

• GET /v1/services: mapa efectivo de los servicios habilitados para tu cuenta (payouts, payins, transfers, crypto, banking, kyc, cards) — úsalo para decidir qué mostrar en tu UI. Los servicios se habilitan por cuenta según tu acuerdo comercial; si uno está apagado, sus acciones responden el nuevo error 403 service_disabled (las lecturas y el dinero en tránsito nunca se bloquean).

​

v1.18

• Tarjetas virtuales y físicas que gastan directo del saldo USDT de la cuenta, sin prefondeo: cada compra se autoriza en tiempo real contra el saldo disponible y los límites de la tarjeta. Personas: 1 virtual + 1 física; empresas: ilimitadas, propias o para personas designadas (ej. empleados). Nuevos endpoints POST/GET /v1/cards, GET/PATCH /v1/cards/{id} (límites y congelar/descongelar), POST /v1/cards/{id}/activate|cancel|reveal y GET /v1/cards/{id}/transactions. Ver la guía de tarjetas.
• Nuevos servicios facturables (fijos, configurables, pueden ser 0): card_creation_virtual, card_creation_physical, card_monthly (si no hay saldo, la tarjeta se congela — sin deuda) y card_cancellation.
• Nuevos webhooks card_transaction (autorizada/anulada/ajustada) y card_status_changed (cambios de estado, incluido el congelamiento automático).
• Nuevos tipos de movimiento en el ledger: card_debit, card_refund, card_fee, card_fee_refund.

​

v1.17

• Chile: página de pago hosted (method: "fintoc") en POST /v1/payins. La respuesta trae una payment_url que el pagador abre para transferir desde cualquier banco o billetera chilena (Banco Estado, Santander, Mach, Tenpo, Mercado Pago, entre otros); el depósito se detecta, valida y acredita automáticamente en USDT con el webhook payin_credited de siempre. Soporta idempotency_key opcional: un reintento devuelve el mismo payin y la misma URL sin abrir otra sesión de pago. Ver la guía de payins.

​

v1.16

• Filtros de fecha from/to en todos los listados: /v1/movements, /v1/payouts, /v1/payins y /v1/crypto/transactions ahora aceptan from/to (YYYY-MM-DD, UTC, inclusive), además de la paginación de siempre (page, page_size hasta 200). Fechas inválidas devuelven 400 invalid_range.
• Consulta de transferencias: GET /v1/transfers (lista con paginación y fechas) y GET /v1/transfers/{id} — antes solo se podían crear.
• Listar suscripciones de webhook: GET /v1/webhooks/subscriptions.
• Idempotencia en cobros activos: POST /v1/payins/collect ahora exige idempotency_key (ejecuta un cargo real; un reintento nunca vuelve a cobrar al pagador). Igual refuerzo en creación de wallet (no dobla el fee en reintentos) y en ajustes de administración.
• Paginación uniforme agregada a members, crypto/wallets, deposit-accounts y (admin) orgs.
• Cartola / estado de cuenta (GET /v1/reports/statement): consolida todos los movimientos del período — payouts, payins, crypto, transferencias y comisiones — en un solo documento auditable con cuadratura contable exacta (saldo inicial + entradas − salidas = saldo final, verificada contra el ledger). Tres formatos con el mismo endpoint: JSON para tu web, PDF con branding CBPay y Excel multi-hoja con celdas numéricas, filtros y hoja de movimientos para auditores (format=json|pdf|xlsx, lang=es|en). El org admin puede generar la cartola de cualquiera de sus cuentas. Ver la guía.

​

v1.15

• Diagramas de flujo visuales en toda la documentación: mapa del dinero en la introducción (todo lo que entra y sale del saldo USDT), ciclo de vida del payout con débito/hold/reembolso, flujo QR en dos pasos, las 4 modalidades de payin convergiendo al abono, depósito y retiro crypto, ciclo completo de banking, estados del KYC, entrega y reintentos de webhooks, y la regla de decisión de idempotencia (“¿con qué clave reintento?“).

​

v1.14

• Nueva URL base: https://api.qbank.cl/platform (antes exchange.qbank.cl/platform). El dominio anterior sigue funcionando como alias, así que ninguna integración existente se rompe — pero usa api.qbank.cl para todo lo nuevo. Toda la documentación, el spec y el Postman ya apuntan a la URL nueva.

​

v1.13

• Banking: cuentas bancarias reales para tu cuenta — recibe, mantén y envía dinero por rieles bancarios internacionales (SEPA, SWIFT, ACH según la moneda). 14 endpoints nuevos bajo /v1/banking/*:
  • Perfil bancario: crear, consultar, subir documentos y enviar a verificación.
  • Cuentas: abrir por moneda, listar y consultar saldo en vivo.
  • Beneficiarios: registrar, listar y agregar cuentas destino.
  • Pagos: cotizar (prepare, gratis) y ejecutar TRANSFER/WITHDRAW con idempotencia.
• Webhooks nuevos: banking_customer_status_changed y banking_operation_status_changed.
• Comisiones nuevas (fijas, configurables, reembolsables si la operación falla): banking_customer, banking_account, banking_operation — el campo banking_fee de cada respuesta muestra lo cobrado.
• Guía completa de Banking con el flujo end-to-end y ejemplos de cada operación.

​

v1.12

• API Reference completamente en español: títulos, descripciones, campos y grupos del sidebar ahora están traducidos cuando navegas la documentación en español (antes solo la interfaz cambiaba de idioma).
• Guía de payouts reordenada: PIX de Brasil vive ahora solo en “Ejemplos por país” (se eliminó la sección duplicada); el QR quedó como única sección de flujo aparte por ser un flujo distinto (scan + confirm).
• Webhooks: payload de ejemplo de cada uno de los 5 eventos.
• Quickstart: registro con ejemplos de persona y empresa.
• Colección Postman ampliada a 53 requests: los endpoints con varios casos de uso ahora traen un request por caso (un payout por país y método, payins por modalidad, KYC persona/empresa, etc.), cada uno con su body listo para enviar.
• Guía de payins reestructurada por país, igual que payouts: matriz de corredores con la modalidad de cada país y pestañas Chile / Perú / México / Venezuela / Bolivia / Brasil con sus ejemplos completos.
• Nueva página de preguntas frecuentes: sandbox, fondeo inicial, costos previos al payout, garantía de tasa, tiempos de llegada, reintentos seguros, depósitos sin referencia y más — las dudas del primer día respondidas en la misma docu.
• Quickstart abre con la tabla de datos clave (URL base, header de auth, slug, formato de montos, ambiente) y el ejemplo de respuesta de GET /v1/rates con la fórmula para estimar costos.
• Payouts: respuesta de ejemplo de los catálogos de métodos y bancos, y tabla de estados con el efecto en tu saldo. Payins: respuesta de ejemplo del catálogo con el significado de delivery.

​

v1.11

• Ejemplos completos por caso de uso en toda la documentación:
  • Payouts: ejemplo de cada país y método con su beneficiary real y la respuesta (Chile, Perú CCI + Yape, México CLABE + tarjeta, Venezuela Pago Móvil + transferencia, Bolivia ACH, Brasil PIX, Paraguay).
  • Payins: QR de Bolivia y Brasil lado a lado, cobro activo c2p y debito_inmediato con la respuesta del OTP, cuenta de depósito dedicada.
  • KYC/KYB: requests de persona, empresa y mínimo autocompletado, con las respuestas de screening, rescreening y monitoreo (activar/desactivar).
  • Transferencias: por email, por account_id, empresa→persona (nómina) y replay idempotente.
  • Crypto: creación de wallet persona vs empresa, y el error wallet_limit_reached.
  • API Reference: ejemplos nombrados seleccionables en cada endpoint (10 corredores en payouts, 3 modos en payins, persona/empresa en KYC…).

​

v1.10

• Brasil (BRL) con PIX documentado en payouts y payins:
  • Payout pix por llave (CPF/CNPJ, teléfono, email o llave aleatoria evp) vía POST /v1/payouts.
  • Payout a QR PIX (estático o “copia e cola”) vía el flujo qr/scan + qr/confirm con country: "BR".
  • Payin con QR PIX dinámico vía POST /v1/payins (method: "qr", country: "BR"), con imagen del QR y código “copia e cola”.
  • Payin por transferencia anunciada (method: "bank_transfer").

​

v1.9

• Todos los métodos de cobro (payins) disponibles por API:
  • POST /v1/payins ahora acepta method: qr (cargo QR, como antes) o bank_transfer (anuncias un depósito entrante y recibes la referencia que debe incluir la transferencia para acreditarse sola).
  • POST /v1/payins/collect — cobro activo (pull) al pagador en los corredores que lo soportan (ej. Venezuela c2p / debito_inmediato), con acreditación síncrona; POST /v1/payins/collect/otp para el OTP previo cuando el método lo requiere.
  • POST /v1/payins/deposit-accounts — cuenta de depósito dedicada fija (ej. CLABE en México) vinculada a tu cuenta: todo lo que llega se acredita automáticamente. GET /v1/payins/deposit-accounts para listarlas.
• Matriz completa de corredores y métodos de payout en la guía (Chile, Perú con yape, México SPEI, Venezuela con pago_movil, Bolivia con qr, Paraguay).
• Venezuela (VES) se sumó a las tasas de GET /v1/rates.

​

v1.8

• Payout QR Bolivia: paga a cualquier QR de cobro boliviano en dos pasos — POST /v1/payouts/qr/scan (gratis, devuelve los datos del destinatario) y POST /v1/payouts/qr/confirm (se cobra igual que un payout: tu tasa + fijo, con resultado final síncrono y reembolso automático si falla).
• Bolivia (BOB) se sumó a las tasas de GET /v1/rates.

​

v1.7

• Nueva página Postman: colección oficial descargable con los 25 endpoints, cuerpos de ejemplo y autenticación preconfigurada. Se regenera con cada versión de la API.

• La página de Comisiones y los ejemplos de payout reflejan el modelo de pricing vigente: los payouts se cobran a tu tasa + fijo por operación (sin porcentaje aparte). Si dispersas el equivalente a 100 USDT, se debitan 100 USDT más el fijo configurado.

​

v1.6

• GET /v1/rates ahora entrega el tipo de cambio propio de tu cuenta por país: la misma tasa con la que se ejecutan tus operaciones (monto_local / rate = USDT), sin diferencias entre lo cotizado y lo cobrado.

​

v1.5

• Se eliminó definitivamente GET /v1/crypto/deposit-address (el alias que quedó deprecado en v1.4). Usa POST /v1/crypto/wallets para crear wallets y GET /v1/crypto/wallets para consultarlas.

​

v1.4

• Wallets múltiples para empresas: las cuentas empresa ahora pueden crear wallets ilimitadas por red (las personas mantienen 1 por red).
• Nuevos endpoints: POST /v1/crypto/wallets (crear wallet, con label opcional para distinguirlas) y GET /v1/crypto/wallets (listar mis wallets). Cada creación cobra la comisión fija wallet_creation si está configurada.
• Nuevo error 422 wallet_limit_reached cuando una persona intenta crear una segunda wallet en la misma red.
• Las respuestas de wallet ahora incluyen wallet_id y label.

• La guía de Crypto se reorganizó en: crear wallet, ver mis wallets, depositar, transferir y movimientos.
• GET /v1/crypto/deposit-address queda como alias legacy (deprecado): usa los endpoints de wallets.

• Pulido de redacción y traducciones en ambos idiomas; la tabla de movimientos ahora incluye los tipos wallet_creation_fee y wallet_creation_refund.

​

v1.3

• API Reference de nivel profesional: los 25 endpoints ahora incluyen ejemplos de request y de respuesta para todos los casos (éxito, replay de idempotencia, y cada error posible con su cuerpo real), listos para probar desde el playground de la documentación.
• Los 5 webhooks ahora están documentados dentro de la propia API Reference (sección Webhooks del estándar OpenAPI), con esquema y payload de ejemplo de cada evento.
• Catálogos de métodos y bancos documentados con las formas de respuesta reales del sistema.
• Endpoint GET /healthz documentado (estado del servicio).
• La guía de Crypto agrega “Saldo y actividad de tu wallet”: cómo ver el saldo, la actividad on-chain con tx_id y el historial contable.
• Redacción en voz de marca: toda la documentación habla como CBPay (antes usaba términos genéricos como “tu operador” o “la organización”).
• La verificación de identidad ahora se nombra KYC/KYB en toda la documentación (KYC para personas, KYB para empresas).
• Transferencias internas: documentado explícitamente que funcionan entre cualquier combinación de cuentas (persona↔persona, persona↔empresa, empresa↔empresa) y son siempre sin comisión.

​

v1.2

• Nuevo servicio de comisión wallet_creation: la primera creación de una dirección de depósito en cada red puede tener un cargo fijo configurado por CBPay (0 = gratis, valor por defecto). La respuesta de GET /v1/crypto/deposit-address ahora incluye creation_fee, y el historial de movimientos incorpora los tipos wallet_creation_fee y wallet_creation_refund. Consultar una dirección existente sigue siendo siempre gratis; si la creación falla, el cargo se reembolsa automáticamente.
• Nueva página Novedades (esta página) con el historial de versiones de la API y la documentación.

• La guía de Crypto ahora tiene una sección explícita “Crear tu wallet” que explica la creación por red (201 primera vez con creation_fee, 200 gratis después), y la API Reference renombra el endpoint a “Create or get my wallet (deposit address)“.

​

v1.1

• Comisiones de compliance por operación: compliance_person, compliance_company, compliance_rescreen y compliance_monitoring (cargo fijo por llamada; 0 = gratis). Las respuestas de KYC ahora incluyen compliance_service y compliance_fee.
• Endpoints POST /v1/kyc/rescreen y PATCH /v1/kyc/monitoring (desactivar monitoreo es gratis). Requieren un KYC previo (409 no_kyc).

• Identidad visual oficial de CBPay aplicada a toda la documentación.
• La documentación de administración se movió a un portal interno de CBPay; este sitio contiene solo la API de cuentas.

​

v1.0

• Documentación pública de la API de CBPay, bilingüe (español e inglés): autenticación (sesiones JWT y API keys pk_), modelo de dinero USDT, comisiones, idempotencia, payouts fiat multi-país, payins, transferencias internas, crypto (fondeo y retiros on-chain), KYC, webhooks firmados y catálogo completo de errores.
• API Reference interactiva generada desde OpenAPI 3.1.