Refunds & Notifications · Article 6.4
Étapes du remboursement : émis → demandé → réussi (ou manuel)
La note de crédit passe par jusqu'à quatre états de la création au règlement. Chaque état correspond à un point spécifique du cycle de vie du remboursement, avec des badges d'interface et des déclencheurs d'e-mail prévisibles.
La machine à cinq états sur CreditNote.refund_status est la source de vérité unique pour la progression du remboursement. L'interface freelancer et les e-mails clients lisent tous les deux à partir d'elle. Comprendre la signification de chaque état — et quelles transitions sont possibles depuis lesquels — est le chemin le plus rapide pour diagnostiquer les questions « pourquoi mon remboursement est-il bloqué ? ».
Step by step
Surveillez la bannière de remboursement du devis.
Elle reflète le statut de la note de crédit avec un texte lisible : -
pending(flux Stripe) → « Remboursement en cours — vérification Stripe » -pending(flux SEPA) → « Remboursement manuel — confirmez le virement bancaire » -requested→ « Remboursement en cours — prévu dans 3 à 5 jours ouvrés. Vérifier le statut. » -failed→ « Remboursement échoué : [raison]. Réessayez ou marquez manuellement. » -succeeded→ « Remboursement effectué le [date] via Stripe. » -manual→ « Remboursement effectué le [date] via virement manuel. »Utilisez la bonne action par état.
pendingflux Stripe : attendez ou réessayez.pendingflux SEPA : émettez le virement + marquez comme remboursé.requested: Actualiser le statut (article 8.7) si la bannière reste statique pendant plus de 5 minutes.failed: Réessayer (article 8.8) ou marquez manuellement (article 8.9).Auditez via la Chronologie.
Chaque transition d'état émet un événement dans la Chronologie (
refund_initiated,refund_completed, etc.) avec des métadonnées (montant, méthode). Utile pour les inspecteurs fiscaux ou si vous devez jamais contester une transaction.
Why this works this way
Transitions d'état :
| De | Vers | Déclencheur | Effets secondaires |
|---|---|---|---|
| (aucun) | pending | Note de crédit créée dans _build_credit_note post-signature | Documents (Storno + Berichtigung + Gutschrift) créés ; le client reçoit l'e-mail « Remboursement initié » |
pending | requested | _trigger_stripe_refund réussi (Refund.create accepté) | stripe_refund_id et refund_initiated_at renseignés ; la bannière indique « Remboursement en cours, prévu dans 3 à 5 jours ouvrés » |
pending | failed | _trigger_stripe_refund a levé une exception ou le débit n'était pas confirmé | refund_failure_reason renseigné ; la bannière propose Réessayer + Marquer comme remboursé manuellement |
pending | manual | Le freelancer a cliqué sur Marquer comme remboursé (flux SEPA) | refund_completed_at et manual_refund_reason renseignés ; le client reçoit l'e-mail « remboursement effectué » ; le devis se ferme si applicable |
requested | succeeded | Webhook refund.updated avec status=succeeded OU synchronisation par extraction a renvoyé succeeded | refund_completed_at renseigné ; e-mail « remboursement effectué » ; le devis se ferme |
requested | failed | Webhook avec status=failed/canceled | refund_failure_reason renseigné ; la bannière propose Réessayer + Marquer comme remboursé manuellement |
failed | requested | Le freelancer a cliqué sur Réessayer le remboursement Stripe (article 8.8) | Raison d'échec effacée ; retour vers Stripe |
failed | manual | Le freelancer a cliqué sur Marquer comme remboursé (après avoir émis un remboursement SEPA hors canal) | Identique à pending → manual |
succeeded et manual sont terminaux — les deux indiquent que le flux de trésorerie est réglé, juste via différents canaux. La piste d'audit préserve quel canal ; le comportement visible par l'utilisateur est identique (e-mail de clôture, devis Payé si applicable, PDF de note de crédit accessible).
Troubleshooting
Keep reading
Refunds & Notifications
When refunds happen: the Δ_REFUND amendment branches
A refund in Clozo is always tied to a Δ_REFUND amendment branch — partial (revised total smaller than deposit paid) or full (revised total at zero). The amendment is the legal trigger; the refund is the cash consequence.
Refunds & Notifications
Stripe automatic refund (Direct Charges via Connect)
When the original deposit was paid via Stripe, the refund is automatic. Clozo issues a Refund on the freelancer's connected account, watches for the `refund.updated` webhook, and flips the credit note to `succeeded` once Stripe confirms — typically within 3–5 business days for the cash to reach the client.
Refunds & Notifications
SEPA / out-of-band refund: when automation can't help
When the original deposit was paid via SEPA bank transfer (or any non-Stripe channel), Clozo can't refund automatically — Stripe API has nothing to refund. You issue the SEPA transfer manually from your bank, then click `Mark refunded` to update the credit note and notify the client.
Refunds & Notifications
Refresh status — pull-based sync when the Stripe webhook didn't land
Webhooks aren't perfect. When a credit note appears stuck in `requested` despite Stripe having processed the refund, click `Refresh status` to pull the current state from Stripe directly. Same transition logic as the webhook; no risk of double-firing side-effects.