Bundle de paiement

[OlivierB]

Après l'inscription à l’événement, il y a le paiement.

Après avoir jeté un coup d'oeil à des bundles déjà fait (JMSPaymentPaypal), je n'ai pas trouvé quelque chose à mon gout. Un système basique comme on a besoin demande 1 bouton et une page php de retour pour validation. En cas de besoins plus exigeants quelques lignes de cette nouvelle paypal RESTful API feront l'affaire. Le plus complexe est au niveau des options proposées.

Il faut définir les possibilités de paiement :

• payer pour soi
• payer pour 1 ou plusieurs autre membre de l'équipe
• payer pour une autre personne hors de l'équipe ?

Le problème des cas particuliers (Joueuses et gagnant des dernières éditions) .

Je propose un système de coupons :

• coupon à usage unique avec association (ou non) à un joueur
  • A la fin d'une LAN, on pourras associer un coupon pour chaque gagnant. Ce système peut être facilement automatiser pour créer des coupons pour toute l'équipe avec un simple bouton
  • Autre future amélioration : donner la possibilité d'offrir son coupon à un autre joueur.
• coupon utilisable par tout le monde (avec une date de fin de validité par exemple) : on peut créer le coupon "je suis une joueuse et j'en suis fier !"
  • je n'ai trouvé aucun moyen qui évite une vérification admin. Mais ce système est préférable (pour moi) à une modification à la main par l'admin.

C'est le seul système que j'ai trouvé pour avoir quelque chose d'adaptatif et cohérent. Ca ouvre de nombreuses possibilités pour des innovations futures.

Je ne compte pas implémenter de système de remboursement (au moins au niveau paypal). Libre aux futur admin de le faire.

Pour le paiement, je propose un système de transactions :

• une transaction correspond à une validation de la procédure de paiement (même si celui-ci est de 0€ [pas de passage par paypal])
• toutes les données de cette tables sont en dure pour survivre à toute suppression sur le site
• une transaction n'est pas supprimable

Si on se contente d'un paiement par personne sans gestion de remboursement on peut mettre sur la table d'inscription d'un joueur à un événement un champ qui contient l'id de la transaction (ou nul si non payé).

Pour pouvoir gérer le paiement multiple et les remboursements, je propose une table intermédiaire entre les inscrits et la transaction. S'il y a une transaction pour 5 personnes, cette table contient 5 lignes.

• Le fait de garder une ligne par personne donne la possibilité de faire de la gestion plus fine et de gérer un remboursement pour une des 5 personnes.
• cela permet aussi de gérer plusieurs coupons associés a différentes personnes sur une même transaction.
• les coupons uniques périment a partir du moment ou ils sont associé à une transaction (ou a une ligne de la table intermédiaire plutôt)
• pour les coupons globaux, il faut une table d'associations (utilisateur - table inter - coupon)

Problème visibles :

• utilisation des coupons lors de paiement groupé ? comment la personne qui paye pour quelqu'un d'autre peut sélectionner son coupon si elle en possède un.
• demander une autorisation avant de payer pour une autre personne (peut permettre a la personne qui accepte de sélectionner ses coupons à ce moment là)
• éviter une perte de données si remboursement - il serait bien que le choix initial fait lors du paiement soir retrouvable même s'il est erroné.

Toute autre solution ou structure est bienvenue.

[Jaconil]

ping @KenTiN, @Lulububu, @alexandrescieux

[Jaconil]

Je suis tout de même un petit peu réservé sur ton système de coupons... ça me paraît un peu compliqué d'un point de vue joueur...

[OlivierB]

je me disais qu'une presentation comme sur les sites machants ne perturberiat pas trop les joueurs.

Quelque soit le systeme, il faut que :

• l'information qui provoque un changement de pris soit associe avec le paiement
• eviter a Jaconil ou aux nouveaux admin de tout faire a la main
• simple et comprehensible pour tout le monde (raison pour laquelle je me basais sur un systeme connu et utilise par tout le monde)
• non implemente en dur dans le code (cas par cas)

Si on fait un systeme de paiement 1 par 1, l'ensemble est relativement simple.

[Jaconil]

donc tu crois que si on donne un code de réduction "NA133CSGO" à un joueur pour une prochaine édition, il va s'en rappeler pendant 6 mois ? Personnellement je paris qu'il y aura un mail ou un post sur le forum "Eh, j'ai gagné la dernière édition, mais c'est encore marqué que je dois payer sur le site, vous pouvez me passer en payé svp ?" ...

[OlivierB]

Pour les gagnant, je pensais utiliser un coupon unique attribue a la personne. Ca veut dire que l'id de l'utilisateur est integre dans le coupon.

Il est donc facile de faire une page de paiement "Choix de vos coupons" qui affiche les coupons que la personne possede (checkbox pour la selection). Puis une seconde categorie "Coupons du moment" qui contient celui pour les filles.

Donc un gagnant n'a rien besoin de se souvenir et heureusement !

Maintenant, si un coupon est offert par un de nos partenaires, c'est sur que la il aura beosin du code du coupon.

[Jaconil]

Ben au pire pour les gagnants oui faudrait associer automatiquement le coupon au joueur dans l'admin. Pourquoi la page "sélection de vos coupons" ? Les coupons sont automatiquement appliqués si le joueur en a non ?

[OlivierB]

Ben au pire pour les gagnants oui faudrait associer automatiquement le coupon au joueur dans l'admin.

Et la reponse :

A la fin d'une LAN, on pourras associer un coupon pour chaque gagnant. Ce système peut être facilement automatiser pour créer des coupons pour toute l'équipe avec un simple bouton

Et :

Pourquoi la page "sélection de vos coupons" ? Les coupons sont automatiquement appliqués si le joueur en a non ?

Ca implique que tu es pour ce systeme ? c'est un detail pas vraiment defini. Si la personne a deux coupons ?

J'aimerais aussi les reactions de @KenTiN @Lulububu @alexandrescieux si possible ;) N'hesitez pas a proposer un autre systeme...

[Jaconil]

Penser également à gérer le cas des gens payant au BDE ou lors des préinscriptions à l'école.

[Lulububu]

J'en ai pas mal parlé avec Olivier IRL. Cela me paraît être la solution la plus souple pour nous et user friendly.

Pour les preinscriptions, il y a deux possibilités.

• Leur créer un coupon qu'il devront utiliser sur le site (permet de réutiliser le fonctionnement des coupons)
• créer une interface admin permettant de creer des transactions par argent physique (les joueurs n'auront pas à se connecter pour utiliser un coupon)

Je préfère utiliser à fond le système de coupon perso.

[Jaconil]

Moi je voudrais vraiment minimiser l'utilisation des coupons par les joueurs eux-même... c'est trop compliqué selon moi. Eux ce qu'ils veulent c'est juste s'inscrire. Pas "ah oui mais attends parce qu'il faut que j'utilise ce coupon qu'on m'avait donné, pour que je puisse m'inscrire avec un prix réduit, ah ouais mais alors je clique où du coup pour m'inscrire avec le coupon, mais... oh la la c'est compliqué jvais poster sur le forum ils vont le faire pour moi basta".

Pour information, les autres fois il y avait des comptes joueurs que je créais moi-même pour ceux qui venaient payer à l'école.

[OlivierB]

Et tu trouves ca normal de devoir creer un nouveau compte toi meme ?

Il vient te payer en liquide, s'il a un compte tu valides la transaction (pas besoin de coupon) sinon, tu lui crees un coupon "tiquet" qu'il utilisera lors du paiement pour valider sa place apres s'etre cree un compte.

Prends pas non plus les joueurs pour des idiots. Les coupons n'ont rien d'un systeme innovant. Tu trouves la meme chose sur tous les sites marchant.

[64q]

Et tu trouves ca normal de devoir creer un nouveau compte toi meme ?

D'ailleurs sur ce point il faudra toujours pouvoir le faire @Jaconil non ? Je sais que tous les gens ne sont pas inscrits sur le site et ça permettrait de le faire lors des inscriptions comme tu l'as souligné.

Pour le système de coupon je suis moyennement chaud, si un joueur a gagné l'édition précédente il vaut mieux qu'on mette un lien vers le formulaire de contact et un admin validera sa participation. Vaut mieux garder cet aspect manuel, encore une fois ça fonctionne très bien si quelqu'un s'en charge humainement.

[Jaconil]

D'ailleurs sur ce point il faudra toujours pouvoir le faire @Jaconil non ?

C'est déjà possible.

[OlivierB]

Vaut mieux garder cet aspect manuel, encore une fois ça fonctionne très bien si quelqu'un s'en charge humainement.

Ok je propose un super truc : on garde l'ancien site !

Tout ce que l'on fait, onl'a deja sur l'ancien site ! Pourquoi perdre notre temps a en faire un nouveau ?

• on a un forum pour la recherche d'equipe
• on a deja un systeme avec Paypal qui marche tres bien
• le systeme du contact aussi
• et puis on a Maxime pour aller faire les modifications en base de donnees

En fait je propose :

• on fait un gros forum
• on met toutes les donnees dans des fichiers excel
• on fait des screen des fichiers excel

Il ne reste plus qu'a enfermer @Jaconil dans un bureau pour faire croire au gens que tout se fait en live.

[Jaconil]

et puis on a Maxime pour aller faire les modifications en base de donnees

Hélas ce module souffre de plusieurs bugs critiques...

[OlivierB]

Voila le système que je compte mettre en place. Je ne présente pas les coupons ici, c'est un second temps.

Comme, je vous l'ai expliqué, une fois une action de paiement effectuée, elle n'est plus modifiable (cas particulier sur certain type de paiement fait par les admin)

Pour sauvegarder un paiement, j'ai besoin de 3 tables:

• table payment:
  • id
  • user-id
  • user-name
  • user-surname
  • user-mail
  • date
  • amount
  • valid
  • type (permet de faire de l'héritage):
  • paypal:
    • sid-uniqid
    • paypal-num-transaction (pour de futur remboursement intégré)
  • free (gratis)
  • liquid
  • adaptatif (pour pouvoir gérer les contres temps [dernier recours]):
    • id-admin
• table transaction (une transaction par personne):
  • id
  • user-id
  • event-id
  • price (basé sur EntryType + l'action des futurs coupons)
  • payment-id (not null)
  • refund-id
• table refund:
  • valid (permet de savoir si la transaction à été faite)
  • admin-id

J'ai assez de données en dur dans ces deux tables pour pouvoir reconstruire un paiement cohérent. Et je me base sur des champs suffisamment "solides" pour éviter des pertes d'information

Les règles:

• il ne peut y avoir qu'une seule transaction valide par personne par événement
• toutes les autres transactions doivent avoir un remboursement associé
• un même remboursement peut être associé à plusieurs personnes (je pense limité aux personnes qui ont payé ensemble pour éviter que ça soit le bazar)

requête : le paiement valide d'un joueur peut facilement être retrouvé avec user-id, event-id et refund-id == null.

Maintenant, il serait bien de voir comment lier une transaction avec une Entry (user-id; event-id)

1. pas de liaison, on se contente de la requête précédente:
   • requête un peu plus complexe
   • plus lourd pour le système
2. je peux mettre une Entry à la place de user-id et event-id dans la transaction :
   • si la place (Entry) est supprimée, je perds la raison du paiement
   • peut être corrigé par un champ text desc construit automatiquement dans le paiement (beurk)
3. Un transaction-id intégré à la table Entry:
   • si le champ est null, la personne n'a pas payé
   • sinon il contient l'id de la transaction
   • L'information est, d'une certaine manière, doublée puisqu'on pourait la calculé (0)
   • pour moi, c'est un gain de performance et ça apporte une liaison simple avec l'Entry, ou plutôt, on peut facilement retrouver la transaction valide liée à la place.
4. donnez moi des idées !

je suis pour la 3 perso -_-

D'autre idées de champs important pour le système ?

[OlivierB]

Je viens d'avoir un imprévu.

• Théoriquement, il est possible d'avoir plusieurs événements en même temps ?
• je ne gère actuellement qu'une transaction globale par personne. Ca veut dire que si la personne à une transaction en cours sur un deuxième événement (même si on paye pour elle), elle doit être terminée ou annulée avant de pouvoir faire un autre paiement.
• Je ne sais pas encore si je le corrige, ça vous parait important ?

[Jaconil]

C'est une faille critique

[Jaconil]

Pourquoi n'associerais-tu pas la transaction au couple User / Event ?

[OlivierB]

Je le fais déjà @Jaconil mais en fait, quand je récupère la transaction en cours, j'ignore l'évent associé pour éviter d'avoir a passer le slug event a chaque fois.

En revanche il n'y a pas de risque de confondre 2 events

[OlivierB]

• Ajout d'un système de session de 15 min pour le paiement
• Traitement particulier du paiement de 0 euros (payment paypal minimum de 0.02€)

[OlivierB]

@Jaconil @KenTiN Vous pouvez check mon essai pour garder l'integrite de la BDD ici

J'ai l'impression qu'il y a encore une erreur qui peut s'intercaler entre mon validator et mon flush.

Il faut peut etre rajouter une fonction qui verifie l'integrite complete juste avant le commit ?