Configuration

Constantes du cœur Dolibarr

Deux constantes conditionnent le lien de paiement :

PAYMENT_SECURITY_TOKEN : le secret dont dérive la clé de sécurité du lien de paiement. En son absence, la page de paiement refuse la commande.
PAYMENT_SECURITY_TOKEN_UNIQUE : en mode unique, la clé vaut dol_hash(token + type + ref), si bien que chaque commande possède la sienne. C'est le mode attendu par l'API.

Ces deux constantes ne se saisissent pas ici : ce sont les modules de paiement de Dolibarr qui les renseignent.

Écran de configuration du module avec les avertissements de constantes manquantes

Clients autorisés

Un client autorisé désigne un webservice habilité à appeler l'API. L'onglet Produits SaaS autorisés en dresse la liste. Pour en déclarer un :

Créez chez smartauth un client OAuth confidentiel doté du grant client_credentials, et rattachez-lui un utilisateur de service portant les droits sur les tiers, les produits, les commandes et les factures.
Sur la fiche de ce client, cliquez sur Autoriser sur l'API interne. Les routes protégées de l'instance sont fermées par défaut : sans cette autorisation, le webservice obtient bien un jeton, mais chaque appel au module répond 401. La fiche du produit autorisé signale ce cas et renvoie vers le bouton correspondant.
Créez la fiche dans le module. Elle demande une référence stable, un libellé, le client OAuth, le préfixe des références produit et l'URL du webhook de règlement.
Le secret de signature du webhook est généré à la création. Le bouton Régénérer le secret de signature permet de le renouveler : transmettez alors la nouvelle valeur au webservice, car les notifications signées avec l'ancien secret seront rejetées.

Fiche de création d'un produit SaaS autorisé, avec le client OAuth et le préfixe produit

Un client OAuth dépourvu de fiche active se voit refuser tous les verbes. Un jeton dérobé chez un webservice n'ouvre donc aucun accès aux données des autres.

Préfixe de références produit

Seul le préfixe se configure, par exemple P-SCIFAC-. Le suffixe, lui, encode la nature de l'acte et la tranche : les références s'en déduisent. Le catalogue que lit un webservice ne contient que les fiches portant son propre préfixe.

Créer les fiches produit sans les recopier

Une référence mal saisie passe inaperçue jusqu'au premier acte à commander : la commande est alors refusée, faute de produit correspondant. Le bouton Importer un gabarit de catalogue, sur la fiche du produit autorisé, évite cette recopie. Le webservice appelant produit un fichier JSON qui énumère les fiches qu'il attend, et vous le déposez ici.

L'écran affiche d'abord, ligne par ligne, ce qu'il créerait, avec le prix proposé par le webservice, que vous pouvez modifier avant création. Trois règles s'appliquent :

Une fiche déjà présente n'est jamais modifiée. Le prix d'un service relève d'une décision commerciale prise ici, et un gabarit capable de l'écraser ferait du fichier la source du barème. Un nouvel import ne peut donc rien détériorer.
Seules les références portant le préfixe du client sont reprises. Un gabarit qui nomme les fiches d'un autre produit n'en crée aucune, et le signale.
Rien ne transite par l'API. Le fichier se dépose à la main dans cet écran : un jeton compromis reste incapable de créer la moindre fiche produit.