Paiement de réservation en ligne : faire payer un créneau, une table ou une précommande

Le paiement de réservation en ligne consiste à encaisser au moment où le client réserve, pour que le paiement bloque la place : un créneau, une table, un cours ou une précommande. Avec un site, vous créez une session de paiement qui expire en même temps que le créneau retenu ; sans site, vous envoyez un lien de paiement à usage unique par réservation, avec sa propre date d'expiration s'il est réglé par carte. Dans les deux cas, la réservation se confirme sur la preuve du paiement, jamais sur le simple retour du client. Ce guide détaille les deux montages, les précommandes, le double clic, la politique d'annulation, le remboursement et le no-show.

Paiement de réservation en ligne : encaisser au moment de réserver

ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Pour une réservation, son rôle est simple : faire payer le client au moment où il choisit sa place, et vous dire, de façon fiable, que le paiement est acquis. Un terrain de padel le jeudi soir, une salle de réunion pour une matinée, un cours de surf, une table pour un dîner de groupe, une commande de gâteaux pour l'Aïd : dès que la place est payée, elle est à ce client, et à personne d'autre.

Une règle évite les litiges. 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. Un client qui revient sur votre site n'a pas forcément payé : il a pu abandonner l'authentification auprès de sa banque ; un webhook signé payment.succeeded, lui, ne laisse pas de doute.

Deux cas voisins ont leur propre guide. Si vous demandez un acompte sur devis, puis le solde à la livraison, lisez encaisser un acompte. Si vous vendez des places pour un événement daté à participants multiples — tournoi, gala, atelier —, lisez billetterie en ligne. Ce guide traite le cas d'une place, d'une heure, d'un client, payés en totalité.

Avec un site : une session qui expire avec le créneau

Si votre site ou votre application gère un calendrier, la session de paiement est l'outil naturel. 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. Pour une réservation, c'est exactement ce qu'il faut : la durée de vie de la session devient la durée pendant laquelle vous bloquez le créneau.

Le déroulé, étape par étape :

1. 1Mettez le créneau en attente dans votre calendrier, au nom du client, dès qu'il le choisit.
2. 2Créez la session côté serveur, avec le montant, votre orderId et un expiresAt placé à la fin de la durée de blocage que vous acceptez — courte pour un créneau très demandé ; sans expiresAt, la session vit 72 heures.
3. 3Redirigez le client vers le checkout hébergé : il paie par carte, avec l'authentification 3-D Secure auprès de sa banque.
4. 4Confirmez la réservation à réception du webhook de paiement réussi, et seulement à ce moment-là.
5. 5Libérez le créneau à l'expiration : si l'heure de expiresAt est passée sans paiement, relisez la session par GET /v1/payment-sessions/{sessionId}, puis rendez la place au calendrier.

L'appel de création, avec la clé de test :

curl -X POST 'https://api-psp.charipay.ma/v1/payment-sessions' \
  -H 'X-CHARI-PAY-API-KEY: chari_sk_test_...' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: order-2026-0421-session' \
  -d '{
    "amount": 250.00,
    "orderId": "ORD-2026-0421",
    "externalId": "order-2026-0421",
    "config": {
      "customer": {
        "email": "amine.bennani@example.com",
        "firstName": "Amine",
        "lastName": "Bennani",
        "phone": "+212600000000"
      },
      "urls": {
        "accept": "https://votre-boutique.ma/paiement/succes",
        "decline": "https://votre-boutique.ma/paiement/echec",
        "notification": "https://votre-boutique.ma/webhooks/charipay"
      }
    },
    "metadata": { "cartId": "c_987", "source": "web" }
  }'

Pour une réservation, ajoutez expiresAt (horodatage ISO-8601 en UTC, dans le futur), réglé sur la fin du blocage choisi, et placez l'identifiant du créneau dans metadata : il vous revient tel quel dans l'événement de paiement, avec votre orderId. La réponse contient sessionId, sessionToken, verifyKey, expiresAt et checkoutUrl, rien d'autre ; le statut se lit ensuite par GET /v1/payment-sessions/{sessionId}. Le détail de l'expiration, de l'annulation et des pages de retour est dans expiration et retour d'une session de paiement, et l'offre complète sur la page du checkout hébergé.

Vous pouvez dérouler tout ce scénario avant d'ouvrir les réservations : 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 une session à expiration courte, payez-la avec la carte de test, et regardez votre créneau se confirmer à l'arrivée du webhook : aucun argent réel ne circule.

Sans site : un lien à usage unique par réservation

Pas de moteur de réservation ? Vous prenez les demandes par téléphone, sur WhatsApp ou sur Instagram, et vous tenez le planning vous-même. Le lien de paiement fait alors le travail de la session. 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.

Pour une réservation :

• Un lien par réservation, à usage unique, au montant exact.
• Une description qui identifie la réservation : « Terrain 2 — jeudi 19 h — Amine B. ».
• Une expiration qui suit la place, pour un lien réglé par carte : 24 heures, 7 jours, 30 jours, jamais, ou une date précise — choisissez une date proche pour un créneau convoité, et toujours antérieure au créneau lui-même.
• Un statut à surveiller : actif, payé, annulé, expiré. Vous êtes notifié dans le portail à l'encaissement ; un lien expiré, c'est une place à remettre en vente.

Le lien à usage unique a un avantage que la session n'a pas : sur sa page, le client peut aussi régler en espèces en agence. Il 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 lien passe « Payé ». Une session de paiement, elle, n'encaisse que la carte. Côté serveur, l'état du lien se lit par GET /v1/payment-links/{reference}. Pour une clientèle qui paie volontiers en liquide, c'est ce qui peut décider du montage.

Un réglage à connaître avant d'envoyer le lien. Dans le portail, activer « Paiement en agence » sur un lien désactive son expiration : le lien reste payable sans limite de temps. Un lien qui porte une date d'expiration se présente donc comme un lien à régler par carte ; pour un client qui paie en espèces, créez un lien avec « Paiement en agence », sans expiration. Le choix d'ensemble entre les deux outils est traité dans lien de paiement ou checkout, et l'offre sur la page des liens de paiement.

Précommande et paiement en ligne : le stock suit le paiement

La précommande obéit à la même logique que le créneau, avec une quantité au lieu d'une heure : des gâteaux pour une fête, une série limitée, un panier de saison. La règle pratique tient en une phrase : votre stock ne bouge qu'au paiement réussi, pas à la création de la session ou du lien.

Concrètement :

1. 1À la création de la session ou du lien, vous mettez la quantité de côté dans votre outil, sans toucher au stock, pour la durée de l'expiration.
2. 2À l'événement de paiement réussi, vous décrémentez le stock et lancez la préparation.
3. 3À l'expiration sans paiement, le stock n'a pas bougé : vous remettez simplement en vente la quantité mise de côté.

C'est ce qui évite le scénario classique de la précommande : un stock épuisé sur le papier par des paniers jamais payés, pendant que de vrais clients attendent. Si vous vendez sans site, la boutique hébergée permet aussi de publier un produit avec un stock optionnel et sa page de vente ; gardez la même discipline et ne lancez la préparation qu'une fois la commande payée.

Un double clic ne débite pas deux fois

Le client qui clique deux fois sur « Réserver », la connexion qui coupe et votre serveur qui renvoie la requête : ce sont les cas qui créent deux paiements pour une seule place, si rien ne les arrête. Deux outils les arrêtent à la création.

• L'en-tête `Idempotency-Key` : rejouer la même valeur renvoie le premier résultat, au lieu de créer une seconde session ou un second lien.
• Le champ `externalId`, unique par compte et par environnement : une création avec un externalId existant renvoie la ressource existante en 200 OK au lieu de 201 Created. Dérivez-le de votre numéro de réservation, et testez le statut : les deux sont des succès.

Côté client, la protection est déjà là : une session n'est consommée qu'une seule fois, et un lien à usage unique ne se paie qu'une fois. Le principe général, avec ses pièges, est expliqué dans l'idempotence des paiements.

Annulation : écrire sa politique, puis rembourser

Les annulations ne se gèrent bien que si la règle est écrite avant la vente. Une politique d'annulation claire dit deux choses : jusqu'à quand le client peut annuler, et quel montant il récupère selon le moment. Les chiffres vous appartiennent — tout rembourser jusqu'à la veille, une partie seulement le jour même, rien après le début du créneau : c'est votre choix de commerçant, à afficher sur votre site ou dans le message qui accompagne le lien.

Ensuite, deux gestes selon le moment :

• Avant le paiement, il n'y a rien à rembourser : annulez le lien (un lien annulé ne peut plus être payé) ou la session, puis libérez la place.
• Après un paiement par carte, remboursez 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 il n'est pas instantané côté banque : prévenez le client sans lui promettre de date.

Le mode d'emploi complet — portail, appel API, suivi, message au client — est dans rembourser un client.

No-show : ce que le paiement d'avance protège

Le client qui ne vient pas, c'est la raison d'être du paiement à la réservation. Quand la place a été payée d'avance, le no-show ne vous coûte pas le créneau : le montant est déjà sur votre compte de paiement, disponible à l'instant du paiement réussi.

Ce que le paiement d'avance ne permet pas, en revanche, c'est d'encaisser plus tard une somme que le client n'a pas réglée lui-même. Pour un encaissement ultérieur — un complément, des frais prévus par vos conditions —, envoyez-lui un nouveau lien de paiement, qu'il règle lui-même ; si les paiements sont réguliers, comme un forfait mensuel de cours, créez un abonnement : un lien de paiement lui est alors envoyé par e-mail à chaque échéance. Il n'y a donc pas de « frais de no-show » encaissés d'office après coup : tout ce que vous voulez protéger doit être payé au moment de réserver.

Reste à décider ce que dit votre politique pour un no-show : rien n'est rendu, une partie est rendue, ou la place est reportée une fois. Écrivez-le noir sur blanc, et appliquez-le de la même façon à tout le monde ; si vous choisissez de rendre une partie d'un paiement par carte, c'est un remboursement partiel ordinaire.

Questions fréquentes

Comment faire payer une réservation sans site web ?

Avec un lien de paiement à usage unique par réservation : un montant, une description (créneau, nom du client) et, pour un paiement par carte, une expiration antérieure au créneau. Vous le partagez par WhatsApp ou par e-mail, le client paie sur une page hébergée par ChariPay, et vous êtes notifié dans le portail à l'encaissement. Pour un client qui paie en espèces, créez plutôt un lien avec « Paiement en agence », sans expiration.

Combien de temps la place reste-t-elle bloquée pendant le paiement ?

Le temps que vous décidez. Pour une session, expiresAt fixe la durée de vie ; sans lui, elle vaut 72 heures par défaut. Pour un lien réglé par carte, vous choisissez 24 heures, 7 jours, 30 jours, jamais, ou une date précise. Alignez cette durée sur votre propre délai de blocage, et libérez le créneau dès qu'elle est passée sans paiement.

Un client peut-il payer sa réservation en espèces ?

Oui, avec un lien de paiement à usage unique, créé dans le portail avec « Paiement en agence », donc sans expiration : sur sa page, le client 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. Une session de paiement créée par l'API, elle, n'encaisse que la carte.

Un double clic peut-il faire payer deux fois une réservation ?

Non, si vous utilisez les outils prévus. À la création, l'en-tête Idempotency-Key et un externalId dérivé du numéro de réservation empêchent de créer deux sessions ou deux liens : un rejeu renvoie la ressource existante. Côté client, une session n'est consommée qu'une seule fois et un lien à usage unique ne se paie qu'une fois.

Comment rembourser une réservation annulée ?

Pour une réservation payée par carte, selon votre politique d'annulation, 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 il n'est pas instantané côté banque. Si la réservation n'était pas encore payée, il n'y a rien à rembourser : annulez simplement le lien ou la session, puis libérez la place.

Peut-on faire payer plus tard un client qui ne vient pas ?

Pas d'office : un encaissement ultérieur passe par un nouveau lien de paiement, que le client règle lui-même, s'il l'accepte. Ce que vous voulez protéger contre le no-show doit donc être payé au moment de réserver ; votre politique dit ensuite si une partie est rendue. Pour des paiements réguliers, un abonnement envoie au client un lien de paiement par e-mail à chaque échéance.

Quand confirmer la réservation au client ?

À réception du webhook de paiement réussi, jamais sur la seule redirection : la redirection dit que l'acheteur est revenu, pas que le paiement est acquis. Pour un lien réglé en espèces, attendez que le lien passe « Payé » dans le portail. Entre les deux, affichez « paiement en cours de vérification » plutôt qu'une confirmation prématurée.

Prochaine étape

Choisissez votre montage — session si votre site gère un calendrier, lien à usage unique sinon —, écrivez votre politique d'annulation, puis faites une réservation complète en mode test : Commencer en mode test. Pour la mécanique fine des sessions, lisez expiration et retour d'une session de paiement ; pour les annulations payées, rembourser un client.