FirstPromoter vs Rewardful vs Tolt : remboursements Stripe comparés

Les remboursements Stripe sont le moment où la comptabilité affiliée devient concrète. Un outil peut bien suivre les clics et les inscriptions, mais le vrai test arrive quand l'argent change après la première facture.

Ce comparatif regarde cinq scénarios Stripe : Remboursement total, Remboursement partiel, Upgrade en milieu de cycle, Downgrade et Churn avec remboursement.

Vérifié le 6 juillet 2026 à partir de la documentation publique et du code RefCampaign courant. Les produits concurrents évoluent, donc lisez ceci comme une note d'achat datée plutôt que comme un verdict permanent.

Sources utilisées :

• Stripe documente les remboursements complets ou partiels après paiement réussi via le Dashboard ou l'API Refunds : documentation Stripe refunds.
• FirstPromoter documente les ventes, remboursements et annulations Stripe, ainsi qu'une API refund qui génère des commissions négatives : intégration Stripe FirstPromoter et API refund FirstPromoter.
• Rewardful documente la gestion automatique des refunds, upgrades et downgrades, avec traitement manuel si la commission a déjà été payée : automated refund handling Rewardful.
• Tolt documente le support Stripe et Paddle et indique que les refunds émis déduisent la commission de l'affilié : FAQ pricing Tolt.
• Le comportement RefCampaign a été vérifié dans refund-handling.ts, stripe-connect-events.ts et api/v1/conversions/refund/route.ts.

Les disputes sont hors scope ici. RefCampaign a du code de gestion des disputes, et FirstPromoter documente charge.dispute.created, mais l'issue #584 garde les failed payments et disputes hors de cet article.

Tableau de synthèse

Scénario	FirstPromoter	Rewardful	Tolt	RefCampaign
Remboursement total	Documenté via les événements Stripe refund et l'API refund	Documenté tant que la commission est pending ou due	Documenté à haut niveau comme déduction de commission	Documenté dans le code : rejet des commissions non payées ou clawback des commissions payées
Remboursement partiel	L'API refund peut générer des commissions négatives, mais le détail public Stripe est limité	Documenté comme recalcul automatique tant que la commission est pending ou due	Non détaillé publiquement	Documenté dans le code : ratio de clawback proratisé
Upgrade en milieu de cycle	L'API dit pouvoir suivre les upgrades ; la page Stripe n'est pas spécifique sur ce cas	Documenté comme ajustement automatique tant que la commission est pending ou due	Non détaillé publiquement	La logique de conversion récurrente est séparée du refund handling ; éviter de traiter une facture d'upgrade comme une nouvelle acquisition sauf règle explicite
Downgrade	L'API supporte le suivi lifecycle, mais le comportement Stripe downgrade n'est pas détaillé publiquement	Documenté comme ajustement automatique tant que la commission est pending ou due	Comportement cancellation documenté, downgrade non détaillé	Même principe que l'upgrade : règle de récurrence, pas clawback refund
Churn avec remboursement	Cancellation et refund sont documentés comme événements séparés	Cancellation et refund sont documentés ; si la commission est déjà payée, le trop-payé est manuel	Cancellation arrête les commissions ; refund déduit la commission	Refund appliqué via webhook Stripe ou postback ; le churn seul n'est pas un événement refund

La différence pratique n'est pas d'avoir le mot "refund" sur une page produit. La différence est de pouvoir prédire l'écriture comptable dans chaque cas limite.

Scénario 1 : Remboursement total

Le remboursement total est le minimum. Si le client récupère tout le paiement Stripe, la commission affiliée ne doit pas rester payable.

FirstPromoter documente charge.refunded pour Stripe et une API refund qui génère des commissions négatives. Cela suffit pour considérer les refunds comme une capacité documentée, mais la page publique ne détaille pas toutes les branches de statut commission.

Rewardful documente la branche plus explicitement : si le refund arrive avant paiement de la commission, le montant est ajusté automatiquement. Si la commission a déjà été payée, le marchand traite le trop-payé manuellement.

Tolt indique que les refunds déduisent la commission de l'affilié. Sa FAQ pricing publique ne précise pas si cela signifie rejet avant payout, solde négatif après payout ou autre modèle de ledger.

RefCampaign applique le refund à la conversion, rejette les commissions non payées et crée une ligne de clawback négative pour les commissions payées. Ce comportement se trouve dans refund-handling.ts via reverseCommissionsForMoneyEvent.

Scénario 2 : Remboursement partiel

Le remboursement partiel est plus difficile car la correction doit être proportionnelle.

Exemple :

Élément	Montant
Paiement Stripe initial	200 EUR
Commission à 20 %	40 EUR
Remboursement partiel	50 EUR
Réduction de commission correcte	10 EUR

FirstPromoter documente une API refund qui génère des commissions négatives. C'est utile pour une correction manuelle ou API, mais sa documentation Stripe publique ne décrit pas en détail le calcul du refund partiel.

Rewardful décrit publiquement un recalcul automatique quand une vente remboursée change le montant de transaction, tant que la commission reste pending ou due.

Tolt ne publie pas la mécanique de refund partiel dans la source vérifiée pour cet article.

RefCampaign calcule un ratio entre le montant remboursé et le montant original de la conversion, le borne, puis l'applique aux clawbacks de commission. Les remboursements partiels successifs sont idempotents quand un refund ID est fourni.

Scénario 3 : Upgrade en milieu de cycle

Un upgrade n'est pas un remboursement, mais il peut créer une facture Stripe proratisée. Cette facture peut être prise par erreur pour une deuxième vente si l'outil affilié se fonde trop largement sur les paiements bruts.

FirstPromoter indique que son API peut suivre les upgrades, mais la page d'intégration Stripe vérifiée ici liste les ventes, refunds et cancellations plutôt qu'une matrice détaillée des proratas d'upgrade.

Rewardful inclut explicitement les upgrades dans son message d'ajustement automatique, toujours dans la limite des commissions pending ou due.

Tolt ne documente pas de comportement spécifique aux upgrades dans la source publique vérifiée ici.

RefCampaign garde ce sujet séparé du refund handling. La règle importante est de décider si le revenu d'expansion est commissionnable. Sinon, les factures d'upgrade ne doivent pas créer une deuxième commission d'acquisition. Pour le contexte comptable complet, lisez comment gérer les commissions affiliées sur les refunds Stripe et upgrades.

Scénario 4 : Downgrade

Le downgrade ressemble à l'upgrade : ce n'est pas un refund par lui-même, mais un événement lifecycle qui peut modifier la base de revenu.

Rewardful est la source publique la plus explicite des trois concurrents sur les ajustements de downgrade.

FirstPromoter documente le support API des changements lifecycle, mais la page Stripe publique n'est pas granulaire sur les proratas de downgrade.

Tolt documente cancellations et refunds, pas le comportement spécifique au downgrade dans la source vérifiée.

Pour RefCampaign, les downgrades doivent passer par la politique de commission récurrente plutôt que par le code de clawback refund. Un downgrade sans remboursement ne doit pas être forcé dans refund-handling.ts.

Scénario 5 : Churn avec remboursement

Le churn avec remboursement correspond à deux événements : le client arrête l'abonnement et récupère de l'argent.

Cette distinction compte. La cancellation doit arrêter les futures commissions. Le refund doit corriger la commission déjà liée au revenu retourné.

FirstPromoter documente le tracking des cancellations et le tracking des refunds.

Rewardful documente les refunds et les ajustements lifecycle, mais indique que les trop-payés après payout sont manuels.

Tolt indique que la cancellation arrête le calcul des commissions et que les refunds émis déduisent la commission.

RefCampaign traite le refund par trois chemins :

1. Les webhooks Stripe Connect normalisent les événements charge.refunded et refund.*.
2. L'API publique de postback refund permet au marchand de déclarer un refund par ID externe de conversion.
3. Les pending refunds sont stockés puis rejoués si le refund Stripe arrive avant la conversion.

Ce troisième chemin compte dans les systèmes Stripe réels, car l'ordre des webhooks peut différer de celui que la finance attend.

Comment lire le comparatif

Si vous avez besoin d'un programme affilié Stripe simple avec une période pending alignée sur votre politique de remboursement, Rewardful et FirstPromoter ont tous deux des workflows refund documentés.

Si vous devez savoir exactement ce qui se passe après un refund partiel sur une commission déjà payée, demandez à chaque éditeur un exemple ledger avant migration. La documentation publique est inégale sur ce cas.

Si vous évaluez Tolt, traitez son wording refund public comme haut niveau. Il indique que les refunds déduisent la commission, mais la source vérifiée ici n'explique pas les refunds partiels, les clawbacks après payout ou les proratas.

Si vous évaluez RefCampaign, la force est le modèle explicite de money events : webhooks Stripe, postbacks refund, retry des pending refunds, idempotence par refund ID et lignes de clawback proratisées. Le gap à garder honnête : disputes et failed payments ne font pas partie de ce comparatif.

Checklist acheteur

Avant de choisir une plateforme affiliée Stripe, demandez ces cinq réponses par écrit :

1. Que devient une commission non payée après un refund total.
2. Que devient une commission déjà payée après un refund total.
3. Comment un refund partiel modifie le montant de commission.
4. Si les factures d'upgrade et downgrade peuvent créer des commissions d'acquisition en double.
5. Si l'affilié voit la raison d'un rejet de commission ou d'un clawback.

La plateforme avec le ledger le plus lisible crée souvent moins de tickets support que celle avec la liste de fonctionnalités la plus longue.

RefCampaign est conçu pour les équipes SaaS qui veulent garder le revenu Stripe, l'état de remboursement et le statut de commission affiliée alignés. Commencez par la page tarifs pour relier ces règles à votre stade de programme.