Périmètre

Back Office

Possibilité de refuser définitivement une commande bloquée par une buying policy

Une commande qui est bloquée par une buying policy d'encours ou de quota peut être désormais refusée définitivement (la validation forcée reste également possible).

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.

Djust Pay Marketplace

Création d’une commission marketplace par fournisseur

Contexte

Djust PAY permet désormais aux opérateurs de créer une ligne de commission marketplace associée à un fournisseur, afin de définir le taux de commission (%) appliqué lors du calcul des splits de paiement au moment de la capture.

Fonctionnement métier

Une commission marketplace est définie :
- pour un fournisseur existant, identifié uniquement par son externalId,
- avec un taux exprimé en pourcentage, strictement compris entre 0 (inclus) et 100 (exclu).
Un fournisseur ne peut avoir qu’une seule ligne de commission marketplace : tout doublon est refusé.

Nouveauté API

ADM-PAY-103 - POST /v1/payments/marketplace-commissions

Exemple de requête :

{
  "supplierId": "SUP-4781-AZ",
  "commissionRate": 2.5000
}

Suppression d’une ligne de commission marketplace

Contexte

Les opérateurs peuvent désormais supprimer définitivement une ligne de commission marketplace associée à un fournisseur, lorsqu’il n’est plus éligible au modèle de commissionnement (changement contractuel, sortie du catalogue, évolution du schéma de rémunération, etc.). Cette action garantit que le fournisseur concerné ne sera plus jamais inclus dans aucun calcul de split de paiement, tout en préservant l’historique des transactions déjà réalisées.

Fonctionnement métier

La suppression porte uniquement sur la ligne de commission marketplace (pas sur le fournisseur lui-même) et est définitive.

Nouveauté API

ADM-PAY-300 - DELETE /v1/payments/marketplace-commissions/{supplierId}

Activation / désactivation d’une ligne de commission marketplace

Contexte

Les opérateurs peuvent désormais activer ou désactiver une ligne de commission marketplace associée à un fournisseur, sans modifier les paramètres financiers sensibles (taux, historique, fournisseur). Cette évolution permet de piloter finement l’éligibilité d’un fournisseur au split marketplace, tout en conservant la ligne de commission pour un usage futur.

Fonctionnement métier

La mise à jour porte exclusivement sur le statut de la ligne de commission :
- ACTIVE → la commission est appliquée lors des calculs de split,
- INACTIVE → la commission est ignorée sans être supprimée.

Nouveauté API

ADM-PAY-201 - PATCH /v1/payments/marketplace-commissions/{supplierId}

{ "status": "ACTIVE" }

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

Nouvelle version /v2 pour la validation des commandes commerciales (ORDER-212)

Contexte

L’API historique ORDER-212 (/created) 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 valider 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-212 - PUT /v2/shop/commercial-orders/{commercialOrderId}/created

-> commercialOrderId doit être un REFERENCE ID.

Dépôt de documents autorisé quel que soit le statut de la commande logistique

Contexte

Jusqu’à présent, le dépôt de documents sur une commande logistique via l’API d'administration était limité à certains statuts (WAITING_SHIPMENT, SHIPPED, COMPLETED). Ce comportement bloquait plusieurs cas d’usage métier, notamment le dépôt de documents dès les premières étapes du cycle de vie (ex. bons de commande joints dès le checkout).

Évolution apportée

La contrainte de statut est désormais levée : • Le dépôt de documents est autorisé quel que soit le statut de la commande logistique. • Cette évolution s’applique à la route d'administration : POST /v1/documents

Customer users

Mise à jour de l’adresse email d’un Customer User

La route PUT /v1/customer-users/{userId} permet désormais de modifier l’adresse email d’un Customer User

Comportements

Le champ email remplace l’adresse email existante.
Les règles de validation restent inchangées :
- L’adresse email doit être unique parmi les Customer Users
- Si le champ email est vide ou non renseigné, aucune mise à jour n’est effectuée.

Customer Account

Création de compte sans utilisateur

La route POST /v1/customer-accounts permet désormais de créer un compte client sans créer un utilisateur. Le champ createCustomerUserRequest devient ainsi optionnel.

La route ADM-CUSTOMER-USER-250 permet de rattacher un Customer User à un ou plusieurs Customer Accounts existants.

Global

Lorsqu’on appelle une API avec le mauvais type de client (ex: OPERATOR alors que CUSTOMER est attendu), on a actuellement une erreur 403 avec le détail suivant : code:"GEN0001", message:"Access forbidden"

Afin de respecter les standards API, le retour sera désormais : code:"F_E_030", message:"Permission denied. User with this role is not allowed to perform this action on this entity."