Billetterie en ligne au Maroc : vendre billets et inscriptions, et savoir qui a payé

La billetterie en ligne au Maroc ne demande pas de logiciel de billetterie : pour les inscriptions ouvertes, un produit de votre boutique hébergée ou, par l'API, un lien de paiement réutilisable et son affiche QR ; un lien à usage unique par participant quand il faut une liste nominative ou un paiement en espèces ; le stock d'un produit quand les places sont limitées ; et une session de paiement si vous avez déjà un site d'inscription. Le portail et l'export disent qui a payé, combien et quand ; le jour J, l'accueil pointe à partir de cette liste. Ce guide s'adresse aux organisateurs de tournois, de galas, de salons, de conférences et d'ateliers.

La billetterie en ligne au Maroc, sans logiciel de billetterie

ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Pour un organisateur, il fait deux choses : encaisser les participants, par carte ou en espèces, et lister les paiements. Il ne fait pas le reste du métier de billetterie, et mieux vaut le savoir avant d'ouvrir les inscriptions.

Le billet, c'est donc votre confirmation : un message que vous envoyez une fois le paiement confirmé, ou simplement le nom du participant sur la liste d'accueil. L'outil de base reste le lien : tout le fonctionnement des liens de paiement est décrit sur leur page produit. Deux cas voisins ont leur propre guide : les adhésions récurrentes d'une association relèvent des cotisations d'association en ligne, et un créneau réservé par une seule personne — un terrain, une table, une séance — relève de faire payer une réservation en ligne.

Inscriptions ouvertes : un lien réutilisable et son affiche QR

Pour un événement ouvert à tous à prix fixe — un tournoi amateur, une soirée de gala, l'entrée d'un salon —, un seul lien suffit : un lien réutilisable au prix du billet. Un lien de paiement, c'est un montant et une description ; le client paie sur une page hébergée par ChariPay. Il se partage par lien, QR code, affiche PDF à imprimer, e-mail ou WhatsApp. Vous collez le lien dans vos publications et vos groupes, vous imprimez l'affiche avec son QR code pour les lieux où passe votre public, et chacun paie depuis son téléphone.

Où le créer : depuis le portail, chaque lien de paiement créé est à usage unique. Le lien réutilisable — un même montant payé par plusieurs clients — se crée par l'API, avec singleUse: false ; une fois créé, il apparaît dans le portail comme les autres. Sans développeur, pour vendre plusieurs fois au même prix, publiez un produit sur votre boutique hébergée et partagez son lien : c'est l'outil présenté plus bas pour les places limitées, et le stock y est optionnel.

Trois règles pour qu'il fonctionne :

1. 1Un lien par tarif. Un lien porte un montant : tarif plein, tarif étudiant et tarif équipe font trois liens et trois affiches.
2. 2Une expiration à la clôture des inscriptions. Donnez au lien une date d'expiration (expiresAt) : passé cette date, le lien expire et personne ne paie une place qui n'existe plus.
3. 3La carte seulement. Le lien réutilisable, son affiche et son QR code encaissent par carte, avec 3-D Secure ; les espèces passent par un lien à usage unique, une référence par dépôt.

Ce que vous voyez ensuite : le lien compte ses paiements. useCount donne leur nombre et totalCollected le total encaissé, par GET /v1/payment-links/{reference}, et chaque paiement apparaît dans le portail avec sa référence. Ce que vous ne voyez pas forcément : une liste nominative des participants. Si vous avez besoin des noms, recueillez-les avec votre propre formulaire, ou passez aux liens à usage unique. L'affiche PDF à imprimer — elle porte le QR code et le montant — s'obtient depuis la fiche du lien dans le portail, ou par l'API avec GET /v1/payment-links/{reference}/poster. La génération et l'emplacement de l'affiche sont détaillés dans paiement par QR code.

Avant d'imprimer quoi que ce soit, regardez l'affiche et le parcours d'un participant : Commencer en mode test. Trois champs — nom, e-mail professionnel, entreprise —, un lien d'activation reçu par e-mail pour choisir votre mot de passe, puis le portail, où vous créez vous-même votre clé de test. Créez un lien au prix du billet — depuis le portail, il sera à usage unique, ce qui suffit pour l'essai —, téléchargez son affiche depuis sa fiche, scannez-la et payez avec la carte de test. C'est gratuit, sans limite de durée et sans validation à attendre ; la vérification de votre entreprise (KYB) ne conditionne que le passage en production.

Une liste nominative : un lien à usage unique par participant

Dès que vous devez savoir qui a payé — invités, tarifs particuliers, inscriptions validées une à une, équipes à confirmer —, passez au lien à usage unique : un lien par personne, payé une seule fois, à son nom. Vous renseignez customerName et customerEmail à la création, ou choisissez un client enregistré, et chaque lien porte son statut : actif, payé, annulé, expiré. La liste des liens payés est votre liste d'inscrits.

C'est aussi la voie des espèces. Sur la page d'un lien de paiement à usage unique, votre client choisit les espèces, reçoit une référence, la règle dans une agence du réseau Chari, et vous êtes notifié dès que le réseau confirme le dépôt. Le paiement en espèces en agence s'appuie toujours sur un lien à usage unique — une référence par dépôt. Le lien passe alors « Payé ». ChariPay est la seule passerelle de paiement au Maroc à encaisser aussi les espèces en agence. Un participant sans carte n'est donc pas un participant perdu.

Quand les inscrits sont nombreux, créez les liens par l'API à partir de votre tableur ou de votre formulaire. Un appel suffit : POST /v1/payment-links renvoie le payUrl à partager. Renseignez amount, description, customerName, customerEmail, et un externalId égal à votre numéro d'inscription : unique par compte et par environnement, il évite de créer deux fois le même lien si votre script repasse. POST /v1/payment-links/{reference}/send peut ensuite l'envoyer par e-mail au participant.

Places limitées : un produit à stock

Quand la salle a une capacité, il vous faut une jauge. ChariPay en documente deux, pas davantage. La première passe par la boutique hébergée : pas encore de site ? Publiez vos produits sur votre vitrine hébergée et suivez vos commandes — en attente de paiement, payée, expédiée, livrée — depuis votre portail. Par l'API, le module Produits porte le prix, le stock optionnel et la page de vente de chaque produit. Pour un atelier à places comptées, le billet devient un produit, avec le nombre de places comme stock et sa page de vente comme page d'inscription. Sur la boutique hébergée, l'acheteur choisit à la commande de payer par carte — sur la page de paiement hébergée, avec 3-D Secure — ou en espèces : il reçoit alors une référence à régler dans une agence du réseau Chari. Vous suivez chaque commande dans le portail ; par l'API, une commande payée par carte déclenche l'événement order.paid.

La seconde se construit à la main : autant de liens à usage unique que de places, envoyés aux personnes que vous retenez. Chaque lien ne se paie qu'une fois : le compte est juste par construction.

Ce que nous ne promettons pas : une gestion de quotas par tarif, une liste d'attente automatique, ou le détail des informations qu'une commande recueille sur l'acheteur. Avant d'ouvrir un événement à places limitées sur un produit, passez une commande d'essai par carte en mode test et regardez ce que le portail vous montre.

Vous avez déjà un site d'inscription : la session de paiement

Si votre événement a déjà son site, avec son formulaire et sa base d'inscrits, branchez le paiement au bout du formulaire. Une commande devient une session : vous créez la session côté serveur, vous redirigez l'acheteur vers le checkout hébergé — carte avec 3-D Secure —, et vous recevez le résultat par webhook signé. Chaque session a une durée de vie limitée — 72 heures par défaut, expiresAt pour la raccourcir — et n'est consommée qu'une seule fois.

Trois règles pour une billetterie :

• Confirmez l'inscription sur le webhook. Confirmez la commande sur réception du webhook, jamais sur la seule redirection : la redirection dit que l'acheteur est revenu, pas que le paiement est acquis.
• Mettez votre identifiant d'inscription dans `metadata`. Retrouvez votre commande par votre metadata, renvoyé tel quel dans l'événement ; pour une session, l'événement porte aussi votre orderId.
• Raccourcissez `expiresAt` si vous retenez une place le temps du paiement : une session abandonnée ne doit pas bloquer une place pendant 72 heures.

Une session n'encaisse que la carte : pour un inscrit qui veut payer en espèces, envoyez un lien à usage unique. Le parcours complet est décrit sur la page du checkout hébergé.

Savoir qui a payé : portail, statuts et export

Chaque outil répond différemment à la question « qui a payé ? ».

Pour la liste de la veille comme pour la comptabilité, chaque mouvement du compte porte la référence de la vente, du remboursement ou du versement qui l'explique ; le portail distingue montant payé, frais et net, et l'export CSV reprend ces références — depuis le portail ou par GET /v1/transactions/export.csv (jusqu'à 10 000 lignes ; au-delà, découpez par période avec from/to). Les horodatages sont en UTC ; le Maroc est en UTC+1 : votre outil de rapprochement doit convertir.

Pour savoir où les inscrits s'arrêtent, le portail montre l'entonnoir d'un lien ou d'une session — combien ont ouvert la page, combien ont saisi leur carte, combien sont allés au bout — et le module API Parcours client expose le résumé d'entonnoir et le détail des événements d'une ressource. Beaucoup d'ouvertures et peu de paiements ? Relisez le prix affiché, la description et le message qui accompagne le lien.

Annulation ou désistement : annuler, rembourser

Pour fermer les inscriptions, annulez le lien réutilisable et les liens à usage unique encore actifs. Un lien annulé ne peut plus être payé : une affiche restée collée quelque part ne fera plus entrer d'argent.

Pour un désistement ou un événement annulé, remboursez les paiements par carte. Remboursez un client, en totalité ou partiellement, depuis le portail ou par l'API. Le remboursement est gratuit ; son montant est déduit de votre solde disponible, et si le solde ne suffit pas, l'opération est bloquée plutôt que de créer un découvert. Un remboursement n'est pas instantané côté banque.

Deux conséquences pour un organisateur :

• Gardez de quoi rembourser tant que l'annulation reste possible : si les recettes sont déjà parties vers votre banque, une vague de remboursements peut être bloquée faute de solde.
• Annoncez votre politique avant l'ouverture des inscriptions — remboursement total, partiel ou report — et rappelez-la dans le message qui accompagne le lien.

Par l'API, chaque remboursement porte une refundReference déterministe, dérivée de l'inscription : rejouer le même appel ne rembourse pas deux fois. Le pas-à-pas est dans rembourser un client.

Le jour J : l'accueil à partir de la liste

ChariPay ne contrôle pas l'accès : l'accueil se fait à partir de votre liste, en cinq gestes.

1. 1Établissez la liste la veille au soir, à partir du portail et de l'export CSV : liens à usage unique payés, commandes, inscriptions confirmées par webhook — horodatages convertis à l'heure marocaine.
2. 2Partagez-la avec les bénévoles de l'accueil, triée par nom, imprimée ou sur un téléphone.
3. 3Pointez les noms à l'entrée : la liste fait foi, pas un message transféré.
4. 4Pour un retardataire sans inscription, créez sur place un lien à usage unique à son nom et affichez son QR code depuis la liste des liens, ou montrez l'affiche QR du tarif s'il paie par carte.
5. 5Vérifiez le statut « Payé » dans le portail, jamais sur une capture d'écran : une capture se fabrique, un statut non. Les bénévoles en rôle caissier encaissent sans voir le solde ni les virements, mais ne voient que leurs propres liens et leurs propres transactions : un paiement fait ailleurs se vérifie par l'organisateur, propriétaire ou gestionnaire.

Après l'événement, l'export et le portail font le bilan : chaque paiement et chaque remboursement avec sa référence, et le montant payé, les frais et le net tels que le portail les distingue.

Questions fréquentes

Comment vendre des billets en ligne au Maroc sans site web ?

Sans développeur, publiez le billet comme produit de votre boutique hébergée et partagez son lien : l'acheteur paie par carte avec 3-D Secure, ou choisit les espèces et reçoit une référence à régler en agence. Pour une liste nominative, envoyez à chaque participant un lien à usage unique depuis le portail. Le lien réutilisable, carte seule, se crée par l'API ; son affiche QR se télécharge ensuite depuis sa fiche. Ni site ni logiciel de billetterie ne sont nécessaires.

Peut-on limiter le nombre de places d'un événement ?

Oui, de deux façons documentées : publier le billet comme produit de la boutique hébergée, avec le nombre de places comme stock optionnel, ou créer autant de liens à usage unique que de places, chacun payable une seule fois. Nous ne documentons ni gestion de quotas par tarif ni liste d'attente automatique : essayez votre montage en mode test avant d'ouvrir.

ChariPay envoie-t-il un billet ou un QR d'entrée au participant ?

Non. ChariPay encaisse et liste les paiements, mais n'émet ni billet ni QR code d'entrée, et ne contrôle pas l'accès. Le billet, c'est votre confirmation : un message que vous envoyez une fois le paiement confirmé, ou le nom du participant sur la liste d'accueil, établie à partir du portail et de l'export.

Un participant peut-il payer son inscription en espèces ?

Oui, avec un lien à usage unique à son nom : sur la page du lien, il choisit les espèces, reçoit une référence et la règle dans une agence du réseau Chari. Dès que le réseau confirme le dépôt, le lien passe « Payé » et vous êtes notifié dans le portail. Sur la boutique hébergée, l'acheteur peut aussi choisir les espèces à la commande ; le lien réutilisable et son affiche QR, eux, n'encaissent que la carte.

Comment savoir qui a payé son inscription ?

Avec des liens à usage unique, chaque participant a son lien et son statut : la liste des liens payés est votre liste d'inscrits. Avec un lien réutilisable, vous voyez le nombre et le total des paiements, pas les noms, qui viennent de votre propre formulaire. Dans tous les cas, l'export CSV reprend chaque paiement avec sa référence.

Comment rembourser les participants si l'événement est annulé ?

Fermez d'abord les inscriptions en annulant les liens, puis remboursez chaque paiement par carte, en totalité ou partiellement, depuis le portail ou par l'API. Le remboursement est gratuit et déduit de votre solde disponible ; s'il ne suffit pas, l'opération est bloquée. Gardez donc de quoi rembourser, et prévenez les participants que le retour sur carte n'est pas instantané.

Peut-on encaisser les inscriptions depuis son propre site ?

Oui, avec une session de paiement : votre serveur crée une session pour chaque inscription, redirige le participant vers le checkout hébergé — carte avec 3-D Secure — et confirme l'inscription à réception du webhook signé, jamais sur la seule redirection. Mettez votre identifiant d'inscription dans metadata : il revient tel quel dans l'événement. Pour les espèces, envoyez un lien à usage unique.

Prochaine étape

Montez la billetterie complète en mode test avant d'ouvrir les inscriptions : Commencer en mode test, créez deux liens d'invités à usage unique, téléchargez l'affiche de l'un depuis sa fiche, payez-les avec la carte de test, puis lisez l'export ; le lien réutilisable, lui, se crée par l'API avec votre clé de test. La page liens de paiement résume l'offre, et le guide du paiement par QR code vous aide à placer l'affiche.