Paiement¶

Voir aussi le laïus standard sur le paiement.

Configuration du service de paiement¶

Cette partie devrait aller dans la documentation Publik de l'administrateur technique.

Dans Combo, dans le menu sur la page d'accueil du /manage/, "Paiement en ligne", ajouter une régie, les paramètres varient d'un fournisseur à l'autre.

PayZen¶

Pour la recette :

{
  "secret_test": "xxx", 
  "site_id": "xxx", 
  "ctx_mode": "TEST" 
}

Et pour la prod :

{
  "secret_production": "xxx", 
  "site_id": "xxx", 
  "ctx_mode": "PRODUCTION" 
}

SIPSv2 (Atos en Belgique)¶

{
  "platform": "test", 
  "secret_key": "002001000000001_KEY1", 
  "merchant_id": "002001000000001", 
  "key_version": "1" 
}

Ingenico (ex Ogone)¶

Attention ils demandent configuration dans leur backoffice de l'adresse de callback. (https://combo.example.net/lingo/callback/<numéro de la régie>/).

Dans leur backoffice également, il faut choisir « Vente » sous l’onglet « Paramètres de transaction globaux », dans la rubrique « Code d’opération par défaut » de la page d’Information technique. (sinon la notification annonce les paiements comme "acceptés" et non "payés" et ils ne sont pas pris en compte).

{
  "sha_out": "XXX", 
  "environment": "TEST", 
  "sha_in": "XXX", 
  "pspid": "XXX" 
}

(environment est à mettre à "PROD" pour utiliser leur environnement de production)

Remarque de Daniel (IMIO) :

Dans le backoffice Ingenico, les URL de callback se paramètrent dans "Configuration > Technical information > Transaction feedback" sous "HTTP request for status changes", sous "Direct HTTP server-to-server request".

Lors du paramétrage de la plateforme dans Publik :

Le SHA-out est une passphrase définie dans "Configuration > Technical information > Transaction feedback > Security for request parameters".
Le SHA-in est une passphrase définie dans "Configuration > Technical information > Data and origin verification > Checks for e-Commerce".

Enfin, si je ne me trompe, "Nom d'affiliation dans le système" correspondrait au PSPID, et ce PSPID figure notamment, et parmi d'autres informations relatives au compte, dans le pied de page du backoffice Ingenico. Et si c'est bien ça, ce serait probablement utile de l'indiquer en remarque du champ, au niveau du paramétrage de la plateforme.

PayFiP Régie / Régie web-service (ex-TIPI)¶

La collectivité (le régisseur ou son service financier) doit prendre contact avec le correspondant monétique de la trésorerie dont elle dépend, suite à la signature d'une convention ils obtiendrons un identifiant, le NUMCLI.

• en test
  

  {
    "saisie": "T",
    "numcli": "XXXXX" 
  }

• en activation (phase avant mise en prod)
  

  {
    "saisie": "X",
    "numcli": "XXXXX" 
  }

• en production
  

  {
    "saisie": "W",
    "numcli": "XXXXX" 
  }

PayFip/TIPI et SNI¶

• pour PayFiP/TIPI Régie classique :
  

  {
    "service_url": "https://www.tipi-client.budget.gouv.fr/tpa/paiement.web" 
  }
  

  , le reste du paramétrage est comme décrit plus bas.
• pour PayFiP/TIPI Régie Web-Service : ce n'est pas actuellement supporté car on ne peut pas surcharger PAYMENT_URL, un ticket est ouvert : #43939.

Workflow de paiement dans w.c.s.¶

Cette partie devrait aller dans la documentation Publik de l'administrateur fonctionnel (en cours).

Il faut dans le workflow une étape "en attente de paiement" qui contienne :

• un appel webservice,
  • url : [portal_url]/api/lingo/add-basket-item?NameId=[form_user_name_identifier_0] (optionnellement, &regie_id=xxx)
  • Clé de signature de la requête : laisser vide, ça sera déterminé automatiquement
  • Méthode : POST (JSON)
  • Envoyer les données du formulaire : oui (ou non si on veut gérer un libellé différent pour l'entrée dans le panier)
  • Données à envoyer (POST):
    • amount : le montant du paiement
    • éventuellement cancellable=no si on ne veut pas permettre à l'usager d'annuler le paiement depuis son panier
    • (si on décide de ne pas envoyer les données du formulaire) :
      • url: =form_url
      • display_name: =form_var_number (c'est le nom de la variable du formulaire qui stocke le numéro de la facture)
  • Type de réponse : JSON
  • Nom de variable : panier (ou autre, c'est utisé pour l'annulation)

• un saut sur déclencheur ("trigger"),
  • Déclencheur : paid
  • Rôles autorisés : laisser vide
  • Statut : le statut avec la suite du workflow devant s'exécuter une fois le paiement fait.

Le montant du paiement est calculé en prenant dans l'URL les paramètres "amount" (on pourrait donc ajouter &amount=[form_var_amount]) et le paramètre "amount" qui peut être présent dans "Données à envoyer (POST)", les différents montants sont additionnés.

Pour avoir un workflow unique associé à des demandes dont le montant varie, on peut passer par une variable de workflow, qui sera ensuite configurée formulaire par formulaire.

Pour permettre à l'usager d'annuler depuis le panier (ce qui par défaut est autorisé, cf cancellable=no plus haut pour le refuser), il faut également un saut sur le déclencheur adéquat ("cancelled").

• Déclencheur : cancelled
• Rôles autorisés : laisser vide
• Statut : le statut avec la suite du workflow devant s'exécuter une fois l'élément retiré du panier

Pour retirer un élément du panier :

• un appel webservice
  • url : [portal_url]/api/lingo/remove-basket-item?NameId=[form_user_name_identifier_0]
  • Clé de signature de la requête : laisser vide, ça sera déterminé automatiquement
  • Méthode : POST (JSON)
  • Envoyer les données du formulaire : non
  • Données à envoyer (POST):
    • basket_item_id : [panier_response_id] (panier c'est le nom utilisé dans l'appel d'ajout)
  • Type de réponse : JSON