Changelog a poznámky k vydání Swipelux API

​

Přidáno

• Cíle příjemců přijímají typy pix a pix_safe pro výplaty v BRL v Brazílii. Cíl Pix platí na klíč Pix. Cíl Pix Safe platí na bankovní účet identifikovaný číslem CPF nebo CNPJ majitele, kódem ISPB banky, pobočkou a číslem účtu. Oba vyžadují připravenou capability Pix zákazníka (pix_pooled) a jejich výplaty jsou financovány v USDC a nenesou žádný vývojářský poplatek. Viz Příjemci a Odesílat prostředky.
• GET /v3/customers/{customerId}/tasks/{taskId} přijímá documentCandidatesFor s ID požadavku na dokument a také documentAlternativeKey pro požadavek s alternativami. Odpověď pak v data.documentCandidates uvádí soubory, které zákazník již nahrál a které mohou daný požadavek splnit, včetně případných missingMetadata nebo conflictingMetadata. Místo opětovného nahrání souboru odešlete documentId kandidáta s chybějícími documentMetadata. Dotaz vyžaduje accounts:read a customers:read a neplatný výběr vrací 400 validation_error.

​

Změněno

• GET /v3/webhooks/portal vrací URL portálu, jejíž platnost vyprší po jedné hodině, s hlavičkou Cache-Control: no-store. S API klíčem, který má webhooks:write, portál zobrazuje podpisové tajemství endpointu a umožňuje spravovat endpointy, opakovat doručení a znovu je přehrát. Pouze s webhooks:read portál zobrazuje jen doručení. Viz Webhooky.
• Citi (citibank) je nabízena pouze firemním zákazníkům. Každá firma si ponechává sdílenou Citi a pojmenovaná Citi je nabízena pouze firmám registrovaným mimo USA. Pokud zákazníkovi Citi nabízena není, seznam podporovaných bank ji vynechává, její uvedení vrací 422 capability_institutions_unsupported a metoda, kterou nabízí pouze Citi, je uvedena jako disabled. Požadavek bez institutions vybírá ze zbývajících bank. Stávající žádosti a účty se nemění.
• Pojmenované capabilities CFSB (cfsb) jsou nabízeny pouze zákazníkům z USA: firmám registrovaným v USA a fyzickým osobám, které tam mají bydliště. U ostatních zákazníků seznam podporovaných bank pojmenovanou CFSB vynechává a její uvedení vrací 422 capability_institutions_unsupported. Požadavek bez institutions vybírá ze zbývajících bank. Sdílená CFSB, zákazníci s neznámou zemí a stávající žádosti se nemění.
• Pojmenované capabilities ACH, Wire a SWIFT u Lead Bank (lead_bank) jsou nabízeny pouze zákazníkům, které Lead Bank může onboardovat na základě jejich právní formy a zemí. U ostatních zákazníků seznam podporovaných bank vynechává lead_bank a její uvedení vrací 422 capability_institutions_unsupported. Zákazníci, které Lead Bank již onboardovala, a capabilities, jejichž otevřený požadavek již uvádí lead_bank, si ji ponechávají. Stávající žádosti a účty se nemění.
• RTP je pouze sdílená. Žádná banka nenabízí rtp_named novým požadavkům, proto ji seznam podporovaných bank uvádí jako disabled. U zákazníka, který rtp_named nemá, vrací požadavek na capability nebo náhled úloh, který uvádí banku, 422 capability_institutions_unsupported a požadavek bez institutions vrací 422 capability_variant_unavailable. Sdílená RTP (rtp_pooled) je nabízena u Citi, proto o ni mohou žádat pouze firemní zákazníci.
• Nové požadavky na doklady totožnosti pro fyzické osoby a skutečné majitele mohou nastavit constraints.identityMetadataRequired: true, takže každý soubor vyžaduje číslo dokladu a zemi vydání v documentMetadata. Nové požadavky na doklad o adrese firmy a doklad o bydlišti vlastníka mohou nastavit constraints.maxIssueAgeDays: 90, takže každý soubor vyžaduje datum vydání. Stávající úkoly si ponechávají své požadavky, proto u každého požadavku úkolu čtěte jeho omezení.
• Odpověď na úkol k požadavku na registraci firmy, jehož profilePointer je /business/registration, vyžaduje současně zemi jurisdikce, registrační číslo a datum založení před datem odeslání. Toto pravidlo zveřejňuje valueSchema požadavku a neúplná odpověď vrací 400 validation_error.
• Po hostovaném ověření Swipelux přijme hostovanou odpověď na profilový požadavek na strukturovanou hodnotu, například adresu nebo daňové identifikátory, pouze pokud projde stejnými kontrolami schématu a omezení jako přímá odpověď. Jinak požadavek zůstane otevřený a tuto hodnotu odešlete pomocí POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Požadavek, který Swipelux z tohoto důvodu vrátí do stavu action_required, nese reviewFeedback.code: hosted_profile_direct_submission_required. Úkoly, které už jsou satisfied, si svůj stav ponechají. Viz Schopnosti a požadavky.
• Úkol zamítnutý hostovaným ověřením může opustit stav rejected, pokud je toto rozhodnutí o ověření později zvráceno. Poté přejde do stavu satisfied, nebo do action_required v nové revision se znovu otevřenými požadavky, na které nové rozhodnutí neodpovídá. Dřívější odeslání pro tyto požadavky zůstávají rejected, proto tyto odpovědi odešlete znovu. Viz Migrace na v3.
• type cíle příjemce je nyní otevřený enum. Dřívější verze této reference jej popisovaly jako uzavřený, proto aktualizujte každého klienta, který neznámé typy odmítá nebo zahazuje. Odpovědi s cíli a události destination.status_changed nyní mohou obsahovat pix a pix_safe a mohou přibýt další typy.
• Požadavky na vytvoření a aktualizaci příjemce, včetně vnořené address, ignorují pole, která nedefinují, místo aby vracely 400 validation_error. V požadavku na vytvoření pole jména nebo odvětví pro druhý typ příjemce nadále vrací 400 a totéž platí pro type a externalId v PATCH /v3/customers/{customerId}/recipients/{recipientId}. PATCH bez jakéhokoli pole, které rozpozná, vrací 400 validation_error místo 200.
• Ověřovací odkaz pro způsobilou relaci, která žádá pouze o dokumenty, nyní otevírá stránku pro nahrání dokumentů hostovanou společností Swipelux. Samotný odkaz se nemění a ostatní relace nadále otevírají hostovaný ověřovací proces.
• employment.occupation u zákazníků fyzických osob a osob souvisejících stran přijímá nejvýše 255 znaků.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} a POST /v3/customers/{customerId}/tasks/{taskId}/submissions vracejí 400 validation_error, když hodnota profilu nebo odpověď na úkol obsahuje odkaz na formulář Swipelux, například odkaz na RFI, žádost zákazníka nebo sledování převodu. To se netýká externalId ani metadata. Každá odmítnutá hodnota se objeví v errors[] s code: public_form_link a svým JSON Pointerem a odpověď odkaz nikdy nezopakuje. Místo toho odešlete samotné informace. Viz Chyby a opakování.

​

Opraveno

• Odpovědi s quotes a převody výplat zachovávají zdrojovou částku v USDC nebo USDT na šest desetinných míst, například 4009.711365 místo 4009.71. Fiat částky si ponechávají dvě desetinná místa. Vytvoření nebo čtení výplaty, jejíž zdrojová částka ve stablecoinu má více než dvě desetinná místa, již nevrací 500.
• Reference POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel nyní popisuje zrušení tak, jak skutečně funguje. Capability ve stavu ready můžete zrušit, capability stablecoin_transfers zrušit nelze a zrušení ukončí pouze danou capability, zatímco její žádosti si ponechají svůj stav, úkoly a schválení.
• Požadavek na capability nebo náhled úloh, který v institutions uvádí kód banky místo veřejného ID instituce, například citi místo citibank, vrací 422 capability_institutions_unsupported s uvedením dostupných ID místo 503 kyc_configuration_unavailable.
• Požadavek na capability nebo náhled úloh pro metodu, kterou zákazníkovi nenabízí žádná banka a kterou seznam podporovaných bank uvádí jako disabled, vrací 422 capability_variant_unavailable s retryable: false místo 503 kyc_configuration_unavailable, pokud zákazník danou capability již nemá.
• documentCandidates již neuvádí soubory, které si Swipelux ponechává z dokončeného hostovaného ověření a které nemůžete číst ani stáhnout. Odpověď na úkol, která na takový soubor odkazuje, vrací 400 invalid_document_reference, stejně jako neznámý dokument.

​

Přidáno

• GET /v3/customers přijímá include=documentRequirements. Souhrn každého zákazníka pak uvádí, kolik povinných dokumentů ještě chybí, nezávisle na připravenosti schopností. Kombinujte jej jako include=capabilities,documentRequirements. Viz Zákazníci.
• Stránka Webhooks v panelu obchodníka přidává do nabídky endpointu Replay missed events. Znovu odešle události za posledních 13 dní, které endpoint nikdy neobdržel, a nikdy neodešle stejnou událost dvakrát. Viz Webhooky.
• Stránka Settings v panelu obchodníka má sekci Compliance. Vlastníci a administrátoři mohou nastavit e-mail pro compliance a zvolit, zda chtějí dostávat e-maily, když Swipelux požaduje další informace o zákazníkovi.
• Obchodníci mohou na vlastní požadavky KYB týkající se dodržování předpisů odpovídat přímo na stránce KYB v panelu obchodníka.

​

Změněno

• Aktualizace zákazníků a souvisejících stran už po dokončeném bankovním přijímacím procesu nevracejí 409 field_conflicts_with_completed_intake. Aktualizace se uloží a každá nová bankovní žádost ověří nejnovější profil podle svých vlastních požadavků.
• Požadavky na schopnosti vracejí 409 capability_route_header_conflict, pokud stávající bankovní směrování schopnosti nelze bezpečně aktualizovat. Před opakováním kontaktujte podporu Swipelux.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview vrací 422 capability_institutions_unsupported, pokud institutions uvádí banku, kterou schopnost nenabízí, stejně jako požadavky na schopnosti.
• V sandboxu jsou schopnosti ACH, Wire a SWIFT poskytovány pouze u JPMorgan Chase. Požadavky, které vynechají institutions, vyberou jpmorgan, a uvedení jiné banky vrací 422 capability_institutions_unsupported. Směrování v produkci se nemění. Viz Testování v sandboxu.
• Vynucení stavu schopnosti v sandboxu vrací 409 capability_status_blocked se statusReason, pokud simulovaný případ nemůže dosáhnout požadovaného stavu. Opakování vynucení, které již bylo použito, vrací 200 beze změny. Viz Testování v sandboxu.
• POST /v3/sandbox/tasks/{taskId}/review vrací 409 task_not_sandbox_reviewable pro úkol, který vlastní Operations nebo jiný workflow. Úkoly z POST /v3/sandbox/tasks a úkoly příjmu capabilities, které Swipelux shromažďuje, zůstávají kontrolovatelné. Viz Testování v sandboxu.
• PATCH /v3/customers/{customerId}/accounts/{accountId} vrací 409 account_provisioning_unresolved, pokud měníte vypořádání, zatímco se účet u banky stále zřizuje. Akci zopakujte po vyřešení zřizování. Viz Chyby a opakování.
• POST /v3/transfers může vrátit 409 quote_execution_evidence_conflict. Vytvořte nový quote a proveďte jej. Viz Chyby a opakování.
• Postranní panel Pay out v panelu obchodníka zobrazuje úplné údaje o cíli, skrývá čísla účtů a adresy peněženek za přepínačem a u každé platební metody zobrazuje odhadovaný čas doručení.
• Panel obchodníka začleňuje bankovní účty do karty zákazníka Payment access s kartou úloh, která uvádí každou banku. Karta Documents se přesunula do Profile.
• Otevření pojmenovaného bankovního účtu v panelu obchodníka je nyní jediný krok, který uvádí měnu, metody a dobu onboardingu každé banky. Viz Účty.
• Bankovní účty pozastavené ke kontrole se v panelu obchodníka zobrazují jako On hold s ID účtu a akcí Contact support.
• Capability ve stavu pending nyní hlásí statusReason.code: preparing_submission místo review_in_progress, zatímco Swipelux připravuje žádost k odeslání a neprobíhá žádná kontrola. Oba kódy používají resolution: wait. Změna mezi nimi ponechá stav pending, takže se neodešle žádná událost capability.status_changed. Stávající capabilities převezmou nový kód při příštím přehodnocení. Viz Schopnosti a požadavky.
• Tabulka Shared methods na kartě Payment access zákazníka v panelu obchodníka zobrazuje In preparation místo In review u sdílené metody, jejíž capability hlásí preparing_submission.
• Seznam applications capability nyní zobrazuje pouze její aktuální žádosti, a to při čtení capabilities (včetně GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), v odpovědích na žádosti o capability a v událostech capability.status_changed. Žádost nahrazená novější žádostí se stále zobrazuje v GET /v3/customers/{customerId}/applications, kde supersededByApplicationId uvádí jejího nástupce. Otevřené úkoly nahrazené žádosti se stále započítávají do openTaskIds capability. Stav capability ani openTaskIds se nemění, takže samotná změna neodesílá žádnou webhook událost. Viz Schopnosti a požadavky.

​

Opraveno

• Druhý požadavek allowPending na stejný vydaný účet, odeslaný před schválením bankou, vrací 409 s čekajícím účtem uvedeným v holder.accountId místo 500. Viz Vydat bankovní účet.
• Zrušení schopnosti nyní uzavře požadavky na vydané účty, které stále čekaly na schválení bankou, takže pozdější požadavek u stejné banky začne od začátku.
• Opětovné vyžádání zrušené schopnosti, jejíž bankovní případy byly všechny zamítnuty, publikuje jedinou událost capability.status_changed ze stavu canceled.
• Opětovné vyžádání banky poté, co byla její dřívější žádost archivována, nyní odešle novou žádost.
• Cíle příjemců lze přidat, jakmile odpovídající schopnost hlásí ready, místo vracení 409 rail_not_ready. Viz Příjemci.
• Události webhooku odeslané předtím, než poprvé otevřete stránku Webhooks v panelu obchodníka, se nyní uchovávají, takže je můžete znovu přehrát na nový endpoint.
• Termíny splnění úloh v panelu obchodníka se zobrazují ve vašem časovém pásmu a postranní panely bankovní kontroly zobrazují All requirements submitted, jakmile nic nezůstává otevřené.

​

Přidáno

• POST /v3/quotes přijímá volitelné institutionId pro výběr schválené bankovní trasy pro quote výplaty z kryptoměn do fiat měny. Vynechte jej, chcete-li zachovat automatické směrování. Banka, která pro výplatu není dostupná, vrací 422 bank_not_supported_for_customer a odeslání institutionId u jakéhokoli jiného typu quote vrací 400 validation_error. Viz Odesílat prostředky.
• Požadavky na vydané bankovní účty na POST /v3/customers/{customerId}/accounts přijímají institution k připnutí účtu k jedné bance bez záložní varianty a allowPending: true k uložení požadavku, zatímco žádost u této banky stále čeká na schválení. allowPending vyžaduje institution. Uložené požadavky uvádějí řídicí applicationId. Viz Vydat bankovní účet.
• Panel obchodníka má nativní stránku Webhooks pro správu endpointů. Viz Webhooky.
• Panel obchodníka přidává panel Pay in s pojmenovanými bankovními účty, vklady kryptoměn a krokem kontroly.
• Tok Pay out v panelu obchodníka zobrazuje zůstatky peněženek ve výběru zdroje, přidává možnost částky Max a obsahuje krok kontroly.
• Profily zákazníků v panelu obchodníka mají kartu Recipients & destinations.
• Požadavky úloh mohou obsahovat krátký nadpis title. Pokyny nadále nese prompt požadavku. Viz Schopnosti a požadavky.

​

Změněno

• Quotes pro pay-in bankovním převodem wire na sdílených trasách Wire nyní vyžadují alespoň 20 $. Quotes pod minimem dané trasy nebo příliš malé na pokrytí poplatků za převod vracejí 422 amount_not_deliverable místo obecného selhání quote. Viz Příjem prostředků.
• Portál webhooků nyní seskupuje typy událostí v3 podle prostředku a u každé události zobrazuje schéma payloadu a příklad. Starší typy událostí se zobrazují v samostatné skupině Legacy a jsou označeny jako zastaralé. Endpointy, které je již odebírají, je nadále dostávají; pro nové odběry používejte typy událostí v3. Viz Webhooky.
• Dobití v sandboxu nyní generují události webhooku transfer.created a transfer.state_changed. Viz Testování v sandboxu.
• accountProvisioning nyní hlásí issued, pokud zákazník již má aktivní vydaný účet. Viz Schopnosti a požadavky.
• Podrobnosti bankovního účtu v panelu obchodníka se otevírají v postranním panelu s logy bank. Viz Účty.
• Panel obchodníka označuje pohyb peněz jako Pay in a Pay out, udržuje vás přihlášené šest hodin a odesílá žádosti o pomoc podpoře Swipelux e-mailem.
• V přijímacích úlohách, které přijímají přímé odeslání, přecházejí způsobilé požadavky již podložené profilem zákazníka nebo nahranými dokumenty automaticky do stavu in_review. Viz Schopnosti a požadavky.

​

Opraveno

• Opětovné vyžádání zrušené schopnosti již neselhává kvůli nahrazeným záznamům žádostí nebo zastaralým požadavkům.
• Schopnosti uložené pod vyřazeným ID Fedwire se nyní čtou jako wire místo vracení 500.

​

Přidáno

• GET /v3/customers/{customerId}/applications vypisuje žádosti zákazníka spolu se schopnostmi vyžádanými v rámci každé žádosti a schopnostmi, které pokrývá její schválení. Jedno schválení u banky může pokrýt více schopností. Uchované historické žádosti odkazují na svou nástupnickou žádost přes supersededByApplicationId. Seznam podporuje stránkování kurzorem a updatedAfter. Viz Schopnosti a požadavky.
• Odpovědi POST /v3/customers/{customerId}/capabilities/{capabilityId} obsahují selectedApplicationId pro schopnosti založené na žádosti. Identifikuje existující žádost, kterou požadavek znovu použil, nebo žádost, kterou otevřel. Viz Schopnosti a požadavky.
• Instituce vracené endpointem GET /v3/institutions a seznamem podporovaných schopností obsahují logoUrl, které může být null. Použijte jej k zobrazení značky banky, je-li k dispozici, a pokud je null, použijte název instituce. Viz Schopnosti a požadavky.
• Výplaty SWIFT v USD jsou nyní dostupné. Výplaty SWIFT vyžadují alespoň 100 USD. Panel obchodníka shromažďuje bankovní instrukce SWIFT pro příjemce. Viz Odesílat prostředky.
• Vydané bankovní účty mohou přijímat přes SWIFT s pojmenovanými platebními údaji. Viz Vydat bankovní účet.
• USDT je nyní podporováno jako zdroj pro výplaty ACH a Wire. Viz Odesílat prostředky.
• Vydané bankovní účty přijímají settlement.currency s hodnotou USDC nebo USDT k volbě stablecoinu doručovaného do vypořádací peněženky, nezávisle na měně účtu peněženky. Vynechte jej, chcete-li dál vypořádávat v měně peněženky. Viz Vydat bankovní účet.
• Bankovní účty SWIFT a cíle příjemců přijímají bankCity, bankState, bankPostalCode a bankAddressLine2 a dále volitelné beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode a údaje o zprostředkující bance. Viz Odesílat prostředky.
• Údaje vydaných bankovních účtů obsahují achRoutingNumber a wireRoutingNumber, pokud banka poskytuje samostatná směrovací čísla ACH a Wire, a bankLogoUrl přijímající banky. Viz Vydat bankovní účet.
• Události webhooku capability.created obsahují applicationId a origin s hodnotou requested nebo approval, takže rozlišíte schopnosti, které jste vyžádali, od těch, které pokrylo schválení. Viz Webhooky.
• Požadavky mohou deklarovat validační constraints.format, například http_url, us_ssn, us_ein nebo bank_industry_classification. Viz Schopnosti a požadavky.

​

Změněno

• Vytváření bankovního účtu v panelu obchodníka nyní začíná výběrem banky a bankovní účty zobrazují samostatná směrovací čísla ACH a Wire. Viz Účty.
• Výčet network nyní obsahuje solana. Jde o otevřený výčet, proto tolerujte hodnoty sítí, které nerozpoznáte. Viz Účty.
• Otevření hostovaného ověřovacího odkazu pro úlohu, jejíž zbývající požadavky vyžadují přímé odeslání, vrací 409 verification_session_not_allowed. Místo toho tyto požadavky odešlete jako odeslání úlohy. Viz Chyby a opakování.
• Archivace vydaného účtu, jehož zřizování ještě není vyřešeno, vrací 409 account_provisioning_unresolved. Akci zopakujte po vyřešení zřizování. Viz Chyby a opakování.
• Nové požadavky na pojmenované bankovní účty se zařadí do fronty ke zřízení hned po vytvoření účtu, místo čekání na další obnovení zákazníka. Viz Vydat bankovní účet.

​

Odebráno

• Sdílené (pooled) platební údaje SWIFT se již pro nové účty nenabízejí. Místo nich použijte pojmenované platební údaje SWIFT. Viz Vydat bankovní účet.

​

Opraveno

• Čtení převodů výplat nyní vrací příjemce z quote.
• Vytvoření účtu ACH po archivaci existujícího účtu již nevrací 409 a archivované čekající požadavky na účet již neblokují slot účtu.
• Bankovní poplatky u quotes pro pay-in v místní měně se uvádějí ve správné fiat měně.

​

Přidáno

• GET /v3/webhooks/{webhookId} čte jeden endpoint webhooku a jeho výběr events. Viz Webhooky.
• Požadavky úloh nyní publikují allowedValues a valueSchema ve formátu JSON Schema pro pole profilu, včetně povinných polí adresy. Pole země uvádějí valueType nebo itemValueType s hodnotou country, tedy kód ISO 3166-1 alpha-2. Vstupy a volby můžete vykreslit bez jejich natvrdo zakódování. Viz Schopnosti a požadavky.
• Existující peněženky Tron nyní mohou odesílat USDT na externí účty peněženek zákazníka a čtení převodů obsahuje odkaz na průzkumník bloků pro transakce Tron. Nové peněženky na síti Tron vydat nelze. Viz Odesílat prostředky.
• Požadavky úloh mohou deklarovat requiredWhen (odpovídat pouze tehdy, když se shoduje určená odpověď ano/ne), profileAssertion (us_person) a ownershipPolicy a požadavky na dokumenty mohou nastavit identityMetadataRequired a maxIssueAgeDays. Odpovědi úloh přijímají documentMetadata (idNumber, issuingCountry, issuedOn) pro odkazované dokumenty a čtení úloh vrací zkontrolované řídicí odpovědi v conditionValues. Viz Schopnosti a požadavky.
• Požadavky na dokumenty mohou uvádět acceptedDocumentSets a požadavky na související strany mohou kromě beneficial_owner vyžadovat kvalifikaci associated_person nebo control_person. Viz Schopnosti a požadavky.
• Objekty correction u převodů nyní pokrývají také neúspěšné financované výplaty: kind: funding_failure s kompenzační akcí recover_source_funding, recoveryStatus s hodnotou unknown nebo reported a připsané výstupy v USDT. Viz Quotes a převody.

​

Změněno

• PATCH /v3/webhooks/{webhookId} nyní přijímá starší typy událostí, k jejichž odběru je endpoint již přihlášen, takže je můžete zachovat, zatímco přidáváte typy událostí v3. events nahrazuje celý výběr, proto uveďte každý typ události, který chcete zachovat. Přidání staršího typu události, který endpoint dosud neměl, vrátí 400 validation_error. Viz Webhooky.
• Bankovní identifikátory u příjemců a účtů jsou před uložením validovány. Viz Příjemci.
• Požadavky na schopnosti, odeslání úloh a změny stavu v sandboxu nyní vracejí 409 capability_application_stale místo 500, pokud byla schopnost vytvořena v rámci dřívějšího modelu onboardingu. Viz Chyby a opakování.
• Veřejná stránka RFI je nyní jeden souvislý formulář. Podporuje související osoby a shromažďuje jedno daňové identifikační číslo na osobu. Viz Požadavky na dokumenty.
• Quotes a převody vracejí 409 customer_bank_limit_exceeded, když platba překročí zbývající denní nebo měsíční limit zákazníka u banky, a 503 customer_bank_limits_unavailable, když tento limit nelze ověřit. Převody vracejí 409 payout_execution_unavailable, když výplatu nelze z jejího quote zahájit. Viz Chyby a opakování.
• Aktualizace zákazníků a souvisejících stran, které kolidují s dokončeným bankovním přijímacím procesem, vracejí 409 field_conflicts_with_completed_intake s taskId a fields.

​

Opraveno

• Historie zrušených schopností zůstává čitelná.
• Výplaty wire se v seznamu transakcí panelu obchodníka zobrazují a filtrují správně.

​

Změněno

• POST /v3/transfers a čtení převodů používají pro předvýběr kartového checkoutu checkoutMethod místo paymentMethod a přijímají card, apple_pay, google_pay, cash_app, sepa a blik. Seznam je otevřený a může se rozšiřovat. paymentMethod se již nerozpoznává; požadavky, které jej stále odesílají, se zpracují, jako by byl vynechán. sepa a blik jsou možnosti financování uvnitř kartového checkoutu, nikoli schopnosti Swipelux. Viz Příjem prostředků.

​

Přidáno

• POST /v3/transfers přijímá pro kartové quotes volitelné paymentMethod s hodnotou card, apple_pay nebo google_pay. Hostovaný checkout se otevře s vyžádanou metodou, pokud je pro zákazníka a jeho zařízení dostupná, čtení převodu vrací požadavek a částky i poplatky quote zůstávají beze změny. Viz Příjem prostředků.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview přijímá institutions k náhledu úloh pro konkrétní banky vrácené seznamem podporovaných schopností. Viz Schopnosti a požadavky.

​

Změněno

• Kartové quotes nyní zohledňují poplatky checkoutu a čistou doručenou částku USDC. Viz Příjem prostředků.
• Zamítnuté quotes výplat vracejí místo obecného selhání konkrétní kód problému: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported nebo quote_failed, a 503 quote_temporarily_unavailable, pokud lze quote zopakovat později. Viz Chyby a opakování.

​

Opraveno

• Kartové quotes již neselhávají kvůli zaokrouhlování poplatků.
• Opětovné otevření hostovaného odkazu KYC již nevrací 409 kyc_process_conflict, když odpovědi v dotazníku obsahují nadbytečné mezery.
• Zaseknutá potvrzení výběrů pomocí passkey v panelu obchodníka se nyní obnoví.

​

Přidáno

• POST /v3/customers/{customerId}/documents nyní přijímá také tělo application/json s poli storageKey, fileName a type. storageKey musí být čerstvá reference v rozsahu zákazníka zaparkovaná přes dřívější tok direct-upload a nahrání prochází stejnou validací velikosti a signatury souboru jako multipart nahrávání. Viz Migrace na v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download vrací url ke stažení aktivního dokumentu zákazníka. URL vyprší po jedné hodině a poskytuje soubor jako přílohu. Archivované dokumenty, neznámé dokumenty a dokumenty jiných zákazníků vracejí 404. Viz Schopnosti a požadavky.
• Vyžádání schopnosti pro firmu bez skutečného majitele nyní vytvoří přijímací úlohu k jeho doplnění místo selhání chybou 503. Požadavky, které nemohou pokračovat, vrátí 422 beneficial_owner_required s pokyny k přidání individuální související strany s deklarovaným nebo alespoň 25% vlastnictvím. Viz Akcionáři, UBO a kontrolní osoby.
• Tabulka úloh v panelu obchodníka nyní zobrazuje subjekt a rozsah schopnosti každého požadavku, takže vidíte, koho a čeho se požadavek na dodržování předpisů týká. Viz Schopnosti a požadavky.
• Pole klasifikace odvětví v panelu obchodníka nyní nabízejí vyhledávatelné kódy NAICS v profilech zákazníků a úlohách požadavků. Viz Pracovní postup KYB.
• Bankovní instrukce pro pay-in mohou obsahovat bankName, bankAddress, accountHolderName a accountHolderAddress. Zobrazte je spolu s ostatními bankovními údaji. Viz Příjem prostředků.
• POST /v3/transfers přijímá volitelné redirectUrl, které zákazníka po hostovaném checkoutu kartou nebo Apple Pay vrátí do vaší aplikace. Dosažení této URL nepotvrzuje dokončení; použijte čtení převodů nebo webhooky. Viz Příjem prostředků.
• Převody vytvořené pravidlem v3 (Rule) se zobrazují ve čtení a seznamech převodů s origin: rule a generují události transfer.state_changed stejně jako ostatní převody. Filtrujte je pomocí GET /v3/transfers?origin=rule. Viz Kotace a převody.
• Doklady totožnosti u zákazníků a souvisejících stran přijímají sideApplicability (front_only, front_and_back nebo unknown) a úlohy mohou jako odpovědi shromažďovat údaje dokladu totožnosti, například type, number, issuingCountry, issuingRegion, issuedOn, expiresOn a doesNotExpire. Viz Schopnosti a požadavky.

​

Změněno

• Odeslání bankovních údajů, která kolidují s probíhajícím nastavením banky, nyní vrací 409 ops_rail_handoff_conflict. Uchovejte si ID nahraných dokumentů a po vyřešení konfliktu zopakujte stejné odeslání místo opětovného nahrávání dokumentů. Viz Chyby a opakování.
• Minimum pro neohlášené vklady stablecoinů do peněženek zákazníků je nyní 1 jednotka místo 10. Menší vklady jsou nadále považovány za prach (dust). Viz Příjem prostředků.
• Konfigurace webhooků je nyní izolována podle prostředí. Portál webhooků se otevře v rozsahu prostředí, ze kterého jej vyžádáte, takže endpointy sandboxu a produkce již nesdílejí nastavení. Viz Webhooky.
• Panel obchodníka nyní odvozuje dostupné metody pay-in ze schopností v3 daného zákazníka, takže nastavení účtu nabízí pouze metody, na které má zákazník nárok. Viz Účty.
• Formuláře RFI nyní shromažďují kvalifikované skutečné majitele pomocí kratších a jasnějších výzev a historie RFI se zobrazuje jako milníky životního cyklu. Viz Požadavky na dokumenty.
• Otevřené úlohy bez explicitního termínu nyní mají dueAt ve výchozím nastavení 31 dní po vytvoření. Viz Schopnosti a požadavky.

​

Odebráno

• Panel obchodníka již při přidávání nových metod pay-in nenabízí Fedwire. Existující účty Fedwire zůstávají čitelné. Viz Účty.

​

Opraveno

• Neohlášené vklady USDT do peněženek zákazníků jsou nyní rozpoznány a vypořádány místo ignorování.
• Již odeslané doklady se nyní přenášejí do dalších úloh, které vyžadují stejnou položku, takže zákazníci nejsou žádáni o stejný dokument dvakrát.
• Opětovné vyžádání schopnosti již nezahazuje bankovní trasy, které jsou již připraveny, takže vydané údaje o účtu zůstávají stabilní.
• Zobrazení bankovních instrukcí v panelu obchodníka nyní ukazují kompletní podrobnosti včetně adres SWIFT a adresy cílové peněženky.
• Formuláře RFI nyní zobrazují chyby validace při odeslání, validují popisy právní formy před odesláním a přijímají více firemních webových stránek.
• Koncepty souvisejících osob ve formulářích RFI lze nyní před odesláním upravit.
• Zrušené požadavky na dodržování předpisů se již nezobrazují v seznamu úloh panelu obchodníka.
• Stavy kontroly dokumentů se v panelu obchodníka opět zobrazují správně.

​

Přidáno

• Hostované ověřovací relace a relace Podmínek služby v rozsahu zákazníka nyní obsahují autoritativní objekt action. Řiďte se jeho druhem available nebo unavailable; plochá pole url a expiresAt zůstávají pro dostupné akce zrcadly kvůli kompatibilitě. Viz Schopnosti a požadavky.
• Dobití peněženky v sandboxu nyní vrací ID převodu, které můžete načíst pomocí GET /v3/transfers/{transferId} nebo vypsat pomocí GET /v3/transfers. Zobrazí se jako dokončené příchozí vklady stablecoinů. Viz Testování v sandboxu.
• Čtení převodů obsahuje objekt correction, pokud jsou prostředky převodu po jeho dokončení vráceny nebo stornovány. Uvádí kind opravy, normalizovaný providerStatus, případný providerShortfall a compensatingIntent, který Swipelux uplatní. Viz Kotace a převody.

​

Změněno

• Průvodce First pay-in v panelu obchodníka pro karty a Apple Pay nyní vyžaduje peněženku Polygon daného zákazníka. Vytvořte ji před spuštěním průvodce. Viz Účty.
• Nové požadavky a veřejné odpovědi používají sepa jako kanonický název metody a schopnosti. Vstupní alias sepa_instant a dříve uložené prostředky zůstávají kompatibilní, ale veřejné odpovědi používají sepa. Viz Účty.
• Nové požadavky na schopnosti, vydané účty a kotace Faster Payments nejsou dostupné. Existující účty, kotace a převody zůstávají čitelné. Viz Účty.
• První stránka KYB již neshromažďuje datum narození zástupce. Data narození akcionářů zůstávají samostatným požadavkem. Viz Pracovní postup KYB.
• Odkazy na dokumenty RFI nyní kromě image/jpeg přijímají také alias MIME image/jpg. Viz Požadavky na dokumenty.
• Historie úloh v panelu obchodníka nyní zobrazuje čitelný auditní záznam bez čítačů revizí. Viz Schopnosti a požadavky.
• Kotace a převody nyní před jakýmkoli pohybem peněz kontrolují podporované směry schopnosti. Použití schopnosti ve směru, který nepodporuje, vrací 422 capability_direction_unsupported a přesuny mezi peněženkami vyžadují schopnost stablecoin_transfers. Viz Chyby a opakování.

​

Odebráno

• Panel obchodníka již nenabízí nastavení nových účtů UAEFTS. Existující účty UAEFTS zůstávají čitelné. Viz Účty.

​

Opraveno

• Formuláře RFI zachovávají existující údaje, když kontrolor přidá nové pole pro dokument, takže se dříve zadané odpovědi při opětovném odeslání neztratí.
• Panel obchodníka obnovuje hostované relace pro dodržování předpisů z dostupných akcí, aniž by zahodil platné odkazy.
• Hostované odkazy na Podmínky služby nyní fungují pro každý rozsah úloh vrácený rozhraním API.
• Po vyžádání Payment Access v panelu obchodníka se otevře přijímací úloha vrácená tímto požadavkem místo úlohy z dřívějšího požadavku.
• Ukázka KYB v panelu obchodníka nyní vyžaduje aktuální povinná pole.
• Kotace, která znovu použije zdrojovou peněženku jako destinationId, nyní před zahájením práce poskytovatele vrátí použitelné podrobnosti 422 quote_direction_invalid. Viz Kotace a převody.
• Rozhraní API odmítne chybně kódovaný řetězec dotazu chybou 400 místo tiché normalizace požadavku. Viz Chyby a opakování.
• POST /v3/customers/{customerId}/documents nyní odmítne prázdné, nemultipartové nebo chybně formátované tělo požadavku chybou 400.

​

Přidáno

• V OpenAPI specifikaci byl publikován katalog Problem Details pro v3, takže integrátoři mohou mapovat chybové odpovědi přímo ze schématu. Viz Chyby.
• K webhook událostem účtů ve v3 bylo přidáno pole customerId, které umožňuje korelovat aktivitu účtu s jeho vlastnickým zákazníkem bez následného čtení. Viz Webhooky.
• V panelu obchodníka je nyní kompletní pokrytí polí individuálního profilu V3, takže operátoři onboardingu mohou zkontrolovat a upravit všechna KYC pole shromážděná přes v3 API. Viz Zákazníci.
• Byl publikován vývojářský průvodce migrací z v3. Viz Migrace na v3.

​

Změněno

• Kódy zemí zákazníků a účtů se nyní při zápisu validují jako přidělené hodnoty ISO 3166-1 alpha-2. Čtení tolerují dříve uložené hodnoty, aby existující záznamy zůstaly rozpoznatelné. Viz Účty a peněženky.
• Dostupnost USDC je nyní omezena podle cílové sítě, takže quotes a převody nabízejí USDC pouze na sítích, které cíl skutečně podporuje.
• Každý onboardingový tok nyní vyžaduje Podmínky služby Swipelux. Existující relace zůstávají obnovitelné. Viz Zákazníci.
• Capability.ready nadále oznamuje schválení oprávnění. Použijte accountProvisioning ke sledování vydávání účtu jako not_applicable, not_started, in_progress, issued nebo failed. Viz Schopnosti a požadavky.
• Nahrávání HEIC z iPhone jsou nyní přijímána jako doklady totožnosti a adresy.
• Vymazání pole zákazníka nebo související strany, které otevřená úloha stále vyžaduje, nyní vrací 409 field_required_by_open_task s blokujícím taskId a fields místo konfliktu, který lze opakovat. Před změnou těchto polí úlohu dokončete nebo zrušte. Viz Chyby a opakování.

​

Opraveno

• Opětovné provedení již spotřebovaného quote nyní vrací 409 quote_execution_consumed místo obecné chyby. Viz Quotes a převody.
• Čtení seznamů převodů a čtení částek quotes již u velkých historických výsledků neselhávají chybou 500.
• Souběžná přesměrování KYC nyní vrací konflikt místo 404, takže se opakování řeší čistě. Hostovaná přesměrování se již v polovině nevracejí zpět a odkazy KYC zůstávají obnovitelné.
• Čtení souvisejících stran u individuálních zákazníků již nevrací 404.
• Odeslání KYB s neplatnými poli peněženky jsou odmítnuta před odesláním a neúspěšná synchronizace se v panelu obchodníka již nehlásí jako úspěch.
• Úlohy požadavků v panelu obchodníka nyní zobrazují odeslané odpovědi jako dokončené, sledují akce podmínek samostatně, odstraňují duplicitní text dokumentů, ponechávají zahájené relace KYC jako čekající až do dokončení a zvládají zastaralé úlohy bez narušení pohledu na požadavky.
• Řádky odkazů na verifikaci v panelu obchodníka nyní na každém řádku zobrazují akci Open a každý odkaz na úlohu se vykresluje v pohledu na požadavky.