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 :

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.

Génération du Token PayPage

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

paymentMethodData.type = "purchasing_card_l3"

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.

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