Comment gérer les commissions d'affiliation sur les remboursements et upgrades Stripe

Un remboursement Stripe n'est pas seulement un événement support. Dans un programme d'affiliation, il modifie le revenu qui justifiait la commission.

Si le ledger de paiement ne suit pas cette modification, deux problèmes apparaissent : le marchand paie une commission sur du revenu qu'il ne conserve plus, ou l'affilié voit une correction sans piste d'audit. Les deux cas créent des questions de réconciliation.

Ce guide couvre le modèle opérationnel pour les SaaS qui facturent avec Stripe : remboursement total, remboursement partiel, commission déjà payée, commission non payée, et factures d'upgrade qui peuvent créer des commissions en double si elles sont traitées comme de nouveaux clients.

Pour le setup global, lisez comment créer un programme d'affiliation avec Stripe. Pour le choix d'architecture, consultez logiciel d'affiliation Stripe : natif vs intégration.

---

Un remboursement Stripe change la base de commission

Stripe permet de rembourser un paiement en totalité ou en partie. Son API de création de remboursement accepte aussi des montants inférieurs au paiement initial, et c'est cette réalité de paiement que votre ledger d'affiliation doit suivre.

Le ledger doit répondre à quatre questions pour chaque paiement remboursé :

• Quelle conversion est affectée par ce remboursement ?
• La commission était-elle encore en attente, approuvée, ou déjà payée ?
• Quel revenu reste après remboursement ?
• Quelle correction doit être visible côté marchand et côté affilié ?

Si le système marque seulement le paiement comme "remboursé" sans toucher aux commissions, votre CAC affilié est faux. S'il réécrit silencieusement les montants historiques, l'affilié perd la piste d'audit.

Un modèle propre enregistre le remboursement, conserve l'historique de commission, puis ajoute une correction explicite quand de l'argent a déjà été versé.

Définir les statuts avant de calculer les clawbacks

Un programme d'affiliation SaaS a besoin de plus que "vente" et "payée".

Statut	Signification	Traitement du remboursement
Commission en attente	Paiement reçu, fenêtre de remboursement ouverte	Rejeter ou annuler avant versement
Commission approuvée	Fenêtre passée, versement pas encore envoyé	Sortir du solde payable ou créer une correction
Commission payée	L'affilié a déjà reçu l'argent	Créer une ligne de clawback négative
Conversion remboursée	Le paiement Stripe a été reversé totalement ou partiellement	Stocker le montant et la raison
Ligne de clawback	Commission négative créée après paiement	Garder le ledger auditable

Les libellés peuvent changer selon les plateformes. Le principe ne change pas : ne masquez pas la commission d'origine, et ne versez rien sans vérifier la fenêtre de remboursement.

Remboursement total avant paiement affilié

Le cas le plus simple est un remboursement total avant paiement de l'affilié.

Exemple :

• Le client paie 200 EUR
• Le taux de commission est 20%
• La commission en attente est 40 EUR
• Le client est remboursé intégralement pendant la fenêtre de remboursement

La bonne action n'est pas un paiement négatif. Rien n'a encore été versé. La commission doit être rejetée ou annulée avec une raison du type Paiement remboursé.

C'est pour cela que le timing de paiement compte. Une période de retenue de 14 ou 30 jours permet au marchand de traiter les remboursements normaux avant de rendre une commission payable. L'article sur comment payer ses affiliés SaaS détaille ce point.

Remboursement partiel après paiement affilié

Un remboursement partiel demande un calcul proportionnel.

Exemple :

• Le client paie 200 EUR
• La commission affiliée est de 20%, donc 40 EUR ont été payés
• Le client reçoit un remboursement partiel de 100 EUR
• La moitié du revenu a été annulée

La correction de commission doit aussi porter sur la moitié de la commission initiale : -20 EUR.

Ce clawback doit être une ligne de commission négative séparée. Le ledger reste lisible :

Ligne	Montant
Commission payée initiale	40 EUR
Clawback lié au remboursement	-20 EUR
Commission nette après remboursement	20 EUR

C'est souvent là que les outils d'affiliation dérivent. Ils marquent la commande comme remboursée, mais la commission déjà payée reste intacte. Ou ils écrasent la commission d'origine, ce qui complique la réconciliation.

RefCampaign enregistre les clawbacks liés aux remboursements Stripe comme des lignes de commission négatives explicites. Les commissions non payées sont rejetées ; les commissions payées reçoivent un clawback proratisé.

Remboursement reçu avant la conversion

L'ordre des webhooks n'est pas toujours celui que les équipes imaginent. Un événement de remboursement peut arriver avant que la conversion affiliée soit créée, surtout quand les systèmes traitent les événements de billing de manière asynchrone.

Le chemin sûr consiste à mettre le remboursement en attente avec son identifiant Stripe, puis à le rejouer quand la conversion existe.

Cela compte pour deux raisons :

1. Le marchand ne perd pas l'ajustement à cause d'un problème de timing.
2. Le même remboursement ne doit pas créer deux clawbacks pendant les retries.

La mise à jour des webhooks de remboursement Stripe expose des événements au niveau du remboursement, comme refund.created, ce qui aide les systèmes à travailler avec l'identifiant du refund plutôt qu'uniquement avec la charge mise à jour.

Les upgrades sont un risque comptable distinct

Les upgrades ne sont pas des remboursements, mais ils posent un problème de ledger similaire : le montant facturé change après l'acquisition initiale.

Quand un client passe de 49 EUR/mois à 99 EUR/mois, Stripe peut créer une facture de prorata. Si votre système d'affiliation traite cette facture comme une nouvelle acquisition, vous pouvez compter deux fois le même client.

Une politique saine commence par une décision, pas par du code :

• Les affiliés gagnent-ils une commission sur l'expansion de revenu ?
• Si oui, est-elle récurrente, ponctuelle, ou plafonnée ?
• Si non, les factures d'upgrade doivent-elles être exclues de la logique d'acquisition ?
• Comment séparer les prorata des factures de renouvellement normales ?

Pour une commission d'acquisition ponctuelle, la règle la plus sûre est de créer la commission uniquement sur la première facture d'abonnement payée. Les factures d'upgrade ne doivent pas créer un second referral. Pour les commissions récurrentes, décidez avant le lancement si l'expansion MRR est commissionnable.

Checklist de gestion des remboursements Stripe

Utilisez cette checklist avant de payer les commissions :

• La fenêtre de remboursement correspond à votre politique client.
• Les événements charge.refunded ou refund.created sont traités.
• Les remboursements sont liés au paiement Stripe initial.
• Les refunds partiels créent des corrections proportionnelles.
• Les commissions payées sont corrigées par des clawbacks négatifs.
• Les commissions non payées sont rejetées au lieu d'être annulées après paiement.
• Les identifiants de refunds servent à l'idempotence.
• Les refunds arrivés avant la conversion sont rejoués.
• Les factures d'upgrade et de prorata ne peuvent pas créer une seconde commission d'acquisition.
• L'affilié peut voir pourquoi une commission a changé.

Si une plateforme d'affiliation ne répond pas à ces points, attendez-vous à de la réconciliation manuelle.

La règle pratique

Ne calculez pas les paiements affiliés à partir des paiements Stripe bruts. Calculez-les à partir du revenu après politique de remboursement, statut de commission et timing de paiement.

RefCampaign garde Stripe proche du ledger de commission : les remboursements peuvent rejeter les commissions non payées, créer des clawbacks proratisés sur les commissions payées, et laisser une piste d'audit au marchand comme à l'affilié.

Voir les tarifs pour vérifier si le workflow Stripe-native correspond à votre programme.