Registro de cambios y notas de la API de Swipelux

​

Añadido

• Los destinos de destinatario aceptan los tipos pix y pix_safe para pagos en BRL en Brasil. Un destino Pix paga a una clave Pix. Un destino Pix Safe paga a una cuenta bancaria identificada por el CPF o CNPJ del titular, el código ISPB del banco, la sucursal y el número de cuenta. Ambos necesitan la capacidad Pix lista del cliente (pix_pooled), y sus pagos se financian con USDC y no llevan comisión de desarrollador. Consulta Destinatarios y Enviar fondos.
• GET /v3/customers/{customerId}/tasks/{taskId} acepta documentCandidatesFor con el ID de un requisito de documento, además de documentAlternativeKey para un requisito con alternativas. La respuesta muestra entonces, en data.documentCandidates, los archivos que el cliente ya subió y que pueden responder a ese requisito, con cualquier missingMetadata o conflictingMetadata. Envía el documentId de un candidato con el documentMetadata que falta en lugar de volver a subir el archivo. La consulta necesita accounts:read y customers:read, y una selección no válida devuelve 400 validation_error.

​

Cambiado

• GET /v3/webhooks/portal devuelve una URL de portal que caduca al cabo de una hora, con Cache-Control: no-store. Con una clave de API que tenga webhooks:write, el portal muestra el secreto de firma del endpoint y permite gestionar endpoints, reintentar entregas y repetirlas. Con solo webhooks:read, el portal muestra únicamente las entregas. Consulta Webhooks.
• Citi (citibank) se ofrece solo a clientes empresariales. Todas las empresas conservan Citi agrupado, y Citi con nombre solo se ofrece a empresas registradas fuera de EE. UU. Cuando a un cliente no se le ofrece Citi, la lista de admitidos lo omite, indicarlo devuelve 422 capability_institutions_unsupported y un método que solo ofrece Citi aparece como disabled. Una solicitud sin institutions selecciona entre los bancos restantes. Las solicitudes y cuentas existentes no cambian.
• Las capacidades CFSB (cfsb) con nombre se ofrecen solo a clientes de EE. UU.: empresas registradas en EE. UU. y personas físicas que residen allí. Para otros clientes, la lista de admitidos omite CFSB con nombre, e indicarlo devuelve 422 capability_institutions_unsupported. Una solicitud sin institutions selecciona entre los bancos restantes. CFSB agrupado, los clientes cuyo país se desconoce y las solicitudes existentes no cambian.
• Las capacidades ACH, Wire y SWIFT con nombre de Lead Bank (lead_bank) se ofrecen solo a clientes que Lead Bank puede dar de alta, según su forma jurídica y sus países. Para otros clientes, la lista de admitidos omite lead_bank, e indicarlo devuelve 422 capability_institutions_unsupported. Los clientes que Lead Bank ya dio de alta, y las capacidades cuya solicitud abierta ya indica lead_bank, lo conservan. Las solicitudes y cuentas existentes no cambian.
• RTP es solo agrupado. Ningún banco ofrece rtp_named a nuevas solicitudes, así que la lista de admitidos lo muestra como disabled. Para un cliente que no tiene rtp_named, una solicitud de capacidad o una vista previa de tareas para esa capacidad que indica un banco devuelve 422 capability_institutions_unsupported, y una sin institutions devuelve 422 capability_variant_unavailable. RTP agrupado (rtp_pooled) se ofrece en Citi, así que solo los clientes empresariales pueden solicitarlo.
• Las nuevas solicitudes de documentos de identidad para personas físicas y beneficiarios finales pueden establecer constraints.identityMetadataRequired: true, de modo que cada archivo necesita su número de identificación y país emisor en documentMetadata. Las nuevas solicitudes de comprobante de domicilio de empresa y de comprobante de residencia del propietario pueden establecer constraints.maxIssueAgeDays: 90, de modo que cada archivo necesita su fecha de emisión. Las tareas existentes conservan sus requisitos, así que lee las restricciones de cada solicitud de tarea.
• Una respuesta de tarea a una solicitud de registro de empresa, cuyo profilePointer es /business/registration, necesita el país de la jurisdicción, el número de registro y una fecha de constitución anterior a la fecha de envío, todos juntos. El valueSchema de la solicitud publica esta regla, y una respuesta parcial devuelve 400 validation_error.
• Después de una verificación alojada, Swipelux acepta una respuesta alojada a un requisito de perfil para un valor estructurado, como una dirección o identificadores fiscales, solo cuando supera las mismas comprobaciones de esquema y restricciones que una respuesta directa. En caso contrario, el requisito sigue abierto y envías ese valor con POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Un requisito que Swipelux devuelve a action_required por este motivo lleva reviewFeedback.code: hosted_profile_direct_submission_required. Las tareas que ya están en satisfied conservan su estado. Consulta Capacidades y requisitos.
• Una tarea rechazada por una verificación alojada puede salir de rejected cuando esa decisión de verificación se revierte más adelante. Entonces pasa a satisfied, o a action_required con una nueva revision en la que se reabren los requisitos que la nueva decisión no responde. Los envíos anteriores para esos requisitos siguen en rejected, así que vuelve a enviar esas respuestas. Consulta Migrar a v3.
• El type de los destinos de destinatario es ahora un enum abierto. Versiones anteriores de esta referencia lo describían como cerrado, así que actualiza cualquier cliente que rechace o descarte tipos desconocidos. Las respuestas de destinos y los eventos destination.status_changed ahora pueden incluir pix y pix_safe, y se pueden añadir más tipos.
• Las solicitudes de creación y actualización de destinatarios, incluido el address anidado, ignoran los campos que no definen en lugar de devolver 400 validation_error. En una solicitud de creación, un campo de nombre o de sector del otro tipo de destinatario sigue devolviendo 400, al igual que type y externalId en PATCH /v3/customers/{customerId}/recipients/{recipientId}. Un PATCH sin ningún campo que reconozca devuelve 400 validation_error en lugar de 200.
• Un enlace de verificación para una sesión elegible que solo solicita documentos ahora abre una página de carga de documentos alojada por Swipelux. El enlace en sí no cambia, y las demás sesiones siguen abriendo el flujo de verificación alojado.
• employment.occupation en clientes personas físicas y personas de partes relacionadas acepta como máximo 255 caracteres.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} y POST /v3/customers/{customerId}/tasks/{taskId}/submissions devuelven 400 validation_error cuando un valor del perfil o una respuesta de tarea contiene un enlace a un formulario de Swipelux, como un enlace de RFI, de solicitud del cliente o de seguimiento de transferencia. Esto no se aplica a externalId ni a metadata. Cada valor rechazado aparece en errors[] con code: public_form_link y su JSON Pointer, y la respuesta nunca repite el enlace. Envía la información en sí. Consulta Errores y reintentos.

​

Corregido

• Las respuestas de cotizaciones y transferencias de pago mantienen un importe de origen en USDC o USDT con seis decimales, por ejemplo 4009.711365 en lugar de 4009.71. Los importes fiat mantienen dos decimales. Crear o leer un pago cuyo importe de origen en stablecoin tiene más de dos decimales ya no devuelve 500.
• La referencia de POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel ahora describe la cancelación tal como funciona. Puedes cancelar una capacidad ready, la capacidad stablecoin_transfers no se puede cancelar, y cancelar finaliza solo esa capacidad, mientras que sus solicitudes conservan su estado, tareas y aprobaciones.
• Una solicitud de capacidad o una vista previa de tareas que indica en institutions un código de banco en lugar de un ID público de institución, como citi para citibank, devuelve 422 capability_institutions_unsupported con los ID disponibles en lugar de 503 kyc_configuration_unavailable.
• Una solicitud de capacidad o una vista previa de tareas para un método que ningún banco ofrece al cliente, y que la lista de admitidos muestra como disabled, devuelve 422 capability_variant_unavailable con retryable: false en lugar de 503 kyc_configuration_unavailable, salvo que el cliente ya tenga esa capacidad.
• documentCandidates ya no muestra los archivos que Swipelux conserva de una verificación alojada completada, que no puedes leer ni descargar. Una respuesta de tarea que indica uno de ellos devuelve 400 invalid_document_reference, igual que un documento desconocido.

​

Añadido

• GET /v3/customers acepta include=documentRequirements. Cada resumen de cliente indica entonces cuántos documentos obligatorios siguen pendientes, con independencia de la disponibilidad de las capacidades. Combínalo como include=capabilities,documentRequirements. Consulta Clientes.
• La página de Webhooks del panel de comercio añade Replay missed events al menú del endpoint. Reenvía los eventos de los últimos 13 días que el endpoint nunca recibió y nunca envía el mismo evento dos veces. Consulta Webhooks.
• La página Settings del panel de comercio tiene una sección Compliance. Los propietarios y administradores pueden definir el correo electrónico de cumplimiento y elegir si quieren recibir correos cuando Swipelux solicita más información sobre un cliente.
• Los comercios pueden responder a sus propias solicitudes de cumplimiento KYB directamente en la página de KYB del panel de comercio.

​

Cambiado

• Las actualizaciones de clientes y partes relacionadas ya no devuelven 409 field_conflicts_with_completed_intake después de una admisión bancaria completada. La actualización se guarda y cada nueva solicitud de alta bancaria comprueba el perfil más reciente con sus propios requisitos.
• Las solicitudes de capacidad devuelven 409 capability_route_header_conflict cuando el enrutamiento bancario existente de una capacidad no se puede actualizar de forma segura. Contacta con el soporte de Swipelux antes de reintentar.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview devuelve 422 capability_institutions_unsupported cuando institutions indica un banco que la capacidad no ofrece, igual que las solicitudes de capacidad.
• En el sandbox, las capacidades ACH, Wire y SWIFT se ofrecen solo en JPMorgan Chase. Las solicitudes que omiten institutions seleccionan jpmorgan, e indicar otro banco devuelve 422 capability_institutions_unsupported. El enrutamiento en producción no cambia. Consulta Pruebas en el sandbox.
• Forzar el estado de una capacidad en sandbox devuelve 409 capability_status_blocked con un statusReason cuando el caso simulado no puede alcanzar el estado solicitado. Repetir un forzado que ya se aplicó devuelve 200 sin cambios. Consulta Pruebas en el sandbox.
• POST /v3/sandbox/tasks/{taskId}/review devuelve 409 task_not_sandbox_reviewable para una tarea que pertenece a Operaciones o a otro flujo de trabajo. Las tareas de POST /v3/sandbox/tasks y las tareas de admisión de capacidades que Swipelux recopila siguen siendo revisables. Consulta Pruebas en el sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} devuelve 409 account_provisioning_unresolved cuando cambias la liquidación mientras la cuenta aún se está aprovisionando en el banco. Reintenta cuando el aprovisionamiento se haya resuelto. Consulta Errores y reintentos.
• POST /v3/transfers puede devolver 409 quote_execution_evidence_conflict. Crea una nueva cotización y ejecútala. Consulta Errores y reintentos.
• El panel lateral Pay out del panel de comercio muestra los datos completos del destino, oculta los números de cuenta y las direcciones de monedero tras un interruptor y muestra un tiempo estimado de llegada para cada método de pago.
• El panel de comercio integra las cuentas bancarias en la pestaña Payment access del cliente, con una tarjeta de tareas que indica el nombre de cada banco. La pestaña Documents se ha trasladado a Profile.
• Abrir una cuenta bancaria con nombre en el panel de comercio ahora es un solo paso que muestra la moneda, los métodos y el tiempo de alta de cada banco. Consulta Cuentas.
• Las cuentas bancarias retenidas para revisión aparecen como On hold en el panel de comercio, con el ID de la cuenta y una acción Contact support.
• Una capacidad pending ahora informa statusReason.code: preparing_submission en lugar de review_in_progress mientras Swipelux prepara una solicitud para su envío y no hay ninguna revisión en curso. Ambos códigos usan resolution: wait. Un cambio entre ellos mantiene el estado pending, por lo que no envía ningún evento capability.status_changed. Las capacidades existentes adoptan el nuevo código en su próxima reevaluación. Consulta Capacidades y requisitos.
• La tabla Shared methods de la pestaña Payment access del cliente en el panel de comercio muestra In preparation en lugar de In review para un método compartido cuya capacidad informa preparing_submission.
• La lista applications de una capacidad ahora muestra solo sus solicitudes actuales, en las lecturas de capacidades (incluido GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), en las respuestas a solicitudes de capacidad y en los eventos capability.status_changed. Una solicitud reemplazada por otra más reciente sigue apareciendo en GET /v3/customers/{customerId}/applications, donde supersededByApplicationId indica su sucesora. Las tareas abiertas de una solicitud reemplazada siguen contando en el openTaskIds de la capacidad. El estado y el openTaskIds de la capacidad no cambian, por lo que el cambio en sí no envía ningún evento de webhook. Consulta Capacidades y requisitos.

​

Corregido

• Una segunda solicitud allowPending para la misma cuenta emitida, enviada antes de que el banco la apruebe, devuelve 409 indicando la cuenta en espera en holder.accountId en lugar de 500. Consulta Emitir una cuenta bancaria.
• Cancelar una capacidad ahora cierra las solicitudes de cuentas emitidas que seguían pendientes de aprobación del banco, de modo que una solicitud posterior en el mismo banco empieza desde cero.
• Volver a solicitar una capacidad cancelada cuyos casos bancarios fueron todos rechazados publica un único evento capability.status_changed desde canceled.
• Volver a solicitar un banco después de que su solicitud anterior se archivara ahora envía la nueva solicitud.
• Los destinos de los destinatarios se pueden añadir en cuanto la capacidad correspondiente indica ready, en lugar de devolver 409 rail_not_ready. Consulta Destinatarios.
• Los eventos de webhook enviados antes de que abras por primera vez la página de Webhooks del panel de comercio ahora se conservan, para que puedas reenviarlos a un endpoint nuevo.
• Las fechas de vencimiento de las tareas en el panel de comercio se muestran en tu propia zona horaria, y los paneles laterales de revisión bancaria muestran All requirements submitted cuando no queda nada pendiente.

​

Añadido

• POST /v3/quotes acepta un institutionId opcional para elegir una ruta bancaria aprobada para una cotización de pago de cripto a fiat. Omítelo para mantener el enrutamiento automático. Un banco que no está disponible para el pago devuelve 422 bank_not_supported_for_customer, y enviar institutionId con cualquier otro tipo de cotización devuelve 400 validation_error. Consulta Enviar fondos.
• Las solicitudes de cuentas bancarias emitidas en POST /v3/customers/{customerId}/accounts aceptan institution para fijar la cuenta a un banco sin alternativa, y allowPending: true para guardar la solicitud mientras la solicitud de alta de ese banco sigue pendiente de aprobación. allowPending requiere institution. Las solicitudes guardadas indican el applicationId que las rige. Consulta Emitir una cuenta bancaria.
• El panel de comercio tiene una página nativa de Webhooks para gestionar los endpoints. Consulta Webhooks.
• El panel de comercio añade un panel lateral Pay in con cuentas bancarias con nombre, depósitos de cripto y un paso de revisión.
• El flujo Pay out del panel de comercio muestra los saldos de los monederos en el selector de origen, añade una opción de importe Max e incluye un paso de revisión.
• Los perfiles de cliente del panel de comercio tienen una pestaña Recipients & destinations.
• Los requisitos de las tareas pueden incluir un encabezado title breve. El prompt de la solicitud sigue conteniendo las indicaciones. Consulta Capacidades y requisitos.

​

Cambiado

• Las cotizaciones de pay-in por wire en rutas Wire compartidas ahora requieren al menos 20 $. Las cotizaciones por debajo del mínimo de una ruta, o demasiado pequeñas para cubrir las comisiones de transferencia, devuelven 422 amount_not_deliverable en lugar de un error genérico de cotización. Consulta Recibir fondos.
• El portal de webhooks ahora agrupa los tipos de evento v3 por recurso y muestra el esquema del payload de cada evento y un ejemplo. Los tipos de evento heredados aparecen en un grupo Legacy independiente y están marcados como obsoletos. Los endpoints que ya están suscritos a ellos siguen recibiéndolos; usa tipos de evento v3 para las suscripciones nuevas. Consulta Webhooks.
• Las recargas en sandbox ahora emiten los eventos de webhook transfer.created y transfer.state_changed. Consulta Pruebas en el sandbox.
• accountProvisioning ahora indica issued cuando el cliente ya tiene una cuenta emitida activa. Consulta Capacidades y requisitos.
• Los datos de las cuentas bancarias del panel de comercio se abren en un panel lateral con logotipos de bancos. Consulta Cuentas.
• El panel de comercio etiqueta el movimiento de dinero como Pay in y Pay out, mantiene tu sesión iniciada durante seis horas y envía las solicitudes de ayuda al soporte de Swipelux por correo electrónico.
• En las tareas de admisión que aceptan envío directo, los requisitos aptos que ya están respaldados por el perfil del cliente o por documentos subidos pasan a in_review automáticamente. Consulta Capacidades y requisitos.

​

Corregido

• Volver a solicitar una capacidad cancelada ya no falla debido a registros de solicitud reemplazados o a requisitos desactualizados.
• Las capacidades almacenadas con el ID retirado de Fedwire ahora se leen como wire en lugar de devolver 500.

​

Añadido

• GET /v3/customers/{customerId}/applications enumera los casos de solicitud de un cliente, con las capacidades solicitadas en cada caso y las capacidades que cubre su aprobación. Una sola aprobación en un banco puede cubrir varias capacidades. Los casos históricos conservados apuntan a su sucesor mediante supersededByApplicationId. La lista admite paginación por cursor y updatedAfter. Consulta Capacidades y requisitos.
• Las respuestas de POST /v3/customers/{customerId}/capabilities/{capabilityId} incluyen selectedApplicationId para las capacidades respaldadas por un caso. Identifica el caso de solicitud existente que reutilizó la petición o el caso que abrió. Consulta Capacidades y requisitos.
• Las instituciones que devuelven GET /v3/institutions y la lista de capacidades admitidas incluyen un logoUrl que puede ser nulo. Úsalo para mostrar la marca del banco cuando esté disponible y recurre al nombre de la institución cuando sea null. Consulta Capacidades y requisitos.
• Los pagos SWIFT en USD ya están disponibles. Los pagos SWIFT requieren al menos 100 USD. El panel de comercio recopila las instrucciones bancarias SWIFT de los destinatarios. Consulta Enviar fondos.
• Las cuentas bancarias emitidas pueden recibir por SWIFT con datos de recepción nominativos. Consulta Emitir una cuenta bancaria.
• USDT ahora se admite como origen para pagos ACH y Wire. Consulta Enviar fondos.
• Las cuentas bancarias emitidas aceptan settlement.currency con el valor USDC o USDT para elegir la stablecoin que se entrega en el monedero de liquidación, con independencia de la moneda de la cuenta del monedero. Omítelo para seguir liquidando en la moneda del monedero. Consulta Emitir una cuenta bancaria.
• Las cuentas bancarias SWIFT y los destinos de los destinatarios aceptan bankCity, bankState, bankPostalCode y bankAddressLine2, además de los campos opcionales beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode y paymentCode, y los datos del banco intermediario. Consulta Enviar fondos.
• Los datos de las cuentas bancarias emitidas incluyen achRoutingNumber y wireRoutingNumber cuando el banco proporciona números de ruta ACH y Wire separados, y bankLogoUrl del banco receptor. Consulta Emitir una cuenta bancaria.
• Los eventos de webhook capability.created incluyen applicationId y un origin con el valor requested o approval, para que puedas distinguir las capacidades que solicitaste de las que cubrió una aprobación. Consulta Webhooks.
• Las solicitudes de requisitos pueden declarar un constraints.format de validación, como http_url, us_ssn, us_ein o bank_industry_classification. Consulta Capacidades y requisitos.

​

Cambiado

• La creación de cuentas bancarias en el panel de comercio ahora empieza por la selección del banco, y las cuentas bancarias muestran números de ruta ACH y Wire separados. Consulta Cuentas.
• El enum network ahora incluye solana. Es un enum abierto, así que tolera los valores de red que no reconozcas. Consulta Cuentas.
• Abrir un enlace de verificación alojado para una tarea cuyos requisitos restantes necesitan envío directo devuelve 409 verification_session_not_allowed. Envía esos requisitos como un envío de tarea. Consulta Errores y reintentos.
• Archivar una cuenta emitida cuyo aprovisionamiento aún no se ha resuelto devuelve 409 account_provisioning_unresolved. Reintenta cuando el aprovisionamiento se haya resuelto. Consulta Errores y reintentos.
• Las nuevas solicitudes de cuentas bancarias con nombre se ponen en cola para su aprovisionamiento en cuanto se crea la cuenta, en lugar de esperar a la siguiente actualización del cliente. Consulta Emitir una cuenta bancaria.

​

Eliminado

• Ya no se ofrecen datos de recepción SWIFT compartidos para cuentas nuevas. Usa en su lugar datos de recepción SWIFT nominativos. Consulta Emitir una cuenta bancaria.

​

Corregido

• Las lecturas de transferencias de pago ahora devuelven el destinatario cotizado.
• Crear una cuenta ACH después de archivar una existente ya no devuelve 409, y las solicitudes de cuenta pendientes archivadas ya no ocupan una plaza de cuenta.
• Las comisiones bancarias de las cotizaciones de pay-in en moneda local se indican en la moneda fiat correcta.

​

Añadido

• GET /v3/webhooks/{webhookId} lee un único endpoint de webhook y su selección de events. Consulta Webhooks.
• Los requisitos de las tareas ahora publican allowedValues y un valueSchema de JSON Schema para los campos de perfil, incluidos los campos de dirección obligatorios. Los campos de país indican un valueType o itemValueType con el valor country, un código ISO 3166-1 alpha-2. Puedes renderizar entradas y opciones sin codificarlas de forma fija. Consulta Capacidades y requisitos.
• Los monederos de Tron existentes ahora pueden enviar USDT a las cuentas de monedero externo del cliente, y las lecturas de transferencias incluyen un enlace a un explorador de bloques para las transacciones de Tron. No se pueden emitir monederos nuevos en Tron. Consulta Enviar fondos.
• Los requisitos de las tareas pueden declarar requiredWhen (responder solo cuando coincide una respuesta de sí/no indicada), profileAssertion (us_person) y ownershipPolicy, y las solicitudes de documentos pueden establecer identityMetadataRequired y maxIssueAgeDays. Las respuestas de las tareas aceptan documentMetadata (idNumber, issuingCountry, issuedOn) para los documentos referenciados, y las lecturas de tareas devuelven las respuestas de control revisadas en conditionValues. Consulta Capacidades y requisitos.
• Los requisitos de documentos pueden enumerar acceptedDocumentSets, y los requisitos de partes relacionadas pueden pedir una cualificación associated_person o control_person además de beneficial_owner. Consulta Capacidades y requisitos.
• Los objetos correction de las transferencias ahora también cubren los pagos financiados fallidos: kind: funding_failure con una acción compensatoria recover_source_funding, un recoveryStatus con el valor unknown o reported, y salidas acreditadas en USDT. Consulta Cotizaciones y transferencias.

​

Cambiado

• PATCH /v3/webhooks/{webhookId} ahora acepta los tipos de evento heredados a los que el endpoint ya está suscrito, de modo que puedes conservarlos mientras añades tipos de evento v3. events reemplaza la selección completa, así que incluye todos los tipos de evento que quieras conservar. Añadir un tipo de evento heredado que el endpoint no tenía previamente devuelve 400 validation_error. Consulta Webhooks.
• Los identificadores bancarios de los destinatarios y las cuentas se validan antes de guardarse. Consulta Destinatarios.
• Las solicitudes de capacidad, los envíos de tareas y los cambios de estado en el sandbox ahora devuelven 409 capability_application_stale en lugar de 500 cuando una capacidad se creó con un modelo de onboarding anterior. Consulta Errores y reintentos.
• La página pública de RFI ahora es un único formulario continuo. Admite personas relacionadas y recopila un número de identificación fiscal por persona. Consulta Requisitos de documentos.
• Las cotizaciones y transferencias devuelven 409 customer_bank_limit_exceeded cuando un pago supera el margen diario o mensual restante del cliente en el banco, y 503 customer_bank_limits_unavailable cuando no se puede comprobar ese margen. Las transferencias devuelven 409 payout_execution_unavailable cuando un pago no puede iniciarse a partir de su cotización. Consulta Errores y reintentos.
• Las actualizaciones de clientes y partes relacionadas que entran en conflicto con una admisión bancaria completada devuelven 409 field_conflicts_with_completed_intake con el taskId y los fields.

​

Corregido

• El historial de capacidades canceladas sigue siendo legible.
• Los pagos por wire se muestran y se filtran correctamente en la lista de transacciones del panel de comercio.

​

Cambiado

• POST /v3/transfers y las lecturas de transferencias usan checkoutMethod en lugar de paymentMethod para la preselección del checkout de tarjeta, y aceptan card, apple_pay, google_pay, cash_app, sepa y blik. La lista es abierta y puede crecer. paymentMethod ya no se reconoce; las solicitudes que aún lo envían se tratan como si se hubiera omitido. sepa y blik son opciones de pago dentro del checkout de tarjeta, no capacidades de Swipelux. Consulta Recibir fondos.

​

Añadido

• POST /v3/transfers acepta un paymentMethod opcional con el valor card, apple_pay o google_pay para cotizaciones de tarjeta. El checkout alojado se abre con el método solicitado cuando está disponible para el cliente y su dispositivo, las lecturas de la transferencia devuelven la solicitud, y los importes y las comisiones de la cotización no cambian. Consulta Recibir fondos.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview acepta institutions para previsualizar las tareas de bancos concretos devueltos por la lista de capacidades admitidas. Consulta Capacidades y requisitos.

​

Cambiado

• Las cotizaciones con tarjeta ahora reflejan las comisiones del checkout y el USDC neto entregado. Consulta Recibir fondos.
• Las cotizaciones de pago rechazadas devuelven un código de problema específico en lugar de un error genérico: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported o quote_failed, y 503 quote_temporarily_unavailable cuando la cotización puede reintentarse más tarde. Consulta Errores y reintentos.

​

Corregido

• Las cotizaciones con tarjeta ya no fallan por el redondeo de las comisiones.
• Volver a abrir un enlace de KYC alojado ya no devuelve 409 kyc_process_conflict cuando las respuestas del cuestionario incluyen espacios adicionales.
• Las confirmaciones de retiro con passkey bloqueadas en el panel de comercio ahora se recuperan.

​

Añadido

• POST /v3/customers/{customerId}/documents ahora también acepta un cuerpo application/json con storageKey, fileName y type. El storageKey debe ser una referencia reciente con ámbito de cliente aparcada mediante el flujo anterior de direct-upload, y la subida pasa la misma validación de tamaño y de firma de archivo que las subidas multipart. Consulta Migrar a v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download devuelve una url de descarga para un documento de cliente activo. La URL expira después de una hora y sirve el archivo como adjunto. Los documentos archivados, desconocidos y de otros clientes devuelven 404. Consulta Capacidades y requisitos.
• Solicitar una capacidad para una empresa sin beneficiario efectivo ahora crea una tarea de admisión para añadir uno en lugar de fallar con un 503. Las solicitudes que no pueden continuar devuelven 422 beneficial_owner_required con instrucciones para añadir una parte relacionada individual con una participación declarada o de al menos el 25 %. Consulta Accionistas, UBO y personas de control.
• La tabla de tareas del panel de comercio ahora muestra el sujeto y el ámbito de capacidad de cada solicitud, de modo que puedes ver a quién y qué cubre una solicitud de cumplimiento. Consulta Capacidades y requisitos.
• Los campos de clasificación industrial del panel de comercio ahora ofrecen códigos NAICS con búsqueda en los perfiles de cliente y en las tareas de requisitos. Consulta Flujo de KYB.
• Las instrucciones bancarias de pay-in pueden incluir bankName, bankAddress, accountHolderName y accountHolderAddress. Muéstralos junto con el resto de los datos bancarios. Consulta Recibir fondos.
• POST /v3/transfers acepta un redirectUrl opcional que devuelve al cliente a tu aplicación después de un checkout alojado con tarjeta o Apple Pay. Llegar a la URL no confirma que la operación se haya completado; usa las lecturas de transferencias o los webhooks. Consulta Recibir fondos.
• Las transferencias creadas por una Rule de v3 aparecen en las lecturas y listas de transferencias con origin: rule y emiten eventos transfer.state_changed como las demás transferencias. Fíltralas con GET /v3/transfers?origin=rule. Consulta Cotizaciones y transferencias.
• Los documentos de identidad de clientes y partes relacionadas aceptan sideApplicability (front_only, front_and_back o unknown), y las tareas pueden recopilar como respuestas datos del documento de identidad como type, number, issuingCountry, issuingRegion, issuedOn, expiresOn y doesNotExpire. Consulta Capacidades y requisitos.

​

Cambiado

• Los envíos de datos bancarios que entran en conflicto con una configuración bancaria en curso ahora devuelven 409 ops_rail_handoff_conflict. Conserva los identificadores de los documentos subidos y reintenta el mismo envío cuando el conflicto se haya resuelto, en lugar de volver a subir los documentos. Consulta Errores y reintentos.
• El mínimo para depósitos de stablecoins no anunciados en los monederos de los clientes ahora es de 1 unidad en lugar de 10. Los depósitos más pequeños se siguen tratando como residuales. Consulta Recibir fondos.
• La configuración de webhooks ahora está aislada por entorno. El portal de webhooks se abre limitado al entorno desde el que lo solicitas, por lo que los endpoints de sandbox y de producción ya no comparten ajustes. Consulta Webhooks.
• El panel de comercio ahora deriva los métodos de pay-in disponibles de las capacidades v3 del cliente, por lo que la configuración de cuentas solo ofrece métodos a los que el cliente tiene derecho. Consulta Cuentas.
• Los formularios RFI ahora recopilan los beneficiarios efectivos que cumplen los requisitos con indicaciones más cortas y claras, y el historial de RFI se muestra como hitos del ciclo de vida. Consulta Requisitos de documentos.
• Las tareas abiertas sin una fecha de vencimiento explícita ahora establecen dueAt por defecto en 31 días después de su creación. Consulta Capacidades y requisitos.

​

Eliminado

• El panel de comercio ya no ofrece Fedwire al añadir nuevos métodos de pay-in. Las cuentas Fedwire existentes siguen siendo legibles. Consulta Cuentas.

​

Corregido

• Los depósitos de USDT no anunciados en los monederos de los clientes ahora se reconocen y se liquidan en lugar de ignorarse.
• Las evidencias que ya has enviado ahora se trasladan a otras tareas que requieren el mismo elemento, por lo que no se pide a los clientes el mismo documento dos veces.
• Volver a solicitar una capacidad ya no descarta las rutas bancarias que ya están listas, por lo que los datos de las cuentas emitidas se mantienen estables.
• Las vistas de instrucciones bancarias del panel de comercio ahora muestran los datos completos, incluidas las direcciones SWIFT y la dirección del monedero de destino.
• Los formularios RFI ahora muestran los errores de validación del envío, validan las descripciones de la forma jurídica antes del envío y aceptan varios sitios web de la empresa.
• Ahora puedes editar los borradores de personas relacionadas en los formularios RFI antes de enviarlos.
• Las solicitudes de cumplimiento canceladas ya no aparecen en la lista de tareas del panel de comercio.
• Los estados de revisión de documentos vuelven a mostrarse correctamente en el panel de comercio.

​

Añadido

• Las sesiones alojadas de verificación y de Términos del servicio con ámbito de cliente ahora incluyen un objeto action autoritativo. Sigue su tipo available o unavailable; los campos planos url y expiresAt se mantienen como reflejos de compatibilidad para las acciones disponibles. Consulta Capacidades y requisitos.
• Las recargas de monederos en el sandbox ahora devuelven identificadores de transferencia que puedes consultar con GET /v3/transfers/{transferId} o listar con GET /v3/transfers. Aparecen como depósitos entrantes de stablecoins completados. Consulta Pruebas en el sandbox.
• Las lecturas de transferencias incluyen un objeto correction cuando los fondos de una transferencia se devuelven o se revierten después de completarse. Indica el kind de la corrección, el providerStatus normalizado, cualquier providerShortfall y el compensatingIntent que aplica Swipelux. Consulta Cotizaciones y transferencias.

​

Cambiado

• El recorrido First pay-in del panel de comercio para tarjetas y Apple Pay ahora requiere un monedero Polygon del cliente. Créalo antes de iniciar el recorrido. Consulta Cuentas.
• Las solicitudes nuevas y las respuestas públicas utilizan sepa como nombre canónico del método y la capacidad. El alias de entrada sepa_instant y los recursos almacenados anteriormente siguen siendo compatibles, pero las respuestas públicas utilizan sepa. Consulta Cuentas.
• Las nuevas solicitudes de capacidad, cuenta emitida y cotización de Faster Payments no están disponibles. Las cuentas, cotizaciones y transferencias existentes siguen siendo legibles. Consulta Cuentas.
• La primera página de KYB ya no recopila la fecha de nacimiento del representante. Las fechas de nacimiento de los accionistas siguen siendo un requisito independiente. Consulta Flujo de KYB.
• Las referencias de documentos RFI ahora aceptan el alias MIME image/jpg además de image/jpeg. Consulta Requisitos de documentos.
• El historial de tareas del panel de comercio ahora muestra un registro de auditoría legible sin contadores de revisión. Consulta Capacidades y requisitos.
• Las cotizaciones y transferencias ahora comprueban las direcciones admitidas por la capacidad antes de que se mueva dinero. Usar una capacidad en una dirección que no admite devuelve 422 capability_direction_unsupported, y los movimientos entre monederos requieren una capacidad stablecoin_transfers. Consulta Errores y reintentos.

​

Eliminado

• El panel de comercio ya no ofrece la configuración de nuevas cuentas UAEFTS. Las cuentas UAEFTS existentes siguen siendo legibles. Consulta Cuentas.

​

Corregido

• Los formularios RFI conservan las entradas existentes cuando un revisor añade una nueva entrega de documentos, por lo que las respuestas anteriores no se pierden al volver a enviar.
• El panel de comercio reanuda las sesiones alojadas de cumplimiento desde las acciones disponibles sin descartar enlaces válidos.
• Los enlaces alojados a los Términos del servicio ahora funcionan para todos los ámbitos de tarea que devuelve la API.
• Después de solicitar Payment Access en el panel de comercio, se abre la tarea de admisión devuelta por esa solicitud en lugar de una tarea de una solicitud anterior.
• La demostración de KYB del panel de comercio ahora solicita los campos obligatorios actuales.
• Una cotización que reutiliza su monedero de origen como destinationId ahora devuelve detalles útiles de 422 quote_direction_invalid antes de iniciar cualquier trabajo del proveedor. Consulta Cotizaciones y transferencias.
• La API rechaza la codificación incorrecta de la cadena de consulta con un error 400 en lugar de normalizar silenciosamente la solicitud. Consulta Errores y reintentos.
• POST /v3/customers/{customerId}/documents ahora rechaza los cuerpos de solicitud vacíos, que no sean multipart o que estén mal formados con un error 400.

​

Añadido

• Se publicó el catálogo de Problem Details de v3 en la especificación OpenAPI para que los integradores puedan asignar las respuestas de error directamente desde el esquema. Consulta Errores.
• Se añadió customerId a los eventos webhook de cuenta en v3, lo que te permite correlacionar la actividad de cuenta con el cliente propietario sin una lectura adicional. Consulta Webhooks.
• Cobertura completa de los campos del perfil individual en V3 en el panel del comerciante, para que los operadores de onboarding puedan revisar y editar cada campo KYC recopilado a través de la API v3. Consulta Clientes.
• Se publicó una guía de migración para desarrolladores de v3. Consulta Migrar a v3.

​

Cambiado

• Los códigos de país de clientes y cuentas ahora se validan como valores ISO 3166-1 alpha-2 asignados en el momento de la escritura. Las lecturas toleran los valores heredados almacenados para que los registros existentes sigan resolviéndose. Consulta Cuentas y carteras.
• La disponibilidad de USDC ahora se limita según la red de destino, por lo que las cotizaciones y transferencias solo ofrecen USDC en las redes que el destino realmente admite.
• Todos los flujos de onboarding ahora requieren los Términos del servicio de Swipelux. Las sesiones existentes siguen siendo reanudables. Consulta Clientes.
• Capability.ready sigue indicando la aprobación del derecho. Usa accountProvisioning para seguir la emisión de la cuenta como not_applicable, not_started, in_progress, issued o failed. Consulta Capacidades y requisitos.
• Ahora se aceptan las subidas HEIC desde iPhone como documentos de identidad y de domicilio.
• Borrar un campo de cliente o de parte relacionada que una tarea abierta todavía requiere ahora devuelve 409 field_required_by_open_task con el taskId bloqueante y los fields, en lugar de un conflicto reintentable. Completa o cancela la tarea antes de cambiar esos campos. Consulta Errores y reintentos.

​

Corregido

• Volver a ejecutar una cotización ya consumida ahora devuelve 409 quote_execution_consumed en lugar de un error genérico. Consulta Cotizaciones y transferencias.
• Las lecturas de la lista de transferencias y de los importes de cotización ya no devuelven 500 en resultados históricos grandes.
• Las redirecciones de KYC concurrentes ahora devuelven un conflicto en lugar de 404, por lo que los reintentos se resuelven correctamente. Las redirecciones alojadas ya no se revierten a mitad de camino, y los enlaces de KYC siguen siendo reanudables.
• Las lecturas de partes relacionadas para clientes individuales ya no devuelven 404.
• Los envíos de KYB con campos de wallet inválidos se rechazan antes del envío, y la sincronización fallida ya no se informa como éxito en el panel del comerciante.
• Las tareas de requisitos en el panel del comerciante ahora muestran las respuestas enviadas como completadas, siguen por separado las acciones de términos, eliminan el texto duplicado de los documentos, mantienen como pendientes las sesiones de KYC iniciadas hasta su finalización y gestionan las tareas obsoletas sin romper la vista de requisitos.
• Las filas de enlaces de verificación en el panel del comerciante ahora muestran una acción Open en cada fila, y cada enlace de tarea se representa en la vista de requisitos.