Swipelux API Changelog und Versionshinweise

​

Hinzugefügt

• Empfängerziele akzeptieren die Typen pix und pix_safe für BRL-Payouts in Brasilien. Ein Pix-Ziel zahlt an einen Pix-Schlüssel. Ein Pix Safe-Ziel zahlt an ein Bankkonto, das über die CPF oder CNPJ des Inhabers, den ISPB-Code der Bank, die Filiale und die Kontonummer identifiziert wird. Beide benötigen die bereite Pix-Fähigkeit des Kunden (pix_pooled), und ihre Payouts werden mit USDC finanziert und enthalten keine Entwicklergebühr. Siehe Empfänger und Gelder senden.
• GET /v3/customers/{customerId}/tasks/{taskId} akzeptiert documentCandidatesFor mit einer Dokumentanforderungs-ID sowie documentAlternativeKey für eine Anforderung mit Alternativen. Die Antwort listet dann in data.documentCandidates Dateien auf, die der Kunde bereits hochgeladen hat und die diese Anforderung erfüllen können, mit etwaigen missingMetadata oder conflictingMetadata. Übermitteln Sie die documentId eines Kandidaten mit den fehlenden documentMetadata, statt die Datei erneut hochzuladen. Die Abfrage benötigt accounts:read und customers:read, und eine ungültige Auswahl gibt 400 validation_error zurück.

​

Geändert

• GET /v3/webhooks/portal gibt eine Portal-URL zurück, die nach einer Stunde abläuft, mit Cache-Control: no-store. Mit einem API-Schlüssel, der webhooks:write hat, zeigt das Portal das Signaturgeheimnis des Endpunkts an und kann Endpunkte verwalten sowie Zustellungen wiederholen und erneut abspielen. Mit nur webhooks:read zeigt das Portal ausschließlich Zustellungen an. Siehe Webhooks.
• Citi (citibank) wird nur Geschäftskunden angeboten. Jedes Unternehmen behält gepooltes Citi, und benanntes Citi wird nur Unternehmen angeboten, die außerhalb der USA registriert sind. Wenn einem Kunden Citi nicht angeboten wird, lässt die Liste der unterstützten Banken es weg, die Angabe gibt 422 capability_institutions_unsupported zurück, und eine Methode, die nur Citi anbietet, wird als disabled aufgeführt. Eine Anfrage ohne institutions wählt unter den verbleibenden Banken. Bestehende Anträge und Konten bleiben unverändert.
• Benannte CFSB-Fähigkeiten (cfsb) werden nur US-Kunden angeboten: in den USA registrierten Unternehmen und Privatpersonen, die dort wohnen. Für andere Kunden lässt die Liste der unterstützten Banken benanntes CFSB weg, und die Angabe gibt 422 capability_institutions_unsupported zurück. Eine Anfrage ohne institutions wählt unter den verbleibenden Banken. Gepooltes CFSB, Kunden mit unbekanntem Land und bestehende Anträge bleiben unverändert.
• Benannte ACH-, Wire- und SWIFT-Fähigkeiten von Lead Bank (lead_bank) werden nur Kunden angeboten, die Lead Bank aufgrund ihrer Rechtsform und Länder onboarden kann. Für andere Kunden lässt die Liste der unterstützten Banken lead_bank weg, und die Angabe gibt 422 capability_institutions_unsupported zurück. Kunden, die Lead Bank bereits onboardet hat, und Fähigkeiten, deren offene Anfrage bereits lead_bank nennt, behalten es. Bestehende Anträge und Konten bleiben unverändert.
• RTP ist nur gepoolt verfügbar. Keine Bank bietet rtp_named für neue Anfragen an, daher führt die Liste der unterstützten Banken es als disabled auf. Für einen Kunden, der rtp_named nicht besitzt, gibt eine Fähigkeitsanfrage oder Aufgabenvorschau dafür, die eine Bank nennt, 422 capability_institutions_unsupported zurück, und eine ohne institutions gibt 422 capability_variant_unavailable zurück. Gepooltes RTP (rtp_pooled) wird bei Citi angeboten, daher können es nur Geschäftskunden anfragen.
• Neue Anfragen nach Ausweisdokumenten für Privatpersonen und wirtschaftlich Berechtigte können constraints.identityMetadataRequired: true setzen, sodass jede Datei ihre Ausweisnummer und ihr Ausstellungsland in documentMetadata benötigt. Neue Anfragen nach Adressnachweisen für Unternehmen und Wohnsitznachweisen für Inhaber können constraints.maxIssueAgeDays: 90 setzen, sodass jede Datei ihr Ausstellungsdatum benötigt. Bestehende Aufgaben behalten ihre Anforderungen, lesen Sie daher die Einschränkungen jeder Aufgabenanfrage.
• Eine Aufgabenantwort auf eine Anfrage zur Unternehmensregistrierung, deren profilePointer /business/registration ist, benötigt das Land der Rechtsordnung, die Registernummer und ein Gründungsdatum vor dem Einreichungsdatum, alle zusammen. Das valueSchema der Anfrage veröffentlicht diese Regel, und eine unvollständige Antwort gibt 400 validation_error zurück.
• Nach einer gehosteten Verifizierung akzeptiert Swipelux eine gehostete Antwort auf eine Profilanforderung für einen strukturierten Wert, etwa eine Adresse oder Steueridentifikationsnummern, nur dann, wenn sie dieselben Schema- und Einschränkungsprüfungen besteht wie eine direkte Antwort. Andernfalls bleibt die Anforderung offen, und Sie reichen diesen Wert mit POST /v3/customers/{customerId}/tasks/{taskId}/submissions ein. Eine Anforderung, die Swipelux aus diesem Grund auf action_required zurücksetzt, trägt reviewFeedback.code: hosted_profile_direct_submission_required. Aufgaben, die bereits satisfied sind, behalten ihren Status. Siehe Funktionen und Anforderungen.
• Eine durch eine gehostete Verifizierung abgelehnte Aufgabe kann rejected verlassen, wenn diese Verifizierungsentscheidung später aufgehoben wird. Sie wird dann satisfied oder unter einer neuen revision action_required, wobei die Anforderungen, die die neue Entscheidung nicht beantwortet, wieder geöffnet werden. Frühere Einreichungen für diese Anforderungen bleiben rejected, reichen Sie diese Antworten daher erneut ein. Siehe Migration zu v3.
• Der type von Empfängerzielen ist jetzt ein offenes Enum. Frühere Versionen dieser Referenz beschrieben ihn als geschlossen, aktualisieren Sie daher jeden Client, der unbekannte Typen ablehnt oder verwirft. Zielantworten und destination.status_changed-Ereignisse können jetzt pix und pix_safe enthalten, und weitere Typen können hinzukommen.
• Anfragen zum Erstellen und Aktualisieren von Empfängern, einschließlich der verschachtelten address, ignorieren Felder, die sie nicht definieren, statt 400 validation_error zurückzugeben. In einer Erstellungsanfrage gibt ein Namens- oder Branchenfeld für den anderen Empfängertyp weiterhin 400 zurück, ebenso type und externalId in PATCH /v3/customers/{customerId}/recipients/{recipientId}. Ein PATCH ohne ein Feld, das er erkennt, gibt 400 validation_error statt 200 zurück.
• Ein Verifizierungslink für eine berechtigte Sitzung, die nur Dokumente anfordert, öffnet jetzt eine von Swipelux gehostete Seite zum Hochladen von Dokumenten. Der Link selbst bleibt unverändert, und andere Sitzungen öffnen weiterhin den gehosteten Verifizierungsablauf.
• employment.occupation bei Privatkunden und verbundenen Personen akzeptiert höchstens 255 Zeichen.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} und POST /v3/customers/{customerId}/tasks/{taskId}/submissions geben 400 validation_error zurück, wenn ein Profilwert oder eine Aufgabenantwort einen Swipelux-Formularlink enthält, etwa einen RFI-, Kundenanfrage- oder Transfer-Tracking-Link. Dies gilt nicht für externalId oder metadata. Jeder abgelehnte Wert erscheint in errors[] mit code: public_form_link und seinem JSON Pointer, und die Antwort wiederholt den Link nie. Senden Sie stattdessen die Information selbst. Siehe Fehler und Wiederholungen.

​

Behoben

• Antworten zu Payout-Quotes und Transfers behalten einen USDC- oder USDT-Quellbetrag mit sechs Dezimalstellen bei, zum Beispiel 4009.711365 statt 4009.71. Fiat-Beträge behalten zwei Dezimalstellen. Das Erstellen oder Lesen eines Payouts, dessen Stablecoin-Quellbetrag mehr als zwei Dezimalstellen hat, gibt nicht mehr 500 zurück.
• Die Referenz zu POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel beschreibt die Stornierung jetzt so, wie sie funktioniert. Sie können eine ready-Fähigkeit stornieren, die Fähigkeit stablecoin_transfers kann nicht storniert werden, und eine Stornierung beendet nur diese Fähigkeit, während ihre Anträge Status, Aufgaben und Genehmigungen behalten.
• Eine Fähigkeitsanfrage oder Aufgabenvorschau, die in institutions einen Bankcode statt einer öffentlichen Institutions-ID angibt, etwa citi für citibank, gibt 422 capability_institutions_unsupported mit den verfügbaren IDs zurück statt 503 kyc_configuration_unavailable.
• Eine Fähigkeitsanfrage oder Aufgabenvorschau für eine Methode, die keine Bank dem Kunden anbietet und die die Liste der unterstützten Banken als disabled aufführt, gibt 422 capability_variant_unavailable mit retryable: false statt 503 kyc_configuration_unavailable zurück, sofern der Kunde diese Fähigkeit nicht bereits besitzt.
• documentCandidates listet keine Dateien mehr auf, die Swipelux aus einer abgeschlossenen gehosteten Verifizierung aufbewahrt und die Sie nicht lesen oder herunterladen können. Eine Aufgabenantwort, die eine solche Datei angibt, gibt 400 invalid_document_reference zurück, wie bei einem unbekannten Dokument.

​

Hinzugefügt

• GET /v3/customers akzeptiert include=documentRequirements. Jede Kundenzusammenfassung meldet dann, wie viele Pflichtdokumente noch ausstehen, unabhängig von der Bereitschaft der Funktionen. Kombinieren Sie es als include=capabilities,documentRequirements. Siehe Kunden.
• Die Webhooks-Seite im Händler-Panel ergänzt das Endpunktmenü um Replay missed events. Damit werden Ereignisse der letzten 13 Tage erneut gesendet, die der Endpunkt nie erhalten hat, und dasselbe Ereignis wird nie zweimal gesendet. Siehe Webhooks.
• Die Seite Settings im Händler-Panel hat einen Bereich Compliance. Inhaber und Administratoren können die Compliance-E-Mail-Adresse festlegen und wählen, ob sie E-Mails erhalten möchten, wenn Swipelux weitere Informationen zu einem Kunden anfordert.
• Händler können ihre eigenen KYB-Compliance-Anfragen direkt auf der KYB-Seite des Händler-Panels beantworten.

​

Geändert

• Aktualisierungen von Kunden und verbundenen Personen geben nach einer abgeschlossenen Bankaufnahme kein 409 field_conflicts_with_completed_intake mehr zurück. Die Aktualisierung wird gespeichert, und jeder neue Bankantrag prüft das aktuelle Profil anhand seiner eigenen Anforderungen.
• Funktionsanfragen geben 409 capability_route_header_conflict zurück, wenn das bestehende Bankrouting einer Funktion nicht sicher aktualisiert werden kann. Wenden Sie sich vor einem erneuten Versuch an den Swipelux-Support.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview gibt 422 capability_institutions_unsupported zurück, wenn institutions eine Bank nennt, die die Funktion nicht anbietet, wie es Funktionsanfragen bereits tun.
• In der Sandbox werden ACH-, Wire- und SWIFT-Funktionen nur bei JPMorgan Chase bereitgestellt. Anfragen ohne institutions wählen jpmorgan, und die Angabe einer anderen Bank gibt 422 capability_institutions_unsupported zurück. Das Live-Routing bleibt unverändert. Siehe In der Sandbox testen.
• Das Erzwingen eines Funktionsstatus in der Sandbox gibt 409 capability_status_blocked mit einem statusReason zurück, wenn der simulierte Fall den angeforderten Status nicht erreichen kann. Das Wiederholen eines bereits angewendeten Erzwingens gibt unverändert 200 zurück. Siehe In der Sandbox testen.
• POST /v3/sandbox/tasks/{taskId}/review gibt 409 task_not_sandbox_reviewable für eine Aufgabe zurück, die Operations oder einem anderen Workflow gehört. Aufgaben aus POST /v3/sandbox/tasks und die Aufnahmeaufgaben für Fähigkeiten, die Swipelux erfasst, bleiben prüfbar. Siehe In der Sandbox testen.
• PATCH /v3/customers/{customerId}/accounts/{accountId} gibt 409 account_provisioning_unresolved zurück, wenn Sie das Settlement ändern, während das Konto bei der Bank noch bereitgestellt wird. Versuchen Sie es erneut, nachdem die Bereitstellung abgeschlossen ist. Siehe Fehler und Wiederholungen.
• POST /v3/transfers kann 409 quote_execution_evidence_conflict zurückgeben. Erstellen Sie ein neues Quote und führen Sie es aus. Siehe Fehler und Wiederholungen.
• Die Pay out-Schublade im Händler-Panel zeigt die vollständigen Zieldetails an, verbirgt Kontonummern und Wallet-Adressen hinter einem Umschalter und zeigt für jede Zahlungsmethode eine geschätzte Ankunftszeit an.
• Das Händler-Panel integriert Bankkonten in den Tab Payment access des Kunden, mit einer Aufgabenkarte, die jede Bank nennt. Der Tab Documents wurde nach Profile verschoben.
• Das Eröffnen eines benannten Bankkontos im Händler-Panel ist jetzt ein einziger Schritt, der Währung, Methoden und Onboarding-Dauer jeder Bank auflistet. Siehe Konten.
• Zur Prüfung zurückgehaltene Bankkonten werden im Händler-Panel als On hold angezeigt, mit der Konto-ID und einer Aktion Contact support.
• Eine pending-Fähigkeit meldet jetzt statusReason.code: preparing_submission statt review_in_progress, während Swipelux einen Antrag zur Einreichung vorbereitet und keine Prüfung läuft. Beide Codes verwenden resolution: wait. Ein Wechsel zwischen ihnen belässt den Status bei pending, daher wird kein capability.status_changed-Ereignis gesendet. Bestehende Fähigkeiten übernehmen den neuen Code bei ihrer nächsten Neubewertung. Siehe Funktionen und Anforderungen.
• Die Tabelle Shared methods auf dem Tab Payment access des Kunden im Händler-Panel zeigt In preparation statt In review für eine gemeinsam genutzte Methode, deren Fähigkeit preparing_submission meldet.
• Die applications-Liste einer Fähigkeit zeigt jetzt nur ihre aktuellen Anträge, in Fähigkeitsabfragen (einschließlich GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), in Antworten auf Fähigkeitsanfragen und in capability.status_changed-Ereignissen. Ein Antrag, den ein neuerer ersetzt hat, erscheint weiterhin in GET /v3/customers/{customerId}/applications, wo supersededByApplicationId seinen Nachfolger nennt. Offene Aufgaben eines ersetzten Antrags zählen weiterhin in den openTaskIds der Fähigkeit. Status und openTaskIds der Fähigkeit ändern sich nicht, daher sendet die Änderung selbst kein Webhook-Ereignis. Siehe Funktionen und Anforderungen.

​

Behoben

• Eine zweite allowPending-Anfrage für dasselbe ausgegebene Konto, die vor der Genehmigung durch die Bank gesendet wird, gibt 409 mit dem wartenden Konto in holder.accountId statt 500 zurück. Siehe Bankkonto ausgeben.
• Das Stornieren einer Funktion schließt jetzt Anfragen für ausgegebene Konten, die noch auf die Genehmigung der Bank warteten, sodass eine spätere Anfrage bei derselben Bank neu beginnt.
• Das erneute Anfordern einer stornierten Funktion, deren Bankfälle alle abgelehnt wurden, veröffentlicht ein einziges capability.status_changed-Ereignis ausgehend von canceled.
• Das erneute Anfordern einer Bank, nachdem ihr früherer Antrag archiviert wurde, reicht jetzt den neuen Antrag ein.
• Empfängerziele können hinzugefügt werden, sobald die passende Funktion ready meldet, statt 409 rail_not_ready zurückzugeben. Siehe Empfänger.
• Webhook-Ereignisse, die gesendet wurden, bevor Sie die Webhooks-Seite im Händler-Panel zum ersten Mal öffnen, werden jetzt aufbewahrt, sodass Sie sie erneut an einen neuen Endpunkt senden können.
• Fälligkeitsdaten von Aufgaben im Händler-Panel werden in Ihrer eigenen Zeitzone angezeigt, und Bankprüfungs-Schubladen zeigen All requirements submitted an, sobald nichts mehr offen ist.

​

Hinzugefügt

• POST /v3/quotes akzeptiert eine optionale institutionId, um eine genehmigte Bankroute für ein Krypto-zu-Fiat-Payout-Quote auszuwählen. Lass sie weg, um das automatische Routing beizubehalten. Eine Bank, die für den Payout nicht verfügbar ist, gibt 422 bank_not_supported_for_customer zurück, und das Senden von institutionId bei einem anderen Quote-Typ gibt 400 validation_error zurück. Siehe Gelder senden.
• Anfragen für ausgegebene Bankkonten an POST /v3/customers/{customerId}/accounts akzeptieren institution, um das Konto ohne Fallback an eine einzige Bank zu binden, und allowPending: true, um die Anfrage zu speichern, während der Antrag bei dieser Bank noch auf Genehmigung wartet. allowPending erfordert institution. Gespeicherte Anfragen melden die maßgebliche applicationId. Siehe Bankkonto ausgeben.
• Das Händler-Panel hat eine native Webhooks-Seite zur Verwaltung von Endpunkten. Siehe Webhooks.
• Das Händler-Panel ergänzt eine Pay in-Schublade mit benannten Bankkonten, Krypto-Einzahlungen und einem Prüfschritt.
• Der Pay out-Ablauf im Händler-Panel zeigt Wallet-Guthaben in der Quellauswahl an, ergänzt eine Betragsoption Max und enthält einen Prüfschritt.
• Kundenprofile im Händler-Panel haben einen Tab Recipients & destinations.
• Aufgabenanforderungen können eine kurze Überschrift title enthalten. Der prompt der Anfrage enthält weiterhin die Hinweise. Siehe Funktionen und Anforderungen.

​

Geändert

• Wire-Pay-in-Quotes auf gepoolten Wire-Routen erfordern jetzt mindestens 20 $. Quotes, die unter dem Minimum einer Route liegen oder zu klein sind, um die Überweisungsgebühren zu decken, geben 422 amount_not_deliverable statt eines generischen Quote-Fehlers zurück. Siehe Geld empfangen.
• Das Webhook-Portal gruppiert v3-Ereignistypen jetzt nach Ressource und zeigt für jedes Ereignis das Payload-Schema und ein Beispiel. Legacy-Ereignistypen erscheinen in einer separaten Gruppe Legacy und sind als veraltet markiert. Endpunkte, die sie bereits abonniert haben, erhalten sie weiterhin; verwende für neue Abonnements v3-Ereignistypen. Siehe Webhooks.
• Sandbox-Aufladungen lösen jetzt die Webhook-Ereignisse transfer.created und transfer.state_changed aus. Siehe In der Sandbox testen.
• accountProvisioning meldet jetzt issued, wenn der Kunde bereits ein aktives ausgegebenes Konto hat. Siehe Funktionen und Anforderungen.
• Bankkontodetails im Händler-Panel öffnen sich in einer Schublade mit Banklogos. Siehe Konten.
• Das Händler-Panel bezeichnet Geldbewegungen als Pay in und Pay out, hält dich sechs Stunden lang angemeldet und sendet Hilfeanfragen per E-Mail an den Swipelux-Support.
• In Aufnahmeaufgaben, die eine direkte Einreichung akzeptieren, wechseln geeignete Anforderungen, die bereits durch das Kundenprofil oder hochgeladene Dokumente belegt sind, automatisch zu in_review. Siehe Funktionen und Anforderungen.

​

Behoben

• Das erneute Anfordern einer stornierten Funktion schlägt nicht mehr aufgrund abgelöster Antragsdatensätze oder veralteter Anforderungen fehl.
• Funktionen, die unter der eingestellten Fedwire-ID gespeichert sind, werden jetzt als wire gelesen, statt 500 zurückzugeben.

​

Hinzugefügt

• GET /v3/customers/{customerId}/applications listet die Antragsfälle eines Kunden auf, mit den für jeden Fall angeforderten Funktionen und den Funktionen, die seine Genehmigung abdeckt. Eine Genehmigung bei einer Bank kann mehrere Funktionen abdecken. Aufbewahrte historische Fälle verweisen über supersededByApplicationId auf ihren Nachfolger. Die Liste unterstützt Cursor-Paginierung und updatedAfter. Siehe Funktionen und Anforderungen.
• Antworten von POST /v3/customers/{customerId}/capabilities/{capabilityId} enthalten für fallbasierte Funktionen selectedApplicationId. Es identifiziert den bestehenden Antragsfall, den die Anfrage wiederverwendet hat, oder den Fall, den sie eröffnet hat. Siehe Funktionen und Anforderungen.
• Institutionen, die von GET /v3/institutions und von der Liste der unterstützten Funktionen zurückgegeben werden, enthalten ein nullable logoUrl. Verwende es, um das Branding der Bank anzuzeigen, sofern verfügbar, und greife auf den Namen der Institution zurück, wenn es null ist. Siehe Funktionen und Anforderungen.
• USD-SWIFT-Payouts sind jetzt verfügbar. SWIFT-Payouts erfordern mindestens 100 USD. Das Händler-Panel erfasst SWIFT-Bankanweisungen für Empfänger. Siehe Gelder senden.
• Ausgegebene Bankkonten können über SWIFT mit namentlichen Empfangsdaten empfangen. Siehe Bankkonto ausgeben.
• USDT wird jetzt als Quelle für ACH- und Wire-Payouts unterstützt. Siehe Gelder senden.
• Ausgegebene Bankkonten akzeptieren settlement.currency mit USDC oder USDT, um den an die Settlement-Wallet gelieferten Stablecoin unabhängig von der Währung des Wallet-Kontos zu wählen. Lass es weg, um weiterhin in der Währung der Wallet abzuwickeln. Siehe Bankkonto ausgeben.
• SWIFT-Bankkonten und Empfängerziele akzeptieren bankCity, bankState, bankPostalCode und bankAddressLine2 sowie optional beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode und Angaben zur zwischengeschalteten Bank. Siehe Gelder senden.
• Die Details ausgegebener Bankkonten enthalten achRoutingNumber und wireRoutingNumber, wenn die Bank getrennte ACH- und Wire-Routingnummern bereitstellt, sowie bankLogoUrl für die empfangende Bank. Siehe Bankkonto ausgeben.
• Webhook-Ereignisse vom Typ capability.created enthalten applicationId und einen origin mit dem Wert requested oder approval, sodass du von dir angeforderte Funktionen von solchen unterscheiden kannst, die eine Genehmigung abgedeckt hat. Siehe Webhooks.
• Anforderungsanfragen können ein Validierungsformat constraints.format angeben, etwa http_url, us_ssn, us_ein oder bank_industry_classification. Siehe Funktionen und Anforderungen.

​

Geändert

• Die Bankkontoerstellung im Händler-Panel beginnt jetzt mit der Bankauswahl, und Bankkonten zeigen getrennte ACH- und Wire-Routingnummern. Siehe Konten.
• Das Enum network enthält jetzt solana. Es ist ein offenes Enum, toleriere also Netzwerkwerte, die du nicht kennst. Siehe Konten.
• Das Öffnen eines gehosteten Verifizierungslinks für eine Aufgabe, deren verbleibende Anforderungen eine direkte Einreichung erfordern, gibt 409 verification_session_not_allowed zurück. Reiche diese Anforderungen stattdessen als Aufgabeneinreichung ein. Siehe Fehler und Wiederholungen.
• Das Archivieren eines ausgegebenen Kontos, dessen Bereitstellung noch nicht abgeschlossen ist, gibt 409 account_provisioning_unresolved zurück. Versuche es erneut, nachdem die Bereitstellung abgeschlossen ist. Siehe Fehler und Wiederholungen.
• Neue Anfragen für benannte Bankkonten werden zur Bereitstellung eingereiht, sobald das Konto erstellt ist, statt auf die nächste Aktualisierung des Kunden zu warten. Siehe Bankkonto ausgeben.

​

Entfernt

• Gepoolte SWIFT-Empfangsdaten werden für neue Konten nicht mehr angeboten. Verwende stattdessen namentliche SWIFT-Empfangsdaten. Siehe Bankkonto ausgeben.

​

Behoben

• Lesevorgänge für Payout-Transfers geben jetzt den im Quote angegebenen Empfänger zurück.
• Das Erstellen eines ACH-Kontos nach dem Archivieren eines bestehenden gibt nicht mehr 409 zurück, und archivierte ausstehende Kontoanfragen belegen keinen Kontoplatz mehr.
• Bankgebühren bei Pay-in-Quotes in Landeswährung werden in der korrekten Fiat-Währung ausgewiesen.

​

Hinzugefügt

• GET /v3/webhooks/{webhookId} liest einen einzelnen Webhook-Endpunkt und seine events-Auswahl. Siehe Webhooks.
• Aufgabenanforderungen veröffentlichen jetzt allowedValues und ein JSON-Schema-valueSchema für Profilfelder, einschließlich erforderlicher Adressfelder. Länderfelder melden als valueType oder itemValueType den Wert country, also einen ISO-3166-1-alpha-2-Code. Du kannst Eingaben und Auswahlmöglichkeiten rendern, ohne sie fest zu codieren. Siehe Funktionen und Anforderungen.
• Bestehende Tron-Wallets können jetzt USDT an die externen Wallet-Konten des Kunden senden, und Transfer-Lesevorgänge enthalten einen Block-Explorer-Link für Tron-Transaktionen. Neue Wallets können nicht auf Tron ausgegeben werden. Siehe Gelder senden.
• Aufgabenanforderungen können requiredWhen (nur beantworten, wenn eine benannte Ja/Nein-Antwort übereinstimmt), profileAssertion (us_person) und ownershipPolicy angeben, und Dokumentanfragen können identityMetadataRequired und maxIssueAgeDays festlegen. Aufgabenantworten akzeptieren documentMetadata (idNumber, issuingCountry, issuedOn) für referenzierte Dokumente, und Aufgaben-Lesevorgänge geben geprüfte steuernde Antworten in conditionValues zurück. Siehe Funktionen und Anforderungen.
• Dokumentanforderungen können acceptedDocumentSets auflisten, und Anforderungen an verbundene Personen können zusätzlich zu beneficial_owner eine Qualifikation als associated_person oder control_person verlangen. Siehe Funktionen und Anforderungen.
• correction-Objekte von Transfers decken jetzt auch fehlgeschlagene finanzierte Payouts ab: kind: funding_failure mit der Ausgleichsaktion recover_source_funding, einem recoveryStatus von unknown oder reported und gutgeschriebenen Ausgaben in USDT. Siehe Quotes und Transfers.

​

Geändert

• PATCH /v3/webhooks/{webhookId} akzeptiert jetzt Legacy-Ereignistypen, die der Endpunkt bereits abonniert hat, sodass du sie behalten kannst, während du v3-Ereignistypen hinzufügst. events ersetzt die gesamte Auswahl, gib also jeden Ereignistyp an, den du behalten möchtest. Das Hinzufügen eines Legacy-Ereignistyps, den der Endpunkt noch nicht hatte, gibt 400 validation_error zurück. Siehe Webhooks.
• Bankkennungen bei Empfängern und Konten werden vor dem Speichern validiert. Siehe Empfänger.
• Funktionsanfragen, Aufgabeneinreichungen und Statusänderungen in der Sandbox geben jetzt 409 capability_application_stale statt 500 zurück, wenn eine Funktion unter einem früheren Onboarding-Modell erstellt wurde. Siehe Fehler und Wiederholungen.
• Die öffentliche RFI-Seite ist jetzt ein durchgehendes Formular. Sie unterstützt verbundene Personen und erfasst eine Steuer-ID pro Person. Siehe Dokumentanforderungen.
• Quotes und Transfers geben 409 customer_bank_limit_exceeded zurück, wenn eine Zahlung das verbleibende Tages- oder Monatskontingent des Kunden bei der Bank überschreitet, und 503 customer_bank_limits_unavailable, wenn dieses Kontingent nicht geprüft werden kann. Transfers geben 409 payout_execution_unavailable zurück, wenn ein Payout nicht aus seinem Quote gestartet werden kann. Siehe Fehler und Wiederholungen.
• Aktualisierungen von Kunden und verbundenen Personen, die mit einer abgeschlossenen Bankaufnahme kollidieren, geben 409 field_conflicts_with_completed_intake mit taskId und fields zurück.

​

Behoben

• Der Verlauf stornierter Funktionen bleibt lesbar.
• Wire-Payouts werden in der Transaktionsliste des Händler-Panels korrekt angezeigt und gefiltert.

​

Geändert

• POST /v3/transfers und Transfer-Lesevorgänge verwenden für die Vorauswahl im Karten-Checkout checkoutMethod statt paymentMethod und akzeptieren card, apple_pay, google_pay, cash_app, sepa und blik. Die Liste ist offen und kann wachsen. paymentMethod wird nicht mehr erkannt; Anfragen, die es weiterhin senden, werden behandelt, als wäre es weggelassen worden. sepa und blik sind Zahlungsoptionen innerhalb des Karten-Checkouts, keine Swipelux-Fähigkeiten. Siehe Geld empfangen.

​

Hinzugefügt

• POST /v3/transfers akzeptiert für Karten-Quotes ein optionales paymentMethod mit dem Wert card, apple_pay oder google_pay. Der gehostete Checkout öffnet sich mit der angeforderten Methode, wenn sie für den Kunden und sein Gerät verfügbar ist, Transfer-Lesevorgänge geben die Anforderung zurück, und die Beträge und Gebühren des Quotes bleiben unverändert. Siehe Geld empfangen.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview akzeptiert institutions, um eine Vorschau der Aufgaben für bestimmte Banken anzuzeigen, die von der Liste der unterstützten Funktionen zurückgegeben werden. Siehe Funktionen und Anforderungen.

​

Geändert

• Karten-Quotes berücksichtigen jetzt Checkout-Gebühren und den netto gelieferten USDC-Betrag. Siehe Geld empfangen.
• Abgelehnte Payout-Quotes geben statt eines generischen Fehlers einen spezifischen Problemcode zurück: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported oder quote_failed, sowie 503 quote_temporarily_unavailable, wenn das Quote später erneut versucht werden kann. Siehe Fehler und Wiederholungen.

​

Behoben

• Karten-Quotes schlagen nicht mehr aufgrund von Gebührenrundung fehl.
• Das erneute Öffnen eines gehosteten KYC-Links gibt nicht mehr 409 kyc_process_conflict zurück, wenn Fragebogenantworten zusätzliche Leerzeichen enthalten.
• Hängende Passkey-Bestätigungen für Auszahlungen im Händler-Panel werden jetzt wiederhergestellt.

​

Hinzugefügt

• POST /v3/customers/{customerId}/documents akzeptiert jetzt auch einen application/json-Body mit storageKey, fileName und type. Der storageKey muss eine frische kundenbezogene Referenz sein, die über den früheren Direct-Upload-Ablauf geparkt wurde, und der Upload durchläuft dieselbe Größen- und Dateisignatur-Validierung wie Multipart-Uploads. Siehe Migration zu v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download liefert eine Download-url für ein aktives Kundendokument. Die URL läuft nach einer Stunde ab und liefert die Datei als Anhang aus. Archivierte, unbekannte und kundenfremde Dokumente liefern 404. Siehe Funktionen und Anforderungen.
• Wird eine Funktion für ein Unternehmen ohne wirtschaftlich Berechtigten angefordert, wird jetzt eine Aufnahmeaufgabe zum Hinzufügen erstellt, statt mit einem 503 fehlzuschlagen. Anfragen, die nicht fortgesetzt werden können, geben 422 beneficial_owner_required mit der Anweisung zurück, eine natürliche verbundene Person mit erklärter oder mindestens 25 % Beteiligung hinzuzufügen. Siehe Anteilseigner, UBOs und Kontrollpersonen.
• Die Aufgabentabelle im Händler-Panel zeigt jetzt das Subjekt und den Funktionsumfang jeder Anfrage, sodass du siehst, wen und was eine Compliance-Anfrage abdeckt. Siehe Funktionen und Anforderungen.
• Felder zur Branchenklassifizierung im Händler-Panel bieten jetzt durchsuchbare NAICS-Codes in Kundenprofilen und Anforderungsaufgaben. Siehe KYB-Ablauf.
• Bank-Pay-in-Anweisungen können bankName, bankAddress, accountHolderName und accountHolderAddress enthalten. Zeige sie zusammen mit den anderen Bankdaten an. Siehe Geld empfangen.
• POST /v3/transfers akzeptiert eine optionale redirectUrl, die den Kunden nach einem gehosteten Karten- oder Apple-Pay-Checkout zu deiner App zurückführt. Das Erreichen der URL bestätigt nicht den Abschluss; verwende Transfer-Lesevorgänge oder Webhooks. Siehe Geld empfangen.
• Von einer v3-Rule erstellte Transfers erscheinen in Transfer-Lesevorgängen und -Listen mit origin: rule und lösen wie andere Transfers transfer.state_changed-Ereignisse aus. Filtere sie mit GET /v3/transfers?origin=rule. Siehe Quotes und Transfers.
• Identitätsdokumente bei Kunden und verbundenen Personen akzeptieren sideApplicability (front_only, front_and_back oder unknown), und Aufgaben können Angaben zu Identitätsdokumenten wie type, number, issuingCountry, issuingRegion, issuedOn, expiresOn und doesNotExpire als Antworten erfassen. Siehe Funktionen und Anforderungen.

​

Geändert

• Übermittlungen von Bankdaten, die mit einer laufenden Bankeinrichtung kollidieren, geben jetzt 409 ops_rail_handoff_conflict zurück. Behalte deine hochgeladenen Dokument-IDs und wiederhole dieselbe Übermittlung, nachdem der Konflikt gelöst ist, statt Dokumente erneut hochzuladen. Siehe Fehler und Wiederholungen.
• Das Minimum für unangekündigte Stablecoin-Einzahlungen in Kunden-Wallets beträgt jetzt 1 Einheit statt 10. Kleinere Einzahlungen werden weiterhin als Dust behandelt. Siehe Geld empfangen.
• Die Webhook-Konfiguration ist jetzt pro Umgebung isoliert. Das Webhook-Portal öffnet sich beschränkt auf die Umgebung, aus der du es anforderst, sodass Sandbox- und Produktions-Endpunkte keine Einstellungen mehr teilen. Siehe Webhooks.
• Das Händler-Panel leitet verfügbare Pay-in-Methoden jetzt aus den v3-Funktionen des Kunden ab, sodass die Kontoeinrichtung nur Methoden anbietet, zu denen der Kunde berechtigt ist. Siehe Konten.
• RFI-Formulare erfassen qualifizierende wirtschaftlich Berechtigte jetzt mit kürzeren, klareren Eingabeaufforderungen, und der RFI-Verlauf wird als Lebenszyklus-Meilensteine angezeigt. Siehe Dokumentanforderungen.
• Offene Aufgaben ohne explizites Fälligkeitsdatum setzen dueAt jetzt standardmäßig auf 31 Tage nach der Erstellung. Siehe Funktionen und Anforderungen.

​

Entfernt

• Das Händler-Panel bietet beim Hinzufügen neuer Pay-in-Methoden kein Fedwire mehr an. Bestehende Fedwire-Konten bleiben lesbar. Siehe Konten.

​

Behoben

• Unangekündigte USDT-Einzahlungen in Kunden-Wallets werden jetzt erkannt und abgewickelt, statt ignoriert zu werden.
• Bereits eingereichte Nachweise werden jetzt auf andere Aufgaben übertragen, die dasselbe Element erfordern, sodass Kunden nicht zweimal nach demselben Dokument gefragt werden.
• Das erneute Anfordern einer Funktion verwirft keine bereits bereiten Bankrouten mehr, sodass ausgegebene Kontodaten stabil bleiben.
• Bankanweisungsansichten im Händler-Panel zeigen jetzt vollständige Details, einschließlich SWIFT-Adressen und der Ziel-Wallet-Adresse.
• RFI-Formulare zeigen jetzt Validierungsfehler beim Einreichen an, validieren Beschreibungen der Rechtsform vor dem Einreichen und akzeptieren mehrere Unternehmens-Websites.
• Entwürfe verbundener Personen in RFI-Formularen können jetzt vor dem Einreichen bearbeitet werden.
• Stornierte Compliance-Anfragen erscheinen nicht mehr in der Aufgabenliste des Händler-Panels.
• Dokumentprüfungsstatus werden im Händler-Panel wieder korrekt angezeigt.

​

Hinzugefügt

• Kundenbezogene gehostete Verifizierungs- und Nutzungsbedingungen-Sitzungen enthalten jetzt ein maßgebliches action-Objekt. Richte dich nach dessen Typ available oder unavailable; die flachen Felder url und expiresAt bleiben für verfügbare Aktionen Kompatibilitätsspiegel. Siehe Funktionen und Anforderungen.
• Sandbox-Wallet-Aufladungen geben jetzt Übertragungs-IDs zurück, die du mit GET /v3/transfers/{transferId} lesen oder mit GET /v3/transfers auflisten kannst. Sie erscheinen als abgeschlossene eingehende Stablecoin-Einzahlungen. Siehe In der Sandbox testen.
• Lesevorgänge für Übertragungen enthalten ein correction-Objekt, wenn die Mittel einer Übertragung nach ihrem Abschluss zurückgegeben oder rückgängig gemacht werden. Es meldet die Art der Korrektur (kind), den normalisierten providerStatus, einen etwaigen providerShortfall und den compensatingIntent, den Swipelux anwendet. Siehe Angebote und Übertragungen.

​

Geändert

• Der First pay-in-Assistent im Händler-Panel für Karten und Apple Pay erfordert jetzt eine Polygon-Wallet des Kunden. Erstelle sie, bevor du den Assistenten startest. Siehe Konten.
• Neue Anfragen und öffentliche Antworten verwenden sepa als kanonischen Methoden- und Funktionsnamen. Der Eingabealias sepa_instant und zuvor gespeicherte Ressourcen bleiben kompatibel, öffentliche Antworten verwenden jedoch sepa. Siehe Konten.
• Neue Anfragen für Faster-Payments-Funktionen, ausgegebene Konten und Angebote sind nicht verfügbar. Bestehende Konten, Angebote und Übertragungen bleiben lesbar. Siehe Konten.
• Die erste KYB-Seite erfasst nicht mehr das Geburtsdatum des Vertreters. Geburtsdaten von Anteilseignern bleiben eine separate Anforderung. Siehe KYB-Ablauf.
• RFI-Dokumentverweise akzeptieren jetzt neben image/jpeg auch den MIME-Alias image/jpg. Siehe Dokumentanforderungen.
• Der Aufgabenverlauf im Händler-Panel zeigt jetzt einen lesbaren Audit-Trail ohne Revisionszähler. Siehe Funktionen und Anforderungen.
• Angebote und Übertragungen prüfen jetzt die unterstützten Richtungen der Funktion, bevor Geld bewegt wird. Die Verwendung einer Funktion in einer Richtung, die sie nicht unterstützt, gibt 422 capability_direction_unsupported zurück, und Bewegungen zwischen Wallets erfordern eine stablecoin_transfers-Funktion. Siehe Fehler und Wiederholungen.

​

Entfernt

• Das Händler-Panel bietet keine Einrichtung neuer UAEFTS-Konten mehr an. Bestehende UAEFTS-Konten bleiben lesbar. Siehe Konten.

​

Behoben

• RFI-Formulare behalten bestehende Eingaben bei, wenn ein Prüfer eine neue Dokumentablage hinzufügt, sodass zuvor angegebene Antworten beim erneuten Senden nicht verloren gehen.
• Das Händler-Panel setzt gehostete Compliance-Sitzungen über verfügbare Aktionen fort, ohne gültige Links zu verwerfen.
• Gehostete Links zu den Nutzungsbedingungen funktionieren jetzt für jeden von der API zurückgegebenen Aufgabenumfang.
• Nach einer Payment-Access-Anfrage im Händler-Panel öffnet es die von dieser Anfrage zurückgegebene Aufnahmeaufgabe statt einer Aufgabe aus einer früheren Anfrage.
• Die KYB-Demo im Händler-Panel fragt jetzt die aktuell erforderlichen Felder ab.
• Ein Angebot, das seine Quell-Wallet erneut als destinationId verwendet, gibt jetzt vor Beginn von Anbieterarbeit verwertbare 422 quote_direction_invalid-Details zurück. Siehe Angebote und Übertragungen.
• Die API weist fehlerhaft codierte Abfragezeichenfolgen mit einem 400-Fehler ab, statt die Anfrage stillschweigend zu normalisieren. Siehe Fehler und Wiederholungen.
• POST /v3/customers/{customerId}/documents weist jetzt leere, nicht als multipart gesendete oder fehlerhafte Anfragekörper mit einem 400-Fehler ab.

​

Hinzugefügt

• Der v3 Problem-Details-Katalog wurde in der OpenAPI-Spezifikation veröffentlicht, sodass Integratoren Fehlerantworten direkt aus dem Schema abbilden können. Siehe Fehler.
• customerId wurde zu v3-Account-Webhook-Ereignissen hinzugefügt, sodass Sie Kontoaktivitäten dem zugehörigen Kunden zuordnen können, ohne einen weiteren Lesevorgang zu benötigen. Siehe Webhooks.
• Vollständige V3-Feldabdeckung des Einzelprofils im Händler-Panel, damit Onboarding-Operator:innen jedes über die v3-API erfasste KYC-Feld prüfen und bearbeiten können. Siehe Kunden.
• Ein Entwickler-Migrationsleitfaden von v3 wurde veröffentlicht. Siehe Migration zu v3.

​

Geändert

• Länderkennungen von Kunden und Konten werden beim Schreiben nun als zugewiesene ISO 3166-1 alpha-2-Werte validiert. Lesevorgänge tolerieren zuvor gespeicherte Werte, sodass bestehende Datensätze weiterhin auflösbar bleiben. Siehe Konten und Wallets.
• Die USDC-Verfügbarkeit ist jetzt nach Zielnetzwerk begrenzt, sodass Quotes und Transfers USDC nur auf den Netzwerken anbieten, die das Ziel tatsächlich unterstützt.
• Jeder Onboarding-Flow erfordert jetzt die Swipelux-Nutzungsbedingungen. Bestehende Sitzungen bleiben fortsetzbar. Siehe Kunden.
• Capability.ready meldet weiterhin die Genehmigung der Berechtigung. Verwenden Sie accountProvisioning, um die Kontoausstellung als not_applicable, not_started, in_progress, issued oder failed zu verfolgen. Siehe Fähigkeiten und Aufgaben.
• HEIC-Uploads vom iPhone werden nun als Identitäts- und Adressnachweisdokumente akzeptiert.
• Das Leeren eines Kunden- oder Related-Party-Felds, das eine offene Aufgabe noch benötigt, gibt jetzt 409 field_required_by_open_task mit der blockierenden taskId und fields zurück, statt eines wiederholbaren Konflikts. Schließen Sie die Aufgabe ab oder brechen Sie sie ab, bevor Sie diese Felder ändern. Siehe Fehler und Wiederholungen.

​

Behoben

• Die erneute Ausführung eines bereits verbrauchten Quote liefert nun 409 quote_execution_consumed statt eines generischen Fehlers. Siehe Quotes und Transfers.
• Transfer-Listen-Lesevorgänge und Quote-Betrag-Lesevorgänge geben bei großen historischen Ergebnissen keinen 500-Fehler mehr zurück.
• Gleichzeitige KYC-Weiterleitungen geben jetzt einen Konflikt statt 404 zurück, sodass Wiederholungen sauber aufgelöst werden. Gehostete Weiterleitungen werden nicht mehr auf halbem Weg zurückgesetzt, und KYC-Links bleiben fortsetzbar.
• Related-Party-Lesevorgänge für einzelne Kunden liefern nicht mehr 404.
• KYB-Einreichungen mit ungültigen Wallet-Feldern werden vor der Einreichung abgelehnt, und eine fehlgeschlagene Synchronisierung wird im Händler-Panel nicht mehr als Erfolg gemeldet.
• Anforderungsaufgaben im Händler-Panel zeigen eingereichte Antworten jetzt als abgeschlossen an, verfolgen Nutzungsbedingungen-Aktionen separat, entfernen doppelten Dokumenttext, halten begonnene KYC-Sitzungen bis zum Abschluss als ausstehend und behandeln veraltete Aufgaben, ohne die Anforderungsansicht zu beeinträchtigen.
• Verifikationslink-Zeilen im Händler-Panel zeigen jetzt in jeder Zeile eine Open-Aktion, und jeder Aufgabenlink wird in der Anforderungsansicht gerendert.