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 par date d’activité
65 discussions
Bonjour Cédric,
Tout est OK jusqu’aux pages de retour qui génèrent une erreur 404 avec un message Spip « Aucun squelette bank_retour_ok.html n’est disponible... » . Je suis avec la dernière version « bank-master » et ne trouve pas de solution.
Ce site http://nomathon.fr organise une manifestation sportive pour une association caritative qui opère les enfants victimes de maladies dé-génératrices .
SPIP 3.0.14, Sarka-SPIP 3.2.36 , Saisies pour formulaires 2.6.1, YAML 1.5.2, SPIP Bonux 3.2.1, Formulaires de paiement 1.0.6, Formidable 2.9.13, Facteur 3.3.4, API Prix 0.1.11, API de vérification 1.0.9
PHP Version 5.6.20
MYSQL v.5.5
D’avance merci
Jacques
Hello,
Les 2 squelettes correspondants sont fournis avec le plugin me semble-t-il.
Mais sinon, tu peux les créer toi même et les personnaliser : bank_retour_ok.html et bank_retour_erreur.html.
Dedans, il faut une boucle de la sorte :
On dispose de plusieurs balises utiles pour personnaliser le contenu :
#MESSAGE
#REGLEE
#MONTANT
etc. Voir la liste complète dans la table spip_transactions.Merci d’avoir pris la peine de répondre à mon poste et de me donner une piste, je vais essayer de mettre cela en place !!!
Les 2 squelettes existent déjà dans le dossier « content » !
Je suppose que : bank_retour_echec.html doit correspondre à bank_retour_erreur.html
Dans : bank_retour_ok.htm
La boucle créée par Cédric est :
Je dois la remplacer par celle que tu me proposes (Boucle transaction....) ou simplement l’ajouter ?
encore merci
Ah, ben ça devrait marcher avec le squelette de base du plugin (ma boucle n’apporte rien de plus, il manque le filtre
|propre
même !). Peut-être manque-t-il les paramètres id_transaction et transaction_hash dans l’URL de retour ?Tu peux vérifier avec quelque chose comme
[(#ENV{id_transaction}|sinon{"pas d'id_transaction"})] [(#ENV{transaction_hash}|sinon{"pas de transaction_hash"})]
.Si ces 2 paramètres sont bien présents, il faut vérifier qu’ils correspondent à une transaction existante.
En copiant le squelette bank_retour_attente.html dans le dossier squelettes, il n’y a plus d’erreur 404
Tout est rentré dans l’ordre grâce à vous !
Merci à vous deux de partager vos connaissances et de nous venir en aide.
Jacques
Tant mieux !
Après il suffit de compléter le squelette pour que cela ressemble aux autres page du site !
Pour ma part j’ai copié le squelette sommaire.html et inséré le contenu de bank_retour_attente.html à l’intérieur de la div class=« main »
Très bonne idée, encore merci !
Répondre à ce message
Bonjour Cédric,
Merci beaucoup pour ce plugin !
Dans la doc tu parles de l’API Abonnements :
Comment fait on pour l’implémenter ?
Merci d’avance,
Martin
Répondre à ce message
Bonjour,
Je voudrais essayer « Bank » mais sa recherche dans l’espace privé par « Gestion des plugins » me renvoie sur le plugin « Sauvegarde automatique ». La recherche en tapant « ban » ne le pointe pas.
Comment faire ?
Spip 3.0.21
Répondre à ce message
Bonjour,
est-il possible de transferer d’autres informations à la banque au moment du paiement ? comme par exemple le numéro de transaction bank ou le nom et le prenom du client ? Comment procéder ?
Répondre à ce message
bonjour à tous
et merci pour ce gros travail répondant certainement aux besoins de beaucoup d’associations...
une question/suggestion... Est-il imaginable d’avoir un module pour d’autres services de paiement, comme paymill ou b2bill (non US !) ou stripe (moins cher...), monetico (nouvelle version CIC...)...
pam
Répondre à ce message
Bonjour à tous,
Pour le paramétrage du plugin Bank, quelles sont les valeurs des urls à communiquer au prestataire CM-CIC ? 3 urls différentes sont demandées :
merci par avance ;-)
Pour la première URL, tu mets bien ce que tu veux, en fonction de là ou tu veux faire revenir tes utilisateurs hors circuit de paiement (ça doit corredondre à un lien « retour à la boutique » je crois).
Pour les autres URLs il faut indiquer l’URL_CGI2 fournie par le plugin dans la configuration de CM-CIC, et c’est la même dans le cas ok et dans le cas err.
Répondre à ce message
Bonjour,
Impossible de d’abandonner une commande dans la partie privée du plugin.
ligne 23 : bank/action/abandonner_commande.php
AND $row["statut"]=="commande"){
En le remplacant par :
AND $row["statut"]=="attente"){
Et la commande passe bien du status « attente » à « abandon ».
Répondre à ce message
Salut Cédric,
Merci pour le plugin Bank, depuis sa version pour SPIP 2 je l’utilise sur plusieurs sites et ça fonctionne super bien !
J’ai pourtant un blocage, là sur un site en SPIP 3.0, lors de la configuration d’un moyen de paiement CIC : sur ma config, dès qu’un nouveau moyen de paiement CIC est créé, le champ ’URL CGI2’ vient avec une valeur par défaut, que je ne parviens pas à changer :
bank.api/cmcic-690D/autoresponse/
, alors que la bonne valeur serait plutôt :spip.php?action=bank_autoresponse&bankp=cmcic-690D
.Aucune table ne semble contenir la valeur ’bank.api’ (j’aurais pu forcer la bonne valeur dans la bdd) et je n’ai trouvé aucun fichier de configuration où j’aurais pu écrire la bonne valeur.
Si tu penses à une piste, elle est la bien venue.
Merci !
Hello,
Quelle est la question ? Pourquoi ça t’embêtes que l’URL proposée par le plugin soit de cette forme ? Est-ce que ça marche ou pas ?
Pour info, cela utilise la Rewrite Rule .api du htaccess fourni par SPIP :
https://core.spip.net/projects/spip/repository/entry/branches/spip-3.0/htaccess.txt#L93
et le plugin teste que la Rewrite Rule est bien présente dans le htaccess avant de basculer sur ce format d’URL qui est plus facile à manipuler.
Donc je pense que ça doit marcher comme c’est prévu :)
La question est que les pages de retour
/bank.api/cmcic-690D/cancel/?id=123;123456
ou/bank.api/cmcic-690D/autoresponse/
génèrent une erreur 404.Nulle part sur le site ni dans les plugins il y a une page qui s’appelle ’bank.api’.
Mais la piste du .htaccess est bonne puisque sur un nginx le .htaccess n’est pas pris en compte.
Je check de ce coté, merci ;-)
Hello Cédric, hello à tous,
Après des recherches (et les conseils de quelques amis...) j’ai mis à jour ma config nginx afin de prendre en compte les urls en ’.api’. La rewrite rule Apache à faire prendre en compte par nginx était la suivante :
J’ai trouvé ce site qui permet de traduire des rewrite rules Apache en rewrite rules nginx : http://winginx.com/en/htaccess. Après une première tentative infructueuse, puis la modification du paramètre
break;
enlast;
j’ai obtenu une nouvelle rewrite rule au format nginx, et qui cette fois fonctionne bien :Merci pour tes réponses, et j’espère que ces quelques infos pourront aider d’autres spipeurs qui font tourner leur site sous nginx et utilisent bank !
Répondre à ce message
Bonjour Cerdic ,
Sauf erreur de ma part, le message de retour après « régler par chèque » ou « régler par virement » (bank_retour_attente.html) retourne la même chose, soit les indications du paiement par chèque. Un paramètre serait-il manquant dans l’URL ? Ou un champ input manque-t-il ?
Merci en tout cas pour ce plugin.
J’ajoute que le problème se produit quand les deux options sont proposées : paiement par chèque et par virement. Si seul le paiement par virement est activé, le retour affiche bien les indications du virement.
En déactivant temporairement le cache, le problème n’apparait plus !
#CACHE0 dans le squelette « bank_retour_attente.html » et le tour est joué !
Répondre à ce message
Bonjour,
Je teste le plugin Souscription (v. 2.0.3) sur un site de développement (v. 3.0.20).
J’ai installé le plugin Bank, qui a été configuré.
J’ai suivi les instructions (création d’une campagne).
Après avoir validé un don, j’ai ce message d’erreur : « Aucun squelette payer-acte.html n’est disponible... »
Le squelette est pourtant présent dans les fichiers du plugin.
Marc
Répondre à ce message
Ajouter un commentaire
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.
Suivre les commentaires : |