Plugin Bank

Le plugin Bank prend en charge l’interface technique de paiement avec de nombreux prestataires de paiement par Carte Bleue, SEPA… Il prend également en charge la conservation de l’historique des transactions de paiement et de leur état et offre une API pour permettre aux autres plugins d’offrir des fonctionnalités autour des paiements (plugins de dons et souscriptions, paiement avec formidable, gestion de commandes…)

À partir du 14 septembre 2019, la réglementation DSP2 exigera l’utilisation de l’authentification forte du client, aussi appelée Strong Customer Authentication (SCA) pour la plupart des paiements en ligne réalisés par les clients européens dans le but de réduire la fraude.

La v4 du plugin Bank prend en compte les modifications nécessaires et est donc requise pour la mise en conformité avec la DSP2

Configuration

La configuration du plugin permet d’ajouter, activer, ordonner et configurer les modules de paiement que vous souhaitez utiliser ainsi que les notifications [1].

Configuration du plugin Bank
Configuration du plugin Bank

L’ordre dans lequel vous positionnez les modules de paiement dans cette configuration sera l’ordre dans lequel ils seront proposés aux visiteurs sur les pages de paiement.

Paiements à l’acte

Paiements à l’acte par Carte Bancaire
Le plugin permet les paiements uniques par Carte Bancaire avec

Paiements à l’acte par SEPA
Les paiements à l’acte sont possibles par SEPA via le prestataire Payzen.

Paiements à l’acte par Chèque
Les paiements par chèque sont pris en compte par un module dédié.

Paiements à l’acte par Virement
Les paiements par virement sont pris en compte par un module dédié.

Paiements à l’acte sur la facture du fournisseur Internet

Supprimé à partir de la v4

Le module de paiement Internet+ permet le paiement des petits montants directement via la facture du fournisseur Internet du visiteur.

Simulation du paiement
Le plugin permet également la simulation du paiement en phase de développement du site.

Paiements récurrents

Paiements récurrents par Carte Bancaire
Les paiements récurrents sont possibles par Carte Bancaire via les prestataires Paybox, Payzen et Stripe.

Paiements récurrents par SEPA
Les paiements récurrents sont possibles par SEPA via le prestataire Payzen.

Paiements récurrents sur la facture du fournisseur Internet

Supprimé à partir de la v4

Le module de paiement Internet+ permet le paiement récurrent de petits montants directement via la facture du fournisseur Internet du visiteur.

Notifications

Le plugin génère un ticket d’achat comportant les informations techniques de chaque paiement, et vous pouvez configurer l’adresse email qui recevra ce ticket ainsi que l’email expéditeur.

Il en est de même pour le récapitulatif journalier des paiements : indiquez l’adresse qui recevra ce récapitulatif par mail.

Suivi des transactions

Avant tout affichage du formulaire de paiement, une transaction est créée en base avec toutes les informations concernant le paiement (prix, prix HT, id_auteur ou email associé, date de la transaction).

Le menu Activités > Transactions permet de retrouver la liste de toutes les transactions et de les trier par statut :

  • OK pour les transactions dont le paiement a été réalisé
  • Commande pour les transactions créées mais qui restent en attente de paiement
  • Attente pour les transactions dont le paiement a été initié par un mode qui ne permet pas l’encaissement instantané (chèque, virement)
  • Echec lorsqu’une tentative de paiement a eu lieu mais n’a pas réussi. Le code d’erreur est alors visible au survol du statut de la transaction
  • Abandon pour les transactions abandonnées (si votre site permet l’abandon de commandes par exemple)
  • Remboursées pour les transactions remboursées à posteriori
Liste des transactions
Liste des transactions

Pour chaque transaction la liste affiche le mode de paiement utilisé (nom et identifiant du module de paiement), le numéro d’autorisation, dont le format dépend du module de paiement, et le lien vers l’auteur si il est connu.

Certaines transactions peuvent avoir le mode ’gratuit’ indiqué. Ce “mode de paiement” est automatiquement utilisé lorsqu’on demande le paiement d’une transaction dont le montant est nul (cas de remises ou cadeaux), il se compose d’un simple bouton de validation, mais permet le passage dans tout le processus de paiement, comme pour le paiement via une plateforme externe.

La recherche permet de retrouver une transaction par son numéro d’autorisation, ou toutes les transactions utilisant un mode de paiement particulier.

Squelettes

#FORMULAIRE_PAYER_ACTE

Ce formulaire permet de proposer un formulaire de paiement.

[(#FORMULAIRE_PAYER_ACTE{10,
		      #ARRAY{
			      montant_ht,8,
			      id_auteur,#ID_AUTEUR,
		      }
})]

La transaction est automatiquement créée. Les arguments sont les mêmes que pour l’API inserer_transaction ci-dessous.

modeles/payer_acte.html

Ce modèle permet d’afficher le formulaire de paiement pour une transaction existante :

  1. <INCLURE{fond=modeles/payer_acte,id_transaction,env} />

Les modules de paiements à l’acte activés et configurés seront utilisés pour proposer les modes de paiement aux visiteur.

modeles/payer_abonnement.html

Ce modèle permet d’afficher le formulaire de paiement récurrent pour une transaction existante :

  1. <INCLURE{fond=modeles/payer_abonnement,id_transaction,env} />

Les modules de paiements récurrents activés et configurés seront utilisés pour proposer les modes de paiement aux visiteurs.

modeles/transaction_details.html

Ce modèle est utilisé pour afficher le détail du paiement de la transaction, par exemple sur les factures (via un plugin externe). Vous pouvez le surcharger pour afficher une liste de produits associée à la transaction et qui en constituent le prix par exemple.

content/payer.html

Ce squelette affiche le contenu minimum d’une page de paiement d’une transaction.

content/bank_retour_ok.html

Ce squelette fournit le contenu de la page de retour après paiement réussi. Vous pouvez l’utiliser pour fournir une page spip.php?page=bank_retour_ok fonctionnelle qui est nécessaire au fonctionnement du plugin.

content/bank_retour_attente.html

Ce squelette fournit le contenu de la page de retour après un paiement en attente d’encaissement (typiquement lors du paiement par chèque ou virement). Vous pouvez l’utiliser pour fournir une page spip.php?page=bank_retour_attente fonctionnelle qui est nécessaire au fonctionnement du plugin.

content/bank_retour_echec.html

Ce squelette fournit le contenu de la page de retour après paiement échoué. Vous pouvez l’utiliser pour fournir une page spip.php?page=bank_retour_echec fonctionnelle qui est nécessaire au fonctionnement du plugin.

API

inserer_transaction

$inserer_transaction = charger_fonction('inserer_transaction','bank');
$id_transaction = $inserer_transaction($montant,$options);
Paramètre
string $montant montant a payer
array $options tableau d’options
   string montant_ht Montant HT du paiement
   int id_auteur id_auteur associé à la transaction 
   string auteur_id  autre identifiant de l’auteur
   string auteur nom ou email de l’auteur
   string parrain parrain/tracking associé à la transaction
   int tracking_id numéro de tracking
   bool force false pour recycler une transaction identique encore au statut commande (par défaut), true pour forcer la creation d’une nouvelle transaction
   array champs autre champs ajoutés a la transaction

La fonction retourne l’id_transaction de la transaction créée, ou 0 en cas d’erreur.

Pipelines

Les pipelines suivants permettent de s’insérer dans le processus de paiement et de personnaliser selon vos besoins.

bank_dsp2_renseigner_facturation

A partir de la v4. Mise en conformité DSP2

Ce pipeline sert a renseigner les informations personnelles (nom et adresse de facturation, email) de la personne réalisant l’achat et avec le passage à la DSP2 il est fortement recommandé de les renseigner pour faciliter le paiement et éviter que les banques ne demandent systématiquement une authentification de type 3DSv2

bank_pre_facturer_reglement

Le pipeline est appelé après le règlement d’une transaction, avant facturation éventuelle de la transaction. Le pipeline peut servir a créer un compte client post-achat (mais avant facturation). Il a le même format de données que bank_traiter_reglement. Il est possible de récupérer les informations éventuellement fournies par la banque sur l’identité du client dans la globale $GLOBALS['bank_session']

bank_facturer_reglement

Le pipeline est appelé après le règlement d’une transaction, lorsqu’on peut facturer la transaction (si nécessaire). Le pipeline est utilisé par un éventuel plugin de facturation. Il a le même format de données que bank_traiter_reglement.
Il est possible de récupérer les informations éventuellement fournies par la banque sur l’identité du client dans la globale $GLOBALS['bank_session']

bank_traiter_reglement

Le pipeline est appelé lors du règlement d’une transaction
Il est possible de récupérer les informations éventuellement fournies par la banque sur l’identité du client dans la globale $GLOBALS['bank_session']

bank_traiter_remboursement

Le pipeline est appelé lors du remboursement d’une transaction. Le format des données est le même que pour le pipeline bank_traiter_reglement.

bank_editer_ticket_reglement

Le pipeline est appelé après le règlement d’une transaction, lors de l’édition du ticket de paiement (ticket interne, à destination des administrateurs du site et non du client).

bank_redirige_apres_retour_transaction

Le pipeline est appelé au moment de déterminer l’URL de retour après transaction. Par défaut on retourne vers l’une des URLs ?page=bank_retour_ok, ?page=bank_retour_attente ou ?page=bank_retour_echec mais ce pipeline permet de modifier ce comportement pour changer la page de retour en fonction du module de paiement utilisé ou d’autres paramètres liés à la transaction.

trig_bank_notifier_reglement

Le pipeline est appelé après le règlement, pour notifier le bon règlement. Il a le même format de données que bank_redirige_apres_retour_transaction.

trig_bank_reglement_en_attente

Le pipeline est appelé lorsqu’une transaction est marquée en mode de paiement chèque ou virement, et que le règlement effectif devra attendre la réception du chèque ou virement. Cela permet par exemple d’envoyer un mail aux administrateurs ou au client.

trig_bank_reglement_en_echec

Le pipeline est appelé lorsqu’un échec ou un abandon de paiement est constaté sur une transaction.

API Abonnements

Le plugin prend en charge les paiements récurrents, mais pas du tout les abonnements associés à ces paiements récurrents qui sont du ressort d’un autre plugin.
Une API est fournie et doit être implémentée pour le bon fonctionnement des paiements récurrents.

Pour ces 4 fonctions une implémentation minimale incomplète est fournie dans le dossier abos/ du plugin et contient les informations nécessaires pour son implémentation complète. Pour chacune on pourra réaliser l’implémentation par le pipeline idoine, ou par surcharge du fichier, selon les cas.

abos/decrire_echeance

Cette fonction est appelée lors de l’affichage du formulaire de paiement récurrent, pour connaître le détail de la récurrence : périodicité, montant des échéances (qui peut être différent du montant du premier paiement), numéro d’offre abonnement pour Internet+

abos/activer_abonnement

Cette fonction est appelée après que le premier paiement ait été reçu. Elle a en charge l’activation de l’abonnement lié à la transaction.
Attention, dans le cas où le paiement de la première transaction est à encaissement différé (SEPA par exemple), la fonction sera appelée une première fois à l’enregistrement du mode de paiement (avec la transaction en statut attente) et une seconde fois quand le paiement de la transaction sera effectivement encaissé. Il convient donc de vérifier le statut de la transaction pour décider d’activer ou non l’abonnement (avec une période d’essai par exemple).

abos/preparer_echeance

Cette fonction est appelée lorsque le plugin est notifié d’un paiement récurrent. La fonction doit créer une nouvelle transaction correspondant à l’échéance attendue de l’abonnement concerné et la retourner pour permettre la prise en compte du bon paiement ou du rejet du paiement de cette transaction.

abos/renouveler_abonnement

Cette fonction est appelée lorsque le plugin est notifié d’un paiement récurrent réussi, après avoir traiter le règlement de la transaction correspondant à l’échéance. Elle peut par exemple se charger de prolonger la date de validité de l’abonnement jusqu’à la prochaine échéance.

abos/resilier

Cette fonction est appelée lorsque le plugin est notifié d’un paiement récurrent échoué.

Footnotes

[1Vous pouvez configurer plusieurs modules du même prestataire, avec des configurations différentes dans le cas où vous disposez de plusieurs contrats.

Portfolio

updated on 2 October 2019

Discussion

41 discussions

  • Bonjour,
    Sur cette page la version du plugin est :
    Téléchargements Version 3.6.7 https://files.spip.net/externals/bank.zip
    Sur un site en production (SPIP 3.2.5 [24404] ) la version installée est Banque&paiement 3.6.1 - stable et il n’y a pas de notification de mise à jour disponible vers 4.0.2 - stable.
    Est-ce qu’il faut aller sur https://github.com/nursit/bank pour manuellement télécharger la nouvelle version ?

    Merci

    Reply to this message

  • 2
    Lucie2006

    Bonjour,

    Suite à la nouvelle législation en vigueur, je souhaite mettre à jour le plugin Bank.
    J’ai actuellement la version 3.3.6 stable de ce plugin ainsi que la version 3.1 de SPIP.

    Mon site fonctionne en ce moment correctement avec une petite boutique en ligne. N’étant qu’une développeuse autodidacte et apprentie, j’ai vraiment beaucoup travaillé pour la faire fonctionner...mais je n’ai jamais perdu espoir grâce à la communauté SPIP qui m’a aidé dans les moments où je me trouvais bloquée.

    Par précaution, je voudrais savoir si la simple mise à jour manuelle du plugin (par FTP dans mon dossier plugin/auto, car les mises à jour de plugin ne fonctionnent pas pour moi sur l’espace privé dans “gestion des plugins”...) suffira à l’actualisation du système de paiement avec ma configuration existante, ou si je devrais faire à nouveau toutes les démarches de configuration (clé API, configuration Stripe etc.).

    Merci pour votre aide.

    • Bonjour Lucie,

      la mise à jour du plugin suffira, il n’y a pas de modification nécessaire sur la configuration.

      Le mieux est d’uploader la nouvelle version dans un autre, dossier à côté de l’ancienne version, et ensuite d’aller sur le panneau de gestion des plugins pour désactiver l’ancienne version et activer la nouvelle à la place.

    • Lucie2006

      Merci beaucoup cela a fonctionné sans embûches...
      Bonne fin de journée

    Reply to this message

  • 2

    Bonjour,

    Comment faire un export des transactions ?
    ecrire/?exec=transactions ne fait que les lister, je ne vois pas de bouton exportation (CSV/XLS).

    Voir aussi : https://contrib.spip.net/Paiement-avec-Formidable-4614#comment502426

    • Bonne question... Le copier/coller dans un tableur c’est pas pratique.
      Il y a un export pour ?exec=factures (par défaut il n’y a que l’export par mois je crois, je l’ai bidouillé pour l’avoir par année).
      Peut-être possible de l’adapter aux transactions.
      La réponse “patate chaude” est que le client doit avoir la liste des transactions dans son tableau de bord de solution bancaire..

    • En fait, je crois que ce qu’ils veulent, c’est un lien entre les information saisies dans formidable et la transaction bancaire : “Par ailleurs, le n° de transaction n’est pas repris (nécessaire pour l’appariement avec le fichier de la banque).”

      Donc, l’export des transactions seules n’est pas suffisant, c’est la liaison avec les informations saisies dans formidable qui va vraiment être utile.

    Reply to this message

  • 6

    Bonjour Cedric,
    est-ce qu’il te serait possible partout ou il y a “EUR” ou ’EUR’ de remplacer par une constante (qui fonctionne aussi avec le plugin PRIX) et qui permette de débrayer la devise par defaut ?

    Merci pour l’Internationale !

    //devise de référence
    define('DEVISE_DEFAUT','&nbsp;EUR');
    
    //écriture de la devise par défaut
    define('PRIX_DEVISE','fr_FR.utf8');
    
    //pour money_format
    setlocale(LC_MONETARY, PRIX_DEVISE); 
    • Bonjour à tous,

      Je soutiens la demande de Touti !

      J’ai des sites sur plusieurs continents, je suis obligé d’avoir une version modifié manuellement pour avoir les bonnes devises... Inutile de dire que je ne suis plus les mises à jours...
      Dans la page de config il faudrait pouvoir configuré Pays et Devise et avec les codes ISO. Le module Paypal appelle ces valeurs par exemple, elles sont en dur dans le code.. Dommage.

      Un rapprochement avec le plugin DEVISE serait judicieuse je pense :)

      Merci en tout cas pour ce super plugin !

      Bien à vous,
      Julien

    • La gestion propre des devises est en effet à intégrer dans le plugin. Ça ne concerne pas uniquement les affichages mais aussi les echanges techniques avec (toutes) les plateformes de paiement.

      C’est sur ma liste de todo, mais pas encore eu le temps (ou le projet) pour le faire et le tester intensivement.

      Sur ce plugin j’ai une politique très restrictive d’évolution/commit : je ne valide que des évolutions que j’ai pu tester en live, car il est hors de question d’envoyer des évolutions qui cassent le paiement sur des sites en production.

      Par contre je crois que la demande de Touti ne concerne que les affichages, ce qui serait déjà un premier pas. Mais à ce point là rien ne sert de mettre une constante qui sera dépréciée dans 4 matins, je pense qu’une fonction surchargeable pour afficher le libellé de la devise sera préférable, car pouvant gérer le multi-devises.

    • Pour info dans ma version “custom”

      J’ai modifié/ajouté dans le plugin et ces modules :
      -  La devise dans le fichier option (une fonction _dist serait la bienvenue)
      -  Les frais fixe et variable dans Paypal
      -  la devise (currency_code et mc_currency) dans Paypal
      -  le pays (lc) dans Paypal

      J’ai également fait developpé une module “presta” pour Global Payment Webpay https://www.globalpaymentsinc.com/en/europe/accept-payments/online/gp-webpay, utilisé en europe centrale, si cela peut servir à quelqu’un ;)

    • Bonjour Cerdic,

      Je viens aux nouvelles quant à la prise en charge de plusieurs devises sur le plugin BANK.

      Pour ma part j’utilise toujours des versions “Custom” du plugin BANK que j’utilise sur tous les continents ou presque :)

      Ca marche très bien, je serais heureux de pouvoir profiter des mises à jour du plugin.

      En vous remerciant.
      Julien

    • Je t’invite à faire une proposition de Pull Request pour tes modifications, qui semblent au moins avoir été testée sur PayPal, et je pourrais par la suite regarder pour compléter les autres prestataires bancaires.

      En pratique on ne peut pas releaser une version multi-devise sans que ça soit pris en compte sur tous les modules de paiements.

      Attention, avec la mise en place de la DSP2 en septembre 2019, il est fortement recommandé de passer à la v4 du plugin

    • Bonjour Cerdic,
      Je ne suis pas très familier avec GitHub, si il y aurait un guide qqpart ce serait super.

      Quoiqu’il en soit, je me suis créé un compte github, j’ai cloné le repository nursit/bank/, j’ai créé une nouvelle branche (nommé devise), j’ai fais une première modification permettant de modifier la devise via la page du plugin.
      J’ai commité ma modif, mais je ne sais pas si vous l’avez reçu.
      Merci d’avance pour vos lumières,
      JuL

    Reply to this message

  • Est-ce normal si la dernière version du plugin Bank (Version 3.6.7) n’est pas détectée pour mise à jour sur la page ?exec=admin_plugin ? J’ai pour l’instant la version
    Banque&paiement 3.6.1 - stable
    J’ai bien l’icône de mise à jour pour d’autres plugins.

    Et en faisant une recherche sur “bank” ou “banque” sur la page ?exec=charger_plugin ce plugin n’est pas listé.

    Merci
    dd

    Reply to this message

  • 2

    Merci pour le gros travail réalisé pour l’échéance du 14 septembre.

    Néanmoins je ne comprends pas trop ce que je dois faire pour le pipeline bank_dsp2_renseigner_facturation.

    Dans mon cas, le paiement arrive en fin de formulaire formidable sur lequel j’ai notamment collecté nom, prénom, email. Que dois-je faire pour que Stripe reçoive ces éléments ?

    • C’est dans le plugin formidable_paiement que cela devra être géré, notamment en permettant de définir quels champs correspondent aux infos de nom, adresse, CP, ville, pays, pour que la demande de paiement soit au maximum complète. Mais formidable_paiement n’a pas encore été modifié.

      Dans l’attente ça ne bloquera pas et ça fonctionnera comme ça, le seul inconvénient étant un risque d’avoir plus de demande d’authentification type 3DS par la banque lors du paiement.

    • OK merci. Pour l’instant le seul champ que le plugin formidable_paiement me demande de mapper est l’adresse email.
      Je vais surveiller les évolutions de ce plugin

    Reply to this message

  • Bonjour,
    Merci pour cet excellent plugin ;-).
    Même si c’est anecdotique, j’ai trouvé un petit bug (a priori) sur les images de CB pour SIPS dans la page de l’admin quand on fait “Payer” sur une transaction par virement.
    J’ai modifié le fichier sips.php de presta\sips\inc :
    AVANT : $result = $sips_exec_request($service,$params,$certificat,’$dir_logo,$request); (ligne 83)
    APRES : rajout de ’../’. devant $dir_logo
    Cela semble fonctionner sans affecter le formulaire publique ni la validation du paiement.
    Bonne journée

    Reply to this message

  • 2

    bonjour,
    j’ai quelques transactions qui ont été enregistrées avec le code -1 (dans la colonne “Finie”) et je vois le message suivant pour ces transactions : “La prise en compte du paiement de cette transaction a été interrompue en cours de traitement. Une réparation manuelle de la base de données est nécessaire.”

    Qu’entendez-vous exactement par une “réparation manuelle de la base” ?

    Deuxième question : y a-t-il un moyen de savoir d’où vient ce problème car les transactions concernées par ce code -1 ont pourtant bien abouties chez Stripe et elles sont bien enregistrées comme payées dans la base.

    merci
    christophe

    • Comme l’indique le message, c’est “la prise en compte du paiement” dans SPIP qui a été interrompue.

      Le paiement a bien été effectué, Stripe a envoyé une notification au site pour dire “hé ce paiement est OK” et là le plugin déclenche un certain nombre d’opérations : mise à jour de la base avec les informations du paiement, envoi d’un mail de confirmation, éventuellement emission d’une facture si le plugin adhoc est installé etc…

      Pendant toutes ces opérations la transaction est mise dans un état intermédiaire avec un -1 sur le flag `finie` : ça permet au plugin de savoir qu’elle est en cours de traitement si jamais on a une double notification (ce qui arrive souvent avec certains moyens de paiement) et donc de ne la traiter qu’une fois.

      A la fin du traitement le flag -1 est enlevé et la transaction est marquée comme réellement finie.
      Mais si pendant ce traitement il y a un restart apache, ou un timeout parce que le serveur est lent ou tout autre évènement qui fait que le traitement ne va pas au bout, la transaction reste dans cet état.

      Ce n’est pas dramatique, mais selon là ou le traitement s’est arrêté, peut-être il manque la facture, ou peut-être le mail n’a pas été envoyé à l’acheteur etc…

      Aucun moyen de savoir en détail où ça a coincé et ce qu’il faut faire pour réparer, il faut analyser en détail. Mais ça peut aussi rester comme ça sans conséquence

    • c’est très clair, merci.

    Reply to this message

  • 1

    J’ai installé le plugin Bank + Stripe, mais je voudrais utiliser la librairie de stripe directement dans mon code PHP.

    Est-ce que l’API stripe est intallée via Composer, et on ajoute simplement :

    1. require_once('vendor/autoload.php');

    en début du script PHP ?

    Ou bien un autre include est nécessaire avant de faire les appels à l’API du type :

    \Stripe\Stripe::setApiKey("sk_test_ByhT13mszp6j");
     
    	// Create a Customer:
    	$customer = \Stripe\Customer::create([
    		'source' => 'tok_mastercard',
    		'email' => 'paying.user@example.com',
    	]);

    Merci de votre aide sur ce problème un peu en marge du plugin Bank.
    Julien

    • Je complète :
      -  l’installation via composer ne marche pas pour le moment sur OVH, il bug sur le téléchargement d’un Json
      -  si je fais un include direct de /stripe/init.php, cela bloque tout...

    Reply to this message

  • Bonjour,

    pourquoi systempay, dans sa version SPPlus, ne gère-t-il pas les abonnements ? C’est pourtant possible dans la documentation : https://www.ocl.natixis.com/systempay/document/index/key/3b2e53ddf3c4080a95dd2d4471a814d7#

    En PJ j’ai mis un extrait de code proposé par la doc.

    .Gilles

    Reply to this message

Comment on this article

Who are you?
  • [Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom