Registre de canvis i notes de versió de l'API de Swipelux

​

Afegit

• Les destinacions de destinataris accepten els tipus pix i pix_safe per a pagaments en BRL al Brasil. Una destinació Pix paga a una clau Pix. Una destinació Pix Safe paga a un compte bancari identificat pel CPF o CNPJ del titular, el codi ISPB del banc, la sucursal i el número de compte. Totes dues necessiten la capacitat Pix preparada del client (pix_pooled), i els seus pagaments es financen amb USDC i no porten comissió de desenvolupador. Consulta Destinataris i Envia fons.
• GET /v3/customers/{customerId}/tasks/{taskId} accepta documentCandidatesFor amb un ID de requisit de document, a més de documentAlternativeKey per a un requisit amb alternatives. Aleshores, la resposta llista a data.documentCandidates els fitxers que el client ja ha pujat i que poden respondre aquest requisit, amb qualsevol missingMetadata o conflictingMetadata. Envia el documentId d’un candidat amb el documentMetadata que falta en lloc de tornar a pujar el fitxer. La consulta necessita accounts:read i customers:read, i una selecció no vàlida retorna 400 validation_error.

​

Canviat

• GET /v3/webhooks/portal retorna una URL de portal que caduca al cap d’una hora, amb Cache-Control: no-store. Amb una clau d’API que té webhooks:write, el portal mostra el secret de signatura del punt final i permet gestionar punts finals, reintentar lliuraments i repetir-los. Amb només webhooks:read, el portal només mostra els lliuraments. Consulta Webhooks.
• Citi (citibank) només s’ofereix a clients empresa. Totes les empreses conserven Citi compartit, i Citi amb nom només s’ofereix a empreses registrades fora dels EUA. Quan no s’ofereix Citi a un client, la llista d’admesos l’omet, indicar-lo retorna 422 capability_institutions_unsupported, i un mètode que només ofereix Citi apareix com a disabled. Una sol·licitud sense institutions tria entre els bancs restants. Les sol·licituds i els comptes existents no canvien.
• Les capacitats de CFSB amb nom (cfsb) només s’ofereixen a clients dels EUA: empreses registrades als EUA i particulars que hi resideixen. Per a la resta de clients, la llista d’admesos omet CFSB amb nom, i indicar-lo retorna 422 capability_institutions_unsupported. Una sol·licitud sense institutions tria entre els bancs restants. CFSB compartit, els clients amb país desconegut i les sol·licituds existents no canvien.
• Les capacitats ACH, Wire i SWIFT amb nom de Lead Bank (lead_bank) només s’ofereixen als clients que Lead Bank pot donar d’alta, segons la seva forma jurídica i els seus països. Per a la resta de clients, la llista d’admesos omet lead_bank, i indicar-lo retorna 422 capability_institutions_unsupported. Els clients que Lead Bank ja ha donat d’alta, i les capacitats la sol·licitud oberta de les quals ja indica lead_bank, el conserven. Les sol·licituds i els comptes existents no canvien.
• RTP només és compartit. Cap banc no ofereix rtp_named a les noves sol·licituds, així que la llista d’admesos el mostra com a disabled. Per a un client que no té rtp_named, una sol·licitud de capacitat o una previsualització de tasques per a aquesta capacitat que indica un banc retorna 422 capability_institutions_unsupported, i una sense institutions retorna 422 capability_variant_unavailable. RTP compartit (rtp_pooled) s’ofereix a Citi, així que només els clients empresa el poden sol·licitar.
• Les noves sol·licituds de documents d’identitat per a particulars i beneficiaris efectius poden definir constraints.identityMetadataRequired: true, de manera que cada fitxer necessita el seu número d’identificació i el país emissor a documentMetadata. Les noves sol·licituds de justificant d’adreça de l’empresa i de justificant de residència dels propietaris poden definir constraints.maxIssueAgeDays: 90, de manera que cada fitxer necessita la seva data d’emissió. Les tasques existents conserven els seus requisits, així que llegeix les restriccions de cada sol·licitud de tasca.
• Una resposta a una tasca per a una sol·licitud de registre de l’empresa, el profilePointer de la qual és /business/registration, necessita el país de la jurisdicció, el número de registre i una data de constitució anterior a la data d’enviament, tots junts. El valueSchema de la sol·licitud publica aquesta regla, i una resposta parcial retorna 400 validation_error.
• Després d’una verificació allotjada, Swipelux accepta una resposta allotjada a un requisit de perfil per a un valor estructurat, com ara una adreça o identificadors fiscals, només quan supera les mateixes comprovacions d’esquema i de restriccions que una resposta directa. En cas contrari, el requisit continua obert i envies aquest valor amb POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Un requisit que Swipelux torna a action_required per aquest motiu porta reviewFeedback.code: hosted_profile_direct_submission_required. Les tasques que ja són satisfied mantenen el seu estat. Consulta Capacitats i requisits.
• Una tasca rebutjada per una verificació allotjada pot sortir de l’estat rejected quan aquesta decisió de verificació es revoca més endavant. Aleshores passa a satisfied, o a action_required amb una nova revision i amb els requisits que la nova decisió no respon reoberts. Els enviaments anteriors d’aquests requisits continuen rejected, així que torna a enviar aquestes respostes. Consulta Migrar a v3.
• El type de les destinacions de destinataris ara és una enumeració oberta. Les versions anteriors d’aquesta referència la descrivien com a tancada, així que actualitza qualsevol client que rebutgi o descarti tipus desconeguts. Les respostes de destinacions i els esdeveniments destination.status_changed ara poden incloure pix i pix_safe, i se’n poden afegir més tipus.
• Les sol·licituds de creació i actualització de destinataris, inclosa l’address niada, ignoren els camps que no defineixen en lloc de retornar 400 validation_error. En una sol·licitud de creació, un camp de nom o de sector de l’altre tipus de destinatari continua retornant 400, i també type i externalId a PATCH /v3/customers/{customerId}/recipients/{recipientId}. Un PATCH sense cap camp que reconegui retorna 400 validation_error en lloc de 200.
• Un enllaç de verificació per a una sessió elegible que només demana documents ara obre una pàgina de pujada de documents allotjada per Swipelux. L’enllaç en si no canvia, i les altres sessions continuen obrint el flux de verificació allotjat.
• employment.occupation en clients particulars i en persones de parts relacionades accepta com a màxim 255 caràcters.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} i POST /v3/customers/{customerId}/tasks/{taskId}/submissions retornen 400 validation_error quan un valor del perfil o una resposta a una tasca conté un enllaç a un formulari de Swipelux, com ara un enllaç de RFI, de sol·licitud del client o de seguiment de transferència. Això no s’aplica a externalId ni a metadata. Cada valor rebutjat apareix a errors[] amb code: public_form_link i el seu JSON Pointer, i la resposta mai no repeteix l’enllaç. Envia la informació en si. Consulta Errors i reintents.

​

Corregit

• Les respostes de cotitzacions i transferències de pagament conserven l’import d’origen en USDC o USDT amb sis decimals, per exemple 4009.711365 en lloc de 4009.71. Els imports en moneda fiduciària conserven dos decimals. Crear o llegir un pagament amb un import d’origen en stablecoin de més de dos decimals ja no retorna 500.
• La referència de POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel ara descriu la cancel·lació tal com funciona. Pots cancel·lar una capacitat ready, la capacitat stablecoin_transfers no es pot cancel·lar, i la cancel·lació només finalitza aquesta capacitat, mentre que les seves sol·licituds conserven l’estat, les tasques i les aprovacions.
• Una sol·licitud de capacitat o una previsualització de tasques que indica a institutions un codi de banc en lloc d’un ID públic d’institució, com ara citi per a citibank, retorna 422 capability_institutions_unsupported amb els ID disponibles en lloc de 503 kyc_configuration_unavailable.
• Una sol·licitud de capacitat o una previsualització de tasques per a un mètode que cap banc no ofereix al client, i que la llista d’admesos mostra com a disabled, retorna 422 capability_variant_unavailable amb retryable: false en lloc de 503 kyc_configuration_unavailable, tret que el client ja tingui aquesta capacitat.
• documentCandidates ja no llista els fitxers que Swipelux conserva d’una verificació allotjada completada, que no pots llegir ni baixar. Una resposta a una tasca que n’indica un retorna 400 invalid_document_reference, igual que un document desconegut.

​

Afegit

• GET /v3/customers accepta include=documentRequirements. Aleshores, el resum de cada client indica quants documents obligatoris encara estan pendents, independentment de la preparació de les capacitats. Combina-ho com a include=capabilities,documentRequirements. Consulta Clients.
• La pàgina de Webhooks del panell del comerç afegeix Replay missed events al menú del punt final. Torna a enviar els esdeveniments dels darrers 13 dies que el punt final no ha rebut mai, i mai no envia el mateix esdeveniment dues vegades. Consulta Webhooks.
• La pàgina Settings del panell del comerç té una secció Compliance. Els propietaris i els administradors poden definir el correu electrònic de compliment i triar si volen rebre correus quan Swipelux sol·licita més informació sobre un client.
• Els comerços poden respondre les seves pròpies sol·licituds de compliment de KYB directament a la pàgina de KYB del panell del comerç.

​

Canviat

• Les actualitzacions de clients i de parts relacionades ja no retornen 409 field_conflicts_with_completed_intake després d’una admissió bancària completada. L’actualització es desa, i cada nova sol·licitud d’alta bancària comprova el perfil més recent amb els seus propis requisits.
• Les sol·licituds de capacitats retornen 409 capability_route_header_conflict quan l’encaminament bancari existent d’una capacitat no es pot actualitzar de manera segura. Contacta amb el suport de Swipelux abans de tornar-ho a provar.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview retorna 422 capability_institutions_unsupported quan institutions indica un banc que la capacitat no ofereix, tal com ja fan les sol·licituds de capacitats.
• Al sandbox, les capacitats ACH, Wire i SWIFT només es serveixen a JPMorgan Chase. Les sol·licituds que ometen institutions seleccionen jpmorgan, i indicar un altre banc retorna 422 capability_institutions_unsupported. L’encaminament en producció no canvia. Consulta Proves al sandbox.
• Forçar l’estat d’una capacitat al sandbox retorna 409 capability_status_blocked amb un statusReason quan el cas simulat no pot arribar a l’estat sol·licitat. Repetir un forçament que ja s’ha aplicat retorna 200 sense canvis. Consulta Proves al sandbox.
• POST /v3/sandbox/tasks/{taskId}/review retorna 409 task_not_sandbox_reviewable per a una tasca que pertany a Operacions o a un altre flux de treball. Les tasques de POST /v3/sandbox/tasks i les tasques d’admissió de capacitats que Swipelux recull continuen sent revisables. Consulta Proves al sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} retorna 409 account_provisioning_unresolved quan canvies la liquidació mentre el compte encara s’està aprovisionant al banc. Torna-ho a provar quan l’aprovisionament s’hagi resolt. Consulta Errors i reintents.
• POST /v3/transfers pot retornar 409 quote_execution_evidence_conflict. Crea una cotització nova i executa-la. Consulta Errors i reintents.
• El calaix Pay out del panell del comerç mostra totes les dades de la destinació, amaga els números de compte i les adreces de cartera darrere d’un commutador i mostra un temps d’arribada estimat per a cada mètode de pagament.
• El panell del comerç integra els comptes bancaris a la pestanya Payment access del client, amb una targeta de tasques que indica cada banc. La pestanya Documents s’ha traslladat a Profile.
• Obrir un compte bancari amb nom al panell del comerç ara és un sol pas que llista la moneda, els mètodes i el temps d’alta de cada banc. Consulta Comptes.
• Els comptes bancaris retinguts per a revisió es mostren com a On hold al panell del comerç, amb l’ID del compte i una acció Contact support.
• Una capacitat pending ara informa statusReason.code: preparing_submission en lloc de review_in_progress mentre Swipelux prepara una sol·licitud per enviar-la i no hi ha cap revisió en curs. Tots dos codis utilitzen resolution: wait. Un canvi entre ells manté l’estat pending, de manera que no envia cap esdeveniment capability.status_changed. Les capacitats existents adopten el nou codi en la seva propera reavaluació. Consulta Capacitats i requisits.
• La taula Shared methods de la pestanya Payment access del client al panell del comerç mostra In preparation en lloc de In review per a un mètode compartit la capacitat del qual informa preparing_submission.
• La llista applications d’una capacitat ara només mostra les sol·licituds actuals, en les lectures de capacitats (incloent-hi GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), en les respostes a les sol·licituds de capacitat i en els esdeveniments capability.status_changed. Una sol·licitud substituïda per una de més nova continua apareixent a GET /v3/customers/{customerId}/applications, on supersededByApplicationId indica la seva successora. Les tasques obertes d’una sol·licitud substituïda continuen comptant a l’openTaskIds de la capacitat. L’estat i l’openTaskIds de la capacitat no canvien, de manera que el canvi en si no envia cap esdeveniment de webhook. Consulta Capacitats i requisits.

​

Corregit

• Una segona sol·licitud allowPending per al mateix compte emès, enviada abans que el banc l’aprovi, retorna 409 amb el compte en espera indicat a holder.accountId en lloc de 500. Consulta Emet un compte bancari.
• Cancel·lar una capacitat ara tanca les sol·licituds de comptes emesos que encara esperaven l’aprovació del banc, de manera que una sol·licitud posterior al mateix banc comença de zero.
• Tornar a sol·licitar una capacitat cancel·lada amb tots els casos bancaris rebutjats publica un únic esdeveniment capability.status_changed des de canceled.
• Tornar a sol·licitar un banc després que la seva sol·licitud d’alta anterior s’hagi arxivat ara envia la sol·licitud nova.
• Les destinacions dels destinataris es poden afegir tan bon punt la capacitat corresponent indica ready, en lloc de retornar 409 rail_not_ready. Consulta Destinataris.
• Els esdeveniments de webhook enviats abans d’obrir per primera vegada la pàgina de Webhooks del panell del comerç ara es conserven, de manera que els pots tornar a enviar a un punt final nou.
• Les dates de venciment de les tasques al panell del comerç es mostren en la teva zona horària, i els calaixos de revisió bancària mostren All requirements submitted quan ja no queda res pendent.

​

Afegit

• POST /v3/quotes accepta un institutionId opcional per triar una ruta bancària aprovada per a una cotització de pagament de cripto a fiat. Omet-lo per mantenir l’encaminament automàtic. Un banc que no està disponible per al pagament retorna 422 bank_not_supported_for_customer, i enviar institutionId amb qualsevol altre tipus de cotització retorna 400 validation_error. Consulta Enviar fons.
• Les sol·licituds de comptes bancaris emesos a POST /v3/customers/{customerId}/accounts accepten institution per fixar el compte a un sol banc sense alternativa, i allowPending: true per desar la sol·licitud mentre la sol·licitud d’alta en aquest banc encara està pendent d’aprovació. allowPending requereix institution. Les sol·licituds desades indiquen l’applicationId que les regeix. Consulta Emet un compte bancari.
• El panell del comerç té una pàgina nativa de Webhooks per gestionar els punts finals. Consulta Webhooks.
• El panell del comerç afegeix un calaix Pay in amb comptes bancaris amb nom, dipòsits de cripto i un pas de revisió.
• El flux Pay out del panell del comerç mostra els saldos de les carteres al selector d’origen, afegeix l’opció d’import Max i inclou un pas de revisió.
• Els perfils de client del panell del comerç tenen una pestanya Recipients & destinations.
• Els requisits de les tasques poden incloure un encapçalament curt title. El prompt de la sol·licitud continua contenint les indicacions. Consulta Capacitats i requisits.

​

Canviat

• Les cotitzacions de pay-in per transferència wire en rutes Wire agrupades ara requereixen almenys 20 $. Les cotitzacions per sota del mínim d’una ruta, o massa petites per cobrir les comissions de transferència, retornen 422 amount_not_deliverable en lloc d’un error genèric de cotització. Consulta Rebre fons.
• El portal de webhooks ara agrupa els tipus d’esdeveniment v3 per recurs i mostra l’esquema de la càrrega útil de cada esdeveniment i un exemple. Els tipus d’esdeveniment antics apareixen en un grup Legacy separat i estan marcats com a obsolets. Els punts finals que ja hi estan subscrits els continuen rebent; utilitza tipus d’esdeveniment v3 per a les subscripcions noves. Consulta Webhooks.
• Les recàrregues de sandbox ara emeten els esdeveniments de webhook transfer.created i transfer.state_changed. Consulta Proves al sandbox.
• accountProvisioning ara informa issued quan el client ja té un compte emès actiu. Consulta Capacitats i requisits.
• Les dades dels comptes bancaris al panell del comerç s’obren en un calaix amb els logotips dels bancs. Consulta Comptes.
• El panell del comerç etiqueta el moviment de diners com a Pay in i Pay out, manté la sessió iniciada durant sis hores i envia les sol·licituds d’ajuda al suport de Swipelux per correu electrònic.
• A les tasques d’admissió que accepten l’enviament directe, els requisits aptes que ja estan avalats pel perfil del client o pels documents carregats passen automàticament a in_review. Consulta Capacitats i requisits.

​

Corregit

• Tornar a sol·licitar una capacitat cancel·lada ja no falla a causa de registres de sol·licitud d’alta substituïts o de requisits desactualitzats.
• Les capacitats desades amb l’antic ID de Fedwire ara es llegeixen com a wire en lloc de retornar 500.

​

Afegit

• GET /v3/customers/{customerId}/applications llista les sol·licituds d’alta d’un client, amb les capacitats sol·licitades en cada sol·licitud i les capacitats que cobreix la seva aprovació. Una aprovació en un banc pot cobrir diverses capacitats. Les sol·licituds històriques conservades apunten a la seva successora mitjançant supersededByApplicationId. La llista admet paginació per cursor i updatedAfter. Consulta Capacitats i requisits.
• Les respostes de POST /v3/customers/{customerId}/capabilities/{capabilityId} inclouen selectedApplicationId per a les capacitats basades en una sol·licitud d’alta. Identifica la sol·licitud d’alta existent que la petició ha reutilitzat, o la que ha obert. Consulta Capacitats i requisits.
• Les institucions que retornen GET /v3/institutions i la llista de capacitats admeses inclouen un logoUrl que pot ser nul. Utilitza’l per mostrar la marca del banc quan estigui disponible, i recorre al nom de la institució quan sigui null. Consulta Capacitats i requisits.
• Els pagaments SWIFT en USD ja estan disponibles. Els pagaments SWIFT requereixen almenys 100 USD. El panell del comerç recull les instruccions bancàries SWIFT dels destinataris. Consulta Enviar fons.
• Els comptes bancaris emesos poden rebre per SWIFT amb dades de recepció nominatives. Consulta Emet un compte bancari.
• USDT ara s’admet com a origen per a pagaments ACH i Wire. Consulta Enviar fons.
• Els comptes bancaris emesos accepten settlement.currency amb el valor USDC o USDT per triar la stablecoin que es lliura a la cartera de liquidació, independentment de la moneda del compte de la cartera. Omet-lo per continuar liquidant en la moneda de la cartera. Consulta Emet un compte bancari.
• Els comptes bancaris SWIFT i les destinacions dels destinataris accepten bankCity, bankState, bankPostalCode i bankAddressLine2, a més dels camps opcionals beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode i paymentCode i les dades del banc intermediari. Consulta Enviar fons.
• Les dades dels comptes bancaris emesos inclouen achRoutingNumber i wireRoutingNumber quan el banc proporciona números de ruta ACH i Wire separats, i bankLogoUrl per al banc receptor. Consulta Emet un compte bancari.
• Els esdeveniments de webhook capability.created inclouen applicationId i un origin amb el valor requested o approval, de manera que pots distingir les capacitats que has sol·licitat de les que ha cobert una aprovació. Consulta Webhooks.
• Les peticions de requisits poden declarar un format de validació constraints.format, com ara http_url, us_ssn, us_ein o bank_industry_classification. Consulta Capacitats i requisits.

​

Canviat

• La creació de comptes bancaris al panell del comerç ara comença amb la selecció del banc, i els comptes bancaris mostren números de ruta ACH i Wire separats. Consulta Comptes.
• L’enum network ara inclou solana. És un enum obert, així que tolera els valors de xarxa que no reconeguis. Consulta Comptes.
• Obrir un enllaç de verificació allotjat per a una tasca els requisits restants de la qual requereixen enviament directe retorna 409 verification_session_not_allowed. Envia aquests requisits com a enviament de tasca. Consulta Errors i reintents.
• Arxivar un compte emès l’aprovisionament del qual encara no s’ha resolt retorna 409 account_provisioning_unresolved. Torna-ho a provar quan l’aprovisionament s’hagi resolt. Consulta Errors i reintents.
• Les sol·licituds noves de comptes bancaris amb nom es posen a la cua d’aprovisionament tan bon punt es crea el compte, en lloc d’esperar la propera actualització del client. Consulta Emet un compte bancari.

​

Eliminat

• Les dades de recepció SWIFT agrupades ja no s’ofereixen per a comptes nous. Utilitza dades de recepció SWIFT nominatives en el seu lloc. Consulta Emet un compte bancari.

​

Corregit

• Les lectures de transferències de pagament ara retornen el destinatari cotitzat.
• Crear un compte ACH després d’arxivar-ne un d’existent ja no retorna 409, i les sol·licituds de comptes pendents arxivades ja no ocupen una plaça de compte.
• Les comissions bancàries de les cotitzacions de pay-in en moneda local s’informen en la moneda fiat correcta.

​

Afegit

• GET /v3/webhooks/{webhookId} llegeix un únic punt final de webhook i la seva selecció d’events. Consulta Webhooks.
• Els requisits de les tasques ara publiquen allowedValues i un valueSchema de JSON Schema per als camps del perfil, inclosos els camps d’adreça obligatoris. Els camps de país indiquen un valueType o itemValueType de country, un codi ISO 3166-1 alpha-2. Pots mostrar els camps d’entrada i les opcions sense codificar-los de manera fixa. Consulta Capacitats i requisits.
• Les carteres de Tron existents ara poden enviar USDT als comptes de cartera externs del client, i les lectures de transferències inclouen un enllaç a l’explorador de blocs per a les transaccions de Tron. No es poden emetre carteres noves a Tron. Consulta Enviar fons.
• Els requisits de les tasques poden declarar requiredWhen (respondre només quan coincideix una resposta de sí/no determinada), profileAssertion (us_person) i ownershipPolicy, i les peticions de documents poden establir identityMetadataRequired i maxIssueAgeDays. Les respostes de les tasques accepten documentMetadata (idNumber, issuingCountry, issuedOn) per als documents referenciats, i les lectures de tasques retornen les respostes de control revisades a conditionValues. Consulta Capacitats i requisits.
• Els requisits de documents poden llistar acceptedDocumentSets, i els requisits de parts relacionades poden demanar una qualificació associated_person o control_person a més de beneficial_owner. Consulta Capacitats i requisits.
• Els objectes correction de les transferències ara també cobreixen els pagaments finançats fallits: kind: funding_failure amb una acció compensatòria recover_source_funding, un recoveryStatus amb el valor unknown o reported, i sortides abonades en USDT. Consulta Cotitzacions i transferències.

​

Canviat

• PATCH /v3/webhooks/{webhookId} ara accepta els tipus d’esdeveniment antics als quals el punt final ja està subscrit, de manera que pots conservar-los mentre afegeixes tipus d’esdeveniment v3. events substitueix tota la selecció, així que inclou-hi tots els tipus d’esdeveniment que vulguis conservar. Afegir un tipus d’esdeveniment antic que el punt final encara no tenia retorna 400 validation_error. Consulta Webhooks.
• Els identificadors bancaris dels destinataris i dels comptes es validen abans de desar-los. Consulta Destinataris.
• Les sol·licituds de capacitats, els enviaments de tasques i els canvis d’estat al sandbox ara retornen 409 capability_application_stale en lloc de 500 quan una capacitat es va crear amb un model d’onboarding anterior. Consulta Errors i reintents.
• La pàgina pública d’RFI ara és un únic formulari continu. Admet persones relacionades i recull un identificador fiscal per persona. Consulta Requisits dels documents.
• Les cotitzacions i les transferències retornen 409 customer_bank_limit_exceeded quan un pagament supera el límit diari o mensual restant del client al banc, i 503 customer_bank_limits_unavailable quan aquest límit no es pot comprovar. Les transferències retornen 409 payout_execution_unavailable quan un pagament no es pot iniciar a partir de la seva cotització. Consulta Errors i reintents.
• Les actualitzacions de clients i de parts relacionades que entren en conflicte amb una admissió bancària completada retornen 409 field_conflicts_with_completed_intake amb el taskId i els fields.

​

Corregit

• L’historial de capacitats cancel·lades continua sent consultable.
• Els pagaments wire es mostren i es filtren correctament a la llista de transaccions del panell del comerç.

​

Canviat

• POST /v3/transfers i les lectures de transferències utilitzen checkoutMethod en lloc de paymentMethod per a la preselecció del checkout de targeta, i accepten card, apple_pay, google_pay, cash_app, sepa i blik. La llista és oberta i pot créixer. paymentMethod ja no es reconeix; les sol·licituds que encara l’envien es tracten com si s’hagués omès. sepa i blik són opcions de finançament dins del checkout de targeta, no capacitats de Swipelux. Consulta Rebre fons.

​

Afegit

• POST /v3/transfers accepta un paymentMethod opcional amb el valor card, apple_pay o google_pay per a cotitzacions de targeta. El checkout allotjat s’obre amb el mètode sol·licitat quan està disponible per al client i el seu dispositiu, les lectures de la transferència retornen la sol·licitud, i els imports i les comissions de la cotització no canvien. Consulta Rebre fons.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview accepta institutions per previsualitzar les tasques de bancs concrets retornats per la llista de capacitats admeses. Consulta Capacitats i requisits.

​

Canviat

• Les cotitzacions de targeta ara reflecteixen les comissions del checkout i l’USDC net lliurat. Consulta Rebre fons.
• Les cotitzacions de pagament rebutjades retornen un codi de problema específic en lloc d’un error genèric: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported o quote_failed, i 503 quote_temporarily_unavailable quan la cotització es pot tornar a intentar més tard. Consulta Errors i reintents.

​

Corregit

• Les cotitzacions de targeta ja no fallen a causa de l’arrodoniment de comissions.
• Tornar a obrir un enllaç de KYC allotjat ja no retorna 409 kyc_process_conflict quan les respostes del qüestionari inclouen espais addicionals.
• Les confirmacions de retirada amb passkey encallades al panell del comerç ara es recuperen.

​

Afegit

• POST /v3/customers/{customerId}/documents ara també accepta un cos application/json amb storageKey, fileName i type. El storageKey ha de ser una referència recent amb àmbit de client aparcada mitjançant el flux anterior de càrrega directa, i la càrrega passa les mateixes validacions de mida i de signatura de fitxer que les càrregues multipart. Consulta Migrar a v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download retorna una url de descàrrega per a un document de client actiu. La URL expira al cap d’una hora i serveix el fitxer com a adjunt. Els documents arxivats, desconeguts o d’un altre client retornen 404. Consulta Capacitats i requisits.
• Sol·licitar una capacitat per a una empresa sense beneficiari efectiu ara crea una tasca d’admissió per afegir-ne un en lloc de fallar amb un 503. Les sol·licituds que no poden continuar retornen 422 beneficial_owner_required amb instruccions per afegir una part relacionada individual amb una participació declarada o d’almenys el 25%. Consulta Accionistes, UBO i persones de control.
• La taula de tasques del panell del comerç ara mostra el subjecte i l’abast de capacitat de cada sol·licitud, de manera que pots veure a qui i què cobreix una sol·licitud de compliment. Consulta Capacitats i requisits.
• Els camps de classificació industrial del panell del comerç ara ofereixen codis NAICS cercables als perfils de client i a les tasques de requisits. Consulta Flux de treball KYB.
• Les instruccions bancàries de pay-in poden incloure bankName, bankAddress, accountHolderName i accountHolderAddress. Mostra-les amb la resta de coordenades bancàries. Consulta Rebre fons.
• POST /v3/transfers accepta una redirectUrl opcional que retorna el client a la teva aplicació després d’un checkout allotjat de targeta o Apple Pay. Arribar a la URL no confirma la compleció; utilitza les lectures de transferències o els webhooks. Consulta Rebre fons.
• Les transferències creades per una Rule de v3 apareixen a les lectures i llistes de transferències amb origin: rule i emeten esdeveniments transfer.state_changed com les altres transferències. Filtra-les amb GET /v3/transfers?origin=rule. Consulta Cotitzacions i transferències.
• Els documents d’identitat de clients i parts relacionades accepten sideApplicability (front_only, front_and_back o unknown), i les tasques poden recollir com a respostes dades del document d’identitat com ara type, number, issuingCountry, issuingRegion, issuedOn, expiresOn i doesNotExpire. Consulta Capacitats i requisits.

​

Canviat

• Els enviaments de dades bancàries que entren en conflicte amb una configuració bancària en curs ara retornen 409 ops_rail_handoff_conflict. Conserva els identificadors dels documents carregats i reintenta el mateix enviament quan el conflicte s’hagi resolt en lloc de tornar a carregar els documents. Consulta Errors i reintents.
• El mínim per a dipòsits de stablecoins no anunciats a les carteres dels clients ara és d’1 unitat en lloc de 10. Els dipòsits més petits es continuen tractant com a residuals. Consulta Rebre fons.
• La configuració de webhooks ara està aïllada per entorn. El portal de webhooks s’obre limitat a l’entorn des del qual el sol·licites, de manera que els punts finals de sandbox i de producció ja no comparteixen la configuració. Consulta Webhooks.
• El panell del comerç ara deriva els mètodes de pay-in disponibles de les capacitats v3 del client, de manera que la configuració de comptes només ofereix mètodes als quals el client té dret. Consulta Comptes.
• Els formularis RFI ara recullen els beneficiaris efectius qualificats amb indicacions més curtes i clares, i l’historial d’RFI es mostra com a fites del cicle de vida. Consulta Requisits dels documents.
• Les tasques obertes sense una data de venciment explícita ara tenen dueAt per defecte 31 dies després de la creació. Consulta Capacitats i requisits.

​

Eliminat

• El panell del comerç ja no ofereix Fedwire en afegir nous mètodes de pay-in. Els comptes Fedwire existents continuen sent consultables. Consulta Comptes.

​

Corregit

• Els dipòsits d’USDT no anunciats a les carteres dels clients ara es reconeixen i es liquiden en lloc d’ignorar-se.
• Les evidències que ja has enviat ara es traslladen a altres tasques que requereixen el mateix element, de manera que no es demana el mateix document dues vegades als clients.
• Tornar a sol·licitar una capacitat ja no descarta les rutes bancàries que ja estan a punt, de manera que les dades dels comptes emesos es mantenen estables.
• Les vistes d’instruccions bancàries del panell del comerç ara mostren les dades completes, incloses les adreces SWIFT i l’adreça de la cartera de destinació.
• Els formularis RFI ara mostren els errors de validació de l’enviament, validen les descripcions de la forma jurídica abans d’enviar i accepten diversos llocs web de l’empresa.
• Ara pots editar els esborranys de persones relacionades als formularis RFI abans d’enviar-los.
• Les sol·licituds de compliment cancel·lades ja no apareixen a la llista de tasques del panell del comerç.
• Els estats de revisió de documents es tornen a mostrar correctament al panell del comerç.

​

Afegit

• Les sessions allotjades de verificació i de Termes del servei amb abast de client ara inclouen un objecte action autoritatiu. Segueix el seu tipus available o unavailable; els camps plans url i expiresAt es mantenen com a miralls de compatibilitat per a les accions disponibles. Consulta Capacitats i requisits.
• Les recàrregues de carteres de sandbox ara retornen identificadors de transferència que pots consultar amb GET /v3/transfers/{transferId} o llistar amb GET /v3/transfers. Apareixen com a dipòsits entrants de stablecoins completats. Consulta Proves al sandbox.
• Les lectures de transferències inclouen un objecte correction quan els fons d’una transferència es retornen o es reverteixen després de completar-se. Indica el kind de la correcció, el providerStatus normalitzat, qualsevol providerShortfall i el compensatingIntent que aplica Swipelux. Consulta Cotitzacions i transferències.

​

Canviat

• El recorregut First pay-in del panell del comerç per a targetes i Apple Pay ara requereix una cartera Polygon del client. Crea-la abans d’iniciar el recorregut. Consulta Comptes.
• Les sol·licituds noves i les respostes públiques utilitzen sepa com a nom canònic del mètode i la capacitat. L’àlies d’entrada sepa_instant i els recursos emmagatzemats anteriorment continuen sent compatibles, però les respostes públiques utilitzen sepa. Consulta Comptes.
• Les sol·licituds noves de capacitat, compte emès i cotització de Faster Payments no estan disponibles. Els comptes, les cotitzacions i les transferències existents continuen sent consultables. Consulta Comptes.
• La primera pàgina de KYB ja no recull la data de naixement del representant. Les dates de naixement dels accionistes continuen sent un requisit separat. Consulta Flux de treball KYB.
• Les referències de documents RFI ara accepten l’àlies MIME image/jpg a més de image/jpeg. Consulta Requisits dels documents.
• L’historial de tasques del panell del comerç ara presenta un registre d’auditoria llegible sense comptadors de revisió. Consulta Capacitats i requisits.
• Les cotitzacions i les transferències ara comproven les direccions admeses de la capacitat abans de moure diners. Utilitzar una capacitat en una direcció que no admet retorna 422 capability_direction_unsupported, i els moviments entre carteres requereixen una capacitat stablecoin_transfers. Consulta Errors i reintents.

​

Eliminat

• El panell del comerç ja no ofereix la configuració de comptes UAEFTS nous. Els comptes UAEFTS existents continuen sent consultables. Consulta Comptes.

​

Corregit

• Els formularis RFI conserven les entrades existents quan un revisor afegeix una nova càrrega de documents, de manera que les respostes anteriors no es perden en reenviar.
• El panell del comerç reprèn les sessions allotjades de compliment des de les accions disponibles sense descartar enllaços vàlids.
• Els enllaços allotjats dels Termes del servei ara funcionen per a tots els àmbits de tasca retornats per l’API.
• Després de sol·licitar Payment Access al panell del comerç, s’obre la tasca d’admissió retornada per aquella sol·licitud en lloc d’una tasca d’una sol·licitud anterior.
• La demostració de KYB del panell del comerç ara demana els camps obligatoris actuals.
• Una cotització que reutilitza la cartera d’origen com a destinationId ara retorna detalls útils de 422 quote_direction_invalid abans d’iniciar cap operació amb el proveïdor. Consulta Cotitzacions i transferències.
• L’API rebutja una codificació incorrecta de la cadena de consulta amb un error 400 en lloc de normalitzar silenciosament la sol·licitud. Consulta Errors i reintents.
• POST /v3/customers/{customerId}/documents ara rebutja els cossos de sol·licitud buits, que no són multipart o que estan mal formats amb un error 400.

​

Afegit

• S’ha publicat el catàleg de Problem Details de v3 a l’especificació OpenAPI perquè els integradors puguin mapar les respostes d’error directament des de l’esquema. Consulta Errors.
• S’ha afegit customerId als esdeveniments de webhook de comptes v3, la qual cosa permet correlacionar l’activitat del compte amb el client propietari sense una lectura addicional. Consulta Webhooks.
• Cobertura completa dels camps del perfil individual V3 al panell del comerç, de manera que els operadors d’onboarding poden revisar i editar tots els camps de KYC recollits mitjançant l’API v3. Consulta Clients.
• S’ha publicat una guia de migració per a desenvolupadors de v3. Consulta Migrar a v3.

​

Canviat

• Els codis de país de clients i comptes ara es validen com a valors ISO 3166-1 alpha-2 assignats en el moment d’escriptura. Les lectures toleren els valors emmagatzemats heretats perquè els registres existents es continuïn resolent. Consulta Comptes i carteres.
• La disponibilitat d’USDC ara està limitada per xarxa de destinació, de manera que les cotitzacions i transferències només ofereixen USDC a les xarxes que la destinació admet realment.
• Tots els fluxos d’incorporació ara requereixen els Termes del servei de Swipelux. Les sessions existents es mantenen reprenibles. Consulta Clients.
• Capability.ready continua indicant l’aprovació del dret. Utilitza accountProvisioning per seguir l’emissió del compte com a not_applicable, not_started, in_progress, issued o failed. Consulta Capacitats i requisits.
• Les càrregues HEIC des d’iPhone ara s’accepten com a documents d’identitat i d’adreça.
• Esborrar un camp d’un client o d’una part relacionada que una tasca oberta encara requereix ara retorna 409 field_required_by_open_task amb el taskId que el bloqueja i els fields, en lloc d’un conflicte que es pot reintentar. Completa o cancel·la la tasca abans de canviar aquests camps. Consulta Errors i reintents.

​

Corregit

• Tornar a executar una cotització consumida ara retorna 409 quote_execution_consumed en lloc d’un error genèric. Consulta Cotitzacions i transferències.
• Les lectures de llistes de transferències i les lectures d’imports de cotitzacions ja no fan 500 amb resultats històrics grans.
• Les redireccions de KYC concurrents ara retornen un conflicte en lloc de 404, de manera que els reintents es resolen netament. Les redireccions allotjades ja no es reverteixen a mig procés, i els enllaços de KYC es mantenen reprenibles.
• Les lectures de parts relacionades per a clients individuals ja no fan 404.
• Els enviaments de KYB amb camps de cartera no vàlids es rebutgen abans de l’enviament, i la sincronització fallida ja no s’informa com a èxit al panell del comerç.
• Les tasques de requisits del panell del comerç ara mostren les respostes enviades com a completes, fan el seguiment de les accions de termes per separat, eliminen el text duplicat dels documents, mantenen les sessions de KYC iniciades com a pendents fins a la seva compleció i gestionen les tasques obsoletes sense trencar la vista de requisits.
• Les files d’enllaços de verificació al panell del comerç ara mostren una acció Open a cada fila, i cada enllaç de tasca es renderitza a la vista de requisits.