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].
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
- les banques Banque Populaire, Banque Postale, B.N.P., Caisse d’épargne, C.I.C., Crédit Agricole, Crédit du Nord, Crédit Mutuel, HSBC, LCL, Natixis, O.B.C., O.S.B., Société Générale ;
- Ogone, Paybox, Paypal, Paypal Express Checkout, Payzen, Stripe.
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
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
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
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 :
<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 :
<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
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é.
Discussions by date of activity
66 discussions
Sur une page de paiement par virement, j’ai utilisé la balise
#FORMULAIRE_PAYER_ACTE{ #PRIX*, #ARRAY{ montant_ht,#PRIX_HT*, id_commande,#ID_COMMANDE, id_auteur,#ID_AUTEUR, url_retour_ok,#SELF|parametre_url{etape,retour}|parametre_url{paiement,succes}, url_retour_echec,#SELF|parametre_url{etape,retour}|parametre_url{paiement,echec} } }Cela marche, mais m’amène à la page
spip.php?page=bank_retour_attenteau lieu de l’URL #SELF...Je constate en outre que dès qu’on est sur la page retour_attente, la valeur d’ID_COMMANDE n’est plus accessible, alors que c’est celle-là qu’on demande aux clients de signaler en commentaire de leur virement.
Y a t’il moyen de faire circuler l’ID_COMMANDE (par l’URL par exemple), et de retomber sur la page squelette désiré au lieu de bank_retour ?
Merci d’avance de vos pistes éventuelles.
Reply to this message
Bonjour,
Peut t-on envisager dans un futur proche l’intégration de paiement en cryptomonnaie, donc en “monnaie numérique” (ETH ou BTC mais aussi en Euro numérique, Dollar numérique USDT, yen numérique etc.) ?
Étonnant que personne n’en ait déjà parlé !
Ca me rappelle 2005-2010, quand les “administrateurs” prof/universitaire/encartés “bien diplômés” infantilisants et condescendants du forum & assoce (qui ne doivent plus être là, maintenant que ce n’est plus à la mode de se la jouer “dirigeant” d’un projet opensource/web et ne permet plus d’etre invité à des diners en ministère ou à l’elysée......) bridaient les vrais développeurs & réels contributeurs de tests, trad ou doc (de mon espèce) car ne voulaient pas entendre parler de “sociabilisation” ni “d’adresse URL propre” (ou “réécriture d’URL”)... adorant cette aberration d’url en “.../spip.php?index/...”
Reply to this message
Bonjour,
Une petite question à 1€ (payés en ligne) : est-il envisagé l’ajout de la solution Payplug à Bank, et si oui à quelle échéance ? Des clients qui préfèreraient utiliser un système français me demandent ça ....
Merci d’avance !
Pierre.
Reply to this message
Bonjour,
je signale un comportement inattendu avec BANK 6.3.0, qui se produit de façon récurrente si l’on n’y prend pas garde.
Donc, deux sites sur le même serveur : un en prod et l’autre en dev (en sous domaine de celui en prod). Avec une duplication des mêmes fichiers et une BDD propre à chacun et identiques au niveau config (mis à part l’adresse et le nom du site SPIP) avec le même user mysql. Les webhooks sur stripe ont été configurés pour les deux sites. (https://mon_domaine.org/bank.api/stripe-E8E5/autoresponse/ et https://dev.mon_domaine.org/bank.api/stripe-E8E5/autoresponse/)
Le souci est que le site en dev renvoie des notifications d’erreurs de l’api bank chaque fois qu’une nouvelle transaction est effectuée sur le site en prod. Stripe cherche indéfiniment un endpoint de webhook sur une transaction inconnue, puisque provenant du site en prod.
Les notifications envoyées depuis DEV
Le Webhook DEV doit être désactivé sur Stripe car même si je désactive le paiement stripe dans la config BANK sur dev, ça continuait à être interrogé et Stripe envoie alors une notif “Nous avons rencontré un problème lors de l’envoi de requêtes à un endpoint de webhook” avec comme référence le dev.
Ceci dit, les internautes ne sont censés subir aucun inconvénient et l’affichage en prod renvoie bien paiement OK
Reply to this message
Bonjour,
Plus aucun paiement ne passe depuis environ 10 jours. Je me sers de stripe et le formulaire stripe ne s’affiche plus. Lorsqu’on clique sur “payer par carte bancaire” il ne se passe rien :(
Une idée ?
Ma configuration :
spip 3.2.19
banque et paiement 6.2.1
plugin formidable 4.15.7
formulaire de paiement 2.1.0
Pareil pour moi en Spip 4.1.12
Reply to this message
Bonjour
Après la mise à jour du plugin (en version 4, sur spip 3.2.1, php 7.4), le Crédit Agricole ne fonctionne toujours pas pour la DSP2. J’atteins bien l’écran du numéro de carte bleue, mais lorsque je valide, j’ai “paiement refusé”. Est-ce qu’il y’a quelque chose à paramétrer pour que cela fonctionne ? Merci
bonjour,
j’ai apparement le même problème avec le CA et l’authentification 3dsv2
Avez vous trouvé une solution ?
Cordialement
Oui j’ai fini par trouver ! Le plugin Bank nécessite la maj du plugin Formulaire de paiement qui lui même nécessite la maj de Formulaire. J’ai finalement tout mis à jour, passant sur la dernière version de spip + dernières versions de bank + formulaire de paiement. Formulaire de paiement a des nouveaux champs obligatoires (en tout cas je ne les utilisais pas dans mon ancien formulaire, car mon client ne rentrait que son montant, son code client, et le nom de sa société). Il y’a un nouveau sous menu dans la création du formulaire : “configurez les traitements”, puis “paiements” dans options des traitements, et attribuer chaque champ à ce qui est demandé.
Attention au champ “Pays”, il doit être créé avec le plugin “Pays ISO 3166-1”, qui nécessite lui même “Géographie”. Cette option apparaitrait ensuite dans “divers” à la création de champ. Un champ texte ne fonctionnera pas.
bonjour,
merci du retour ainsi que de vos explications , mais le problème pour moi est le 3dsv2
avec l’insertion de la pipeline que je ne sais résoudre cf mon message ici 4627#comment514201
voilà si je comprends bien , en tous cas la banque a alerté et prévenu d’une coupure de service plusieurs fois pour “obliger” à me mettre en “conformité” . Ceci dit à l’heure actuel le plugin bank fonctionne très bien ( l’appel du terminal se fait normalement et le paiement s’effectue...)
Donc quid du pipeline, comment faire, si c’est bien la solution ?
Cordialement
Oui la solution que j’ai proposé au dessus règle le problème de la 3DSv2. Le Crédit Agricole m’avait coupé toute transaction dès lundi 8h, et bien que j’accédais quand même au terminal de la banque, impossible de valider le paiement. Il n’y a rien à faire en code (c’est ce que je pensais aussi au début, avec cette histoire de pipeline), mais bien à paramétrer correctement les traitements et les champs dans le formulaire de paiement mis à jour.
Pour être sûre de passer les paiements, j’ai séparé tous les champs demandés : par exemple j’ai “adresse”, “cp”, “ville”, “pays” plutôt que “adresse cp ville” “pays” ce qui permet de ne relier qu’1 seul champ par traitement.
merci,
est-il vraiment obligatoire de mettre les champs adresse, cp , ville , pays pour passer les paiements ?
nom et prénom du porteur CB ne suffit-il pas? j’ai pas trouvé de doc là dessus...
merci encore
Je pense qu’il faut tout car en épluchant le code de formidablepaiement_pipelines.php on trouve vers la ligne 106
$champs_payeur = [
’auteur’ => ’email’,
’nom’ => ’nom’,
’prenom’ => ’prenom’,
’adresse’ => ’adresse’,
’code_postal’ => ’code_postal’,
’ville’ => ’ville’,
’pays’ => ’pays’,
];
Si aucun champ n’est relié dans les traitements, je pense que ça bug. Dans mon formulaire d’origine je n’avais que le montant (transmis à la banque) et un code client + numéro facture (transmis à moi, ce qui me permettait d’avoir les coordonnées dans l’ERP) et ça ne marchait pas. Peut être qu’en les supprimant dans le code ça marche, mais ça oblige à passer en 3DSv2 pour le payeur, vu que son formulaire est incomplet. Dans le doute, j’ai mis tous les champs, ça oblige mon client à remplir plus de lignes qu’avant, mais avec le remplissage auto pour les prochaines fois (j’en ai beaucoup qui payent tous les mois via mon spip), il gagne en confort sans être trop embêté par le 3DSv2.
Mais je suis d’accord la doc est inexistante, alors que ça me semble être un module utilisé par beaucoup de monde !
certes, mais comme 90% des choses dans SPIP, c’est du benevolat d’écrire de la doc. NOus attendons donc ta contribution :)
Plusieurs échanges sur le dépôt Git :
https://github.com/nursit/bank/issues/99
https://github.com/nursit/bank/issues/118
Oula je suis une dev bricoleuse, j’ai passé un BTS de développeur d’appli en 2003 et je bidouille uniquement pour mes clients que j’avais sur ma première société (je ne fais plus de dev commercial depuis plus d’une décennie ^^). Je comprends ce que je lis, mais je suis rouillée pour partir d’une feuille blanche :P
Je viens de voir les échanges sur Github, je ne suis jamais tombée dessus lors de mes recherches Google, pourtant j’ai cherché ! Bon ça confirme que pour Crédit Agricole tous les champs sont obligatoires.
Reply to this message
re bonjour,
Comment mettre en place concrètement ceci ? :
Grand merci d’avance
Reply to this message
Le plugin bank a visiblement des problèmes de fonctionnement a savoir être conforme à la norme DSP2 et avoir un protocole de sécurisation 3DSV2 . Ceci d’après le Crédit agricole.
Qu’en est t’il réellement
Merci de votre retour
Reply to this message
Est-ce qu’il est possible d’ajouter Payfip dans la liste des services ?
Reply to this message
Bonjour,
Dans ce code généré par le plugin v 5.2.0.
sessionId:’’ est vide et évidement la paiement est annulé directe.
Je ne sais pas quoi faire remplir ce sessionId:’’. Une idée ?
Merci
GL
Tu as du personaliser le squelette
presta/stripe/payer/acte.htmlet du coup il est plus compatible avec le commit https://github.com/nursit/bank/commit/8ddaef4262dc97b6a30704a169d377072c984b91Je t’invite à repartir de celui du plugin dans la version 5.2.0 pour résoudre le soucis
Reply to this message
Add a comment
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Follow the comments:
|
