Périmètre

BackOffice Djust

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 creation d'un fournisseur : Suppliers.
  • Page détail d'un utilisateur fournisseur.
  • Page de creation d'un job d'export : Data Hub -> Create a new job -> Export.
  • Page de detail d'un job d'export : Data Hub -> Export -> Configure job.

Filtrage des comptes clients :

Page liste des comptes clients : Customers > Accounts

  • Le champ de filtre "ID compte" utilise maintenant l’ID externe et l’ID interne.

API

📘

NEW


Buying policies

  • Montants de tolerance de crédit

Quatre nouveaux endpoints ont été ajoutés au module Buying Policies, permettant aux utilisateurs opérateurs de consulter et modifier l’état global des montants de tolerance de crédit sur la plateforme.

⚠️

Attention

Ces routes de gestion des buying policies ne sont disponibles que pour les utilisateur BackOffice opérateurs.


  • Consultation des montants de tolérance de crédit :

ADM-BUYING-POLICY-551 - GET /v1/buying-policies/credit-control/grace-amounts

Permet de de récupérer toutes les montants de tolérance de crédit configurées.
Chaque tolérance est définie par :

  • un montant ajouté au crédit disponible,
  • une période d’application (début obligatoire, fin facultative),
  • un ou plusieurs comptes associés.

Exemple de réponse :

{
  "content": [
    {
      "accountId": "string",
      "amount": 0,
      "createdAt": "2025-07-21T11:58:16.925Z",
      "endDate": "2025-07-21T11:58:16.925Z",
      "graceAmountId": "string",
      "startDate": "2025-07-21T11:58:16.925Z",
      "updatedAt": "2025-07-21T11:58:16.925Z"
    }
  ],
 ...

  • Creation des montants de tolérance de crédit:

ADM-BUYING-POLICY-151 - POST /v1/buying-policies/credit-control/grace-amount

Permet de créer un ou plusieurs montants de tolérance qui augmentent temporairement la disponibilité du crédit pour les comptes clients sélectionnés.

Contenu de la requête :

[
  {
    "accountId": "string",
    "amount": 0,
    "endDate": "string",
    "startDate": "string"
  }
]

⚠️ startDate et amount sont obligatoires. endDate est facultatif.

Exemple de réponse :

{
  "singleWarningReportDtos": [
    {
      "detail": "string",
      "id": "string"
    }
  ]
}

  • Mise à jour des montants de tolérance de crédit:

ADM-BUYING-POLICY-203 - PUT /v1/buying-policies/credit-control/grace-amounts/{graceAmountId}

Permet de mettre à jour l’intégralité du contenu de la tolérance existante pour le compte client.
Vous pouvez mettre à jour le montant, la startDate et/ou la endDate.

Contenu de la requête :

{
  "amount": 0,
  "endDate": "2025-06-30T23:59:59Z",
  "startDate": "2025-06-10T00:00:00Z"
}

  • Suppression des montants de tolérance de crédit

ADM-BUYING-POLICY-301 - DELETE /v1/buying-policies/credit-control/grace-amounts/{graceAmountId}

Supprime une seule blocage/tolérance existante en fonction de son identifiant (ID).



Mirakl settings

⚠️

Attention

Ce changement s'applique uniquement aux utilisateurs qui utilisent le connecteur Mirakl.

  • Mise à jour des paramètres du connecteur Mirakl:

Un nouveaux endpoint a été ajouté au module Settings, permettant aux utilisateurs opérateurs qui utilisent le connecteur Mirakl de consulter et modifier l’état global des montants de tolerance de crédit sur la plateforme.

ADM-SETTINGS-200 - PATCH /v1/settings/mirakl}

  • Permet de mettre à jour les paramètres du connecteur Mirakl, tels que les clés API, l’URL de l’hôte ou la zone de livraison.

⚠️ Seuls les champs fournis dans le body de la requête seront mis a jour. Les autres champs resteront inchangés.



👍

UPDATE

Search V2

  • Support des intervalles de valeurs pour les attributs

    • Les attributs peuvent désormais fonctionner en tant qu'intervalles de valeurs. Ainsi toutes les routes d'administration suivantes voient apparaître la nouvelle propriété searchableRange au niveau des attributeSettings

      GET /v1/catalog-views/{id}/products
      GET /v1/classification-categories
      POST /v1/classification-categories
      GET /v1/classification-categories/{classificationCategoryId}
      PATCH /v1/classification-categories/{classificationCategoryId}
      PATCH /v1/classification-categories/{classificationCategoryId}/attribute-settings
      PUT /v1/classification-categories/{classificationCategoryId}/attribute-settings
      GET /v1/classification-categories/{classificationCategoryId}/parent-tree
      PUT /v1/navigation-categories/{navigationCategoryId}/classification-categories
      GET /v1/offer-inventories
      PATCH /v1/offer-inventories
      GET /v1/offer-inventories/{offerInventoryId}
      GET /v1/products
      PATCH /v1/products
      POST /v1/products
      PUT /v1/products/back-office/{productId}
      GET /v1/products/catalog-views/{id}
      GET /v1/products/with-count
      GET /v1/products/{id}
      PUT /v1/products/{productId}
      GET /v1/products/{productId}/related-products
      PUT /v1/products/{productId}/related-products/{relatedProductId}

    • L'ajout d'un nouveau paramètre attributesRange dans l'API PRODUCT-552 permet - grâce à la nouvelle configuration des attributs - désormais de filtrer les produits selon un intervalle de valeurs.
      Par exemple, il est possible de rechercher des produits dont la taille est comprise entre 38 et 42.

    Exemple de query :

    GET/v2/shop/search?locale=en-GB&currency=USD&taille_externalID|min|38&taille_externalID|max|42

Périmètre

BackOffice Djust

Améliorations sur l'affichage et le filtrage des comptes clients :

Page liste des comptes clients : Customers > Accounts

  • L’ID externe du compte client est désormais affiché à côté du nom dans le tableau des comptes clients.
  • Le champ de filtre "ID compte" utilise maintenant l’ID externe au lieu de l’ID interne.

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 détail des catalogues produits : Catalog > Catalog views.
  • Page détail des paramètres du moteur de recherche : Settings > Search engine settings.

Affichage des champs de mappings disponibles pour l’export des commandes :

La configuration du mapping des jobs d’export est désormais disponible directement dans le Data Hub, via l’interface du Back Office.

Champs disponibles pour le mapping :

  • Order reference
  • Order id
  • Account External Id
  • Supplier External Id
  • Order Creation Date
  • Order Lines :
    • Order Line Id
    • Offer External Id
    • Variant External Id
    • Quantity Per Unit
    • Variant GTIN
    • Order Line Quantity

API

📘

NEW

Orders [DJUST PAY]

  • Nouveau endpoint
    • L'ajout d'un nouveau endpoint POST /v1/logistic-orders/{logisticOrderId}/refunds
    • Initialise un processus de remboursement pour une commande logistique donnée. Le remboursement sera appliqué au(x) paiement(s) associé(s) à cette commande.
  • Ajout d'un nouveau statut de paiement:

Le statut de paiement REFUND_FAILED a été ajouté sur les commandes logistiques ainsi que sur les lignes de commande.

⚠️

Attention

Ce changement concerne exclusivement les utilisateurs du module DJUST-PAY.
Les autres moyens de paiement (PSP) ne sont pas affectés.

Périmètre

API

📘

NEW

Buying Policies

  • Contrôle d’activation de la policy de contrôle d’encours:

Deux nouveaux endpoints ont été ajoutés au module Buying Policies, permettant aux utilisateurs opérateurs de consulter et modifier l’état global de la policy de contrôle d’encours sur la plateforme.

⚠️

Attention

Ces routes de gestion des buying policies ne sont disponibles que pour les utilisateur BackOffice opérateurs.

  • Consultation du statut de la policy d’encours :

ADM-BUYING-POLICY-500 - GET /v1/buying-policies/credit-control

Permet de récupérer l’état d’activation actuel de la policy de contrôle d’encours ainsi que la limite de crédit par défaut.

Exemple de réponse :

{
  "status": "ACTIVE",
  "creditLimit": 10000,
  "updatedAt": "2025-06-06T14:15:22Z"
}

  • Activation / désactivation de la policy d’encours :

ADM-BUYING-POLICY-200 - PATCH /v1/buying-policies/credit-control

Permet d’activer ou de désactiver globalement l’application de la policy (ACTIVE ou INACTIVE).

Contenu de la requête :

{
  "status": "INACTIVE"
}
🗒️

Notes

ℹ️ Lorsque la policy est en statut INACTIVE, les commandes ne sont plus bloquées en cas de dépassement d’encours.
⚠️ Par défaut, la policy est désactivée (INACTIVE) dans les environnements nouvellement initialisés.


  • Définition d’une limite de crédit par défaut:

La policy de contrôle d’encours peut désormais s’appuyer sur une valeur de crédit par défaut, configurable globalement depuis l’API d’administration. Cette valeur s’applique à tous les comptes clients qui n’ont pas de limite de crédit personnalisée définie. Deux endpoints sont disponibles :

  • Consultation de la configuration de la policy d’encours:

Cf. ci-dessus, il s'agit de la même route ADM-BUYING-POLICY-500

ℹ️ Si un account ne dispose pas de limite de crédit spécifique, c’est la valeur par défaut qui est utilisée pour valider les commandes.
Si un account possède un crédit personnalisé (via un champ custom), cette valeur surcharge celle par défaut.

  • Mise à jour de la limite de crédit par défaut:

ADM-BUYING-POLICY-201 - PATCH /v1/buying-policies/credit-control/credit-limit

Permet de modifier la valeur globale appliquée aux comptes sans configuration individuelle.

Contenu de la requête :

{
  "creditLimit": 15000
}

⚠️ La valeur transmise doit être supérieure ou égale à 0.
⚠️ Par défaut, la valeur initiale est 0 lors de la création d’un nouvel environnement.


Accounts

  • Nouvelle structure de configuration des encours via des champs custom des comptes clients:

Les éléments de définition de l’encours sont désormais portés par des Custom Fields associés aux comptes clients (Customer Accounts). Cette évolution permet de rendre la gestion plus flexible, centralisée et pilotable via les APIs d’Account Management (et prochainement le BackOffice Djust).

Nouveau rôle (associé à un CF Account)TypeDescription
Limite de créditNumberMontant maximal autorisé. Si vide, la limite par défaut définie dans la buying policy est appliquée.
EncoursNumberMontant total des commandes non payées. Valeur synchronisée depuis les systèmes de gestion externe.
⚠️

Attention

Contrairement à la logique actuelle, un Custom Field associé à un rôle n’est plus automatiquement requis : la mécanique de validation a été assouplie.

  • Ces champs sont utilisés par la buying policy d’encours lors de la validation des commandes.
  • La logique de validation distingue clairement les valeurs personnalisées (au niveau du compte) et les valeurs par défaut (définies globalement).
  • La valeur du crédit disponible est désormais calculée dynamiquement selon la formule suivante :
🔎

crédit disponible = (limite crédit - encours) + tolérance

  • En cas d’absence de valeur dans les champs "Limite de crédit" ou "Encours", la logique applique :
    • la valeur par défaut (buying policy) pour la limite,
    • un blocage de sécurité si l’encours est inconnu, pour éviter tout risque de dépassement.
  • Les valeurs des champs "Limite de crédit" et "Encours" doivent être synchronisées régulièrement via les jobs de Data Hub.
  • Aucun fetch temps réel depuis les ERP n’est prévu pour cette première version.

Périmètre

BackOffice Djust

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 détail des assortiments produits : Catalog > Assortments.
  • Page détail des organisations : Customers > Organisations.
  • Page de configuration des devises : Settings > Currencies.


API

📘

NEW

Buying Policies

Nouvelle fonctionnalité de gestion des comptes en backoffice permettant de bloquer temporairement ou définitivement un ou plusieurs comptes clients afin d’empêcher toute validation de commande, indépendamment de leur encours ou de leur limite de crédit.

Ainsi, voici les nouveaux endpoints API correspondants :

  • Récupération des blocages en cours ou programmés :

ADM-BUYING-POLICY-550 - GET /v1/buying-policies/credit-control/holds

  • Création de blocages manuels sur un ou plusieurs comptes :

ADM-BUYING-POLICY-150 - POST /v1/buying-policies/credit-control/holds

  • Modification d’un blocage existant, avec règles de cohérence sur les dates :

ADM-BUYING-POLICY-202 - PUT /v1/buying-policies/credit-control/holds/{creditHoldId}

  • Suppression d’un blocage actif ou futur :

ADM-BUYING-POLICY-300 - DELETE /v1/buying-policies/credit-control/holds/{creditHoldId}



👍

UPDATE

Incidents

Filtrage des incidents par supplier :

Chaque commande logistique liée à un incident possède un fournisseur.

Pour pouvoir filtrer par fournisseur, un paramètre supplémentaire de filtre suppliers qui prend en entrée une liste d’external ID de suppliers est ajouté à la route ORDER-559 - GET /v1/shop/incidents.

Son fonctionnement reste similaire au filtre par customerAccountIds.

En résultat, on remonte l’ensemble des incidents liés à une commande/ligne de commande correspondant à au moins un des id de fournisseur passé en paramètre.

Si aucune correspondance n’est trouvée, aucun résultat n’est remonté.


Customer Accounts

Suppression de la contrainte d’unicité sur le nom des comptes clients

Il est désormais possible de créer plusieurs comptes clients portant le même nom, que ce soit via les APIs d'administration, Frontend ou les imports (FTP/API).

  • Les traitements ne s’appuient plus sur le nom pour identifier un compte, mais uniquement sur son identifiant technique (customerAccountId).
  • La recherche par nom retourne tous les comptes correspondants, même en cas d’homonymie.
  • Les processus d’import (FTP ou API) n’échouent plus lorsqu’un doublon de nom est détecté.

Les APIs suivantes ont été mises à jour :

POST /v1/customer-accounts
PUT /v1/customer-accounts/{customerAccountId}

ACCOUNT-100 - POST /v1/shop/customer-accounts
ACCOUNT-201 - PUT /v1/shop/customer-accounts

📌 Aucune action corrective sur les données existantes : les noms précédemment uniques restent valides et modifiables.


Data Hub

Exposition des mappings disponibles à l’export pour les commandes

Il est désormais possible d’interroger par API les mappings utilisables pour l’export des commandes via l’endpoint GET /jobout/mappings?type=ORDER

Périmètre

BackOffice Djust

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 des utilisateurs fournisseurs (Portail fournisseur uniquement) : Users.
  • Page de recherche des produits/variants : Catalog > Product list.
  • Page de détail et de création des utilisateurs front : Customers > Customer users.

Périmètre

BackOffice Djust

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 recherche des utilisateurs fournisseurs (Portail fournisseur uniquement) : Users.
  • Page de recherche des devis : Quotes.

Affichage de l'External ID des variants dans la section Produits d’un devis

Dans la page de détail d’un devis, au sein de la section Produits, un nouveau champ informatif a été ajouté.
Ce champ affiche l’External ID du variant associé à chaque ligne de produit. Cette amélioration permet de faciliter l’identification et le suivi des variants.



API

📘

NEW

Data Hub - Mise à jour des noms des jobs d’import

Une nouvelle route API permet de mettre à jour le nom des jobs d'import.

PATCH /v2/mapper/job/{jobId}

{
	"jobName": "string"
}

Le nom doit être unique pour tous les jobs d’import.


👍

UPDATE

Incidents

Tri des incidents par supplier :

Il est désormais possible de trier les incidents par fournisseur sur la route :

ORDER-559 - GET /v2/shop/incidents

Contrairement au filtre par fournisseur, le tri par fournisseur doit s’appliquer sur le nom du fournisseur.

Ainsi la possibilité de trier sur les noms des fournisseurs se fait 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).

⚠️

Attention

Il s'agit d'une v2 de l'API, la v1 ne pouvant pas supporter le tri, elle a été dépréciée au profit de celle-ci.

Périmètre

BackOffice Djust

Nouveau filtre ajouté sur la page liste des commandes : Custom Field Order

Un nouveau filtre qui concerne les champs personnalisés des commandes, a été ajouté à la page liste des commandes.

Cette amélioration permet aux utilisateurs d’affiner leur recherche et de retrouver plus facilement des commandes en fonction des valeurs de leurs champs personnalisés. Ce filtre facilite la navigation et améliore la gestion des commandes.

Modification du champ “numéro de téléphone” pour les utilisateurs clients

Le champ numéro de téléphone n’est désormais plus obligatoire lors de la création ou de la mise à jour d’un utilisateur. Cette contrainte a été levée afin de faciliter la gestion des comptes clients ne disposant pas nécessairement d’un numéro de téléphone. Cette évolution améliore la flexibilité et réduit les frictions lors de l’enregistrement ou de la modification des utilisateurs.


Data Hub

Import des assortiments par Connecteur API

Un nouveau type de job a été introduit pour permettre l’import et la gestion d’assortiments via Connecteur API. Ce type de job, identifié par l’enum ASSORTMENT_API_JSON_JOB, est désormais pris en charge dans l’ensemble des endpoints liés aux jobs et configurations de mapping.

Objectif du job

  • La création d’un ou plusieurs assortiments
  • La liaison d’un ou plusieurs produits à un assortiment
  • Délier un ou ou plusieurs produits d’un assortiment

Champs pris en charge

ChampTypeObligatoire à la créationUpdate possiblePar défaut
assortment_external_idString✅ Oui✅ Oui
assortment_nameStringNon✅ Oui
product_external_idString Array ou StringNon
unlinkBooleanNon✅ Ouifalse

Règles métier

  • Création/Update d’un Assortment nécessite assortment_external_id.
  • Liaison à un ou plusieurs produits via product_external_id.
  • Suppression du lien entre un Assortment et un ou plusieurs produits via unlink: true.
  • Un produit peut être lié à plusieurs assortiments, sans limite.

Structure attendue du JSON en entrée

{
	"elements": [
		{
			"assortmentExternalId": "1234",
			"assortmentName": "Soft",
			"productExternalId": ["7890", "5678"],
			"unlink": false
		},
		{
			"assortmentExternalId": "56643",
			"assortmentName": "Alcohol",
			"productExternalId": ["9876", "45676"],
			"unlink": false
		}
	],
	"paging": {
		"pageNumber": 0,
		"pageSize": 0,
		"totalPages": 0,
		"totalRecords": 0
	}
}

API

👍

UPDATE

Autorisation de la modification/suppression de lignes pour un user non owner en contexte (Checkout v3) :

En B2B il est nécessaire d’ouvrir la possibilité pour un utilisateur de pouvoir modifier/supprimer les éléments d’une commande qu’il n’a pas créé sur ces route :

ORDER-150 - PUT /v2/shop/commercial-orders/{commercialOrderId}/lines
ORDER-350 - DELETE  /v2/shop/commercial-orders/{commercialOrderId}/lines     

Il doit cependant être présent dans le même compte que celui où est rattaché la commande.

Ainsi, le droit existant suivant est étendu : ORDER_UPDATE_LINES_ON_ALL_ACCOUNT

Ce droit existe déjà pour la modification des quantités sur les commandes logistiques sur ORDER-250 et ORDER-150.

Ce droit est donc étendu pour autoriser l’utilisateur à modifier/supprimer les lignes des commandes sous les conditions suivantes :

  • Le user appartient au même compte que celui lié à la commande
  • Le user a le droit ORDER_UPDATE_LINES_ON_ALL_ACCOUNT à true associé à son rôle
⚠️

Attention

La suppression des lines n’est possible que si la commande commerciale n’a pas été validée (i.e si les commandes logistiques liées sont au statut DRAFT ou DRAFT_ON_HOLD).

Search

Il est dorénavant possible de filtrer sur un interval de prix.

L’interval fonctionne avec les valeurs inclues.

PRODUCT-552 - GET /v2/shop/search

Nouveaux paramètres de requête :

  • priceMin: borne inférieure de recherche de prix
  • priceMax: borne supérieure de recherche de prix

Périmètre

API

👍

UPDATE

Les informations suivantes ont été ajoutées dans les snapshots d’offer inventories de chaque ligne de commande :

  • minOrderQuantity : issu de l’offre (inventory), il correspond à la quantité minimale achetable par commande
  • maxOrderQuantity : issu de l’offre (inventory), il correspond à la quantité maximale achetable par commande

De même, les informations suivantes ont été ajoutées dans les snapshots de products de chaque ligne de commande :

  • navigationCategory : issu du produit, on ne récupère que le nom du noeud le plus fin sur lequel est rattaché le produit.
  • navigationCategoryExternalId : issu du produit, on ne récupère que l’external id du noeud le plus fin sur lequel est rattaché le produit.

Les routes concernées par les changements sont :

ORDER-560 - GET /v1/shop/commercial-orders\
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-561 - GET /v1/shop/commercial-orders/{commercialOrderId}/lines
ORDER-500 - GET /v1/shop/commercial-orders/{orderCommercialId}
N/A - GET /v1/shop/logistic-orders
ORDER-550 - POST /v1/shop/logistic-orders
ORDER-501 - GET /v1/shop/logistic-orders/{orderLogisticId}
ORDER-205 - PATCH /v1/shop/logistic-orders/{orderLogisticId}
ORDER-200 - PUT /v1/shop/logistic-orders/{orderLogisticId}/approve
ORDER-556 - GET /v1/shop/logistic-orders/{orderLogisticId}/approvers
ORDER-201 - PUT /v1/shop/logistic-orders/{orderLogisticId}/cancel
ORDER-203 - PUT /v1/shop/logistic-orders/{orderLogisticId}/confirm-reception
ORDER-204 - PUT /v1/shop/logistic-orders/{orderLogisticId}/disapprove
ORDER-555 - GET /v1/shop/logistic-orders/{orderLogisticId}/lines
ORDER-206 - PATCH /v1/shop/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}

Périmètre

BackOffice Djust

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 configuration des stores : Settings > Stores.
  • Page de recherche des customer users : Customers > Users.

API

👍

UPDATE

Data Hub - Mise à jour des noms des jobs d’import

Une nouvelle route API permet de mettre à jour le nom des jobs d'import.

PATCH /v2/mapper/job/{jobId}
{
	"jobName": "string"
}

Le nom doit être unique pour tous les jobs d’import.

Data Hub - Création multiple de transcoding
L’endpoint POST /v1/mapper/job/{jobId}/transcodings accepte désormais une liste d’objets pour convertir plusieurs valeurs pour plusieurs mappings sur un job d’import donné.

Exemple:

POST /v1/mapper/job/ad249986-0048-4a95-9fb7-8c4d1e01617f/transcodings

[
	{
		"mappingTo": "active",
		"inputValue": "1",
		"outputValue": "true",
		"active": true
	},
	{
		"mappingTo": "deleted",
		"inputValue": "0",
		"outputValue": "false",
		"active": true
	}
]

Périmètre

BackOffice Djust

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 configuration des roles de custom fields : Settings > Custom Field Roles.
  • Page de configuration des éléments d'affichage du panier : Settings > Cart Settings.

Djust PAY

Validation et contrôle des commandes au paiement

Lorsque les commandes en checkout v2 et v3 sont passées via Djust Pay, les contrôles supplémentaires suivants sont opérés pour garantir que la commande est viable : Order Validation Rules


API

📘

NEW

Déclenchement automatique de capture CB :

Lorsque la commande est mise au statut SHIPPED (depuis le BO Djust ou en automatique via le Data Hub) et si celle-ci respecte TOUS les critères :

  • statut de paiement différent de PAID
  • moyen de paiement = credit card

Alors la capture automatique est déclenchée.

L’appel est identique à celui fait lors d’une capture manuelle livrée en 3.60.0.

La commande passe alors de la même manière au statut CAPTURE_PENDING puis PAID ou REFUSED en fonction du retour PSP et des organismes bancaires.


👍

UPDATE

Customer Accounts

  • Recherche par nom d'account :

Il est dorénavant possible de rechercher sur le nom d’un account dans la page liste account d’un Back Office Fournisseur.

GET /v1/customer-accounts

Le paramètre de requête search permet ainsi de rechercher par id, externalId et nom d'account.


Paiement par virement bancaire

L’API d’initialisation de paiement PAY-101 évolue pour prendre en charge les paiements par virement bancaires.

Il faut désormais ajouter le paramètre countryCode qui permet de donner le contexte pays/région d’appel pour les virements bancaires.

⚠️

Attention

Ce paramètre est rendu obligatoire pour tous les types de paiement.

Le retour de l’API évolue dans ce cas d’un virement bancaire, l’objet action remonte les informations nécessaires pour effectuer le virement par le client :

{
	"pspReference":"FJM726V375BV9D82",
	"resultCode":"Received",
	"action":{
		"paymentMethodType":"bankTransfer_IBAN",
		"totalAmount":{
			"currency":"EUR",
			"value":89600
		},
		"beneficiary":"YOUR_DBA_NAME",
		"iban":"DE48499999601234567890",
		"bic":"ADYXDEB2",
		"reference":"V375B8",
		"type":"bankTransfer"
	}
}