Swipelux API changelog és kiadási megjegyzések

​

Hozzáadva

• A címzetti célhelyek elfogadják a pix és pix_safe típusokat brazíliai BRL-kifizetésekhez. A Pix célhely egy Pix-kulcsra fizet. A Pix Safe célhely egy olyan bankszámlára fizet, amelyet a tulajdonos CPF- vagy CNPJ-száma, a bank ISPB-kódja, a fiók és a számlaszám azonosít. Mindkettőhöz az ügyfél kész Pix-képessége (pix_pooled) szükséges, kifizetéseik fedezete USDC, és nem terheli őket fejlesztői díj. Lásd: Címzettek és Pénz küldése.
• A GET /v3/customers/{customerId}/tasks/{taskId} elfogadja a documentCandidatesFor paramétert egy dokumentumkövetelmény azonosítójával, valamint az alternatívákkal rendelkező követelményekhez a documentAlternativeKey paramétert. A válasz ekkor a data.documentCandidates mezőben felsorolja azokat a fájlokat, amelyeket az ügyfél már feltöltött, és amelyek megfelelhetnek a követelménynek, az esetleges missingMetadata vagy conflictingMetadata adatokkal együtt. A fájl újbóli feltöltése helyett küldje be a jelölt documentId értékét a hiányzó documentMetadata adatokkal. A lekérdezéshez accounts:read és customers:read jogosultság szükséges, érvénytelen kiválasztás esetén pedig 400 validation_error választ kap.

​

Módosítva

• A GET /v3/webhooks/portal egy óra után lejáró portál URL-t ad vissza, Cache-Control: no-store fejléccel. webhooks:write jogosultsággal rendelkező API-kulccsal a portál megjeleníti a végpont aláíró titkát, és kezelheti a végpontokat, újrapróbálhatja és újrajátszhatja a kézbesítéseket. Csak webhooks:read jogosultsággal a portál kizárólag a kézbesítéseket mutatja. Lásd: Webhookok.
• A Citi (citibank) kizárólag üzleti ügyfeleknek érhető el. Minden vállalkozás megtartja a közös (pooled) Citit, az elnevezett Citit pedig csak az Egyesült Államokon kívül bejegyzett vállalkozások kapják meg. Ha egy ügyfél számára a Citi nem érhető el, a támogatott lista nem tartalmazza, megadása 422 capability_institutions_unsupported választ ad vissza, és a csak a Citi által kínált módszer disabled állapotúként jelenik meg. Az institutions mezőt elhagyó kérések a fennmaradó bankok közül választanak. A meglévő kérelmek és számlák nem változnak.
• Az elnevezett CFSB (cfsb) képességek csak amerikai ügyfeleknek érhetők el: az Egyesült Államokban bejegyzett vállalkozásoknak és az ott lakó magánszemélyeknek. Más ügyfeleknél a támogatott lista nem tartalmazza az elnevezett CFSB-t, megadása pedig 422 capability_institutions_unsupported választ ad vissza. Az institutions mezőt elhagyó kérések a fennmaradó bankok közül választanak. A közös (pooled) CFSB, az ismeretlen országú ügyfelek és a meglévő kérelmek nem változnak.
• A Lead Bank (lead_bank) elnevezett ACH-, Wire- és SWIFT-képességei csak olyan ügyfeleknek érhetők el, akiket a Lead Bank a jogi formájuk és országaik alapján fel tud venni. Más ügyfeleknél a támogatott lista nem tartalmazza a lead_bank bankot, megadása pedig 422 capability_institutions_unsupported választ ad vissza. Azok az ügyfelek, akiket a Lead Bank már felvett, valamint azok a képességek, amelyek nyitott kérése már megnevezi a lead_bank bankot, megtartják azt. A meglévő kérelmek és számlák nem változnak.
• Az RTP csak közös (pooled) formában érhető el. Egyetlen bank sem kínálja a rtp_named képességet új kérésekhez, ezért a támogatott lista disabled állapotúként mutatja. Olyan ügyfélnél, aki nem rendelkezik rtp_named képességgel, az erre vonatkozó, bankot megnevező képességkérés vagy feladat-előnézet 422 capability_institutions_unsupported választ ad vissza, az institutions mezőt elhagyó pedig 422 capability_variant_unavailable választ. A közös RTP (rtp_pooled) a Citinél érhető el, ezért csak üzleti ügyfelek kérhetik.
• A magánszemélyekre és tényleges tulajdonosokra vonatkozó új személyazonosító dokumentum-kérések beállíthatják a constraints.identityMetadataRequired: true értéket, így minden fájlhoz meg kell adni az azonosító számát és a kibocsátó országot a documentMetadata mezőben. Az új vállalati lakcímigazolási és tulajdonosi lakóhely-igazolási kérések beállíthatják a constraints.maxIssueAgeDays: 90 értéket, így minden fájlhoz meg kell adni a kiállítás dátumát. A meglévő feladatok megtartják követelményeiket, ezért olvassa ki a korlátozásokat minden feladatkérésnél.
• Egy vállalati cégjegyzékezési kérésre adott feladatválasznak, amelynek profilePointer értéke /business/registration, egyszerre tartalmaznia kell a joghatóság országát, a cégjegyzékszámot és a beküldés dátumánál korábbi alapítási dátumot. Ezt a szabályt a kérés valueSchema mezője közzéteszi, a hiányos válasz pedig 400 validation_error hibát ad vissza.
• Hosztolt ellenőrzés után a Swipelux egy strukturált értékre, például címre vagy adóazonosítókra vonatkozó profilkövetelményre adott hosztolt választ csak akkor fogad el, ha az ugyanazokon a séma- és korlátozásellenőrzéseken megy át, mint egy közvetlen válasz. Ellenkező esetben a követelmény nyitva marad, és az értéket a POST /v3/customers/{customerId}/tasks/{taskId}/submissions végponttal kell beküldenie. Az a követelmény, amelyet a Swipelux emiatt visszaállít action_required állapotba, reviewFeedback.code: hosted_profile_direct_submission_required értéket hordoz. A már satisfied állapotú feladatok megtartják státuszukat. Lásd: Képességek és követelmények.
• Egy hosztolt ellenőrzés által elutasított feladat kikerülhet a rejected állapotból, ha az ellenőrzési döntést később visszavonják. Ekkor satisfied állapotba kerül, vagy egy új revision mellett action_required állapotba, és azok a követelmények, amelyeket az új döntés nem válaszol meg, újra megnyílnak. Az ezekre a követelményekre vonatkozó korábbi beküldések rejected állapotban maradnak, ezért küldje be újra ezeket a válaszokat. Lásd: Migrálás v3-ra.
• A címzetti célhely type mezője mostantól nyitott enum. A referencia korábbi változatai zártként írták le, ezért frissítsen minden olyan klienst, amely elutasítja vagy eldobja az ismeretlen típusokat. A célhely-válaszok és a destination.status_changed események mostantól pix és pix_safe értéket is tartalmazhatnak, és további típusok is megjelenhetnek.
• A címzett-létrehozási és -frissítési kérések, a beágyazott address objektummal együtt, figyelmen kívül hagyják az általuk nem definiált mezőket ahelyett, hogy 400 validation_error hibát adnának vissza. Létrehozási kérésben a másik címzetttípushoz tartozó név- vagy iparági mező továbbra is 400 választ ad vissza, és ugyanez érvényes a type és az externalId mezőre a PATCH /v3/customers/{customerId}/recipients/{recipientId} kérésben. Az a PATCH, amely egyetlen általa felismert mezőt sem tartalmaz, 200 helyett 400 validation_error hibát ad vissza.
• Egy olyan jogosult munkamenet ellenőrző linkje, amely csak dokumentumokat kér, mostantól a Swipelux által hosztolt dokumentumfeltöltő oldalt nyitja meg. Maga a link nem változik, a többi munkamenet továbbra is a hosztolt ellenőrzési folyamatot nyitja meg.
• Az employment.occupation mező magánszemély ügyfeleknél és kapcsolt fél személyeknél legfeljebb 255 karaktert fogad el.
• A(z) POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} és POST /v3/customers/{customerId}/tasks/{taskId}/submissions végpontok 400 validation_error hibát adnak vissza, ha egy profilérték vagy feladatválasz Swipelux-űrlaplinket tartalmaz, például RFI-, ügyfélkérés- vagy átutaláskövetési linket. Ez nem vonatkozik az externalId és a metadata mezőkre. Minden elutasított érték megjelenik az errors[] tömbben code: public_form_link értékkel és a saját JSON Pointerével, és a válasz soha nem ismétli meg a linket. Ehelyett magát az információt küldje el. Lásd: Hibák és újrapróbálkozások.

​

Javítva

• A kifizetési árajánlat- és átutalás-válaszok az USDC vagy USDT forrásösszeget hat tizedesjegy pontossággal őrzik meg, például 4009.711365 és nem 4009.71. A fiat összegek két tizedesjegyet tartanak meg. Az olyan kifizetés létrehozása vagy lekérése, amelynek stablecoin forrásösszege kettőnél több tizedesjegyet tartalmaz, már nem ad vissza 500 választ.
• A POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel referencia mostantól a tényleges működésnek megfelelően írja le a visszavonást. Egy ready képesség visszavonható, a stablecoin_transfers képesség nem vonható vissza, és a visszavonás csak az adott képességet szünteti meg, a kérelmei pedig megtartják állapotukat, feladataikat és jóváhagyásaikat.
• Az a képességkérés vagy feladat-előnézet, amely az institutions mezőben nyilvános intézményazonosító helyett bankkódot ad meg, például citibank helyett citi értéket, 503 kyc_configuration_unavailable helyett 422 capability_institutions_unsupported választ ad vissza, amely megnevezi az elérhető azonosítókat.
• Az olyan módszerre vonatkozó képességkérés vagy feladat-előnézet, amelyet egyetlen bank sem kínál az ügyfélnek, és amelyet a támogatott lista disabled állapotúként mutat, 503 kyc_configuration_unavailable helyett 422 capability_variant_unavailable választ ad vissza retryable: false értékkel, kivéve, ha az ügyfél már rendelkezik az adott képességgel.
• A documentCandidates már nem sorolja fel azokat a fájlokat, amelyeket a Swipelux egy befejezett hosztolt ellenőrzésből megőriz, és amelyeket Ön nem olvashat és nem tölthet le. Az ilyen fájlra hivatkozó feladatválasz 400 invalid_document_reference hibát ad vissza, ugyanúgy, mint egy ismeretlen dokumentum.

​

Hozzáadva

• A GET /v3/customers elfogadja az include=documentRequirements paramétert. Ekkor minden ügyfélösszesítő jelzi, hány kötelező dokumentum hiányzik még, a képességek készenlététől függetlenül. Kombinálható így: include=capabilities,documentRequirements. Lásd: Ügyfelek.
• A kereskedői panel Webhooks oldalán a végpont menüje kiegészül a Replay missed events lehetőséggel. Ez újraküldi az elmúlt 13 nap azon eseményeit, amelyeket a végpont soha nem kapott meg, és ugyanazt az eseményt soha nem küldi el kétszer. Lásd: Webhookok.
• A kereskedői panel Settings oldala egy Compliance szakaszt kapott. A tulajdonosok és az adminisztrátorok beállíthatják a megfelelőségi e-mail-címet, és eldönthetik, kapnak-e e-mailt, amikor a Swipelux további információt kér egy ügyfélről.
• A kereskedők a kereskedői panel KYB oldalán közvetlenül válaszolhatnak a saját KYB megfelelőségi megkereséseikre.

​

Módosítva

• Az ügyfél- és kapcsoltfél-frissítések lezárt banki befogadás után már nem adnak vissza 409 field_conflicts_with_completed_intake választ. A frissítés mentésre kerül, és minden új banki kérelem a saját követelményei szerint ellenőrzi a legfrissebb profilt.
• A képességkérések 409 capability_route_header_conflict választ adnak vissza, ha egy képesség meglévő banki útválasztása nem frissíthető biztonságosan. Újrapróbálkozás előtt vegye fel a kapcsolatot a Swipelux ügyfélszolgálatával.
• A GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview 422 capability_institutions_unsupported választ ad vissza, ha az institutions olyan bankot ad meg, amelyet a képesség nem kínál, ahogy a képességkérések is.
• A sandboxban az ACH-, Wire- és SWIFT-képességeket kizárólag a JPMorgan Chase szolgálja ki. Az institutions mezőt elhagyó kérések a jpmorgan bankot választják, más bank megadása pedig 422 capability_institutions_unsupported választ ad vissza. Az éles útválasztás nem változik. Lásd: Tesztelés a sandboxban.
• Egy sandbox-képesség állapotának kényszerítése 409 capability_status_blocked választ ad vissza statusReason mezővel, ha a szimulált eset nem érheti el a kért állapotot. Egy már alkalmazott kényszerítés megismétlése változatlanul 200-at ad vissza. Lásd: Tesztelés a sandboxban.
• A POST /v3/sandbox/tasks/{taskId}/review 409 task_not_sandbox_reviewable választ ad az Operations vagy egy másik munkafolyamat tulajdonában lévő feladatra. A POST /v3/sandbox/tasks feladatai és a Swipelux által gyűjtött képesség-felvételi feladatok továbbra is ellenőrizhetők. Lásd: Tesztelés a sandboxban.
• A PATCH /v3/customers/{customerId}/accounts/{accountId} 409 account_provisioning_unresolved választ ad vissza, ha az elszámolást akkor módosítja, amikor a számla kiépítése a banknál még folyamatban van. Próbálja újra, miután a kiépítés lezárult. Lásd: Hibák és újrapróbálkozások.
• A POST /v3/transfers 409 quote_execution_evidence_conflict választ adhat vissza. Hozzon létre új árajánlatot, és hajtsa végre azt. Lásd: Hibák és újrapróbálkozások.
• A kereskedői panel Pay out fiókja megjeleníti a teljes célhely-adatokat, egy kapcsoló mögé rejti a számlaszámokat és a pénztárcacímeket, és minden fizetési módhoz becsült beérkezési időt mutat.
• A kereskedői panel a bankszámlákat az ügyfél Payment access lapjára vonja össze, egy feladatkártyával, amely megnevezi az egyes bankokat. A Documents lap a Profile alá került.
• Egy elnevezett bankszámla megnyitása a kereskedői panelen mostantól egyetlen lépés, amely felsorolja az egyes bankok pénznemét, módszereit és onboarding idejét. Lásd: Számlák.
• A felülvizsgálat miatt visszatartott bankszámlák On hold állapotúként jelennek meg a kereskedői panelen, a számlaazonosítóval és egy Contact support művelettel.
• Egy pending képesség mostantól review_in_progress helyett statusReason.code: preparing_submission értéket jelez, amíg a Swipelux benyújtásra készít elő egy kérelmet, és nincs folyamatban felülvizsgálat. Mindkét kód resolution: wait értéket használ. A kettő közötti váltás pending állapotban hagyja a státuszt, így nem küld capability.status_changed eseményt. A meglévő képességek a következő újraértékelésükkor veszik fel az új kódot. Lásd: Képességek és követelmények.
• A kereskedői panelen az ügyfél Payment access lapján található Shared methods táblázat In review helyett In preparation értéket mutat az olyan közös módszernél, amelynek képessége preparing_submission értéket jelez.
• Egy képesség applications listája mostantól csak az aktuális kérelmeit mutatja a képességlekérdezésekben (beleértve: GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), a képességkérésekre adott válaszokban és a capability.status_changed eseményekben. Egy újabbal lecserélt kérelem továbbra is megjelenik a GET /v3/customers/{customerId}/applications listában, ahol a supersededByApplicationId megnevezi az utódját. A lecserélt kérelem nyitott feladatai továbbra is beleszámítanak a képesség openTaskIds értékébe. A képesség státusza és openTaskIds értéke nem változik, így maga a változás nem küld webhook eseményt. Lásd: Képességek és követelmények.

​

Javítva

• Ugyanarra a kibocsátott számlára vonatkozó második, a bank jóváhagyása előtt küldött allowPending kérés 500 helyett 409 választ ad vissza, amely a holder.accountId mezőben megnevezi a várakozó számlát. Lásd: Bankszámla kibocsátása.
• Egy képesség visszavonása mostantól lezárja a még banki jóváhagyásra váró kibocsátottszámla-kéréseket, így egy későbbi kérés ugyanannál a banknál tiszta lappal indul.
• Egy olyan visszavont képesség újbóli kérése, amelynek minden banki ügyét elutasították, egyetlen capability.status_changed eseményt tesz közzé a canceled állapotból.
• Egy bank újbóli kérése a korábbi kérelem archiválása után mostantól beküldi az új kérelmet.
• A címzetti célhelyek mostantól hozzáadhatók, amint a megfelelő képesség ready állapotú, ahelyett hogy 409 rail_not_ready választ adnának vissza. Lásd: Címzettek.
• A kereskedői panel Webhooks oldalának első megnyitása előtt küldött webhook-események mostantól megmaradnak, így újrajátszhatja őket egy új végpontra.
• A kereskedői panelen a feladatok határidői az Ön saját időzónájában jelennek meg, a banki felülvizsgálati fiókok pedig All requirements submitted jelzést mutatnak, ha már nincs nyitott tétel.

​

Hozzáadva

• A POST /v3/quotes mostantól opcionális institutionId paramétert fogad el, amellyel jóváhagyott banki útvonal választható egy kripto–fiat kifizetési árajánlathoz. Hagyja el az automatikus útvonalválasztás megtartásához. Olyan bank megadása, amely nem érhető el a kifizetéshez, 422 bank_not_supported_for_customer választ ad vissza, míg az institutionId bármely más árajánlattípussal való küldése 400 validation_error választ eredményez. Lásd: Pénz küldése.
• A POST /v3/customers/{customerId}/accounts végponton a kibocsátott bankszámlára vonatkozó kérések elfogadják az institution mezőt, amellyel a számla tartalék nélkül egyetlen bankhoz rögzíthető, valamint az allowPending: true értéket, amellyel a kérés akkor is menthető, ha az adott banknál a kérelem még jóváhagyásra vár. Az allowPending használatához az institution megadása kötelező. A mentett kérések visszaadják az irányadó applicationId azonosítót. Lásd: Bankszámla kibocsátása.
• A kereskedői panel natív Webhooks oldallal rendelkezik a végpontok kezeléséhez. Lásd: Webhookok.
• A kereskedői panel egy Pay in fiókot kapott elnevezett bankszámlákkal, kriptobefizetésekkel és egy áttekintési lépéssel.
• A kereskedői panel Pay out folyamata megjeleníti a pénztárca-egyenlegeket a forrásválasztóban, Max összegopciót kínál, és áttekintési lépést is tartalmaz.
• A kereskedői panelen az ügyfélprofilok Recipients & destinations lapot kaptak.
• A feladatkövetelmények tartalmazhatnak egy rövid title címsort. Az útmutatást továbbra is a kérés prompt mezője hordozza. Lásd: Képességek és követelmények.

​

Módosítva

• A közös (pooled) Wire-útvonalakon a Wire pay-in árajánlatokhoz mostantól legalább 20 USD szükséges. Az útvonal minimumánál kisebb, illetve az átutalási díjak fedezésére túl kicsi összegű árajánlatok általános árajánlat-hiba helyett 422 amount_not_deliverable választ adnak vissza. Lásd: Pénzeszközök fogadása.
• A webhook-portál mostantól erőforrás szerint csoportosítja a v3 eseménytípusokat, és megjeleníti az egyes események payload-sémáját, valamint egy példát. A régi eseménytípusok egy külön Legacy csoportban jelennek meg, elavultként megjelölve. Az ezekre már feliratkozott végpontok továbbra is megkapják őket; új feliratkozásokhoz használjon v3 eseménytípusokat. Lásd: Webhookok.
• A sandbox-feltöltések mostantól transfer.created és transfer.state_changed webhook-eseményeket küldenek. Lásd: Tesztelés a sandboxban.
• Az accountProvisioning mostantól issued értéket jelez, ha az ügyfélnek már van aktív kibocsátott számlája. Lásd: Képességek és követelmények.
• A kereskedői panelen a bankszámlák adatai egy fiókban nyílnak meg banklogókkal. Lásd: Számlák.
• A kereskedői panel a pénzmozgásokat Pay in és Pay out címkével jelöli, hat órán át bejelentkezve tartja Önt, és a segítségkéréseket e-mailben továbbítja a Swipelux ügyfélszolgálatának.
• A közvetlen beküldést elfogadó befogadási feladatokban az ügyfélprofillal vagy feltöltött dokumentumokkal már alátámasztott, jogosult követelmények automatikusan in_review állapotba kerülnek. Lásd: Képességek és követelmények.

​

Javítva

• Egy visszavont képesség újbóli kérése már nem hiúsul meg a felváltott kérelemrekordok vagy az elavult követelmények miatt.
• A megszűnt Fedwire-azonosító alatt tárolt képességek mostantól wire értékként olvashatók, ahelyett hogy 500-at adnának vissza.

​

Hozzáadva

• A GET /v3/customers/{customerId}/applications listázza egy ügyfél kérelemügyeit az egyes ügyekhez kért képességekkel, valamint azokkal a képességekkel együtt, amelyeket az adott ügy jóváhagyása lefed. Egy banknál adott egyetlen jóváhagyás több képességet is lefedhet. A megőrzött korábbi ügyek a supersededByApplicationId mezőn keresztül hivatkoznak utódjukra. A lista támogatja a kurzoralapú lapozást és az updatedAfter paramétert. Lásd: Képességek és követelmények.
• A POST /v3/customers/{customerId}/capabilities/{capabilityId} válaszai kérelemügyhöz kötött képességek esetén tartalmazzák a selectedApplicationId mezőt. Ez azonosítja azt a meglévő kérelemügyet, amelyet a kérés újrahasznált, vagy azt az ügyet, amelyet megnyitott. Lásd: Képességek és követelmények.
• A GET /v3/institutions és a támogatott képességek listája által visszaadott intézmények tartalmaznak egy null értéket is felvehető logoUrl mezőt. Használja a bank arculatának megjelenítésére, ha elérhető, és ha null, jelenítse meg helyette az intézmény nevét. Lásd: Képességek és követelmények.
• Mostantól elérhetők az USD SWIFT-kifizetések. A SWIFT-kifizetésekhez legalább 100 USD szükséges. A kereskedői panel SWIFT banki utasításokat gyűjt a címzettekhez. Lásd: Pénz küldése.
• A kibocsátott bankszámlák névre szóló fogadási adatokkal SWIFT-en keresztül is fogadhatnak pénzt. Lásd: Bankszámla kibocsátása.
• Az USDT mostantól forrásként támogatott ACH- és Wire-kifizetésekhez. Lásd: Pénz küldése.
• A kibocsátott bankszámlák elfogadják a USDC vagy USDT értékű settlement.currency mezőt, amellyel kiválasztható az elszámolási pénztárcába érkező stablecoin, a pénztárcaszámla pénznemétől függetlenül. Hagyja el, ha továbbra is a pénztárca pénznemében szeretne elszámolni. Lásd: Bankszámla kibocsátása.
• A SWIFT-bankszámlák és a címzetti célhelyek elfogadják a bankCity, bankState, bankPostalCode és bankAddressLine2 mezőket, valamint az opcionális beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode mezőket és a közvetítő bank adatait. Lásd: Pénz küldése.
• A kibocsátott bankszámlák adatai tartalmazzák az achRoutingNumber és wireRoutingNumber mezőket, ha a bank külön ACH és Wire routing számot ad meg, valamint a fogadó bank bankLogoUrl mezőjét. Lásd: Bankszámla kibocsátása.
• A capability.created webhook-események tartalmazzák az applicationId mezőt és egy requested vagy approval értékű origin mezőt, így megkülönböztetheti az Ön által kért képességeket azoktól, amelyeket egy jóváhagyás fedett le. Lásd: Webhookok.
• A követelménykérések megadhatnak egy constraints.format érvényesítési formátumot, például http_url, us_ssn, us_ein vagy bank_industry_classification. Lásd: Képességek és követelmények.

​

Módosítva

• A kereskedői panelen a bankszámla létrehozása mostantól a bank kiválasztásával kezdődik, és a bankszámlák külön ACH és Wire routing számokat jelenítenek meg. Lásd: Számlák.
• A network enum mostantól tartalmazza a solana értéket. Ez nyitott enum, ezért kezelje hibatűrően a nem ismert hálózati értékeket. Lásd: Számlák.
• Ha olyan feladathoz nyit meg hosztolt ellenőrzési linket, amelynek hátralévő követelményei közvetlen beküldést igényelnek, a válasz 409 verification_session_not_allowed. Ezeket a követelményeket helyette feladatbeküldésként küldje be. Lásd: Hibák és újrapróbálkozások.
• Egy olyan kibocsátott számla archiválása, amelynek kiépítése még nem zárult le, 409 account_provisioning_unresolved választ ad vissza. Próbálja újra, miután a kiépítés lezárult. Lásd: Hibák és újrapróbálkozások.
• Az új elnevezett bankszámla-kérések a számla létrehozásakor azonnal bekerülnek a kiépítési sorba, ahelyett hogy az ügyfél következő frissítésére várnának. Lásd: Bankszámla kibocsátása.

​

Eltávolítva

• Az új számlákhoz már nem kínálunk közös (pooled) SWIFT fogadási adatokat. Használjon helyettük névre szóló SWIFT fogadási adatokat. Lásd: Bankszámla kibocsátása.

​

Javítva

• A kifizetési átutalások lekérése mostantól az árajánlatban szereplő címzettet adja vissza.
• Egy meglévő ACH-számla archiválása után egy új ACH-számla létrehozása már nem ad vissza 409-et, és az archivált, függőben lévő számlakérések már nem foglalnak számlahelyet.
• A helyi pénznemű pay-in árajánlatok banki díjai a megfelelő fiat pénznemben jelennek meg.

​

Hozzáadva

• A GET /v3/webhooks/{webhookId} egyetlen webhook-végpontot és annak events kiválasztását kérdezi le. Lásd: Webhookok.
• A feladatkövetelmények mostantól közzéteszik az allowedValues értékeket és egy JSON Schema valueSchema sémát a profilmezőkhöz, beleértve a kötelező címmezőket is. Az országmezők valueType vagy itemValueType értéke country, ami ISO 3166-1 alpha-2 kódot jelent. A beviteli mezőket és választási lehetőségeket így beégetés nélkül jelenítheti meg. Lásd: Képességek és követelmények.
• A meglévő Tron-pénztárcák mostantól USDT-t küldhetnek az ügyfél külső pénztárcaszámláira, az átutalások lekérése pedig a Tron-tranzakciókhoz blokklánc-böngészőre mutató hivatkozást tartalmaz. A Tron hálózaton nem bocsátható ki új pénztárca. Lásd: Pénz küldése.
• A feladatkövetelmények megadhatják a requiredWhen (csak akkor kell megválaszolni, ha egy megnevezett igen/nem válasz egyezik), a profileAssertion (us_person) és az ownershipPolicy mezőt, a dokumentumkérések pedig beállíthatják az identityMetadataRequired és a maxIssueAgeDays mezőt. A feladatválaszok a hivatkozott dokumentumokhoz elfogadják a documentMetadata (idNumber, issuingCountry, issuedOn) mezőt, a feladatok lekérése pedig a conditionValues mezőben adja vissza az ellenőrzött, meghatározó válaszokat. Lásd: Képességek és követelmények.
• A dokumentumkövetelmények felsorolhatnak acceptedDocumentSets készleteket, a kapcsolt félre vonatkozó követelmények pedig a beneficial_owner mellett associated_person vagy control_person minősítést is kérhetnek. Lásd: Képességek és követelmények.
• Az átutalások correction objektumai mostantól a sikertelen, fedezettel ellátott kifizetésekre is kiterjednek: kind: funding_failure recover_source_funding kompenzáló művelettel, unknown vagy reported értékű recoveryStatus mezővel és USDT jóváírt kimenetekkel. Lásd: Árajánlatok és átutalások.

​

Módosítva

• A PATCH /v3/webhooks/{webhookId} mostantól elfogadja azokat a régi eseménytípusokat, amelyekre a végpont már fel van iratkozva, így megtarthatja őket, miközben v3 eseménytípusokat ad hozzá. Az events a teljes kiválasztást lecseréli, ezért adjon meg minden eseménytípust, amelyet meg szeretne tartani. Ha olyan régi eseménytípust ad hozzá, amellyel a végpont korábban nem rendelkezett, 400 validation_error a válasz. Lásd: Webhookok.
• A címzettek és számlák banki azonosítóit mentés előtt ellenőrizzük. Lásd: Címzettek.
• A képességkérések, a feladatbeküldések és a sandbox-állapotmódosítások mostantól 409 capability_application_stale választ adnak vissza 500 helyett, ha a képességet egy korábbi onboarding-modell szerint hozták létre. Lásd: Hibák és újrapróbálkozások.
• A nyilvános RFI-oldal mostantól egyetlen folyamatos űrlap. Támogatja a kapcsolt személyeket, és személyenként egy adóazonosítót gyűjt. Lásd: Dokumentumkövetelmények.
• Az árajánlatok és átutalások 409 customer_bank_limit_exceeded választ adnak vissza, ha egy fizetés meghaladja az ügyfél banknál fennmaradó napi vagy havi keretét, és 503 customer_bank_limits_unavailable választ, ha ez a keret nem ellenőrizhető. Az átutalások 409 payout_execution_unavailable választ adnak vissza, ha egy kifizetés nem indítható el az árajánlatából. Lásd: Hibák és újrapróbálkozások.
• A lezárt banki befogadással ütköző ügyfél- és kapcsoltfél-frissítések 409 field_conflicts_with_completed_intake választ adnak vissza a taskId és a fields mezőkkel.

​

Javítva

• A visszavont képességek előzményei továbbra is olvashatók.
• A wire-kifizetések helyesen jelennek meg és szűrhetők a kereskedői panel tranzakciólistájában.

​

Módosítva

• A POST /v3/transfers és az átutalás olvasása a kártyás checkout előválasztásához a paymentMethod helyett a checkoutMethod mezőt használja, és elfogadja a card, apple_pay, google_pay, cash_app, sepa és blik értékeket. A lista nyitott és bővülhet. A paymentMethod már nem ismert; az azt továbbra is küldő kéréseket úgy kezeli a rendszer, mintha kimaradt volna. A sepa és a blik a kártyás checkouton belüli fizetési lehetőségek, nem Swipelux-képességek. Lásd: Pénzeszközök fogadása.

​

Hozzáadva

• A POST /v3/transfers kártyás árajánlatokhoz elfogad egy opcionális paymentMethod értéket: card, apple_pay vagy google_pay. A hosted checkout a kért módszerrel nyílik meg, ha az elérhető az ügyfél és az eszköze számára, az átutalás olvasása visszaadja a kérést, az árajánlat összegei és díjai pedig változatlanok maradnak. Lásd: Pénzeszközök fogadása.
• A GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview elfogadja az institutions paramétert, amellyel előnézetben megtekinthetők a támogatott képességek listája által visszaadott konkrét bankok feladatai. Lásd: Képességek és követelmények.

​

Módosítva

• A kártyás árajánlatok mostantól tükrözik a fizetési díjakat és a ténylegesen jóváírt nettó USDC-összeget. Lásd: Pénzeszközök fogadása.
• Az elutasított kifizetési árajánlatok általános hiba helyett konkrét problémakódot adnak vissza: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported vagy quote_failed, illetve 503 quote_temporarily_unavailable választ, ha az árajánlat később újrapróbálható. Lásd: Hibák és újrapróbálkozások.

​

Javítva

• A kártyás árajánlatok már nem hiúsulnak meg a díjak kerekítése miatt.
• Egy hosztolt KYC-link újbóli megnyitása már nem ad vissza 409 kyc_process_conflict hibát, ha a kérdőív válaszai extra szóközöket tartalmaznak.
• A kereskedői panelen az elakadt passkey-alapú kifizetés-megerősítések mostantól helyreállnak.

​

Hozzáadva

• A POST /v3/customers/{customerId}/documents mostantól application/json kéréstörzset is elfogad storageKey, fileName és type mezőkkel. A storageKey-nek friss, ügyfél-hatókörű hivatkozásnak kell lennie, amelyet a korábbi direct-upload folyamaton keresztül parkoltak, és a feltöltés ugyanazon a méret- és fájlaláírás-ellenőrzésen megy át, mint a multipart feltöltések. Lásd: Migrálás v3-ra.
• A GET /v3/customers/{customerId}/documents/{documentId}/download letöltési url-t ad vissza egy aktív ügyféldokumentumhoz. Az URL egy óra után lejár, és a fájlt mellékletként szolgálja ki. Az archivált, ismeretlen és más ügyfélhez tartozó dokumentumok 404-et adnak vissza. Lásd: Képességek és követelmények.
• Ha tényleges tulajdonos nélküli vállalkozáshoz kér képességet, az mostantól befogadási feladatot hoz létre a tulajdonos hozzáadására, ahelyett hogy 503 hibával meghiúsulna. A nem folytatható kérések 422 beneficial_owner_required választ adnak vissza, útmutatással egy bejelentett vagy legalább 25%-os tulajdonrésszel rendelkező egyéni kapcsolt fél hozzáadásához. Lásd: Részvényesek, UBO-k és irányító személyek.
• A kereskedői panel feladattáblázata mostantól megjeleníti minden kérés alanyát és képességkörét, így látható, kire és mire vonatkozik egy megfelelőségi kérés. Lásd: Képességek és követelmények.
• Az iparági besorolási mezők a kereskedői panelen mostantól kereshető NAICS-kódokat kínálnak az ügyfélprofilokon és a követelményfeladatokon. Lásd: KYB-munkafolyamat.
• A banki pay-in utasítások tartalmazhatják a bankName, bankAddress, accountHolderName és accountHolderAddress mezőket. Jelenítse meg ezeket a többi banki adattal együtt. Lásd: Pénzeszközök fogadása.
• A POST /v3/transfers opcionális redirectUrl paramétert fogad el, amely a kártyás vagy Apple Pay hosztolt fizetés után visszairányítja az ügyfelet az alkalmazásába. Az URL elérése nem igazolja a befejezést; ehhez használja az átutalások lekérését vagy a webhookokat. Lásd: Pénzeszközök fogadása.
• A v3 Rule által létrehozott átutalások origin: rule értékkel jelennek meg az átutalások lekérésében és listáiban, és a többi átutaláshoz hasonlóan transfer.state_changed eseményeket küldenek. Szűrje őket a GET /v3/transfers?origin=rule kéréssel. Lásd: Árajánlatok és átutalások.
• Az ügyfelek és kapcsolt felek személyazonosító dokumentumai elfogadják a sideApplicability mezőt (front_only, front_and_back vagy unknown), a feladatok pedig válaszként gyűjthetik a személyazonosító dokumentum adatait, például a type, number, issuingCountry, issuingRegion, issuedOn, expiresOn és doesNotExpire mezőket. Lásd: Képességek és követelmények.

​

Módosítva

• A folyamatban lévő banki beállítással ütköző bankadat-beküldések mostantól 409 ops_rail_handoff_conflict választ adnak vissza. Őrizze meg a feltöltött dokumentumazonosítókat, és az ütközés feloldása után küldje be újra ugyanazt a beküldést a dokumentumok ismételt feltöltése helyett. Lásd: Hibák és újrapróbálkozások.
• Az ügyfélpénztárcákba érkező, előre nem jelzett stablecoin-befizetések minimuma mostantól 10 helyett 1 egység. A kisebb befizetéseket továbbra is pornak (dust) tekintjük. Lásd: Pénzeszközök fogadása.
• A webhook-konfiguráció mostantól környezetenként elkülönített. A webhook-portál abban a környezetben nyílik meg, amelyből kérte, így a sandbox és a production végpontok már nem osztoznak a beállításokon. Lásd: Webhookok.
• A kereskedői panel mostantól az ügyfél v3 képességeiből származtatja az elérhető pay-in módszereket, így a számlabeállítás csak azokat a módszereket kínálja, amelyekre az ügyfél jogosult. Lásd: Számlák.
• Az RFI-űrlapok mostantól rövidebb, egyértelműbb kérdésekkel gyűjtik a minősülő tényleges tulajdonosokat, és az RFI-előzmények életciklus-mérföldkövekként jelennek meg. Lásd: Dokumentumkövetelmények.
• A kifejezett határidő nélküli nyitott feladatoknál a dueAt alapértéke mostantól a létrehozást követő 31. nap. Lásd: Képességek és követelmények.

​

Eltávolítva

• A kereskedői panel új pay-in módszerek hozzáadásakor már nem kínálja a Fedwire-t. A meglévő Fedwire-számlák továbbra is lekérhetők. Lásd: Számlák.

​

Javítva

• Az ügyfélpénztárcákba érkező, előre nem jelzett USDT-befizetéseket mostantól felismerjük és elszámoljuk, ahelyett hogy figyelmen kívül maradnának.
• A már beküldött bizonyítékok mostantól átkerülnek az ugyanazt az elemet igénylő többi feladatba, így az ügyfeleknek nem kell kétszer benyújtaniuk ugyanazt a dokumentumot.
• Egy képesség újbóli kérése már nem dobja el a már kész banki útvonalakat, így a kibocsátott számlaadatok stabilak maradnak.
• A banki utasításnézetek a kereskedői panelen mostantól teljes részleteket mutatnak, beleértve a SWIFT-címeket és a célpénztárca címét.
• Az RFI-űrlapok mostantól megjelenítik a beküldési érvényesítési hibákat, beküldés előtt érvényesítik a jogi forma leírását, és több üzleti webhelyet is elfogadnak.
• Az RFI-űrlapokon a kapcsolt személyek piszkozatai mostantól beküldés előtt szerkeszthetők.
• A visszavont megfelelőségi kérések már nem jelennek meg a kereskedői panel feladatlistájában.
• A dokumentum-ellenőrzési állapotok ismét helyesen jelennek meg a kereskedői panelen.

​

Hozzáadva

• Az ügyfélhez kötött hosztolt ellenőrzési és Szolgáltatási feltételek munkamenetek mostantól mérvadó action objektumot tartalmaznak. Kövesse annak available vagy unavailable típusát; a felső szintű url és expiresAt mezők kompatibilitási tükörként megmaradnak az elérhető műveleteknél. Lásd: Képességek és követelmények.
• A sandbox pénztárcafeltöltései mostantól olyan átutalási azonosítót adnak vissza, amelyet a GET /v3/transfers/{transferId} végponton lekérhet, vagy a GET /v3/transfers végponton listázhat. Befejezett bejövő stablecoin-befizetésként jelennek meg. Lásd: Tesztelés a sandboxban.
• Az átutalások lekérése correction objektumot tartalmaz, ha egy átutalás pénzeszközeit a befejezése után visszaküldik vagy sztornózzák. Ez jelzi a korrekció kind típusát, a normalizált providerStatus állapotot, az esetleges providerShortfall hiányt és a Swipelux által alkalmazott compensatingIntent műveletet. Lásd: Árajánlatok és átutalások.

​

Módosítva

• A kereskedői panel kártyás és Apple Pay First pay-in útmutatója mostantól Polygon-pénztárcát igényel az ügyfélnél. Hozza létre a pénztárcát az útmutató megkezdése előtt. Lásd: Számlák.
• Az új kérések és nyilvános válaszok a sepa értéket használják a módszer és a képesség kanonikus neveként. A sepa_instant bemeneti álnév és a korábban tárolt erőforrások kompatibilisek maradnak, de a nyilvános válaszok sepa értéket adnak vissza. Lásd: Számlák.
• Az új Faster Payments képesség-, kibocsátott számla- és árfolyamajánlat-kérések nem érhetők el. A meglévő számlák, ajánlatok és átutalások továbbra is lekérhetők. Lásd: Számlák.
• A KYB első oldala már nem gyűjti a képviselő születési dátumát. A részvényesek születési dátuma továbbra is külön követelmény. Lásd: KYB-munkafolyamat.
• Az RFI dokumentumhivatkozások mostantól az image/jpeg mellett az image/jpg MIME-álnevet is elfogadják. Lásd: Dokumentumkövetelmények.
• A kereskedői panel feladatelőzményei mostantól verziószámlálók nélkül, olvasható auditnaplóként jelennek meg. Lásd: Képességek és követelmények.
• Az árajánlatok és átutalások mostantól minden pénzmozgás előtt ellenőrzik a képesség által támogatott irányokat. Ha egy képességet olyan irányban használ, amelyet az nem támogat, a válasz 422 capability_direction_unsupported, a pénztárcák közötti mozgatásokhoz pedig stablecoin_transfers képesség szükséges. Lásd: Hibák és újrapróbálkozások.

​

Eltávolítva

• A kereskedői panel már nem kínál új UAEFTS-számlabeállítást. A meglévő UAEFTS-számlák továbbra is lekérhetők. Lásd: Számlák.

​

Javítva

• Az RFI-űrlapok megtartják a meglévő bejegyzéseket, amikor egy ellenőr új dokumentumfeltöltést ad hozzá, így a korábbi válaszok nem vesznek el az újbóli beküldéskor.
• A kereskedői panel az elérhető műveletekből folytatja a hosztolt megfelelőségi munkameneteket anélkül, hogy eldobná az érvényes hivatkozásokat.
• A hosztolt Szolgáltatási feltételek hivatkozásai mostantól az API által visszaadott minden feladatkörben működnek.
• Miután Payment Access hozzáférést kér a kereskedői panelen, az a kérés által visszaadott befogadási feladatot nyitja meg egy korábbi kérés feladata helyett.
• A kereskedői panel KYB-bemutatója mostantól az aktuálisan kötelező mezőket kéri.
• Ha egy ajánlat a forráspénztárcát destinationId értékként is felhasználja, a szolgáltatói műveletek megkezdése előtt használható 422 quote_direction_invalid részleteket ad vissza. Lásd: Ajánlatok és átutalások.
• Az API a hibásan kódolt lekérdezési karakterláncot 400 hibával utasítja el a kérés csendes normalizálása helyett. Lásd: Hibák és újrapróbálkozások.
• A POST /v3/customers/{customerId}/documents mostantól 400 hibával utasítja el az üres, nem multipart vagy hibás formátumú kéréstörzseket.

​

Hozzáadva

• Az OpenAPI specifikációban közzétettük a v3 Problem Details katalógust, így az integrátorok közvetlenül a sémából tudják megfeleltetni a hibaválaszokat. Lásd: Hibák.
• A customerId mezőt hozzáadtuk a v3 számla webhook eseményekhez, így egy utólagos olvasás nélkül is összekapcsolhatod a számlatevékenységet a tulajdonos ügyféllel. Lásd: Webhookok.
• Teljes V3 egyéni profil mezőlefedettség a kereskedői panelen, hogy az onboarding operátorok minden, a v3 API-n keresztül gyűjtött KYC mezőt áttekinthessenek és szerkeszthessenek. Lásd: Ügyfelek onboardingja.
• Közzétettük a v3 fejlesztői migrációs útmutatót. Lásd: Migrálás v3-ra.

​

Módosítva

• Az ügyfél- és számlaországkódokat írási időben immár hozzárendelt ISO 3166-1 alpha-2 értékként érvényesítjük. Az olvasások tolerálják a korábban tárolt értékeket, így a meglévő rekordok továbbra is feloldhatók. Lásd: Számlák és tárcák.
• A USDC elérhetőségét ezentúl a célhálózat határolja be, így az árajánlatok és átutalások csak azokon a hálózatokon kínálnak USDC-t, amelyeket a cél ténylegesen támogat.
• Mostantól minden onboarding-folyamat megköveteli a Swipelux Szolgáltatási feltételeit. A meglévő munkamenetek továbbra is folytathatók. Lásd: Ügyfelek onboardingja.
• A Capability.ready továbbra is a jogosultság jóváhagyását jelzi. A számla kiadását az accountProvisioning mezővel kövesd not_applicable, not_started, in_progress, issued vagy failed értékként. Lásd: Képességek és követelmények.
• Az iPhone-ról feltöltött HEIC fájlokat immár elfogadjuk személyazonossági és címigazoló dokumentumként.
• Ha egy nyitott feladat által még megkövetelt ügyfél- vagy kapcsoltfél-mezőt töröl, a válasz mostantól 409 field_required_by_open_task a blokkoló taskId és fields értékekkel, újrapróbálható ütközés helyett. A mezők módosítása előtt fejezze be vagy vonja vissza a feladatot. Lásd: Hibák és újrapróbálkozások.

​

Javítva

• Egy elhasznált árajánlat újbóli végrehajtása mostantól 409 quote_execution_consumed választ ad általános hiba helyett. Lásd: Árajánlatok és átutalások.
• Az átutalási lista olvasások és az árajánlat összeg olvasások nagy múltbeli eredményhalmazokon már nem adnak 500-as hibát.
• Az egyidejű KYC-átirányítások mostantól ütközést adnak vissza 404 helyett, így az újrapróbálkozások tisztán feloldódnak. A hosztolt átirányítások már nem gördülnek vissza félúton, és a KYC-linkek folytathatók maradnak.
• Az egyéni ügyfelekhez tartozó kapcsolt felek olvasása már nem ad 404-et.
• Az érvénytelen tárcamezőket tartalmazó KYB-beküldéseket még a beküldés előtt elutasítjuk, és a sikertelen szinkronizálást a kereskedői panel már nem jelenti sikerként.
• A követelményfeladatok a kereskedői panelen mostantól befejezettként mutatják a beküldött válaszokat, külön követik a feltételekkel kapcsolatos műveleteket, eltávolítják az ismétlődő dokumentumszöveget, a megkezdett KYC-munkameneteket a befejezésig függőben tartják, és az elavult feladatokat a követelmény nézet megtörése nélkül kezelik.
• Az ellenőrzési linksorok a kereskedői panelen mostantól minden soron megjelenítenek egy Open műveletet, és minden feladatlink megjelenik a követelmény nézetben.