Refunds & Notifications · Article 6.8
Réessayer le remboursement Stripe — lorsque les échecs transitoires se résolvent
Un remboursement Stripe échoué peut généralement être réessayé — la plupart des échecs sont transitoires (limites de débit, brèves interruptions Stripe, ou webhook de dépôt payé arrivant après l'exécution du pipeline post-signature). Le bouton Réessayer appelle à nouveau `_trigger_stripe_refund` sur la note de crédit.
L'API de remboursement de Stripe est fiable, mais le chemin de « l'avenant signé » à « Stripe accepte la demande de remboursement » comporte plusieurs étapes. Trois causes fréquentes d'échec du _trigger_stripe_refund initial :
1. Condition de concurrence webhook — le webhook payment_intent.succeeded du dépôt original n'était pas encore arrivé quand l'avenant a été signé ; conformément à [D-113], le déclencheur refuse d'effectuer le remboursement tant que le webhook n'a pas confirmé la charge. Quand le freelancer s'en aperçoit, le webhook est déjà arrivé ; une nouvelle tentative passe le contrôle de confirmation de charge et continue.
2. Transitoire Stripe — limite de débit atteinte, brève interruption, perturbation réseau. La nouvelle tentative résout généralement le problème.
3. Déploiements antérieurs à [D-113] — un ancien chemin de code qui ne reconnaissait pas certaines configurations de charge Stripe. La nouvelle tentative sur le nouveau code trouve correctement le PaymentIntent.
Step by step
Remarquez une note de crédit
failed.La bannière de remboursement indique « Remboursement échoué : [raison]. » avec les options Réessayer et Marquer comme remboursé.
Lisez d'abord la raison de l'échec.
Certaines raisons ne sont pas résolvables par une nouvelle tentative : « charge_disputed » (la charge originale fait l'objet d'un litige ouvert — les remboursements sont bloqués), « balance_insufficient » (votre solde Stripe est insuffisant), « card_account_closed » (le compte de carte du titulaire est clôturé). La nouvelle tentative ne résoudra pas ces cas ; consultez l'article 8.10 pour les chemins de récupération par type d'échec.
Cliquez sur
Réessayer le remboursement Stripe.Le serveur relance
_trigger_stripe_refund.Attendez ~2 secondes.
La bannière se met à jour : succès → « Remboursement en cours, prévu dans 3 à 5 jours ouvrés » ; échec → raison d'échec mise à jour (souvent un nouveau code d'erreur si le problème sous-jacent est différent).
Si l'échec persiste, passez en manuel.
Cliquez sur
Marquer comme remboursé(article 8.9) après avoir émis le remboursement hors canal.
Why this works this way
Implémentation (CreditNoteRetryStripeRefundView dans amendment_views.py:775) :
1. Refus si l'état est succeeded / manual / requested. Renvoie 409 avec details.status pour que le frontend affiche l'erreur appropriée. La nouvelle tentative n'est pertinente qu'en état pending ou failed.
2. Effacement des métadonnées d'échec obsolètes. refund_failure_reason = "", sauvegarde. La nouvelle tentative repart à zéro.
3. Rappel de `_trigger_stripe_refund(cn, cn.amount_gross)`. La fonction ne lève jamais d'exception (elle capture toutes les exceptions et les enregistre sur la ligne de note de crédit), donc le point de terminaison de nouvelle tentative renvoie toujours 200 avec l'état résultant.
4. Renvoi de l'état résolu de la note de crédit. Le frontend met à jour la bannière / la ligne sur place.
Ce que la nouvelle tentative ne fait pas : changer le compte Stripe, le titulaire du compte ou le montant. Ceux-ci sont dérivés de la note de crédit + du devis + de l'avenant + de la configuration Connect — la nouvelle tentative tente simplement la même action à nouveau avec l'état d'erreur effacé.
Troubleshooting
Keep reading
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
Refund stages: issued → requested → succeeded (or manual)
The credit note moves through up to four states from creation to settled. Each state corresponds to a specific point in the refund lifecycle, with predictable UI badges and email triggers.
Refunds & Notifications
Failed refunds & recovery — common Stripe failure reasons
A `failed` credit note has a `refund_failure_reason` string from Stripe. Most reasons fall into a small set; here's what each means and the recommended recovery.
Refunds & Notifications
Mark refunded manually — for SEPA and out-of-band proof
When a refund is issued outside Stripe — SEPA bank transfer, cash, PayPal, mailed cheque — `Mark refunded` is how you record it in Clozo. Reason field is mandatory (typically a bank reference). The credit note moves to `manual` status and the client receives a confirmation email.