Changelog e note di rilascio dell'API Swipelux

​

Aggiunto

• Le destinazioni dei recipient accettano i tipi pix e pix_safe per i payout in BRL in Brasile. Una destinazione Pix paga una chiave Pix. Una destinazione Pix Safe paga un conto bancario identificato dal CPF o CNPJ del titolare, dal codice ISPB della banca, dalla filiale e dal numero di conto. Entrambe richiedono la capacità Pix del cliente in stato ready (pix_pooled), e i relativi payout sono finanziati con USDC e non prevedono developer fee. Consulta Recipient e Invia fondi.
• GET /v3/customers/{customerId}/tasks/{taskId} accetta documentCandidatesFor con l’ID di un requisito documentale, più documentAlternativeKey per un requisito con alternative. La risposta elenca quindi, in data.documentCandidates, i file già caricati dal cliente che possono soddisfare quel requisito, con eventuali missingMetadata o conflictingMetadata. Invia il documentId di un candidato con i documentMetadata mancanti invece di caricare di nuovo il file. La query richiede accounts:read e customers:read, e una selezione non valida restituisce 400 validation_error.

​

Modificato

• GET /v3/webhooks/portal restituisce un URL del portale che scade dopo un’ora, con Cache-Control: no-store. Con una chiave API che ha webhooks:write, il portale mostra il signing secret dell’endpoint e permette di gestire gli endpoint, ritentare le consegne e riprodurle. Con il solo webhooks:read, il portale mostra soltanto le consegne. Consulta Webhook.
• Citi (citibank) è offerta solo ai clienti business. Ogni azienda mantiene Citi condivisa (pooled), mentre Citi nominativa è offerta solo alle aziende registrate fuori dagli Stati Uniti. Quando a un cliente non viene offerta Citi, l’elenco supportato la omette, indicarla restituisce 422 capability_institutions_unsupported e un metodo offerto solo da Citi è elencato come disabled. Una richiesta senza institutions seleziona tra le banche rimanenti. Le domande e i conti esistenti non cambiano.
• Le capacità CFSB nominative (cfsb) sono offerte solo ai clienti statunitensi: aziende registrate negli Stati Uniti e persone fisiche che vi risiedono. Per gli altri clienti, l’elenco supportato omette CFSB nominativa, e indicarla restituisce 422 capability_institutions_unsupported. Una richiesta senza institutions seleziona tra le banche rimanenti. CFSB condivisa (pooled), i clienti il cui paese è sconosciuto e le domande esistenti non cambiano.
• Le capacità ACH, Wire e SWIFT nominative di Lead Bank (lead_bank) sono offerte solo ai clienti che Lead Bank può accogliere in onboarding, in base alla loro forma giuridica e ai loro paesi. Per gli altri clienti, l’elenco supportato omette lead_bank, e indicarla restituisce 422 capability_institutions_unsupported. I clienti già accolti da Lead Bank e le capacità la cui richiesta aperta indica già lead_bank la mantengono. Le domande e i conti esistenti non cambiano.
• RTP è solo condiviso (pooled). Nessuna banca offre rtp_named alle nuove richieste, quindi l’elenco supportato lo mostra come disabled. Per un cliente che non detiene rtp_named, una richiesta di capacità o un’anteprima del task per questa capacità che indica una banca restituisce 422 capability_institutions_unsupported, e una senza institutions restituisce 422 capability_variant_unavailable. RTP condiviso (rtp_pooled) è offerto presso Citi, quindi solo i clienti business possono richiederlo.
• Le nuove richieste di documenti d’identità per persone fisiche e titolari effettivi possono impostare constraints.identityMetadataRequired: true, per cui ogni file richiede il numero del documento e il paese di emissione in documentMetadata. Le nuove richieste di prova dell’indirizzo aziendale e di prova della residenza del titolare possono impostare constraints.maxIssueAgeDays: 90, per cui ogni file richiede la data di emissione. I task esistenti mantengono i propri requisiti, quindi leggi i vincoli di ogni richiesta del task.
• Una risposta del task a una richiesta di registrazione aziendale, il cui profilePointer è /business/registration, richiede insieme il paese della giurisdizione, il numero di registrazione e una data di costituzione anteriore alla data di invio. Il valueSchema della richiesta pubblica questa regola, e una risposta parziale restituisce 400 validation_error.
• Dopo una verifica ospitata, Swipelux accetta una risposta ospitata a un requisito del profilo per un valore strutturato, come un indirizzo o gli identificativi fiscali, solo se supera gli stessi controlli di schema e di vincoli di una risposta diretta. Altrimenti il requisito resta aperto, e invii quel valore con POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Un requisito che Swipelux riporta a action_required per questo motivo include reviewFeedback.code: hosted_profile_direct_submission_required. I task già satisfied mantengono il proprio status. Vedi Capacità e requisiti.
• Un task rifiutato da una verifica ospitata può uscire da rejected quando la decisione di quella verifica viene successivamente annullata. Diventa quindi satisfied, oppure action_required con una nuova revision, con la riapertura dei requisiti a cui la nuova decisione non risponde. Gli invii precedenti per quei requisiti restano rejected, quindi invia di nuovo quelle risposte. Vedi Migrare a v3.
• Il type della destinazione del recipient è ora un enum aperto. Le versioni precedenti di questo riferimento lo descrivevano come chiuso, quindi aggiorna qualsiasi client che rifiuta o scarta i tipi sconosciuti. Le risposte delle destinazioni e gli eventi destination.status_changed possono ora contenere pix e pix_safe, e potranno essere aggiunti altri tipi.
• Le richieste di creazione e aggiornamento dei recipient, incluso l’oggetto annidato address, ignorano i campi che non definiscono invece di restituire 400 validation_error. In una richiesta di creazione, un campo di nome o di settore relativo all’altro tipo di recipient restituisce comunque 400, così come type ed externalId in PATCH /v3/customers/{customerId}/recipients/{recipientId}. Un PATCH senza alcun campo riconosciuto restituisce 400 validation_error invece di 200.
• Un link di verifica per una sessione idonea che richiede solo documenti ora apre una pagina di caricamento documenti ospitata da Swipelux. Il link in sé non cambia, e le altre sessioni continuano ad aprire il flusso di verifica ospitato.
• employment.occupation per i clienti persona fisica e le persone delle parti correlate accetta al massimo 255 caratteri.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} e POST /v3/customers/{customerId}/tasks/{taskId}/submissions restituiscono 400 validation_error quando un valore del profilo o una risposta a un’attività contiene un link a un modulo Swipelux, ad esempio un link di RFI, di richiesta del cliente o di tracciamento del trasferimento. Questo non si applica a externalId né a metadata. Ogni valore rifiutato compare in errors[] con code: public_form_link e il relativo JSON Pointer, e la risposta non ripete mai il link. Invia invece l’informazione stessa. Consulta Errori e nuovi tentativi.

​

Corretto

• Le risposte di preventivi e trasferimenti di payout mantengono un importo di origine in USDC o USDT con sei decimali, ad esempio 4009.711365 invece di 4009.71. Gli importi fiat mantengono due decimali. Creare o leggere un payout il cui importo di origine in stablecoin ha più di due decimali non restituisce più 500.
• Il riferimento di POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel ora descrive l’annullamento come funziona realmente. Puoi annullare una capacità ready, la capacità stablecoin_transfers non può essere annullata, e l’annullamento termina solo quella capacità, mentre le sue domande mantengono stato, task e approvazioni.
• Una richiesta di capacità o un’anteprima del task che indica in institutions un codice bancario invece di un ID pubblico dell’istituto, ad esempio citi per citibank, restituisce 422 capability_institutions_unsupported con gli ID disponibili invece di 503 kyc_configuration_unavailable.
• Una richiesta di capacità o un’anteprima del task per un metodo che nessuna banca offre al cliente, e che l’elenco supportato mostra come disabled, restituisce 422 capability_variant_unavailable con retryable: false invece di 503 kyc_configuration_unavailable, a meno che il cliente non detenga già quella capacità.
• documentCandidates non elenca più i file che Swipelux conserva da una verifica ospitata completata, che non puoi leggere né scaricare. Una risposta del task che ne cita uno restituisce 400 invalid_document_reference, come per un documento sconosciuto.

​

Aggiunto

• GET /v3/customers accetta include=documentRequirements. Ogni riepilogo cliente riporta quindi quanti documenti obbligatori sono ancora mancanti, indipendentemente dalla prontezza delle capacità. Combinalo come include=capabilities,documentRequirements. Consulta Clienti.
• La pagina Webhooks del pannello commerciante aggiunge Replay missed events al menu dell’endpoint. Reinvia gli eventi degli ultimi 13 giorni che l’endpoint non ha mai ricevuto, senza mai inviare due volte lo stesso evento. Consulta Webhook.
• La pagina Settings del pannello commerciante ha una sezione Compliance. Owner e amministratori possono impostare l’email di compliance e scegliere se ricevere email quando Swipelux richiede ulteriori informazioni su un cliente.
• I commercianti possono rispondere alle proprie richieste di compliance KYB direttamente nella pagina KYB del pannello commerciante.

​

Modificato

• Gli aggiornamenti di clienti e parti correlate non restituiscono più 409 field_conflicts_with_completed_intake dopo un’acquisizione bancaria completata. L’aggiornamento viene salvato e ogni nuova domanda bancaria verifica il profilo più recente in base ai propri requisiti.
• Le richieste di capacità restituiscono 409 capability_route_header_conflict quando l’instradamento bancario esistente di una capacità non può essere aggiornato in modo sicuro. Contatta il supporto Swipelux prima di riprovare.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview restituisce 422 capability_institutions_unsupported quando institutions indica una banca che la capacità non offre, come già avviene per le richieste di capacità.
• In sandbox, le capacità ACH, Wire e SWIFT sono servite solo da JPMorgan Chase. Le richieste che omettono institutions selezionano jpmorgan, e indicare un’altra banca restituisce 422 capability_institutions_unsupported. L’instradamento live non cambia. Consulta Test nella sandbox.
• Forzare lo stato di una capacità in sandbox restituisce 409 capability_status_blocked con uno statusReason quando il caso simulato non può raggiungere lo stato richiesto. Ripetere una forzatura già applicata restituisce 200 senza modifiche. Consulta Test nella sandbox.
• POST /v3/sandbox/tasks/{taskId}/review restituisce 409 task_not_sandbox_reviewable per un task di proprietà di Operations o di un altro workflow. I task di POST /v3/sandbox/tasks e i task di raccolta delle capability che Swipelux acquisisce restano revisionabili. Vedi Test nella sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} restituisce 409 account_provisioning_unresolved quando modifichi il regolamento mentre il provisioning del conto presso la banca è ancora in corso. Riprova dopo la conclusione del provisioning. Consulta Errori e nuovi tentativi.
• POST /v3/transfers può restituire 409 quote_execution_evidence_conflict. Crea un nuovo preventivo ed eseguilo. Consulta Errori e nuovi tentativi.
• Il pannello laterale Pay out del pannello commerciante mostra le coordinate complete della destinazione, nasconde i numeri di conto e gli indirizzi wallet dietro un interruttore e indica un tempo di arrivo stimato per ogni metodo di pagamento.
• Il pannello commerciante raggruppa i conti bancari nella scheda Payment access del cliente, con un riquadro delle attività che indica ogni banca. La scheda Documents è stata spostata in Profile.
• L’apertura di un conto bancario denominato nel pannello commerciante ora avviene in un unico passaggio, che elenca valuta, metodi e tempi di onboarding di ogni banca. Consulta Conti.
• I conti bancari trattenuti per revisione compaiono come On hold nel pannello commerciante, con l’ID del conto e un’azione Contact support.
• Una capability pending ora riporta statusReason.code: preparing_submission invece di review_in_progress mentre Swipelux prepara una domanda per l’invio e nessuna revisione è in corso. Entrambi i codici usano resolution: wait. Un passaggio dall’uno all’altro mantiene lo status pending, quindi non invia alcun evento capability.status_changed. Le capability esistenti adottano il nuovo codice alla successiva rivalutazione. Vedi Capacità e requisiti.
• La tabella Shared methods nella scheda Payment access del cliente nel pannello commerciante mostra In preparation invece di In review per un metodo condiviso la cui capability riporta preparing_submission.
• L’elenco applications di una capability ora mostra solo le domande correnti, nelle letture della capability (incluso GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), nelle risposte alle richieste di capability e negli eventi capability.status_changed. Una domanda sostituita da una più recente compare ancora in GET /v3/customers/{customerId}/applications, dove supersededByApplicationId indica la successiva. I task aperti di una domanda sostituita contano ancora negli openTaskIds della capability. Lo status e gli openTaskIds della capability non cambiano, quindi la modifica in sé non invia alcun evento webhook. Vedi Capacità e requisiti.

​

Corretto

• Una seconda richiesta allowPending per lo stesso conto emesso, inviata prima dell’approvazione della banca, restituisce 409 indicando il conto in attesa in holder.accountId invece di 500. Consulta Emetti un conto bancario.
• L’annullamento di una capacità ora chiude le richieste di conto emesso ancora in attesa di approvazione bancaria, così una richiesta successiva presso la stessa banca riparte da zero.
• Richiedere di nuovo una capacità annullata le cui pratiche bancarie sono state tutte rifiutate pubblica un solo evento capability.status_changed da canceled.
• Richiedere di nuovo una banca dopo l’archiviazione della domanda precedente ora invia la nuova domanda.
• Le destinazioni dei recipient possono essere aggiunte non appena la capacità corrispondente risulta ready, invece di restituire 409 rail_not_ready. Consulta Recipient.
• Gli eventi webhook inviati prima della prima apertura della pagina Webhooks del pannello commerciante ora vengono conservati, così puoi riprodurli verso un nuovo endpoint.
• Le scadenze delle attività nel pannello commerciante vengono mostrate nel tuo fuso orario, e i pannelli laterali di revisione bancaria mostrano All requirements submitted quando non resta nulla in sospeso.

​

Aggiunto

• POST /v3/quotes accetta un institutionId opzionale per scegliere una rotta bancaria approvata per un preventivo di payout da crypto a fiat. Omettilo per mantenere l’instradamento automatico. Una banca non disponibile per il payout restituisce 422 bank_not_supported_for_customer, e l’invio di institutionId con qualsiasi altro tipo di preventivo restituisce 400 validation_error. Consulta Invia fondi.
• Le richieste di conti bancari emessi su POST /v3/customers/{customerId}/accounts accettano institution per vincolare il conto a una sola banca senza fallback, e allowPending: true per salvare la richiesta mentre la domanda presso quella banca è ancora in attesa di approvazione. allowPending richiede institution. Le richieste salvate riportano l’applicationId di riferimento. Consulta Emetti un conto bancario.
• Il pannello commerciante dispone di una pagina Webhooks nativa per gestire gli endpoint. Consulta Webhook.
• Il pannello commerciante aggiunge un pannello laterale Pay in con conti bancari denominati, depositi crypto e un passaggio di revisione.
• Il flusso Pay out del pannello commerciante mostra i saldi dei wallet nel selettore della fonte, aggiunge un’opzione di importo Max e include un passaggio di revisione.
• I profili dei clienti nel pannello commerciante hanno una scheda Recipients & destinations.
• I requisiti delle attività possono includere un breve titolo title. Il prompt della richiesta continua a contenere le indicazioni. Consulta Capacità e requisiti.

​

Modificato

• I preventivi di pay-in Wire sulle rotte Wire condivise (pooled) ora richiedono almeno 20 $. I preventivi inferiori al minimo di una rotta, o troppo piccoli per coprire le commissioni di trasferimento, restituiscono 422 amount_not_deliverable invece di un errore generico del preventivo. Consulta Ricevere fondi.
• Il portale dei webhook ora raggruppa i tipi di evento v3 per risorsa e mostra lo schema del payload di ogni evento e un esempio. I tipi di evento legacy compaiono in un gruppo Legacy separato e sono contrassegnati come deprecati. Gli endpoint che vi sono già iscritti continuano a riceverli; usa i tipi di evento v3 per le nuove sottoscrizioni. Consulta Webhook.
• Le ricariche in sandbox ora emettono gli eventi webhook transfer.created e transfer.state_changed. Consulta Test nella sandbox.
• accountProvisioning ora riporta issued quando il cliente ha già un conto emesso attivo. Consulta Capacità e requisiti.
• I dettagli dei conti bancari nel pannello commerciante si aprono in un pannello laterale con i loghi delle banche. Consulta Conti.
• Il pannello commerciante etichetta i movimenti di denaro come Pay in e Pay out, mantiene l’accesso attivo per sei ore e invia le richieste di assistenza al supporto Swipelux via email.
• Nelle attività di acquisizione che accettano l’invio diretto, i requisiti idonei già supportati dal profilo del cliente o da documenti caricati passano automaticamente a in_review. Consulta Capacità e requisiti.

​

Corretto

• Richiedere di nuovo una capacità annullata non fallisce più a causa di record di domanda sostituiti o di requisiti obsoleti.
• Le capacità memorizzate con l’ID Fedwire dismesso ora vengono lette come wire invece di restituire 500.

​

Aggiunto

• GET /v3/customers/{customerId}/applications elenca le pratiche di domanda di un cliente, con le capacità richieste per ogni pratica e le capacità coperte dalla relativa approvazione. Un’unica approvazione presso una banca può coprire più capacità. Le pratiche storiche conservate rimandano alla pratica successiva tramite supersededByApplicationId. L’elenco supporta la paginazione a cursore e updatedAfter. Consulta Capacità e requisiti.
• Le risposte di POST /v3/customers/{customerId}/capabilities/{capabilityId} includono selectedApplicationId per le capacità basate su una pratica. Identifica la pratica di domanda esistente riutilizzata dalla richiesta, oppure la pratica che ha aperto. Consulta Capacità e requisiti.
• Le istituzioni restituite da GET /v3/institutions e dall’elenco delle capacità supportate includono un campo logoUrl che può essere nullo. Usalo per mostrare il marchio della banca quando disponibile, e ricorri al nome dell’istituzione quando è null. Consulta Capacità e requisiti.
• I payout SWIFT in USD sono ora disponibili. I payout SWIFT richiedono almeno 100 USD. Il pannello commerciante raccoglie le istruzioni bancarie SWIFT per i recipient. Consulta Invia fondi.
• I conti bancari emessi possono ricevere tramite SWIFT con coordinate di ricezione nominative. Consulta Emetti un conto bancario.
• USDT è ora supportato come fonte per i payout ACH e Wire. Consulta Invia fondi.
• I conti bancari emessi accettano settlement.currency con valore USDC o USDT per scegliere la stablecoin consegnata al wallet di regolamento, indipendentemente dalla valuta del conto wallet. Omettilo per continuare a regolare nella valuta del wallet. Consulta Emetti un conto bancario.
• I conti bancari SWIFT e le destinazioni dei recipient accettano bankCity, bankState, bankPostalCode e bankAddressLine2, oltre ai campi opzionali beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode e paymentCode e alle coordinate della banca intermediaria. Consulta Invia fondi.
• Le coordinate dei conti bancari emessi includono achRoutingNumber e wireRoutingNumber quando la banca fornisce numeri di routing ACH e Wire separati, e bankLogoUrl per la banca ricevente. Consulta Emetti un conto bancario.
• Gli eventi webhook capability.created includono applicationId e un origin con valore requested o approval, così puoi distinguere le capacità che hai richiesto da quelle coperte da un’approvazione. Consulta Webhook.
• Le richieste dei requisiti possono dichiarare un constraints.format di validazione, come http_url, us_ssn, us_ein o bank_industry_classification. Consulta Capacità e requisiti.

​

Modificato

• La creazione di un conto bancario nel pannello commerciante ora inizia dalla selezione della banca, e i conti bancari mostrano numeri di routing ACH e Wire separati. Consulta Conti.
• L’enum network ora include solana. È un enum aperto, quindi gestisci senza errori i valori di rete che non riconosci. Consulta Conti.
• L’apertura di un link di verifica ospitato per un’attività i cui requisiti rimanenti richiedono l’invio diretto restituisce 409 verification_session_not_allowed. Invia invece quei requisiti come invio dell’attività. Consulta Errori e nuovi tentativi.
• L’archiviazione di un conto emesso il cui provisioning non si è ancora concluso restituisce 409 account_provisioning_unresolved. Riprova dopo la conclusione del provisioning. Consulta Errori e nuovi tentativi.
• Le nuove richieste di conti bancari denominati vengono messe in coda per il provisioning non appena il conto viene creato, invece di attendere il successivo aggiornamento del cliente. Consulta Emetti un conto bancario.

​

Rimosso

• Le coordinate di ricezione SWIFT condivise (pooled) non sono più offerte per i nuovi conti. Usa invece le coordinate di ricezione SWIFT nominative. Consulta Emetti un conto bancario.

​

Corretto

• Le letture dei trasferimenti di payout ora restituiscono il recipient del preventivo.
• La creazione di un conto ACH dopo l’archiviazione di uno esistente non restituisce più 409, e le richieste di conto in sospeso archiviate non occupano più uno slot di conto.
• Le commissioni bancarie sui preventivi di pay-in in valuta locale vengono riportate nella valuta fiat corretta.

​

Aggiunto

• GET /v3/webhooks/{webhookId} legge un singolo endpoint webhook e la relativa selezione events. Consulta Webhook.
• I requisiti delle attività ora pubblicano allowedValues e un valueSchema JSON Schema per i campi del profilo, inclusi i campi dell’indirizzo obbligatori. I campi paese riportano un valueType o itemValueType pari a country, ovvero un codice ISO 3166-1 alpha-2. Puoi visualizzare input e scelte senza codificarli manualmente. Consulta Capacità e requisiti.
• I wallet Tron esistenti ora possono inviare USDT ai conti wallet esterni del cliente, e le letture dei trasferimenti includono un link al block explorer per le transazioni Tron. Non è possibile emettere nuovi wallet su Tron. Consulta Invia fondi.
• I requisiti delle attività possono dichiarare requiredWhen (rispondere solo quando una determinata risposta sì/no corrisponde), profileAssertion (us_person) e ownershipPolicy, e le richieste di documenti possono impostare identityMetadataRequired e maxIssueAgeDays. Le risposte delle attività accettano documentMetadata (idNumber, issuingCountry, issuedOn) per i documenti referenziati, e le letture delle attività restituiscono le risposte di controllo revisionate in conditionValues. Consulta Capacità e requisiti.
• I requisiti dei documenti possono elencare acceptedDocumentSets, e i requisiti delle parti correlate possono richiedere una qualifica associated_person o control_person oltre a beneficial_owner. Consulta Capacità e requisiti.
• Gli oggetti correction dei trasferimenti ora coprono anche i payout finanziati non riusciti: kind: funding_failure con un’azione compensativa recover_source_funding, un recoveryStatus con valore unknown o reported, e output accreditati in USDT. Consulta Preventivi e trasferimenti.

​

Modificato

• PATCH /v3/webhooks/{webhookId} ora accetta i tipi di evento legacy a cui l’endpoint è già iscritto, così puoi mantenerli mentre aggiungi i tipi di evento v3. events sostituisce l’intera selezione, quindi includi ogni tipo di evento che vuoi mantenere. Aggiungere un tipo di evento legacy che l’endpoint non aveva già restituisce 400 validation_error. Consulta Webhook.
• Gli identificativi bancari di recipient e conti vengono convalidati prima del salvataggio. Consulta Recipient.
• Le richieste di capacità, gli invii delle attività e le modifiche di stato nella sandbox ora restituiscono 409 capability_application_stale invece di 500 quando una capacità è stata creata con un modello di onboarding precedente. Consulta Errori e nuovi tentativi.
• La pagina RFI pubblica è ora un unico modulo continuo. Supporta le persone correlate e raccoglie un codice fiscale per persona. Consulta Requisiti dei documenti.
• I preventivi e i trasferimenti restituiscono 409 customer_bank_limit_exceeded quando un pagamento supera il limite giornaliero o mensile residuo del cliente presso la banca, e 503 customer_bank_limits_unavailable quando non è possibile verificare tale limite. I trasferimenti restituiscono 409 payout_execution_unavailable quando un payout non può partire dal relativo preventivo. Consulta Errori e nuovi tentativi.
• Gli aggiornamenti di clienti e parti correlate in conflitto con un’acquisizione bancaria completata restituiscono 409 field_conflicts_with_completed_intake con taskId e fields.

​

Corretto

• La cronologia delle capacità annullate resta leggibile.
• I payout wire vengono visualizzati e filtrati correttamente nell’elenco delle transazioni del pannello commerciante.

​

Modificato

• POST /v3/transfers e le letture dei transfer usano checkoutMethod al posto di paymentMethod per la preselezione del checkout con carta, e accettano card, apple_pay, google_pay, cash_app, sepa e blik. L’elenco è aperto e può crescere. paymentMethod non è più riconosciuto; le richieste che lo inviano ancora vengono trattate come se fosse stato omesso. sepa e blik sono opzioni di pagamento all’interno del checkout con carta, non capability Swipelux. Consulta Ricevere fondi.

​

Aggiunto

• POST /v3/transfers accetta un paymentMethod opzionale con valore card, apple_pay o google_pay per i quote con carta. Il checkout hosted si apre sul metodo richiesto quando è disponibile per il cliente e il suo dispositivo, le letture del transfer restituiscono la richiesta, e gli importi e le commissioni del quote restano invariati. Consulta Ricevere fondi.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview accetta institutions per visualizzare in anteprima le attività per banche specifiche restituite dall’elenco delle capacità supportate. Consulta Capacità e requisiti.

​

Modificato

• I preventivi con carta ora riflettono le commissioni di checkout e l’importo netto in USDC consegnato. Consulta Ricevere fondi.
• I preventivi di payout rifiutati restituiscono un codice di problema specifico invece di un errore generico: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported o quote_failed, e 503 quote_temporarily_unavailable quando il preventivo può essere ritentato in seguito. Consulta Errori e nuovi tentativi.

​

Corretto

• I preventivi con carta non falliscono più a causa dell’arrotondamento delle commissioni.
• Riaprire un link KYC ospitato non restituisce più 409 kyc_process_conflict quando le risposte al questionario contengono spazi in eccesso.
• Le conferme di prelievo con passkey bloccate nel pannello commerciante ora vengono ripristinate.

​

Aggiunto

• POST /v3/customers/{customerId}/documents ora accetta anche un corpo application/json con storageKey, fileName e type. Lo storageKey deve essere un riferimento recente nell’ambito del cliente parcheggiato tramite il precedente flusso direct-upload, e il caricamento passa la stessa validazione di dimensione e firma del file dei caricamenti multipart. Consulta Migrare a v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download restituisce un url di download per un documento cliente attivo. L’URL scade dopo un’ora e serve il file come allegato. I documenti archiviati, sconosciuti o di altri clienti restituiscono 404. Consulta Capacità e requisiti.
• Richiedere una capacità per un’azienda senza titolare effettivo ora crea un’attività di acquisizione per aggiungerne uno invece di fallire con un errore 503. Le richieste che non possono procedere restituiscono 422 beneficial_owner_required con istruzioni per aggiungere una parte correlata individuale con una partecipazione dichiarata o di almeno il 25%. Consulta Azionisti, UBO e persone di controllo.
• La tabella delle attività del pannello commerciante ora mostra il soggetto e l’ambito di capacità di ogni richiesta, così puoi vedere chi e cosa copre una richiesta di conformità. Consulta Capacità e requisiti.
• I campi di classificazione del settore nel pannello commerciante ora offrono codici NAICS ricercabili nei profili dei clienti e nelle attività dei requisiti. Consulta Flusso KYB.
• Le istruzioni di pay-in bancario possono includere bankName, bankAddress, accountHolderName e accountHolderAddress. Mostrali insieme alle altre coordinate bancarie. Consulta Ricevere fondi.
• POST /v3/transfers accetta un redirectUrl opzionale che riporta il cliente alla tua app dopo un checkout ospitato con carta o Apple Pay. Raggiungere l’URL non conferma il completamento; usa le letture dei trasferimenti o i webhook. Consulta Ricevere fondi.
• I trasferimenti creati da una Rule v3 compaiono nelle letture e negli elenchi dei trasferimenti con origin: rule ed emettono eventi transfer.state_changed come gli altri trasferimenti. Filtrali con GET /v3/transfers?origin=rule. Consulta Preventivi e trasferimenti.
• I documenti di identità di clienti e parti correlate accettano sideApplicability (front_only, front_and_back o unknown), e le attività possono raccogliere come risposte i dettagli del documento di identità come type, number, issuingCountry, issuingRegion, issuedOn, expiresOn e doesNotExpire. Consulta Capacità e requisiti.

​

Modificato

• Gli invii di coordinate bancarie in conflitto con una configurazione bancaria in corso ora restituiscono 409 ops_rail_handoff_conflict. Conserva gli ID dei documenti caricati e ripeti lo stesso invio dopo la risoluzione del conflitto invece di caricare di nuovo i documenti. Consulta Errori e nuovi tentativi.
• Il minimo per i depositi di stablecoin non annunciati nei wallet dei clienti è ora di 1 unità invece di 10. I depositi più piccoli vengono comunque trattati come dust. Consulta Ricevere fondi.
• La configurazione dei webhook è ora isolata per ambiente. Il portale dei webhook si apre limitato all’ambiente da cui lo richiedi, così gli endpoint sandbox e di produzione non condividono più le impostazioni. Consulta Webhook.
• Il pannello commerciante ora deriva i metodi di pay-in disponibili dalle capacità v3 del cliente, così la configurazione del conto offre solo i metodi a cui il cliente ha diritto. Consulta Conti.
• I moduli RFI ora raccolgono i titolari effettivi qualificati con richieste più brevi e chiare, e la cronologia RFI viene visualizzata come tappe del ciclo di vita. Consulta Requisiti dei documenti.
• Le attività aperte senza una scadenza esplicita ora impostano dueAt per impostazione predefinita a 31 giorni dopo la creazione. Consulta Capacità e requisiti.

​

Rimosso

• Il pannello commerciante non offre più Fedwire durante l’aggiunta di nuovi metodi di pay-in. I conti Fedwire esistenti restano leggibili. Consulta Conti.

​

Corretto

• I depositi USDT non annunciati nei wallet dei clienti ora vengono riconosciuti e regolati invece di essere ignorati.
• Le prove già inviate ora vengono riportate nelle altre attività che richiedono lo stesso elemento, così ai clienti non viene chiesto due volte lo stesso documento.
• Richiedere di nuovo una capacità non scarta più le rotte bancarie già pronte, così i dettagli dei conti emessi restano stabili.
• Le viste delle istruzioni bancarie nel pannello commerciante ora mostrano dettagli completi, inclusi gli indirizzi SWIFT e l’indirizzo del wallet di destinazione.
• I moduli RFI ora mostrano gli errori di validazione all’invio, convalidano le descrizioni della forma giuridica prima dell’invio e accettano più siti web aziendali.
• Ora puoi modificare le bozze delle persone correlate nei moduli RFI prima dell’invio.
• Le richieste di conformità annullate non compaiono più nell’elenco delle attività del pannello commerciante.
• Gli stati di revisione dei documenti vengono di nuovo visualizzati correttamente nel pannello commerciante.

​

Aggiunto

• Le sessioni ospitate di verifica e dei Termini di servizio nell’ambito del cliente ora includono un oggetto action autorevole. Segui il relativo tipo available o unavailable; i campi piatti url ed expiresAt restano copie di compatibilità per le azioni disponibili. Consulta Capacità e requisiti.
• Le ricariche dei wallet sandbox ora restituiscono ID di trasferimento che puoi leggere con GET /v3/transfers/{transferId} o elencare con GET /v3/transfers. Vengono visualizzate come depositi in entrata di stablecoin completati. Consulta Test nella sandbox.
• Le letture dei trasferimenti includono un oggetto correction quando i fondi di un trasferimento vengono restituiti o stornati dopo il completamento. Riporta il kind della correzione, il providerStatus normalizzato, l’eventuale providerShortfall e il compensatingIntent applicato da Swipelux. Consulta Preventivi e trasferimenti.

​

Modificato

• La procedura First pay-in del pannello commerciante per carte e Apple Pay ora richiede un wallet Polygon del cliente. Crea il wallet prima di iniziare la procedura. Consulta Conti.
• Le nuove richieste e le risposte pubbliche usano sepa come nome canonico del metodo e della capacità. L’alias di input sepa_instant e le risorse memorizzate in precedenza restano compatibili, ma le risposte pubbliche usano sepa. Consulta Conti.
• Le nuove richieste di capacità, conti emessi e preventivi Faster Payments non sono disponibili. I conti, i preventivi e i trasferimenti esistenti restano leggibili. Consulta Conti.
• La prima pagina KYB non raccoglie più la data di nascita del rappresentante. Le date di nascita degli azionisti restano un requisito separato. Consulta Flusso KYB.
• I riferimenti ai documenti RFI ora accettano l’alias MIME image/jpg oltre a image/jpeg. Consulta Requisiti dei documenti.
• La cronologia delle attività nel pannello commerciante ora mostra una traccia di controllo leggibile senza contatori di revisione. Consulta Capacità e requisiti.
• I preventivi e i trasferimenti ora verificano le direzioni supportate dalla capacità prima di qualsiasi movimento di denaro. L’uso di una capacità in una direzione che non supporta restituisce 422 capability_direction_unsupported, e i movimenti tra wallet richiedono una capacità stablecoin_transfers. Consulta Errori e nuovi tentativi.

​

Rimosso

• Il pannello commerciante non offre più la configurazione di nuovi conti UAEFTS. I conti UAEFTS esistenti restano leggibili. Consulta Conti.

​

Corretto

• I moduli RFI conservano le voci esistenti quando un revisore aggiunge un nuovo caricamento di documenti, così le risposte precedenti non vengono perse al nuovo invio.
• Il pannello commerciante riprende le sessioni di conformità ospitate dalle azioni disponibili senza scartare i link validi.
• I link ospitati ai Termini di servizio ora funzionano per ogni ambito di attività restituito dall’API.
• Dopo una richiesta di Payment Access nel pannello commerciante, viene aperta l’attività di acquisizione restituita da quella richiesta anziché un’attività di una richiesta precedente.
• La demo KYB del pannello commerciante ora richiede i campi obbligatori correnti.
• Un preventivo che riutilizza il wallet di origine come destinationId ora restituisce dettagli utilizzabili 422 quote_direction_invalid prima di avviare qualsiasi operazione del fornitore. Consulta Preventivi e trasferimenti.
• L’API rifiuta la codifica non valida della stringa di query con un errore 400 invece di normalizzare silenziosamente la richiesta. Consulta Errori e nuovi tentativi.
• POST /v3/customers/{customerId}/documents ora rifiuta i corpi di richiesta vuoti, non multipart o non validi con un errore 400.

​

Aggiunto

• Pubblicato il catalogo v3 Problem Details nella specifica OpenAPI, così gli integratori possono mappare le risposte di errore direttamente dallo schema. Consulta Errori.
• Aggiunto customerId agli eventi webhook di conto v3, permettendoti di correlare l’attività del conto al cliente proprietario senza una lettura successiva. Consulta Webhook.
• Copertura completa dei campi del profilo individuale V3 nel pannello merchant, così gli operatori di onboarding possono rivedere e modificare ogni campo KYC raccolto tramite l’API v3. Consulta Onboarding dei clienti.
• Pubblicata una guida di migrazione per sviluppatori v3. Consulta Migrare a v3.

​

Modificato

• I codici paese di clienti e conti sono ora validati come valori ISO 3166-1 alpha-2 assegnati in fase di scrittura. Le letture tollerano i valori memorizzati legacy, così i record esistenti continuano a essere risolti. Consulta Conti e wallet.
• La disponibilità di USDC è ora limitata dalla rete di destinazione, così quote e transfer offrono USDC solo sulle reti effettivamente supportate dalla destinazione.
• Ogni flusso di onboarding ora richiede i Termini di servizio Swipelux. Le sessioni esistenti restano riprendibili. Consulta Onboarding dei clienti.
• Capability.ready continua a indicare l’approvazione dell’abilitazione. Usa accountProvisioning per seguire l’emissione del conto come not_applicable, not_started, in_progress, issued o failed. Consulta Capacità e requisiti.
• I caricamenti HEIC da iPhone sono ora accettati come documenti di identità e di indirizzo.
• La cancellazione di un campo del cliente o di una parte correlata ancora richiesto da un’attività aperta ora restituisce 409 field_required_by_open_task con il taskId bloccante e i fields, invece di un conflitto ritentabile. Completa o annulla l’attività prima di modificare quei campi. Consulta Errori e nuovi tentativi.

​

Corretto

• La riesecuzione di una quote già consumata ora restituisce 409 quote_execution_consumed invece di un errore generico. Consulta Quote e transfer.
• Le letture della lista transfer e le letture degli importi delle quote non generano più errori 500 su grandi risultati storici.
• I redirect KYC concorrenti ora restituiscono un conflitto invece di 404, così i retry si risolvono in modo pulito. I redirect ospitati non subiscono più rollback a metà e i link KYC restano riprendibili.
• Le letture delle parti correlate per clienti individuali non restituiscono più 404.
• Le submission KYB con campi wallet non validi vengono rifiutate prima dell’invio e la sincronizzazione fallita non viene più segnalata come riuscita nel pannello merchant.
• I task di requisito nel pannello merchant ora mostrano le risposte inviate come complete, tracciano separatamente le azioni dei termini, rimuovono il testo duplicato dei documenti, mantengono in sospeso le sessioni KYC avviate fino al completamento e gestiscono i task obsoleti senza compromettere la vista dei requisiti.
• Le righe dei link di verifica nel pannello merchant ora mostrano un’azione Open su ogni riga, e ogni link di task viene renderizzato nella vista dei requisiti.