Changelog et notes de version de l'API Swipelux

​

Ajouté

• Les destinations des destinataires acceptent les types pix et pix_safe pour les paiements en BRL au Brésil. Une destination Pix paie une clé Pix. Une destination Pix Safe paie un compte bancaire identifié par le CPF ou le CNPJ du titulaire, le code ISPB de la banque, l’agence et le numéro de compte. Les deux nécessitent que la capacité Pix du client (pix_pooled) soit prête, et leurs paiements sont financés en USDC sans frais développeur. Voir Destinataires et Envoyer des fonds.
• GET /v3/customers/{customerId}/tasks/{taskId} accepte documentCandidatesFor avec l’identifiant d’une exigence documentaire, ainsi que documentAlternativeKey pour une exigence comportant des alternatives. La réponse liste alors, dans data.documentCandidates, les fichiers déjà téléversés par le client qui peuvent satisfaire cette exigence, avec les éventuels missingMetadata ou conflictingMetadata. Soumettez le documentId d’un candidat avec les documentMetadata manquantes au lieu de téléverser à nouveau le fichier. La requête nécessite accounts:read et customers:read, et une sélection invalide renvoie 400 validation_error.

​

Modifié

• GET /v3/webhooks/portal renvoie une URL de portail qui expire au bout d’une heure, avec Cache-Control: no-store. Avec une clé API disposant de webhooks:write, le portail affiche le secret de signature du point de terminaison et permet de gérer les points de terminaison, de relancer les livraisons et de les rejouer. Avec seulement webhooks:read, le portail affiche uniquement les livraisons. Voir Webhooks.
• Citi (citibank) n’est proposée qu’aux clients professionnels. Chaque entreprise conserve Citi mutualisée, et Citi nominative n’est proposée qu’aux entreprises immatriculées hors des États-Unis. Lorsque Citi n’est pas proposée à un client, la liste des capacités prises en charge l’omet, la désigner renvoie 422 capability_institutions_unsupported, et une méthode proposée uniquement par Citi est listée comme disabled. Une requête sans institutions effectue la sélection parmi les banques restantes. Les dossiers et comptes existants ne changent pas.
• Les capacités CFSB (cfsb) nominatives ne sont proposées qu’aux clients américains : les entreprises immatriculées aux États-Unis et les particuliers qui y résident. Pour les autres clients, la liste des capacités prises en charge omet CFSB nominative, et la désigner renvoie 422 capability_institutions_unsupported. Une requête sans institutions effectue la sélection parmi les banques restantes. CFSB mutualisée, les clients dont le pays est inconnu et les dossiers existants ne changent pas.
• Les capacités ACH, Wire et SWIFT nominatives de Lead Bank (lead_bank) ne sont proposées qu’aux clients que Lead Bank peut accueillir, en fonction de leur forme juridique et de leurs pays. Pour les autres clients, la liste des capacités prises en charge omet lead_bank, et la désigner renvoie 422 capability_institutions_unsupported. Les clients que Lead Bank a déjà accueillis, ainsi que les capacités dont la demande ouverte désigne déjà lead_bank, la conservent. Les dossiers et comptes existants ne changent pas.
• RTP est uniquement mutualisé. Aucune banque ne propose rtp_named aux nouvelles demandes : la liste des capacités prises en charge l’affiche donc comme disabled. Pour un client qui ne détient pas rtp_named, une demande de capacité ou un aperçu de tâche qui la concerne et désigne une banque renvoie 422 capability_institutions_unsupported, et une demande sans institutions renvoie 422 capability_variant_unavailable. RTP mutualisé (rtp_pooled) est proposé chez Citi : seuls les clients professionnels peuvent donc le demander.
• Les nouvelles demandes de pièces d’identité pour les particuliers et les bénéficiaires effectifs peuvent définir constraints.identityMetadataRequired: true, de sorte que chaque fichier doit indiquer son numéro d’identification et son pays de délivrance dans documentMetadata. Les nouvelles demandes de justificatif d’adresse d’entreprise et de justificatif de résidence des propriétaires peuvent définir constraints.maxIssueAgeDays: 90, de sorte que chaque fichier doit indiquer sa date d’émission. Les tâches existantes conservent leurs exigences : lisez donc les contraintes de chaque demande de tâche.
• Une réponse de tâche à une demande d’immatriculation d’entreprise, dont le profilePointer est /business/registration, nécessite à la fois le pays de juridiction, le numéro d’immatriculation et une date de constitution antérieure à la date de soumission. Le valueSchema de la demande publie cette règle, et une réponse partielle renvoie 400 validation_error.
• Après une vérification hébergée, Swipelux accepte une réponse hébergée à une exigence de profil portant sur une valeur structurée, comme une adresse ou des identifiants fiscaux, uniquement si elle passe les mêmes contrôles de schéma et de contraintes qu’une réponse directe. Sinon, l’exigence reste ouverte et vous soumettez cette valeur avec POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Une exigence que Swipelux remet en action_required pour cette raison porte reviewFeedback.code: hosted_profile_direct_submission_required. Les tâches déjà satisfied conservent leur statut. Voir Capacités et exigences.
• Une tâche rejetée par une vérification hébergée peut quitter rejected lorsque cette décision de vérification est ultérieurement annulée. Elle passe alors à satisfied, ou à action_required sous une nouvelle revision, avec réouverture des exigences auxquelles la nouvelle décision ne répond pas. Les soumissions antérieures pour ces exigences restent rejected : soumettez donc à nouveau ces réponses. Voir Migrer vers v3.
• Le type des destinations des destinataires est désormais une énumération ouverte. Les versions antérieures de cette référence la décrivaient comme fermée : mettez donc à jour tout client qui rejette ou ignore les types inconnus. Les réponses de destination et les événements destination.status_changed peuvent désormais contenir pix et pix_safe, et d’autres types peuvent être ajoutés.
• Les requêtes de création et de mise à jour de destinataires, y compris l’objet imbriqué address, ignorent les champs qu’elles ne définissent pas au lieu de renvoyer 400 validation_error. Dans une requête de création, un champ de nom ou de secteur d’activité propre à l’autre type de destinataire renvoie toujours 400, de même que type et externalId dans PATCH /v3/customers/{customerId}/recipients/{recipientId}. Un PATCH ne contenant aucun champ reconnu renvoie 400 validation_error au lieu de 200.
• Un lien de vérification pour une session éligible qui demande uniquement des documents ouvre désormais une page de téléversement de documents hébergée par Swipelux. Le lien lui-même ne change pas, et les autres sessions ouvrent toujours le parcours de vérification hébergé.
• employment.occupation sur les clients particuliers et les personnes des parties liées accepte au maximum 255 caractères.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} et POST /v3/customers/{customerId}/tasks/{taskId}/submissions renvoient 400 validation_error lorsqu’une valeur de profil ou une réponse à une tâche contient un lien vers un formulaire Swipelux, comme un lien de RFI, de demande client ou de suivi de transfert. Cela ne s’applique pas à externalId ni à metadata. Chaque valeur rejetée apparaît dans errors[] avec code: public_form_link et son JSON Pointer, et la réponse ne répète jamais le lien. Envoyez plutôt l’information elle-même. Voir Erreurs et nouvelles tentatives.

​

Corrigé

• Les réponses de cotation et de transfert de paiement conservent un montant source en USDC ou USDT avec six décimales, par exemple 4009.711365 au lieu de 4009.71. Les montants en monnaie fiduciaire conservent deux décimales. Créer ou lire un paiement dont le montant source en stablecoin comporte plus de deux décimales ne renvoie plus 500.
• La référence POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel décrit désormais l’annulation telle qu’elle fonctionne. Vous pouvez annuler une capacité ready, la capacité stablecoin_transfers ne peut pas être annulée, et l’annulation ne met fin qu’à cette capacité, tandis que ses dossiers conservent leur statut, leurs tâches et leurs approbations.
• Une demande de capacité ou un aperçu de tâche qui indique dans institutions un code bancaire au lieu d’un identifiant public d’institution, comme citi pour citibank, renvoie 422 capability_institutions_unsupported en citant les identifiants disponibles, au lieu de 503 kyc_configuration_unavailable.
• Une demande de capacité ou un aperçu de tâche pour une méthode qu’aucune banque ne propose au client, que la liste des capacités prises en charge affiche comme disabled, renvoie 422 capability_variant_unavailable avec retryable: false au lieu de 503 kyc_configuration_unavailable, sauf si le client détient déjà cette capacité.
• documentCandidates ne liste plus les fichiers que Swipelux conserve à l’issue d’une vérification hébergée terminée, que vous ne pouvez ni lire ni télécharger. Une réponse de tâche qui en cite un renvoie 400 invalid_document_reference, comme pour un document inconnu.

​

Ajouté

• GET /v3/customers accepte include=documentRequirements. Chaque résumé client indique alors le nombre de documents obligatoires encore manquants, indépendamment de la disponibilité des capacités. Combinez-le sous la forme include=capabilities,documentRequirements. Voir Clients.
• La page Webhooks du panneau marchand ajoute Replay missed events au menu du point de terminaison. Cette action renvoie les événements des 13 derniers jours que le point de terminaison n’a jamais reçus, et n’envoie jamais deux fois le même événement. Voir Webhooks.
• La page Settings du panneau marchand comporte une section Compliance. Les propriétaires et les administrateurs peuvent définir l’adresse e-mail de conformité et choisir de recevoir ou non des e-mails lorsque Swipelux demande des informations complémentaires sur un client.
• Les marchands peuvent répondre directement à leurs propres demandes de conformité KYB sur la page KYB du panneau marchand.

​

Modifié

• Les mises à jour de clients et de parties liées ne renvoient plus 409 field_conflicts_with_completed_intake après une admission bancaire terminée. La mise à jour est enregistrée, et chaque nouveau dossier bancaire vérifie le profil le plus récent selon ses propres exigences.
• Les demandes de capacité renvoient 409 capability_route_header_conflict lorsque le routage bancaire existant d’une capacité ne peut pas être mis à jour en toute sécurité. Contactez le support Swipelux avant de réessayer.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview renvoie 422 capability_institutions_unsupported lorsque institutions désigne une banque que la capacité ne propose pas, comme les demandes de capacité.
• Dans la sandbox, les capacités ACH, Wire et SWIFT sont servies uniquement chez JPMorgan Chase. Les demandes qui omettent institutions sélectionnent jpmorgan, et désigner une autre banque renvoie 422 capability_institutions_unsupported. Le routage en production ne change pas. Voir Tester dans la sandbox.
• Forcer le statut d’une capacité en sandbox renvoie 409 capability_status_blocked avec un statusReason lorsque le cas simulé ne peut pas atteindre le statut demandé. Répéter un forçage déjà appliqué renvoie 200 sans modification. Voir Tester dans la sandbox.
• POST /v3/sandbox/tasks/{taskId}/review renvoie 409 task_not_sandbox_reviewable pour une tâche détenue par les Opérations ou par un autre workflow. Les tâches issues de POST /v3/sandbox/tasks et les tâches de collecte de capacités que Swipelux recueille restent examinables. Voir Tester dans la sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} renvoie 409 account_provisioning_unresolved lorsque vous modifiez le règlement alors que le compte est encore en cours de provisionnement auprès de la banque. Réessayez une fois le provisionnement finalisé. Voir Erreurs et nouvelles tentatives.
• POST /v3/transfers peut renvoyer 409 quote_execution_evidence_conflict. Créez une nouvelle cotation et exécutez-la. Voir Erreurs et nouvelles tentatives.
• Le volet Pay out du panneau marchand affiche les coordonnées complètes de la destination, masque les numéros de compte et les adresses de portefeuille derrière un bouton bascule, et indique un délai d’arrivée estimé pour chaque moyen de paiement.
• Le panneau marchand regroupe les comptes bancaires dans l’onglet Payment access du client, avec une carte de tâches qui nomme chaque banque. L’onglet Documents a été déplacé dans Profile.
• L’ouverture d’un compte bancaire nommé dans le panneau marchand se fait désormais en une seule étape qui indique la devise, les moyens de paiement et le délai d’onboarding de chaque banque. Voir Comptes.
• Les comptes bancaires retenus pour examen apparaissent comme On hold dans le panneau marchand, avec l’identifiant du compte et une action Contact support.
• Une capacité pending indique désormais statusReason.code: preparing_submission au lieu de review_in_progress pendant que Swipelux prépare un dossier pour soumission et qu’aucun examen n’est en cours. Les deux codes utilisent resolution: wait. Un passage de l’un à l’autre conserve le statut pending, donc aucun événement capability.status_changed n’est envoyé. Les capacités existantes adoptent le nouveau code lors de leur prochaine réévaluation. Voir Capacités et exigences.
• Le tableau Shared methods de l’onglet Payment access du client dans le panneau marchand affiche In preparation au lieu de In review pour une méthode mutualisée dont la capacité indique preparing_submission.
• La liste applications d’une capacité n’affiche désormais que ses dossiers actuels, dans les lectures de capacité (y compris GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), les réponses aux demandes de capacité et les événements capability.status_changed. Un dossier remplacé par un plus récent apparaît toujours dans GET /v3/customers/{customerId}/applications, où supersededByApplicationId indique son successeur. Les tâches ouvertes d’un dossier remplacé comptent toujours dans les openTaskIds de la capacité. Le statut et les openTaskIds de la capacité ne changent pas, donc le changement lui-même n’envoie aucun événement webhook. Voir Capacités et exigences.

​

Corrigé

• Une seconde demande allowPending pour le même compte émis, envoyée avant l’approbation de la banque, renvoie 409 en indiquant le compte en attente dans holder.accountId au lieu de 500. Voir Émettre un compte bancaire.
• L’annulation d’une capacité clôture désormais les demandes de compte émis encore en attente d’approbation bancaire, de sorte qu’une demande ultérieure auprès de la même banque repart de zéro.
• Redemander une capacité annulée dont tous les dossiers bancaires ont été rejetés publie un seul événement capability.status_changed depuis canceled.
• Redemander une banque après l’archivage de son dossier précédent soumet désormais le nouveau dossier.
• Les destinations des destinataires peuvent être ajoutées dès que la capacité correspondante indique ready, au lieu de renvoyer 409 rail_not_ready. Voir Destinataires.
• Les événements webhook envoyés avant votre première ouverture de la page Webhooks du panneau marchand sont désormais conservés, afin que vous puissiez les renvoyer vers un nouveau point de terminaison.
• Les dates d’échéance des tâches dans le panneau marchand s’affichent dans votre propre fuseau horaire, et les volets d’examen bancaire affichent All requirements submitted lorsqu’il ne reste plus rien en suspens.

​

Ajouté

• POST /v3/quotes accepte un institutionId facultatif pour choisir une route bancaire approuvée pour une cotation de paiement crypto vers fiat. Omettez-le pour conserver le routage automatique. Une banque qui n’est pas disponible pour le paiement renvoie 422 bank_not_supported_for_customer, et l’envoi de institutionId avec tout autre type de cotation renvoie 400 validation_error. Voir Envoyer des fonds.
• Les demandes de compte bancaire émis sur POST /v3/customers/{customerId}/accounts acceptent institution pour rattacher le compte à une seule banque sans solution de repli, et allowPending: true pour enregistrer la demande tant que le dossier auprès de cette banque est encore en attente d’approbation. allowPending nécessite institution. Les demandes enregistrées indiquent l’applicationId qui les régit. Voir Émettre un compte bancaire.
• Le panneau marchand dispose d’une page Webhooks native pour gérer les points de terminaison. Voir Webhooks.
• Le panneau marchand ajoute un volet Pay in avec des comptes bancaires nommés, des dépôts crypto et une étape de vérification.
• Le flux Pay out du panneau marchand affiche les soldes des portefeuilles dans le sélecteur de source, ajoute une option de montant Max et inclut une étape de vérification.
• Les profils clients du panneau marchand disposent d’un onglet Recipients & destinations.
• Les exigences des tâches peuvent inclure un court intitulé title. Le prompt de la demande continue de porter les instructions. Voir Capacités et exigences.

​

Modifié

• Les cotations de pay-in par wire sur les routes Wire mutualisées exigent désormais au moins 20 $. Les cotations inférieures au minimum d’une route, ou trop faibles pour couvrir les frais de transfert, renvoient 422 amount_not_deliverable au lieu d’un échec de cotation générique. Voir Recevoir des fonds.
• Le portail de webhooks regroupe désormais les types d’événements v3 par ressource et affiche le schéma de payload de chaque événement ainsi qu’un exemple. Les anciens types d’événements apparaissent dans un groupe Legacy distinct et sont marqués comme obsolètes. Les points de terminaison qui y sont déjà abonnés continuent de les recevoir ; utilisez les types d’événements v3 pour les nouveaux abonnements. Voir Webhooks.
• Les rechargements en sandbox émettent désormais les événements webhook transfer.created et transfer.state_changed. Voir Tester dans la sandbox.
• accountProvisioning indique désormais issued lorsque le client possède déjà un compte émis actif. Voir Capacités et exigences.
• Dans le panneau marchand, les détails des comptes bancaires s’ouvrent dans un volet avec les logos des banques. Voir Comptes.
• Le panneau marchand désigne les mouvements de fonds par Pay in et Pay out, maintient votre session ouverte pendant six heures et envoie les demandes d’aide au support Swipelux par e-mail.
• Dans les tâches d’admission qui acceptent la soumission directe, les exigences éligibles déjà étayées par le profil client ou par des documents téléversés passent automatiquement à in_review. Voir Capacités et exigences.

​

Corrigé

• Redemander une capacité annulée n’échoue plus à cause de dossiers de demande remplacés ou d’exigences obsolètes.
• Les capacités enregistrées sous l’ancien identifiant Fedwire retiré sont désormais lues comme wire au lieu de renvoyer 500.

​

Ajouté

• GET /v3/customers/{customerId}/applications liste les dossiers de demande d’un client, avec les capacités demandées pour chaque dossier et les capacités couvertes par son approbation. Une seule approbation auprès d’une banque peut couvrir plusieurs capacités. Les dossiers historiques conservés pointent vers leur successeur via supersededByApplicationId. La liste prend en charge la pagination par curseur et updatedAfter. Voir Capacités et exigences.
• Les réponses de POST /v3/customers/{customerId}/capabilities/{capabilityId} incluent selectedApplicationId pour les capacités adossées à un dossier. Il identifie le dossier de demande existant que la requête a réutilisé, ou le dossier qu’elle a ouvert. Voir Capacités et exigences.
• Les institutions renvoyées par GET /v3/institutions et par la liste des capacités prises en charge incluent un champ logoUrl pouvant être nul. Utilisez-le pour afficher l’identité visuelle de la banque lorsqu’elle est disponible, et revenez au nom de l’institution lorsqu’il vaut null. Voir Capacités et exigences.
• Les paiements SWIFT en USD sont désormais disponibles. Les paiements SWIFT nécessitent au moins 100 USD. Le panneau marchand recueille les instructions bancaires SWIFT des destinataires. Voir Envoyer des fonds.
• Les comptes bancaires émis peuvent recevoir des fonds via SWIFT avec des coordonnées de réception nominatives. Voir Émettre un compte bancaire.
• USDT est désormais pris en charge comme source pour les paiements ACH et Wire. Voir Envoyer des fonds.
• Les comptes bancaires émis acceptent settlement.currency avec la valeur USDC ou USDT pour choisir le stablecoin livré au portefeuille de règlement, indépendamment de la devise du compte du portefeuille. Omettez-le pour continuer à régler dans la devise du portefeuille. Voir Émettre un compte bancaire.
• Les comptes bancaires SWIFT et les destinations des destinataires acceptent bankCity, bankState, bankPostalCode et bankAddressLine2, ainsi que les champs facultatifs beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode et les coordonnées d’une banque intermédiaire. Voir Envoyer des fonds.
• Les coordonnées des comptes bancaires émis incluent achRoutingNumber et wireRoutingNumber lorsque la banque fournit des numéros de routage ACH et Wire distincts, ainsi que bankLogoUrl pour la banque réceptrice. Voir Émettre un compte bancaire.
• Les événements webhook capability.created incluent applicationId et un origin valant requested ou approval, afin que vous puissiez distinguer les capacités que vous avez demandées de celles couvertes par une approbation. Voir Webhooks.
• Les demandes d’exigence peuvent déclarer un format de validation constraints.format, par exemple http_url, us_ssn, us_ein ou bank_industry_classification. Voir Capacités et exigences.

​

Modifié

• La création de comptes bancaires dans le panneau marchand commence désormais par la sélection de la banque, et les comptes bancaires affichent des numéros de routage ACH et Wire distincts. Voir Comptes.
• L’énumération network inclut désormais solana. Il s’agit d’une énumération ouverte : acceptez donc les valeurs de réseau que vous ne reconnaissez pas. Voir Comptes.
• L’ouverture d’un lien de vérification hébergé pour une tâche dont les exigences restantes nécessitent une soumission directe renvoie 409 verification_session_not_allowed. Soumettez plutôt ces exigences sous forme de soumission de tâche. Voir Erreurs et nouvelles tentatives.
• L’archivage d’un compte émis dont le provisionnement n’est pas encore finalisé renvoie 409 account_provisioning_unresolved. Réessayez une fois le provisionnement finalisé. Voir Erreurs et nouvelles tentatives.
• Les nouvelles demandes de compte bancaire nommé sont mises en file d’attente pour le provisionnement dès la création du compte, au lieu d’attendre la prochaine actualisation du client. Voir Émettre un compte bancaire.

​

Supprimé

• Les coordonnées de réception SWIFT mutualisées ne sont plus proposées pour les nouveaux comptes. Utilisez plutôt des coordonnées de réception SWIFT nominatives. Voir Émettre un compte bancaire.

​

Corrigé

• Les lectures de transferts de paiement renvoient désormais le destinataire de la cotation.
• La création d’un compte ACH après l’archivage d’un compte existant ne renvoie plus 409, et les demandes de compte en attente archivées n’occupent plus d’emplacement de compte.
• Les frais bancaires des cotations de pay-in en devise locale sont indiqués dans la bonne devise fiat.

​

Ajouté

• GET /v3/webhooks/{webhookId} lit un point de terminaison de webhook unique et sa sélection events. Voir Webhooks.
• Les exigences des tâches publient désormais allowedValues et un valueSchema au format JSON Schema pour les champs de profil, y compris les champs d’adresse obligatoires. Les champs de pays indiquent un valueType ou un itemValueType égal à country, soit un code ISO 3166-1 alpha-2. Vous pouvez afficher les champs de saisie et les choix sans les coder en dur. Voir Capacités et exigences.
• Les portefeuilles Tron existants peuvent désormais envoyer de l’USDT vers les comptes de portefeuille externe du client, et les lectures de transfert incluent un lien vers un explorateur de blocs pour les transactions Tron. Il n’est pas possible d’émettre de nouveaux portefeuilles sur Tron. Voir Envoyer des fonds.
• Les exigences des tâches peuvent déclarer requiredWhen (à renseigner uniquement lorsqu’une réponse oui/non désignée correspond), profileAssertion (us_person) et ownershipPolicy, et les demandes de documents peuvent définir identityMetadataRequired et maxIssueAgeDays. Les réponses aux tâches acceptent documentMetadata (idNumber, issuingCountry, issuedOn) pour les documents référencés, et les lectures de tâches renvoient les réponses déterminantes examinées dans conditionValues. Voir Capacités et exigences.
• Les exigences documentaires peuvent lister des acceptedDocumentSets, et les exigences relatives aux parties liées peuvent demander une qualification associated_person ou control_person en plus de beneficial_owner. Voir Capacités et exigences.
• Les objets correction des transferts couvrent désormais aussi les paiements financés en échec : kind: funding_failure avec une action compensatoire recover_source_funding, un recoveryStatus valant unknown ou reported, et des sorties créditées en USDT. Voir Cotations et transferts.

​

Modifié

• PATCH /v3/webhooks/{webhookId} accepte désormais les anciens types d’événements auxquels le point de terminaison est déjà abonné, ce qui vous permet de les conserver pendant que vous ajoutez des types d’événements v3. events remplace l’intégralité de la sélection : incluez donc chaque type d’événement que vous souhaitez conserver. L’ajout d’un ancien type d’événement que le point de terminaison n’avait pas déjà renvoie 400 validation_error. Voir Webhooks.
• Les identifiants bancaires des destinataires et des comptes sont validés avant leur enregistrement. Voir Destinataires.
• Les demandes de capacité, les soumissions de tâches et les changements de statut en sandbox renvoient désormais 409 capability_application_stale au lieu de 500 lorsqu’une capacité a été créée dans le cadre d’un modèle d’onboarding antérieur. Voir Erreurs et nouvelles tentatives.
• La page RFI publique est désormais un formulaire unique et continu. Elle prend en charge les personnes liées et recueille un numéro d’identification fiscale par personne. Voir Exigences documentaires.
• Les cotations et les transferts renvoient 409 customer_bank_limit_exceeded lorsqu’un paiement dépasse le plafond quotidien ou mensuel restant du client auprès de la banque, et 503 customer_bank_limits_unavailable lorsque ce plafond ne peut pas être vérifié. Les transferts renvoient 409 payout_execution_unavailable lorsqu’un paiement ne peut pas démarrer à partir de sa cotation. Voir Erreurs et nouvelles tentatives.
• Les mises à jour de clients et de parties liées qui entrent en conflit avec une admission bancaire terminée renvoient 409 field_conflicts_with_completed_intake avec le taskId et les fields.

​

Corrigé

• L’historique des capacités annulées reste consultable.
• Les paiements par wire s’affichent et se filtrent correctement dans la liste des transactions du panneau marchand.

​

Modifié

• POST /v3/transfers et les lectures de transfert utilisent checkoutMethod au lieu de paymentMethod pour la présélection du paiement par carte hébergé, et acceptent card, apple_pay, google_pay, cash_app, sepa et blik. La liste est ouverte et peut s’étendre. paymentMethod n’est plus reconnu ; les requêtes qui l’envoient encore sont traitées comme s’il avait été omis. sepa et blik sont des options de financement à l’intérieur du paiement par carte hébergé, et non des capacités Swipelux. Voir Recevoir des fonds.

​

Ajouté

• POST /v3/transfers accepte un paymentMethod facultatif avec la valeur card, apple_pay ou google_pay pour les devis par carte. Le paiement hébergé s’ouvre sur la méthode demandée lorsqu’elle est disponible pour le client et son appareil, les lectures du transfert renvoient la demande, et les montants et frais du devis restent inchangés. Voir Recevoir des fonds.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview accepte institutions pour prévisualiser les tâches de banques spécifiques renvoyées par la liste des capacités prises en charge. Voir Capacités et exigences.

​

Modifié

• Les cotations par carte reflètent désormais les frais de checkout et le montant net d’USDC livré. Voir Recevoir des fonds.
• Les cotations de paiement rejetées renvoient un code de problème spécifique au lieu d’un échec générique : quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported ou quote_failed, et 503 quote_temporarily_unavailable lorsque la cotation peut être relancée plus tard. Voir Erreurs et nouvelles tentatives.

​

Corrigé

• Les cotations par carte n’échouent plus à cause de l’arrondi des frais.
• Rouvrir un lien KYC hébergé ne renvoie plus 409 kyc_process_conflict lorsque les réponses au questionnaire contiennent des espaces superflus.
• Les confirmations de retrait par passkey bloquées dans le panneau marchand se rétablissent désormais.

​

Ajouté

• POST /v3/customers/{customerId}/documents accepte désormais aussi un corps application/json avec storageKey, fileName et type. Le storageKey doit être une référence récente à portée client, mise en attente via l’ancien flux direct-upload, et le téléversement passe les mêmes validations de taille et de signature de fichier que les téléversements multipart. Voir Migrer vers v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download renvoie une url de téléchargement pour un document client actif. L’URL expire après une heure et sert le fichier en pièce jointe. Les documents archivés, inconnus ou appartenant à un autre client renvoient 404. Voir Capacités et exigences.
• Demander une capacité pour une entreprise sans bénéficiaire effectif crée désormais une tâche d’admission pour en ajouter un au lieu d’échouer avec une erreur 503. Les demandes qui ne peuvent pas aboutir renvoient 422 beneficial_owner_required avec des instructions pour ajouter une partie liée individuelle avec une participation déclarée ou d’au moins 25 %. Voir Actionnaires, UBO et personnes de contrôle.
• Le tableau des tâches du panneau marchand affiche désormais le sujet et la portée de capacité de chaque demande, afin que vous puissiez voir qui et quoi couvre une demande de conformité. Voir Capacités et exigences.
• Les champs de classification sectorielle du panneau marchand proposent désormais des codes NAICS consultables sur les profils clients et les tâches d’exigence. Voir Parcours KYB.
• Les instructions bancaires de pay-in peuvent inclure bankName, bankAddress, accountHolderName et accountHolderAddress. Affichez-les avec les autres coordonnées bancaires. Voir Recevoir des fonds.
• POST /v3/transfers accepte un redirectUrl facultatif qui ramène le client vers votre application après un checkout hébergé par carte ou Apple Pay. L’arrivée sur l’URL ne confirme pas la finalisation ; utilisez les lectures de transfert ou les webhooks. Voir Recevoir des fonds.
• Les transferts créés par une Rule v3 apparaissent dans les lectures et les listes de transferts avec origin: rule et émettent des événements transfer.state_changed comme les autres transferts. Filtrez-les avec GET /v3/transfers?origin=rule. Voir Cotations et transferts.
• Les documents d’identité des clients et des parties liées acceptent sideApplicability (front_only, front_and_back ou unknown), et les tâches peuvent recueillir comme réponses des informations sur les documents d’identité telles que type, number, issuingCountry, issuingRegion, issuedOn, expiresOn et doesNotExpire. Voir Capacités et exigences.

​

Modifié

• Les soumissions de coordonnées bancaires en conflit avec une configuration bancaire en cours renvoient désormais 409 ops_rail_handoff_conflict. Conservez les identifiants de vos documents téléversés et relancez la même soumission après la résolution du conflit au lieu de téléverser à nouveau les documents. Voir Erreurs et nouvelles tentatives.
• Le minimum pour les dépôts de stablecoins non annoncés dans les portefeuilles clients est désormais de 1 unité au lieu de 10. Les dépôts plus petits sont toujours traités comme de la poussière. Voir Recevoir des fonds.
• La configuration des webhooks est désormais isolée par environnement. Le portail de webhooks s’ouvre limité à l’environnement depuis lequel vous le demandez, de sorte que les points de terminaison sandbox et production ne partagent plus leurs paramètres. Voir Webhooks.
• Le panneau marchand déduit désormais les méthodes de pay-in disponibles des capacités v3 du client, de sorte que la configuration de compte ne propose que les méthodes auxquelles le client a droit. Voir Comptes.
• Les formulaires RFI recueillent désormais les bénéficiaires effectifs qualifiés avec des invites plus courtes et plus claires, et l’historique RFI s’affiche sous forme de jalons de cycle de vie. Voir Exigences documentaires.
• Les tâches ouvertes sans date d’échéance explicite définissent désormais dueAt par défaut à 31 jours après leur création. Voir Capacités et exigences.

​

Supprimé

• Le panneau marchand ne propose plus Fedwire lors de l’ajout de nouvelles méthodes de pay-in. Les comptes Fedwire existants restent consultables. Voir Comptes.

​

Corrigé

• Les dépôts USDT non annoncés dans les portefeuilles clients sont désormais reconnus et réglés au lieu d’être ignorés.
• Les justificatifs déjà soumis sont désormais repris dans les autres tâches qui exigent le même élément, afin que les clients ne se voient pas demander deux fois le même document.
• Redemander une capacité ne supprime plus les routes bancaires déjà prêtes, de sorte que les coordonnées de compte émises restent stables.
• Les vues d’instructions bancaires du panneau marchand affichent désormais des détails complets, y compris les adresses SWIFT et l’adresse du portefeuille cible.
• Les formulaires RFI font désormais apparaître les erreurs de validation lors de la soumission, valident les descriptions de forme juridique avant l’envoi et acceptent plusieurs sites web d’entreprise.
• Vous pouvez désormais modifier les brouillons de personnes liées dans les formulaires RFI avant de les soumettre.
• Les demandes de conformité annulées n’apparaissent plus dans la liste des tâches du panneau marchand.
• Les statuts de révision des documents s’affichent de nouveau correctement dans le panneau marchand.

​

Ajouté

• Les sessions hébergées de vérification et de Conditions d’utilisation à l’échelle du client incluent désormais un objet action faisant autorité. Suivez son type available ou unavailable ; les champs plats url et expiresAt restent des miroirs de compatibilité pour les actions disponibles. Voir Capacités et exigences.
• Les rechargements de portefeuilles dans la sandbox renvoient désormais des identifiants de transfert que vous pouvez lire avec GET /v3/transfers/{transferId} ou lister avec GET /v3/transfers. Ils apparaissent comme des dépôts entrants de stablecoins terminés. Voir Tester dans la sandbox.
• Les lectures de transfert incluent un objet correction lorsque les fonds d’un transfert sont retournés ou annulés après sa finalisation. Il indique le kind de la correction, le providerStatus normalisé, l’éventuel providerShortfall et le compensatingIntent appliqué par Swipelux. Voir Cotations et transferts.

​

Modifié

• Le parcours First pay-in du panneau marchand pour les cartes et Apple Pay exige désormais un portefeuille Polygon rattaché au client. Créez ce portefeuille avant de démarrer le parcours. Voir Comptes.
• Les nouvelles requêtes et les réponses publiques utilisent sepa comme nom canonique de la méthode et de la capacité. L’alias d’entrée sepa_instant et les ressources précédemment stockées restent compatibles, mais les réponses publiques utilisent sepa. Voir Comptes.
• Les nouvelles demandes de capacité, de compte émis et de cotation Faster Payments ne sont plus disponibles. Les comptes, cotations et transferts existants restent consultables. Voir Comptes.
• La première page KYB ne recueille plus la date de naissance du représentant. Les dates de naissance des actionnaires restent une exigence distincte. Voir Parcours KYB.
• Les références de documents RFI acceptent désormais l’alias MIME image/jpg en plus de image/jpeg. Voir Exigences documentaires.
• L’historique des tâches du panneau marchand présente désormais une piste d’audit lisible sans compteurs de révision. Voir Capacités et exigences.
• Les cotations et les transferts vérifient désormais les sens pris en charge par la capacité avant tout mouvement de fonds. Utiliser une capacité dans un sens qu’elle ne prend pas en charge renvoie 422 capability_direction_unsupported, et les mouvements entre portefeuilles nécessitent une capacité stablecoin_transfers. Voir Erreurs et nouvelles tentatives.

​

Supprimé

• Le panneau marchand ne propose plus la configuration de nouveaux comptes UAEFTS. Les comptes UAEFTS existants restent consultables. Voir Comptes.

​

Corrigé

• Les formulaires RFI conservent les saisies existantes lorsqu’un réviseur ajoute un nouveau dépôt de document, afin que les réponses précédentes ne soient pas perdues lors d’un nouvel envoi.
• Le panneau marchand reprend les sessions hébergées de conformité à partir des actions disponibles sans écarter les liens valides.
• Les liens hébergés vers les Conditions d’utilisation fonctionnent désormais pour chaque portée de tâche renvoyée par l’API.
• Après une demande de Payment Access dans le panneau marchand, celui-ci ouvre la tâche d’admission renvoyée par cette demande au lieu d’une tâche issue d’une demande antérieure.
• La démonstration KYB du panneau marchand demande désormais les champs obligatoires actuels.
• Une cotation qui réutilise son portefeuille source comme destinationId renvoie désormais des détails exploitables 422 quote_direction_invalid avant tout travail du fournisseur. Voir Cotations et transferts.
• L’API rejette un encodage incorrect de la chaîne de requête avec une erreur 400 au lieu de normaliser silencieusement la requête. Voir Erreurs et nouvelles tentatives.
• POST /v3/customers/{customerId}/documents rejette désormais les corps de requête vides, non multipart ou mal formés avec une erreur 400.

​

Ajouté

• Publication du catalogue Problem Details v3 dans la spécification OpenAPI, pour que les intégrateurs puissent mapper les réponses d’erreur directement depuis le schéma. Voir Erreurs.
• Ajout de customerId aux événements webhook de compte v3, ce qui vous permet de corréler l’activité du compte au client propriétaire sans lecture supplémentaire. Voir Webhooks.
• Couverture complète des champs de profil individuel V3 dans le panneau marchand, afin que les opérateurs d’onboarding puissent examiner et modifier chaque champ KYC collecté via l’API v3. Voir Clients.
• Publication d’un guide de migration développeur v3. Voir Migrer vers v3.

​

Modifié

• Les codes pays des clients et des comptes sont désormais validés comme des valeurs ISO 3166-1 alpha-2 attribuées au moment de l’écriture. Les lectures tolèrent les valeurs stockées héritées afin que les enregistrements existants continuent à être résolus. Voir Comptes et portefeuilles.
• La disponibilité USDC est désormais limitée par réseau de destination, de sorte que les devis et transferts ne proposent USDC que sur les réseaux réellement pris en charge par la destination.
• Chaque flux d’onboarding requiert désormais les Conditions d’utilisation Swipelux. Les sessions existantes peuvent toujours être reprises. Voir Clients.
• Capability.ready continue d’indiquer l’approbation du droit. Utilisez accountProvisioning pour suivre l’émission du compte comme not_applicable, not_started, in_progress, issued ou failed. Voir Capacités et exigences.
• Les téléversements HEIC depuis iPhone sont désormais acceptés comme documents d’identité et de domicile.
• Effacer un champ de client ou de partie liée encore requis par une tâche ouverte renvoie désormais 409 field_required_by_open_task avec le taskId bloquant et les fields, au lieu d’un conflit pouvant être relancé. Terminez ou annulez la tâche avant de modifier ces champs. Voir Erreurs et nouvelles tentatives.

​

Corrigé

• Réexécuter un devis déjà consommé renvoie désormais 409 quote_execution_consumed au lieu d’une erreur générique. Voir Devis et transferts.
• Les lectures de liste de transferts et les lectures de montants de devis ne renvoient plus de 500 sur de grands résultats historiques.
• Les redirections KYC concurrentes renvoient désormais un conflit au lieu de 404, afin que les nouvelles tentatives se résolvent proprement. Les redirections hébergées ne sont plus annulées à mi-parcours, et les liens KYC peuvent toujours être repris.
• Les lectures de parties liées pour les clients individuels ne renvoient plus 404.
• Les soumissions KYB comportant des champs de portefeuille invalides sont rejetées avant la soumission, et une synchronisation échouée n’est plus signalée comme réussie dans le panneau marchand.
• Les tâches d’exigence du panneau marchand affichent désormais les réponses soumises comme complètes, suivent séparément les actions liées aux conditions, suppriment le texte de document en double, conservent les sessions KYC démarrées en attente jusqu’à leur complétion et gèrent les tâches obsolètes sans casser la vue des exigences.
• Les lignes de lien de vérification dans le panneau marchand affichent désormais une action Open sur chaque ligne, et chaque lien de tâche s’affiche dans la vue des exigences.