Une retraite à 2 000 USD est une grosse demande d'entrée. Les paiements en plusieurs fois laissent l'acheteur s'engager avec un premier prélèvement plus petit et payer le reste selon un calendrier lié à la date de début de la retraite. La plateforme gère automatiquement les prélèvements off-session.
Plan Premium uniquement. Réservations carte via Stripe uniquement (les méthodes off-platform ne peuvent pas être prélevées off-session).
Comment ça marche
Tu définis un modèle une fois à la création de la retraite. Chaque acheteur qui opt-in obtient son propre ledger d'échéances résolu à partir de ce modèle.
Le modèle est une liste d'étapes. Chaque étape a :
offsetDays: quand prélever, relatif à la date de début de la retraite. Négatif veut dire avant (par exemple -30 = trente jours avant le début). 0 = à l'inscription.percentageBps: le pourcentage en points de base (5000 = 50%, 3333 = 33,33%).
Les pourcentages doivent sommer à exactement 10000 (= 100%). L'offset de la première étape doit être <= 0 pour que l'acheteur paie au checkout.
Trois formes courantes
Deux étapes, 50/50 :
- Étape 1 : offsetDays 0, 50%
- Étape 2 : offsetDays -30, 50%
Trois étapes, 50/25/25 :
- Étape 1 : offsetDays 0, 50%
- Étape 2 : offsetDays -60, 25%
- Étape 3 : offsetDays -14, 25%
Quatre étapes, quarts égaux :
- 25% à l'inscription, 25% à -90, 25% à -60, 25% à -14.
Ce qui se passe au checkout
L'acheteur choisit "Payer en plusieurs fois" sur la page de réservation. Nous prélevons l'échéance n°1 immédiatement via Stripe et enregistrons sa carte pour les étapes futures (le setup_future_usage: off_session de Stripe).
Ce qui se passe ensuite
Un cron quotidien à 07:00 UTC parcourt chaque échéance SCHEDULED dont scheduledFor est dépassé. Chacune est prélevée sur la carte enregistrée. En cas de succès : marquée PAID, email de reçu envoyé. En cas d'échec : reprise après une grâce de 3 jours (défaut), jusqu'à 2 fois de plus. Une fois la limite de retry épuisée : l'échéance bascule sur FAILED, la réservation est annulée, les échéances SCHEDULED restantes sont CANCELLED, et l'acheteur reçoit un email.
Les échéances précédentes NE SONT PAS remboursées en cas d'échec final. C'est le contrat publié ; l'acheteur perd les sommes versées.
Ce que l'acheteur voit
Sur sa page de confirmation de réservation : chaque ligne d'échéance avec sa date planifiée, son montant et son statut (Paid / Scheduled / Failed / Cancelled). L'agent peut aussi les lister via le tool MCP list_my_installments.
Remboursements pour réservations en plusieurs fois
Quand tu annules et rembourses la réservation, la base éligible est la SOMME des échéances déjà PAID (pas le total contractuel ; tu ne peux pas rembourser de l'argent qui n'a pas été encaissé). Les lignes SCHEDULED restantes sont annulées dans la même transaction pour que le cron arrête d'essayer. Vois Accepter les paiements pour le flow complet de remboursement.