Périmètre

🖥️ Back-Office

📘
NEW

Dashboard Payouts Marketplace

Contexte

Les opérateurs marketplace ne disposaient pas d'interface dédiée pour consulter les payouts marketplace depuis le back-office. Le suivi nécessitait un accès direct aux systèmes de paiement ou une extraction manuelle, là où les dashboards supplier payouts et funding transfers étaient déjà disponibles.

Fonctionnement

Un nouveau dashboard back-office permet désormais de consulter les payouts marketplace :

Liste paginée : vue d'ensemble des payouts marketplace avec filtres et tri, alignée sur l'ergonomie des dashboards existants (supplier payouts, funding transfers).
Détail : consultation du détail complet d'un payout marketplace (montant, statut, dates, informations associées).

L'accès est réservé aux utilisateurs OPERATOR disposant des droits d'administration sur le domaine Payments.

👉 Côté métier : les opérateurs marketplace peuvent désormais suivre et consulter leurs payouts directement depuis le back-office, sans dépendance aux outils internes ou au PSP.

👉 Côté technique : nouveau dashboard administration aligné sur le pattern existant des dashboards PAY (supplier payouts, funding transfers).

🔗 Data Hub

📘
NEW

Sélection du Store cible sur les jobs d'import Order

Contexte

Dans un contexte multi-store, les commandes importées via un job d'import Order (CSV ou Connecteur API) étaient systématiquement rattachées à la Store View par défaut du tenant. Il n'était pas possible de cibler un Store spécifique sans manipulation manuelle.

Fonctionnement

Le paramètre storeExternalIds, déjà disponible sur les endpoints de création et mise à jour de jobs, permet désormais de préciser le Store cible pour les jobs d'import Order. Les commandes externes créées par un job configuré sont automatiquement rattachées à la Store View par défaut du Store choisi, sans manipulation d'identifiant de Store View.

Sans configuration, le comportement reste inchangé : les commandes sont rattachées au Store par défaut du tenant.

Un job dont le Store configuré n'existe pas ou plus est rejeté à la création/mise à jour (HTTP 400) ou signalé en erreur dans le rapport d'exécution.

Impact API

POST /v2/mapper/jobs et PUT /v1/mapper/jobs/{jobId} : utilisation du paramètre storeExternalIds pour les jobs de type Order
Erreur HTTP 400 si le Store référencé est invalide ou inexistant

📄 Documentation :

👉 Côté métier : les opérateurs multi-store peuvent désormais cibler précisément le Store de destination de leurs imports de commandes, sans intervention technique.

👉 Côté technique : le paramètre storeExternalIds est exploité sur les jobs d'import Order — aucun nouveau endpoint, rétrocompatibilité totale.

👍
UPDATE

Renommage du label d'import Supplier « Supplier Deleted »

Contexte

Le label Supplier Deleted affiché dans le mapping d'import Supplier laissait penser à une suppression définitive, alors que le champ correspond à une désactivation (passage à inactif).

Fonctionnement

Le label est renommé en Mark Supplier as Inactive, cohérent avec les conventions déjà en place pour les autres flags d'action (Mark Order Line For Deletion, Mark Account as Inactive, etc.).

Aucun changement de comportement : seul le libellé affiché dans l'interface de configuration des mappings est modifié.

👉 Côté métier : le libellé du champ de mapping reflète désormais fidèlement l'action réalisée (désactivation, non suppression), évitant toute confusion lors de la configuration.

👉 Côté technique : aucun impact sur les mappings existants ni sur la logique d'import — changement de label uniquement.

🛠️ API

📘
NEW

Téléchargement des fichiers exportés

Contexte

Les fichiers générés lors d'un export (SFTP ou Connecteur API) n'étaient pas conservés après l'envoi. En cas de perte côté client ou d'écart dans les données, il était impossible de vérifier ce qui avait été transmis sans intervention technique.

Fonctionnement

Chaque fichier exporté (SFTP XML/JSON ou Connecteur API JSON) est désormais automatiquement archivé avant la tentative d'envoi. En cas d'échec d'envoi (erreur SFTP, timeout HTTP), le fichier reste disponible au téléchargement.

Les fichiers archivés sont nommés de manière explicite (exported-file-{exportIntegrationId}.{extension}), facilitant l'identification lors du téléchargement de plusieurs archives.

La signed URL retournée est valide 24 h. Les fichiers sont conservés 90 jours puis supprimés automatiquement. Ce mécanisme ne s'applique qu'aux exports postérieurs à la mise en production.

Impact API

GET /v2/jobouts/executions/{executionId}/exported-file/signed-url — operationId : ADM-JOBOUT-501
Réponse : 302 Found avec header Location contenant la signed URL, ou 404 si le fichier est absent ou expiré
Accès : OPERATOR uniquement

📄 Documentation :

👉 Côté métier : vérifiez et re-transmettez les données exportées en toute autonomie, sans solliciter l'équipe technique.

👉 Côté technique : nouvel endpoint GET sous le tag Jobs Administration, aucune modification des flux d'export existants.

Gestion des processus d'onboarding PAY

Contexte

La gestion des processus d'onboarding des suppliers sur la plateforme de paiement nécessitait des interventions manuelles ou des accès directs aux systèmes internes. Aucune API ne permettait de consulter, piloter ou relancer ces processus de manière autonome.

Fonctionnement

Deux axes sont désormais couverts par l'API :

Consultation : un endpoint de liste paginée avec filtres (type, statut, supplierId, supplierName) et un endpoint de détail complet (organizationProfile, pspEntities, steps) permettent de suivre l'état de chaque processus d'onboarding.

Le scoping SUPPLIER est appliqué : un supplier ne voit que ses propres processus (404 si tentative d'accès à un processus tiers).

Cycle de vie : cinq actions sont disponibles pour piloter les processus :

Démarrage depuis le brouillon
Relance après échec
Suspension
Réactivation
Annulation (avec nettoyage côté PSP)

Un contrôle strict des transitions de statut est appliqué : une transition invalide retourne le code d'erreur F-E-028. Référence des codes d'erreur : Error / Warning codes

Impact API

Consultation :

GET /v1/payments/onboarding — operationId : ADM-PAY-557
GET /v1/payments/onboarding/{processId} — operationId : ADM-PAY-508

Cycle de vie :

POST /v1/payments/onboarding/{processId}/start — operationId : ADM-PAY-109
POST /v1/payments/onboarding/{processId}/retry — operationId : ADM-PAY-110
POST /v1/payments/onboarding/{processId}/suspend — operationId : ADM-PAY-111
POST /v1/payments/onboarding/{processId}/reactivate — operationId : ADM-PAY-112
POST /v1/payments/onboarding/{processId}/cancel — operationId : ADM-PAY-113

📄 Documentation : Merchant Onboarding Manual Flow

👉 Côté métier : suivez et pilotez l'onboarding de vos suppliers directement depuis l'API, avec une visibilité complète sur chaque étape du processus.

👉 Côté technique : 7 nouveaux endpoints sous le domaine Payments, avec scoping SUPPLIER et contrôle strict des transitions de statut.

Rattachement de catégories de classification à une famille logistique

Contexte

Dans le cadre du module de livraison, les familles logistiques peuvent être associées à des catégories de classification pour définir les règles de shipping applicables. Un nouvel endpoint permet de gérer ce rattachement.

Fonctionnement

L'endpoint permet d'attacher une ou plusieurs catégories de classification à une famille logistique. Les règles suivantes s'appliquent :

Une catégorie ne peut être rattachée qu'à une seule famille logistique à la fois.
Si une catégorie est déjà rattachée à une autre famille, elle est automatiquement détachée de l'ancienne et rattachée à la nouvelle.
Un tableau vide ou null dans le champ classificationCategoryIds est accepté silencieusement (204, aucune modification).
Les identifiants attendus sont les external IDs des catégories.

Accès réservé aux utilisateurs OPERATOR.

Impact API

PATCH /v1/logistic-families/{logisticsFamilyId}/classification-categories — operationId : ADM-LOGISTIC-FAMILY-210
Réponse : 204 No Content
Erreurs : 401 (authentification manquante), 403 (client non OPERATOR), 404 (famille ou catégorie inexistante)

📄 Documentation : Logistic Families

👉 Côté métier : les opérateurs peuvent organiser leurs familles logistiques en les associant aux catégories de classification pertinentes, directement via l'API.

👉 Côté technique : nouvel endpoint PATCH sous le domaine Shipping Administration, identifiants attendus en external ID.

Déclenchement automatique des payouts marketplace

Contexte

Dans un contexte marketplace, le déclenchement des payouts suppliers nécessitait une action manuelle ou une orchestration externe. Aucun mécanisme natif ne permettait de planifier automatiquement les payouts à intervalles réguliers.

Fonctionnement

Un mécanisme de déclenchement automatique (CRON) est désormais intégré à la plateforme. Les payouts sont déclenchés de manière planifiée, par tenant, sans intervention manuelle.

La fréquence par défaut est hebdomadaire (chaque lundi matin). Ce paramétrage est géré côté plateforme et ne nécessite aucune configuration Adyen complémentaire.

👉 Côté métier : les payouts marketplace sont désormais déclenchés automatiquement selon un calendrier régulier, garantissant la ponctualité des versements sans action manuelle.

👉 Côté technique : mécanisme CRON natif par tenant pour le déclenchement des payouts — aucun endpoint exposé, orchestration entièrement côté plateforme.

👍
UPDATE

Affectation d'un acheteur à plusieurs buying policies

Contexte

Un customer user ne pouvait être buyer que dans une seule buying policy, ce qui bloquait les utilisateurs multi-comptes (franchisés, commerciaux, support). Cette contrainte d'unicité globale est levée.

Fonctionnement

Le lien entre une buying policy et un customer account est désormais explicite : chaque buying policy est associée à un customer account spécifique. La contrainte d'unicité du buyer s'applique désormais par account (et non plus globalement).

Un même customer user peut donc être buyer dans plusieurs buying policies, à condition que chacune soit rattachée à un account différent.

Les champs customerAccountId et customerAccountName sont ajoutés aux réponses des endpoints de gestion des buying policies.

Ce changement concerne uniquement les buying policies historiques (validation manuelle).

Impact API

Endpoints de gestion des buying policies : ajout des champs customerAccountId et customerAccountName dans les réponses
Unicité du buyer désormais par account (non plus globale)
Rétrocompatibilité : les tenants mono-account ne sont pas impactés

📄 Documentation : Manual Order Validation

👉 Côté métier : les utilisateurs multi-comptes peuvent désormais être acheteurs dans plusieurs buying policies, une par account, sans contournement nécessaire.

👉 Côté technique : ajout de customerAccountId / customerAccountName sur les endpoints buying policies, contrainte d'unicité buyer réduite au scope account.

Nouveau statut de transaction PAYMENT_INITIATED

Contexte

Les transactions disposant uniquement d'un événement d'initialisation de paiement étaient affichées avec le statut PAYMENT_AUTHORIZED, ce qui portait à confusion avec les transactions réellement autorisées.

Fonctionnement

Un nouveau statut PAYMENT_INITIATED est introduit pour distinguer les transactions dont le paiement a été initié mais pas encore autorisé. Ce statut remplace PAYMENT_AUTHORIZED pour les transactions qui n'ont qu'un événement d'initialisation.

Les transactions déjà autorisées conservent le statut PAYMENT_AUTHORIZED.

Impact API

Nouveau statut PAYMENT_INITIATED dans le cycle de vie des transactions
Les filtres et endpoints de consultation des transactions acceptent ce nouveau statut

📄 Documentation : Transactions

👉 Côté métier : distinction claire entre les paiements initiés et les paiements autorisés, pour un suivi plus précis des transactions.

👉 Côté technique : nouveau statut PAYMENT_INITIATED dans l'énumération des statuts de transaction — à prendre en compte dans les intégrations consommant les statuts.

Verrouillage de la commande pendant l'autorisation de paiement

Contexte

Lorsqu'une commande commerciale était en cours d'autorisation de paiement, il était possible d'effectuer des modifications sur celle-ci avant la confirmation de l'autorisation, ce qui pouvait entraîner des incohérences entre le montant autorisé et le contenu réel de la commande.

Fonctionnement

Une commande en statut CREATED est désormais verrouillée dès qu'une demande d'autorisation de paiement est en cours (AUTHORIZATION_PENDING). Tant que l'autorisation n'est pas confirmée ou rejetée, aucune modification n'est autorisée sur la commande.

Ce verrouillage garantit la cohérence entre le montant soumis à l'autorisation et le contenu de la commande au moment de la validation.

Impact API

Les endpoints de modification d'une commande en statut CREATED retournent une erreur si une autorisation de paiement est en cours
Rétrocompatibilité : aucun impact sur les commandes dont le paiement est déjà autorisé ou qui ne sont pas en cours d'autorisation

👉 Côté métier : les commandes ne peuvent plus être modifiées pendant l'autorisation de paiement, éliminant tout risque de décalage entre le montant autorisé et le contenu de la commande.

👉 Côté technique : nouveau contrôle bloquant sur les commandes en AUTHORIZATION_PENDING — les modifications sont rejetées jusqu'à résolution de l'autorisation.

⚠️
IMPORTANT UPDATE

Mise à jour partielle des paramètres généraux (PATCH) et dépréciation du PUT

Contexte

L'endpoint PUT /v1/settings/general imposait un payload complet pour toute modification, même pour un seul paramètre. Ce comportement rendait les mises à jour ciblées risquées (écrasement involontaire de valeurs) et empêchait la modification de certains flags comme supplierCustomerAccountAssociationAllowed, absent du DTO de mise à jour.

Fonctionnement

Un nouvel endpoint PATCH permet désormais la mise à jour partielle des paramètres généraux : seuls les champs fournis dans le payload sont modifiés, les autres restent inchangés en base.

Règles :

Un body vide ou avec tous les champs à null retourne une erreur 400 (code F-E-001).
Le flag supplierCustomerAccountAssociationAllowed est désormais modifiable via ce nouvel endpoint.
Permission requise : GENERAL_SETTING_UPDATE (identique au PUT existant).

Le PUT /v1/settings/general reste fonctionnel mais est désormais déprécié. Il est recommandé de migrer vers le PATCH pour toute mise à jour de paramètres généraux.

Impact API

PATCH /v1/settings/general — nouvel endpoint de mise à jour partielle
PUT /v1/settings/general — déprécié (marqué deprecated dans le contrat OpenAPI), reste fonctionnel
Nouveau champ modifiable : supplierCustomerAccountAssociationAllowed
Erreur 400 / F-E-001 si aucun champ fourni

Référence des codes d'erreur : Error / Warning codes

📄 Documentation : Job Configuration Overview

👉 Côté métier : les paramètres généraux peuvent désormais être modifiés individuellement, sans risque d'écrasement des autres valeurs.

👉 Côté technique : nouveau PATCH /v1/settings/general (mise à jour partielle), dépréciation du PUT — migration recommandée pour les intégrations existantes.