Périmètre

API

📘

NEW

PCard L3

• Gestion du numéro de facture pour les paiements P-Card Niveau 3

Contexte

Dans le cadre du support des paiements par carte achat Niveau 3 (P-Card L3), Djust PAY intègre désormais une gestion standardisée du numéro de facture lors de la capture. Certains schémas Level 3 (ex. VGIS, LID) exigent en effet un invoice number obligatoire pour constituer l’addendum transmis aux systèmes de paiement.

Cette évolution introduit un rôle générique invoiceNumber, indépendant du PSP, permettant de résoudre automatiquement le numéro de facture depuis un Custom Field porté par la commande logistique.

Fonctionnement métier

• Un Custom Field peut être associé au rôle invoiceNumber (scope ORDER_LOGISTIC, type TEXT).
• La valeur :
  • est optionnelle lors de la création de la commande,
  • devient obligatoire au moment de la capture pour un paiement P-Card L3.

Impact API & Paiement

• Le comportement de la route ADM-PAY-101 est enrichi :
  • l’erreur fonctionnelle F-E-001 couvre désormais le cas invoice number manquant, lorsque le rôle est configuré.
• Aucun nouveau code d’erreur n’est introduit ; la compatibilité API est conservée.

👍

UPDATE

Commandes

• Nouvelle version /v2 pour la mise à jour des informations de livraison (ORDER-215)

Contexte

L’API historique ORDER-215 (/shipping-information) reposait uniquement sur un business ID Djust de commande commerciale dans le path, ce qui n’est plus aligné avec les standards actuels du checkout v3 basés sur les REFERENCE IDs. Afin d’unifier les pratiques et de faciliter l’intégration côté front et partenaires, une nouvelle version /v2 de la route est introduite, tandis que la version existante est désormais dépréciée.

Fonctionnement métier

• Cette opération permet toujours de mettre à jour les informations de livraison d’une commande commerciale pendant le checkout, son fonctionnement général est inchangé.
• Seul le format d’identifiant attendu dans le path évolue.

Nouveauté API

Une nouvelle route est désormais disponible : ORDER-215 - PUT /v2/shop/commercial-orders/{commercialOrderId}/shipping-information

-> commercialOrderId doit être un REFERENCE ID.

Périmètre

API

📘

NEW

Payment commissions

Gestion des commissions marketplace par fournisseur

Djust PAY introduit une gestion centralisée des commissions marketplace par fournisseur, via une matrice dédiée administrée exclusivement par les opérateurs. Cette fonctionnalité permet de définir, contrôler et tracer le taux de commission (%) appliqué à chaque fournisseur, utilisé lors du calcul des splits de paiement côté marketplace, tout en garantissant qu’aucun fournisseur ne puisse modifier ou consulter son propre taux.

• Consultation de la commission marketplace d’un fournisseur

Contexte

Les opérateurs peuvent désormais consulter la ligne de commission marketplace configurée pour un fournisseur, afin de connaître le taux appliqué lors des calculs de split en capture de paiement. Cette fonctionnalité apporte de la transparence et facilite le diagnostic des montants reversés dans un contexte marketplace, sans exposer ni modifier de données sensibles.

Nouveauté API ADM-PAY-500 - GET /v1/payments/marketplace-commissions/{supplierId}

{
  "supplierId": "SUP-AX145",
  "supplierName": "AXSUP Industries",
  "commissionRate": 3.5,
  "status": "ACTIVE",
  "createdAt": "2025-01-10T09:12:00Z",
  "updatedAt": "2025-02-14T10:45:33Z",
  "updatedBy": "OP-998877"
}

👍

UPDATE

Devis

• Support des external IDs dans l'ajout de lignes de devis :

Afin d'améliorer la compatibilité des devis et des versions récentes de checkout, la route d'ajout de lignes au devis QUOTE-200 a été étendue.

La route QUOTE-200 - PUT /v1/shop/master-quotes/{masterQuoteId} supporte désormais un nouveau paramètre :

• idType (optionnel) :
  • valeurs possibles : DJUST_ID (défaut), EXTERNAL_ID
  • s’applique aux variants et aux custom fields présents dans le payload
  • ne s’applique pas à la master quote, qui ne possède pas encore d’external ID

Le comportement par défaut reste inchangé :

👉 si idType n’est pas fourni, l’API continue d’interpréter les identifiants en DJUST_ID pour garantir la compatibilité existante.

• Création d'une commande depuis un devis :

Contexte

Les customer users (ACCOUNT) peuvent désormais créer une commande à partir d’un devis auquel ils ont accès, via la route de checkout v3 ORDER-108 - POST /v2/shop/commercial-orders. L’objectif est de permettre la conversion directe d’un devis en commande, en reprenant ses lignes et conditions, tout en conservant un contrôle strict sur l’éligibilité du devis et le cycle de vie de la commande.

Fonctionnement métier

• Nouvelle source QUOTE supportée dans ORDER-108 La création de commande supporte désormais deux types de source :
  • OPERATION (déjà existant)
  • QUOTE (nouveau)
• Pour pouvoir être transformé en commande, le devis doit :
  • être valide (non expiré, non annulé),
  • être au statut WAITING_FOR_CUSTOMER au moment de l’appel,
  • appartenir à l’account du caller,
  • être dans le store effectif (scoping via dj-store ou store par défaut).
• Si une de ces conditions n’est pas remplie, la création est refusée.
• Contrairement aux opérations, seul le mode FULL est accepté.
• La commande créée est au statut initial DRAFT_ORDER_ON_HOLD.
  • Elle est non éditable : les appels de type ORDER-150, ORDER-213, ORDER-215… sont refusés.
  • Le paiement via PAY-101 est autorisé ; en cas de succès, la commande passe en CREATED (workflow standard).

Périmètre

Back Office

• Revue des lignes de prix et ajout du prix remisé dans l'affichage des lignes de prix d'une offre :

Le champ quantité min n’est plus bloqué et lié au champ articles par lot.

• Dans le cas d’un prix par unité, la notion d'articles par lot n’existe pas.

• Dans le cas d’un prix par lot, la valeur d'articles par lot n’est pas égale à la valeur de quantité min

  

• Ajouts des nouveaux rôles pour la gestion du flux cartes achats niveau 3 :

Deux nouveaux rôles distincts sont ajoutés pour le flux cartes achats niveau 3.

• Rôle identifiant de marché à l'account :

  Le rôle MARKET_ID est associé à un custom field à l'account de type TEXT. Il est disponible dans l'interface de configuration des rôles.

  

• Rôle identifiant d'engagement :

  Le rôle ENGAGEMENT_ID est associé à un custom field à la commande commerciale de type TEXT. Il est disponible dans l'interface de configuration des rôles.

  
  

API

📘

NEW

Orders

• Consultation des informations de paiement d’une commande logistique :

Contexte

Une nouvelle route d’administration permet désormais aux opérateurs et fournisseurs autorisés de consulter les métadonnées de paiement associées à une commande logistique.

L’objectif : offrir un accès rapide et lisible au provider, au mode de paiement et au statut du cycle de paiement, sans jamais exposer d’informations sensibles.

Fonctionnement métier

> Ce que retourne la route

Uniquement 3 champs métier, strictement limités à l’information de paiement :

• provider - prestataire utilisé (ex. DJUST_PAY, LEMONWAY, MANGOPAY)
• option - option / méthode de paiement (ex. CREDIT_CARD, BANK_WIRE, PURCHASE_CARD_L3, etc.)
• status - statut du paiement selon le référentiel interne Djust (ex. PAID, AUTHORIZED, WAITING_PAYMENT, REFUND_FAILED…)

Aucune donnée de commande, aucune donnée sensible → exposition minimale et conforme PCI.

L'API est la suivante :

ADM-ORDER-500 - GET /v1/logistic-orders/{logisticOrderId}/payment-information

{
  "provider": "DJUST_PAY",
  "option": "CREDIT_CARD",
  "status": "PAID"
}

👍

UPDATE

Incidents

• Filtrage par motif d’incident :

Afin de pouvoir réduire le nombre d’incidents à traiter en front et de faciliter la recherche, un filtre par motif d’incident est ajouté.

Il fonctionne de la même manière que le filtre customerAccountIds, il s'agit d'une liste d'id de reasons passées en query param sur la route ORDER-559 - GET /v1/shop/incidents.

Le param reasonCodes ajouté prendra en entrée une liste d’ID de reasons et fonctionne via un OU logique entre chaque valeur.

• Tri des incidents par fournisseur :

Contrairement au filtre par fournisseur, le tri par fournisseur doit s’appliquer sur le nom du fournisseur via la route ORDER-559 - GET /v1/shop/incidents.

Ainsi la possibilité de trier sur les noms des fournisseurs se fait désormais avec le sort suivant :

• supplierName:asc ou supplierName:desc qui trient respectivement les incidents par noms de fournisseurs dans l’ordre croissant (A > Z) et décroissant (Z > A).

Buying Policies

• Refus / abandon d’une commande logistique en statut BLOCKED_BY_POLICY par un opérateur

Contexte

Historiquement, seule une logique “fournisseur” permettait de refuser une commande logistique, et uniquement lorsqu’elle était en attente de traitement (ORDER_CREATED, WAITING_SUPPLIER_APPROVAL). Avec l’arrivée des buying policies (encours, quotas), certaines commandes peuvent désormais rester bloquées très tôt dans leur cycle, au statut BLOCKED_BY_POLICY.

Pour permettre un abandon explicite dans ces situations, la route de decline est étendue : • NEW Les opérateurs peuvent désormais refuser une commande bloquée par une buying policy. • Les fournisseurs conservent leur comportement historique. • Les customer users (ACCOUNT) ne peuvent jamais utiliser cette action.

La route API mise à jour :

• ADM-ORDER-200 - PUT /v1/logistic-orders/{logisticOrderId}/decline

L'action dans le backoffice sera disponible prochainement

Périmètre

API

👍

UPDATE

Commandes

• Nouvelle version d'API pour la mise à jour de adresses de facturation - ORDER-213

Contexte :

L’API historique ORDER-213 (/billing-information) n’acceptait qu’un business ID Djust dans son path, ce qui ne correspond plus au standard actuel des routes Checkout v3 basées sur les REFERENCE IDs. Pour corriger cela, une nouvelle version /v2 de la route est introduite, tandis que la version existante est désormais dépréciée.

Fonctionnement :

• Aucun changement fonctionnel : seul le type d’ID attendu dans le path évolue.

Nouveauté API :

ORDER-213 - PUT /v2/shop/commercial-orders/{commercialOrderId}/billing-information

• commercialOrderId doit être un REFERENCE ID, conformément au comportement des routes du checkout order v3.

Périmètre

Back Office

• Améliorations graphiques et optimisations de design :

  Dans la continuité de la refonte globale du Back Office de Djust, un redesign des pages suivantes a été apporté afin de simplifier l'expérience utilisateur.

  • Page de détail variant : Catalog -> Products -> Product detail -> Product variant detail.
  
  

Cette version comprend les périmètres 3.91.0 et 3.92.0.

Périmètre

Back Office

• Ajout de la configuration de la gestion d'activation des produits :

  L'activation/désactivation du workflow simplifié d'activation de produit est désormais accessible via les paramètres globaux d'application.

  
  

• Ajout de la configuration du mode d'indexation :

  Il est désormais possible de positionner le mode d'indexation via la page des paramètres globaux d'application.

  
  

• Ajout de la possibilité de modifier un nom de job dans le Data Hub :

  Il est désormais possible de mettre à jour le nom d’un job d’import.

  ⚠️ Le nom doit être unique

• Ajout de la possibilité de filtrer la liste des tolérances des Buying Policies d'encours :

  

API

📘

NEW

Paiement

• Paiement par carte achat niveau 3 (P-Card L3)

Contexte :

Djust PAY supporte désormais le démarrage d’un paiement Carte Achat Niveau 3 (P-Card L3) via une PayPage embarquée en mode “token-only”. Ce mécanisme permet d’afficher une page de paiement hébergée (par notre prestataire dédié ITS), où l’acheteur saisit sa carte, sans que Djust ne manipule de PAN - conformité PCI 100% maintenue.

Ce token PayPage est généré côté serveur, puis transmis au front dans la réponse PAY-101 sous forme d’action de redirection POST. L’autorisation carte est ensuite réalisée en server-to-server.

Fonctionnement métier :

1. Pré-check obligatoire (PAY-502)

Avant l’appel PAY-101, le front exécute un pré-check. Il valide la complétude des champs L3 nécessaires au flux carte achat. • Si ready = false → pas de démarrage PayPage. • Si ready = true → le front peut appeler PAY-101.

2. Génération du Token PayPage

Lorsqu’un paiement est initié avec (PAY-101) :

paymentMethodData.type = "purchasing_card_l3"

3. Saisie carte + 3DS v2

Le front exécute l’action retournée par PAY-101 : • method = POST • url = PayPageURL (configurable via ADM-SETTINGS-201) • data = { SupplierID, Token }

La PayPage s’affiche dans l’iFrame, la saisie carte est entièrement gérée par Djust et son prestataire de paiement ITS.

4. Postback

Après saisie → Djust reçoit un callback S2S contenant les informations nécessaires au déclenchement de l'autorisation.

{
  "resultCode": "RedirectShopper",
  "action": {
    "paymentMethodType": "purchasing_card_l3",
    "url": "https://secure.hosted-pay.example/PayPage",
    "method": "POST",
    "type": "redirect",
    "data": {
      "SupplierID": "ACME123",
      "Token": "PP-7d3f1b2c-xxxx-9a1"
    }
  }
}

Dès qu'un paiement est initié, le statut de paiement évolue comme suit :

NOT_INITIATED → INIT_PAYMENT → AUTHORIZATION_PENDING

👍

UPDATE

Commandes

• Filtrage des commandes d'une organisation par statut logistique

Contexte :

Les customer users peuvent désormais filtrer les commandes logistiques de leur organisation par statut lorsqu’ils consultent la liste des commandes via la route ACCOUNT-555. Cette évolution améliore la lisibilité et la recherche des commandes, en s’alignant sur ce qui existe déjà côté endpoint ACCOUNT-550.

Fonctionnement métier :

Nouveau filtre : logisticOrderStatuses

• Filtre optionnel, multi-valeurs.
• Accepte une ou plusieurs valeurs séparées par virgule :

logisticOrderStatuses=WAITING_SUPPLIER_APPROVAL,SHIPPED

• Renvoie uniquement les commandes logistiques appartenant à ces statuts.
• Valeurs inconnues → ignorées silencieusement (comportement standard).
• Si aucune valeur n’est fournie → toutes les commandes de l’organisation sont renvoyées.

Exemple d'appel :

GET /v1/shop/customer-accounts/organisations/ORG-789/orders?logisticOrderStatuses=WAITING_SUPPLIER_APPROVAL,SHIPPED
Headers:
  dj-client: ACCOUNT
  dj-api-key: xxxxx
  dj-store: store_fr

Périmètre

Back Office

• Ajout de la référence externe de la commande dans la page détail order :

  La référence externe d'une commande est désormais affichée dans son détail.

  
  

API

📘

NEW

Paiement

• Paiement par carte achat niveau 3 (P-Card L3)

Contexte :

Djust PAY va très prochainement prendre en charge le paiement par carte achat (P-Card) au niveau 3.

Cette évolution permet aux entreprises clientes d’utiliser leurs cartes d’achat pour régler leurs commandes B2B tout en bénéficiant du niveau de granularité requis par les programmes de facturation corporate (Level 3), notamment sur les marchés publics en France.

Fonctionnement métier :

• Pour pouvoir mettre en place la saisie des informations de cartes, il est nécessaire avant tout de pouvoir configurer par un administrateur les différentes URLs de redirection possibles pour le bon fonctionnement du paiement :
  • onSuccessPath → chemin relatif pour la redirection succès UX.
  • onErrorPath → chemin relatif pour la redirection échec UX.
  • postbackUrl → URL HTTPS absolue du callback S2S (réception du token de paiement).
  • payPageUrl → URL HTTPS absolue de la PayPage utilisée comme PAY-101.action.url.
• Les données sensibles ne transitent jamais par le front ni par Djust.

Les URLs front sont construites à partir de la base de redirection effective (effectiveRedirectBaseUrl), calculée automatiquement selon la configuration du store view.

APIs correspondantes :

🔍 Récupérer la configuration PCard-L3 (provider ITS couplé à Djust PAY)

ADM-SETTINGS-500 - GET /v1/settings/payments/its

{
  "onSuccessPath": "/payment/return",
  "onErrorPath": "/payment/error",
  "postbackUrl": "https://pay.djust.example/connectors/its/postback",
  "payPageUrl": "https://its.example/PayPage",
  "effectiveRedirectBaseUrl": "https://shop.example",
  "successUrlPreview": "https://shop.example/payment/return",
  "errorUrlPreview": "https://shop.example/payment/error",
  "updatedAt": "2025-09-26T12:34:56Z"
}

✏️ Créer / Mettre à jour la configuration PCard-L3

ADM-SETTINGS-201 - PUT /v1/settings/payments/its

{
  "onSuccessPath": "/payment/return",
  "onErrorPath": "/payment/error",
  "postbackUrl": "https://pay.djust.example/connectors/its/postback",
  "payPageUrl": "https://its.example/PayPage"
}

⚙️ Workflow global

1. Le front appelle PAY-101 avec un returnPath, la locale, le pays et paymentMethodData.type = purchasing_card_l3.
2. Djust PAY appelle ITS (Provider PCard L3) en lui transmettant les trois URLs configurées.
3. L’acheteur saisit sa carte sur la PayPage.
4. L'utilisateur est redirigé vers le front (succès / échec).
5. Djust PAY lance l’autorisation carte ensuite côté serveur.

Périmètre

Back Office

• Améliorations graphiques et optimisations de design :

  Dans la continuité de la refonte globale du Back Office de Djust, un redesign des pages suivantes a été apporté afin de simplifier l'expérience utilisateur.

  • Page de détail produit : Catalog -> Products -> Product detail.

• Opérations - Gestion des custom fields Opérations :

  Afin de pouvoir manipuler les Custom Fields de type OPERATION dans le Back Office Djust, une nouvelle page de settings identique aux pages de CF existantes a été créée. La page est accessible via Settings -> Catalog and offer management -> Operation custom fields.

Order

• Ajout d'un statut de paiement initial : NOT_INITIATED

  Afin de rendre plus compréhensible les commandes sans paiement initié ou sans aucun paiement, un statut initial NOT_INITIATED a été ajouté. Il remplace le statut AUTHORIZED qui pouvait apparaître à tort.

Périmètre

API

👍

UPDATE

Orders / Opérations

• Filtrage et tri des commandes commerciales par source

Contexte :

Les acheteurs (ACCOUNT) peuvent désormais repérer et segmenter leurs commandes issues d’une Opération directement dans la liste des commandes.

Objectifs : retrouver rapidement « mes commandes de l’opération X », comparer des périodes, analyser l’impact des campagnes, et exporter facilement des vues cohérentes.

• Route concernée : GET /v1/shop/commercial-orders (ORDER-560)

Filtres & tris ajoutés

• 🧭 Filtres « source »
  • sourceTypes (multi-valeurs) : OPERATION (principal), QUOTE, ORDER, CART (cette version vise uniquement OPERATION)
    • Inclut les commandes dont order.sourceType appartient à la liste.
  • sourceIds (multi-valeurs) : identifiants d’opérations (ou autres sources)
    • Si sourceTypes contient OPERATION → ne retient que les commandes avec sourceType = OPERATION ET sourceId présent dans la liste.
    • Si sourceTypes est absent → fait correspondre tous les sourceType dont le sourceId est dans la liste.
    
    

    Les filtres existants restent disponibles et combinables : connectedUserOnly, customerAccountIds, isValidated, nbPreviewLines, locale.

• ⏱️ Tris disponibles
  • createdAt (défaut) - commandes les plus récentes d’abord (tie-breaker reference:asc)
  • validatedAt - prioriser les commandes validées récemment
  • updatedAt - utile pour le suivi opérationnel
  • sourceType - regrouper/segmenter par type de source (ex. OPERATION)
  • sourceId - ordonner par identifiant de source
  • reference - tri naturel pour l’utilisateur

• Exemples

GET /v1/shop/commercial-orders?locale=fr-FR&sourceTypes=OPERATION
Headers: dj-client: ACCOUNT, dj-store: store_fr

GET /v1/shop/commercial-orders?locale=fr-FR&sourceTypes=OPERATION&sourceIds=OP-2025-001,OP-2025-007

GET /v1/shop/commercial-orders?locale=fr-FR&sort=sourceType:asc,sourceId:asc

GET /v1/shop/commercial-orders?locale=fr-FR&isValidated=true&sort=validatedAt:desc

GET /v1/shop/commercial-orders?locale=fr-FR
-- applique createdAt:desc puis reference:asc (tie-breaker), nulls en fin

Périmètre

Data Hub

• Update des adresses email dans l'import des Customer Users

Il est désormais possible de modifier l’adresse email des utilisateurs lors de l’import des Customer users depuis le data hub. Cette amélioration permet de corriger plus facilement les erreurs d’adresses, de mettre à jour des informations obsolètes et d’assurer une meilleure qualité des données utilisateurs.

Punchout

• Ajout de la clé de punchout dans le retour de l'authentification

Dans le cas des solutions multi-punchouts, l’attribut tenantConfigurationKey est désormais présent dans le JWT généré afin de connaître le punchout utilisé par le front client.