Skip to main content
Cette page répertorie les modifications datées apportées à l’API Swipelux. Chaque entrée précise la version concernée, le type de modification et toute action requise de la part des intégrateurs. Pour mettre à niveau une intégration existante depuis une version antérieure, consultez Migrer vers v3.

​
Non publié

Les prochaines modifications seront listées ici avant leur livraison.

​
2026-09-08

Version : v3

​
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.

​
2026-09-07

Version : v3

​
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.

​
2026-08-31

Version : v3

​
Ajouté

  • 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.

​
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.

​
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.

​
2026-08-24

Version : v3

​
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.

​
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.

​
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.

​
2026-08-17

Version : v3

​
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. Errors.
  • 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.
  • Capability.ready indique que le droit est approuvé, pas qu’un compte a été émis. Utilisez accountProvisioning pour suivre l’émission du compte : not_applicable, not_started, in_progress, issued ou failed.
  • Les téléversements HEIC depuis iPhone sont désormais acceptés comme documents d’identité et de domicile.

​
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 lectures de parties liées pour les clients individuels ne renvoient plus 404.
  • 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 d’infrastructure wallet s’affiche dans la vue des exigences.