Tester sa réservation en ligne avant d’ouvrir

Avant d’ouvrir, un loueur passe souvent quelques réservations d’essai au comptoir : il y vérifie ses prix et le montant de ses cautions.

Au comptoir, on voit ce que voit l’équipe. On n’y voit pas la page de paiement du client, ni la fenêtre de sa banque. On n’y lit pas non plus son e-mail de confirmation, ni le contrat qu’il signe sur son téléphone.

Tout loueur qui ouvre la réservation en ligne se pose la question : comment passer une réservation de bout en bout, côté client, sans encaisser ? Voici ce qu’il faut vérifier, avec quoi, et ce qu’un essai ne doit jamais laisser derrière lui.

Comment tester une réservation en ligne sans encaisser

Trois cartes de test suffisent pour passer une réservation en ligne de bout en bout sans encaisser. Chez Stripe, 4242 4242 4242 4242 simule un paiement accepté, 4000 0025 0000 3155 une validation demandée par la banque, et 4000 0000 0000 0002 un refus. Elles s’utilisent dans l’environnement de test de Stripe, où aucun argent ne circule : date d’expiration future et code à trois chiffres au choix.

La question n’est pas propre à la location : tout site qui encaisse doit pouvoir s’essayer sans vrai argent. Les prestataires de paiement prévoient pour cela un environnement de test, avec ses propres clés et ses numéros de carte fictifs.

Le reste dépend de votre logiciel de réservation. Il doit savoir faire passer votre boutique dans cet environnement le temps d’un essai, puis en sortir sans rien laisser dans vos comptes.

Ce qu’il faut vérifier avant d’ouvrir

Un essai utile suit votre client, pas votre logiciel. Faites-le d’abord sur un téléphone, en données mobiles, puis sur un ordinateur, et passez chaque point de cette liste.

• Le prix. Le total d’une demi-journée, d’un week-end, d’une location à cheval sur deux saisons ou sur un jour de fermeture : chacun doit suivre votre grille.
• L’acompte. Le montant débité tout de suite, et ce que la confirmation annonce comme reste à régler.
• La caution. Le mécanisme annoncé, fonds bloqués ou empreinte, et son montant, lisibles avant de payer. Les deux ne protègent pas de la même façon : voir combien de temps tient une caution par carte.
• Le refus. Ce que lit le client quand sa carte ne passe pas : que rien n’est débité, et comment réessayer.
• La validation bancaire. La fenêtre de la banque sur un téléphone, puis le retour sur votre page, y compris quand le client l’abandonne.
• L’e-mail de confirmation. Son objet, le nom de l’expéditeur, les liens pour signer ou annuler, et sa lecture sur un petit écran.
• Le contrat. Vos conditions de location, vos mentions légales, le montant de la caution et la signature au doigt. Le modèle de contrat de location de vélo liste ce qu’il doit contenir d’autre.
• Votre côté. La réservation dans le planning, l’e-mail qui vous prévient, puis un départ et un retour complets, jusqu’à la libération de la caution.
• L’annulation. Le barème appliqué, et le montant remboursé que le client lit avant de confirmer.

Faites aussi l’essai en anglais si une partie de vos clients vient de l’étranger : c’est là qu’apparaissent les textes oubliés par la traduction.

Trois façons de faire un essai, et ce que chacune laisse derrière elle

Au comptoir. Une réservation saisie à la main vérifie vos prix, votre planning et vos cautions. Elle ne montre ni votre boutique, ni la page de la banque, ni les e-mails tels que votre client les lira.

Avec votre propre carte, en vrai. Le paiement aboutit, vous vous remboursez, et vous n’avez essayé que le cas où tout se passe bien. Stripe l’exclut d’ailleurs dans sa documentation : « Le Contrat d’utilisation du service Stripe interdit les tests en mode production à l’aide de véritables informations de moyens de paiement. »

Si votre logiciel facture à l’encaissement, ce vrai paiement laisse aussi une vraie facture. Sa numérotation suit « une séquence chronologique et continue » (article 242 nonies A de l’annexe II du CGI) : la supprimer y laisserait un trou. Elle se corrige par un avoir, qui reste lui aussi dans vos comptes.

Dans un mode test. Votre logiciel fait passer la réservation par l’environnement de test de son prestataire de paiement, avec les cartes du tableau. C’est la seule des trois façons qui fait vivre tout le parcours sans argent réel, à quatre conditions.

• Aucune facture, aucun numéro pris dans votre série, aucune écriture de caisse.
• Un essai marqué comme tel partout où il apparaît : planning, e-mails, contrat.
• Rien dans vos statistiques, vos exports ni votre chiffre d’affaires.
• Un effacement en un geste, et jamais un essai ouvert à un vrai client.

En pratique, avec Rideloc

Tant que votre compte Stripe n’encaisse pas encore — pas connecté, ou inscription Stripe pas terminée —, l’aperçu de votre boutique paie en mode test. Ouvrez l’adresse de votre boutique de réservation en étant connecté à Rideloc : il n’y a rien à activer. Le tunnel affiche les trois cartes du tableau, et le paiement passe par l’environnement de test de Rideloc.

La suite se déroule comme pour un client. Le paiement suit vos réglages, totalité ou acompte, et la caution aussi : fonds bloqués au départ, ou empreinte posée pendant le paiement. Suivent la validation manuelle si vous l’avez activée, la page de confirmation, l’e-mail à l’adresse saisie et le contrat à signer en ligne.

La réservation arrive dans votre planning, votre liste et sa fiche, marquée « Test » et numérotée TEST-2026-…, hors de la série de vos vraies réservations. Ses e-mails, le vôtre « Nouvelle réservation » comme ceux du client, portent « [TEST] » dans leur objet et un bandeau « Réservation de test ». Son contrat est marqué « document sans valeur contractuelle ».

Depuis sa fiche, la suite s’essaie aussi : départ avec état des lieux et caution, retour et clôture. Retenue totale ou partielle, libération de la caution, frais de retard ou de dégâts : tout passe en mode test. L’annulation applique votre barème et rembourse en tout ou en partie, et le lien de paiement s’envoie comme pour un client.

Au comptoir, tant que votre Stripe n’encaisse pas, l’interrupteur « Réservation de test » apparaît quand vous créez une réservation. Il sert à essayer le lien de paiement et la caution par carte, avec les mêmes cartes de test.

Une réservation de test n’a jamais de facture ni de numéro de facture. Elle n’entre ni au journal des règlements, ni aux clôtures, ni dans vos exports, statistiques, chiffre d’affaires ou accueil du tableau de bord.

Elle s’efface d’un bouton : « Effacer les réservations de test » dans la liste des réservations, « Effacer cette réservation de test » sur sa fiche. Dès que votre Stripe commence à encaisser, le mode test s’éteint de lui-même et vos réservations de test sont effacées.

Ce qu’un essai ne permet pas, dit tout de suite :

• Faire payer un vrai client en test. La boutique non publiée lui est fermée, et la publier exige un Stripe qui encaisse : un client qui passe par votre boutique ne voit jamais les cartes de test.
• Utiliser un bon cadeau. Un bon est un vrai solde, qu’un essai n’entame pas.
• Compter un code promo. Il s’applique, mais son compteur d’utilisations ne bouge pas.
• Envoyer une demande d’avis Google ou une relance de panier. Aucune ne part pour un essai.
• Rembourser hors annulation. Pour une vraie réservation, cela se fait depuis votre tableau de bord Stripe. Les paiements d’essai, eux, vivent dans l’environnement de test de Rideloc, sans tableau de bord à votre nom.
• Retenir les e-mails. Ils partent vraiment, à l’adresse saisie : mettez la vôtre, jamais celle d’un client.
• Essayer après l’ouverture de votre Stripe. Une fois votre Stripe actif, l’aperçu ne réserve plus rien avant la publication : faites vos essais avant.

Le reste du métier, du planning à la facture, est sur la page du logiciel de location de vélos.

Questions fréquentes sur les réservations de test

Cinq questions qui reviennent avant d’ouvrir la réservation en ligne, et la réponse courte à chacune.

Cet article cite la documentation de Stripe et le Code général des impôts, relus le 28 octobre 2026. Il ne remplace pas l’avis de votre expert-comptable sur la tenue de vos factures.