Retenue temporaire
L'inventaire est retenu exactement le temps configuré par produit pendant que le client termine son paiement sur Stripe, sans bloquer l'inventaire pour des paniers qui n'arrivent jamais jusque-là.
Paiement et checkout
Retenu pendant qu’ils décident. Libéré dès qu’ils ne décident plus.
Un paiement en attente ne bloque jamais une place pour toujours, et ne la libère jamais trop tôt. Si le paiement n'arrive jamais, elle se libère toute seule, par trois voies distinctes à la fois, pour ne jamais dépendre d'une seule d'entre elles.
- 3 mécanismes Une tâche planifiée pour l'instant exact, un balayage chaque minute, et un nettoyage si le lancement du paiement échoue
- 2 couches d'idempotence Un événement Stripe en double ne facture jamais deux fois, ne délivre jamais deux fois de billets, et ne corrompt jamais la commande
- Remboursement automatique Si un paiement arrive en retard et que la place est déjà partie à quelqu'un d'autre, il est facturé, détecté et remboursé tout seul
Quatre éléments du checkout.
Chacun résout une façon différente d’être payé, sans dupliquer les règles métier.
Retenue optionnelle par produit
Certains produits acceptent un léger risque de survente en échange de simplicité, sans aucune retenue temporaire. Une même commande peut librement mélanger des lignes avec et sans retenue.
Checkout sans compte
Un acheteur anonyme peut payer directement quand l'organisation l'autorise, ou le canal peut être contraint de passer par son propre serveur avec une clé.
Liens de paiement manuels
Un agent peut générer un lien Stripe depuis le tableau de bord et l'envoyer par WhatsApp ou e-mail, pour une vente téléphonique ou sur les réseaux, sans checkout propre.
Comment un paiement est protégé, étape par étape
Cinq étapes, depuis le moment où une place est retenue jusqu'à ce que la commande soit payée ou remboursée.
- 1
La place est retenue
La commande naît en attente de paiement, avec sa propre expiration, et retient la capacité ou le stock avant même que la session Stripe soit créée. Rien n'est encore confirmé.
- 2
La session de paiement est créée
L'appel à Stripe se fait en dehors de la transaction de base de données : une API externe ne doit jamais garder un verrou de ligne ouvert en attendant une réponse.
- 3
Le webhook confirme, sous verrou
Quand Stripe signale un succès, la ligne de la commande est verrouillée et revérifiée pour voir si elle est toujours en attente, ce qui ferme la fenêtre où deux livraisons du même événement pourraient sinon se concurrencer.
- 4
La retenue devient une vente
Si la commande est toujours en attente, la retenue est confirmée, les billets sont émis, et la commande passe à payée, le tout dans la même transaction.
- 5
S'il est arrivé en retard, il est remboursé
Si la commande n'était plus en attente (expirée, annulée, ou la place n'existe plus), le paiement est remboursé automatiquement, avec le motif enregistré pour que le support puisse l'examiner.
Ce que renvoie vraiment le checkout
La commande avec son statut, son expiration et le total déjà calculé, accompagnés de l'URL de paiement Stripe. Le client ne voit jamais un checkout maison à moitié construit.
POST /api/v1/checkout
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
{
"order": {
"code": "01J8X8QK6Z9K2R3W4M5N6P7Q8R",
"status": "pending_payment",
"hold_expires_at": "2026-08-14T18:15:00Z",
"currency": "EUR",
"grand_total_amount": 53.24
},
"checkout_url": "https://checkout.stripe.com/c/pay/cs_live_..."
}200 Session de paiement créée
Un paiement en retard trouve toujours tout déjà fermé
Libérer une retenue expirée annule aussi toute transaction de paiement encore ouverte pour cette commande. Donc quand un webhook de paiement réussi arrive après l'expiration de la place, il ne trouve jamais une transaction « en attente » qui l'attend : il en trouve une déjà annulée, et le remboursement automatique part exactement de là, comme le chemin normal, pas comme une exception rare.
Questions fréquentes
Rien n'est dupliqué. Il y a une vérification rapide en amont pour les événements déjà traités, et une seconde vérification à l'intérieur du même verrou sur la ligne de la commande, ce qui ferme la fenêtre où deux livraisons vraiment simultanées du même événement pourraient se concurrencer. Une seule l'emporte.
Il est facturé, le conflit est détecté, et il est remboursé automatiquement, avec le motif enregistré pour que le support puisse l'examiner. Un billet n'est jamais émis pour une place déjà partie à quelqu'un d'autre.
Non. Un produit peut accepter un léger risque de survente en échange de ne jamais bloquer une place pendant que quelqu'un décide de payer ou non. Une même commande peut mélanger des lignes avec et sans retenue sans aucun conflit.
Oui, si l'organisation l'autorise pour sa boutique. L'appel peut aussi être contraint de passer par le propre serveur de l'organisation avec une clé, pour éviter d'exposer le checkout directement au navigateur.
Par trois voies à la fois : une tâche planifiée pour l'instant exact d'expiration, un balayage de secours qui vérifie chaque minute toutes les commandes expirées, et un nettoyage automatique si quelque chose échoue au lancement du paiement. N'importe laquelle des trois suffit, et aucune ne peut jamais libérer la même place deux fois.
Plus de réservations. Plus de canaux. Le même calme.
Tiqory garde disponibilité, tarifs, paiements et accès parfaitement synchronisés à mesure que votre activité grandit. Dites-nous où vous allez ; nous vous montrons comment y arriver sans repartir de zéro.