---
title: "Configuration"
weight: 20
description: "Paramétrer smartmakersaasbilling : constantes de paiement et clients autorisés."
---

# 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](screenshots/configuration-avertissements.webp)

## 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 :

1. 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.
2. 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.
3. 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.
4. 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](screenshots/configuration-fiche-client.webp)

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.