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,
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
Répondre à ce message
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.
Répondre à ce message
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 :
en début du script PHP ?
Ou bien un autre include est nécessaire avant de faire les appels à l’API du type :
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...
Répondre à ce 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
Répondre à ce message
Salut,
D’abord merci pour ce superbe plugin très pratique.
J’ai mis en place un système de paiement récurrent avec le provider Stripe. Côté Stripe, les paiements sont bien renouvelés et il appelle correctement le webhook qui lui renvoie une 200. Cependant, côté Spip, rien ne se passe : pas de nouvelle transaction créée, pas de mise à jour de la transaction existante.
Ma question est donc : qu’est-il sensé se passer dans ce cas (la doc est peu bavarde à ce sujet) ? Une nouvelle transaction ne devrait-elle pas apparaitre en base ? Comment savoir qu’un paiement a été renouvelé ?
Merci !
Quelques pistes (mais je ne suis pas arrivé à bout du schmilblick) :
Ligne 174, il manque 2 variables importantes pour décrire le plan :
Il faut donc que tu adaptes ta fonction ’decrire_echeance’ (dispo dans le dossier /abo du plugin) pour délivrer ces 2 paramètres.
Si le produit n’existe pas, il faut le créer.
Voila où j’en suis. Avec ces 2 variables, ça fonctionne.
Répondre à ce message
Bonjour,
Je n’arrive pas à comprendre pourquoi le montant indiqué dans la réservation est correct alors que dans les transactions ce montant est multiplié.
Exemple : je réserve 10 places à 13 € = montant total 130,00 € (correct dans l’espace privé)
Quand je regarde les transactions je me retrouve avec 1300,00 € Pourquoi transactions multiplie t-il le montant total (130,00 €) par le nombre de personnes inscrites ?
Yann
Je précise que j’utilise réservations multiples. Si j’inscris 1 seule personne tout est correct, mais dès que je mets une quantité de 2 ou plus le montant total de la transaction est égal à : (prix X par nombre de personnes) X par nombre de personnes.
Une incompatibilité avec réservations multiples ?
Problème résolu par Rainer Muller. Il s’agissait d’un problème sur le plugin reservation bank. Merci à lui.
Yann
J’activé les paiements par chèque et par virement. Quand je valide j’obtiens Une erreur 404 squelette bank_retour.html manquant. Mais ce squelette comme les autres est bien dans le dossier content du plugin. Quel est le souci ? Comment appeler ce squelette ?
Merci de votre aide.
Yann
Merci à Rainer...j’ai compris.
Désolé pour les doubles messages.
Yann
Bonjour,
Si tu as pas Z sur ton site, il faut faire les pages à la racine de squelettes/
Merci. Ca marche super !
Yann
Répondre à ce message
En « ecrire/ ?exec=configurer_bank », quand on choisi comme prestataire « Simulation (necessite une autorisation par define) (2CF8) », que faut-il faire exactement ?
« define », je suppose que c’est du PHP, mais où et comment ?
Merci d’avance,
Cordialement,
Hervé
Lire la doc par exemple ? :D
https://contrib.spip.net/Module-de-Paiement-Simule
Merci beaucoup !
J’avoue que ce point de la doc m’avait échappé.
Cordialement,
Hervé
Répondre à ce message
Bonjour,
Le « plugin Bank » est manquant dans le dépôt depuis l’espace privé en spip 3.2.1
Merci d’avance,
Cordialement,
Hervé
Répondre à ce message
Bonjour
Au risque de passer pour une blonde que je suis - désolé je débute et je n’arrive pas à tout suivre dans les explications- j’ai créé pour ma petite association un petit site sous spip dans lequel je souhaite mettre un formulaire un formulaire d’adhésion en ligne avec paiement par virement.
Le formulaire est créé (article), j’ai configuré le module de paiement par virement dans mon espace privé, mais comment j’appelle le paiement par virement dans mon article ? Et dois-je configurer une page html du plugins bank au préalable ?
Merci pour vos réponses
C’est un formulaire Formidable ? SI oui Il y a une extension de Formidable pour la transaction : https://contrib.spip.net/Paiement-avec-Formidable-4614
Bonjour monsieur
merci pour votre retour.
Non mon formulaire n’est pas lié à Formidable, il s’agit d’un article basique avec un pdf en bulletin d’adhésion.
Les gens renvoient le bulletin avec un chèque ou le bulletin par mail avec un paiement par virement (et ticket payeur à joindre aussi) depuis le site.
Ce n’est peut-être pas ce squelette dont j’ai besoin
Mademoiselle,
Un article « basique » n’est pas lié par défaut à une transaction. Je pense que le plus simple pour les virements est d’ajouter un formulaire Formidable avec l’extension transaction + le plugin Bank + paramétrer le mode virement.
Dit autrement : si vous demandez aux gens de remplir un PDF puis de l’envoyer par la poste, comment voulez vous qu’on puisse automatiser le traitement avec un plugin comme bank ?
Par contre ce qu’il est possible de faire est de créer un vrai formulaire web (avec le plugin formidable) qui peut se combiner avec l’extension transaction + bank.
Je vous remercie monsieur je vais essayer
je ne cherchais pas forcément à lier le pdf à la transaction mais juste renseigner le montant dans le paiement par virement à travers le plugin bank. le pdf sert juste de support complémentaire isolé.
je vais m’atteler rapidement au plugin formidable. Je vous remercie pour vos retours
Répondre à ce message
Bonjour
J’avais bien configuré les transactions par chèque et par virement.
Mais depuis une mise à jour de SPIP ( passage de 3.0 à 3.2) et des plugins dont celui-ci, lorsque l’on choisit ces options sur le site il apparait une fenêtre d’erreur :
« Aucun squelette bank_retour_attente.html n’est disponible... »
Pourtant ce fichier figure bien dans le dossier du plugin « content ».
La transaction figure bien en attente dans l’interface privée, mais les renseignements documentés dans la config ne parviennent plus à l’utilisateur ( adresse pour envoyer le chèque ou IBAN de la banque pour les virements)
Merci de votre aide
Je me réponds à moi-même.
Après plusieurs désinstallations et réinstallations, ça (re)marche.
Mais l’affichage des renseignements n’est pas stylé.
Merci de votre aide
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 :
|
