Billetterie en ligne pour une association : préparer les paiements

Définir les billets avant la page de vente

Listez les catégories vendues, les quantités disponibles et ce que chaque billet permet réellement. Une place individuelle, une réservation de groupe et un atelier à horaire fixe n’ont pas les mêmes contraintes. Désignez la source de vérité de la capacité : le système de billetterie doit savoir ce qui reste disponible. Un paiement ne gère pas à lui seul l’inventaire des places. Pour chaque catégorie, décrivez aussi qui peut autoriser une correction et où cette décision sera enregistrée.

Billetterie en ligne et paiement des billets — Soon

Organiser l’attente pendant le paiement

Le participant peut quitter sa page alors que la transaction n’est pas encore terminée. Votre système doit décider comment une place est réservée pendant cette attente et comment elle est libérée selon ses règles. Ne traitez pas le retour du navigateur comme un résultat définitif. Une réservation et un paiement doivent avoir des identifiants reliés, mais distincts. Définissez la procédure pour une confirmation reçue après l’expiration d’une réservation, afin que l’équipe ne promette pas une place déjà attribuée à une autre personne.

Intégration et API

Émettre le billet après confirmation vérifiée

Le billet doit être créé selon le résultat serveur vérifié. Les notifications de paiement peuvent être répétées ; la même commande ne doit donc pas produire plusieurs billets valables par accident. Conservez un identifiant unique pour chaque droit d’entrée et une trace de l’émission. Les documentations de Stripe et de Mollie aident à comprendre la réception des résultats indépendamment du parcours visible. Le courriel de billet peut être renvoyé, mais ce renvoi ne doit pas créer un nouveau droit d’accès.

Page de paiement hébergée

Préparer le contrôle d’entrée

À l’accueil, les bénévoles ont besoin d’une décision simple : billet valable, déjà utilisé ou à examiner. Le système de contrôle doit retrouver la même identité de billet que celle émise après le paiement. Un QR code est un support de lecture, pas une garantie à lui seul. Prévoyez le cas d’un téléphone déchargé, d’un billet transféré selon vos règles ou d’un participant présent deux fois dans une liste. Les personnes à l’accueil ne devraient pas devoir consulter un compte PSP pour chaque entrée.

Traiter les changements d’événement

Un changement de date, une annulation ou une demande de correction touche à la fois le droit d’entrée et le suivi du paiement. Décrivez le processus de décision avant la vente et faites valider les conditions applicables. Un billet annulé n’implique pas automatiquement qu’un remboursement a été exécuté. Enregistrez les deux résultats et désignez les personnes habilitées. Si plusieurs bénévoles interviennent, une note de dossier claire évite d’engager deux fois la même opération ou de fournir des réponses contradictoires au participant.

Évaluer le périmètre de chaque solution

La billetterie OrsunPay est sur la feuille de route et n’est pas disponible aujourd’hui. Les concepts envisagent un règlement via le propre compte PSP de l’organisateur, sans date de lancement confirmée. Pour un événement prochain, choisissez un outil de billetterie disponible et vérifiez son périmètre réel. Le paiement, l’émission des billets, le contrôle d’accès et la gestion de capacité doivent être évalués séparément. Aucun frais, niveau de gratuité ou résultat d’acceptation n’est déduit d’une simple présentation commerciale.

• Tester la dernière place disponible et une réservation expirée.
• Simuler une notification reçue deux fois.
• Vérifier qu’un renvoi de billet conserve le même identifiant.
• Préparer une file de résolution à l’accueil.
• Distinguer annulation du billet et résultat du remboursement.

Sources

• Documentation Stripe sur les webhooks
• Documentation Mollie sur les paiements