Conception d’un système de crédits de parrainage pour SaaS : suivre les parrainages, bloquer les abus et appliquer des crédits aux abonnements avec des règles claires et un grand livre auditable.
Un programme de crédits de parrainage est une fonctionnalité de facturation, pas une fonctionnalité de paiements. La récompense est un crédit de compte qui réduit les charges futures (ou prolonge le temps d’abonnement). Ce n’est pas de l’argent envoyé à une banque, pas des cartes cadeau, et pas une promesse d’un paiement ultérieur.
Un bon système répond toujours à une question : « Pourquoi la prochaine facture de ce compte a-t-elle diminué ? » Si vous ne pouvez pas l’expliquer en une ou deux phrases, les tickets support et les litiges arrivent.
Un système de crédits de parrainage comporte trois parties : quelqu’un invite un nouveau client, des règles claires déterminent quand cette invitation compte (la conversion), et des crédits sont gagnés puis appliqués aux factures d’abonnement futures.
Ce que ce n’est pas : des paiements en espèces, une remise vague qui change les chiffres sans trace, ou un système de points qui ne se relie jamais aux factures.
Plusieurs équipes dépendent de ces détails. Les parrains veulent voir ce qu’ils ont gagné et quand cela s’appliquera. Les parrainés veulent savoir ce qu’ils obtiennent et si cela affecte leur offre. Le support doit résoudre rapidement « mon crédit a disparu ». La finance a besoin de totaux qui correspondent aux factures et soient auditables.
Exemple : Sam parraine Priya. Priya démarre un abonnement payant. Sam gagne 20 $ en crédits qui réduisent la prochaine facture de Sam jusqu’à 20 $. Si la prochaine facture de Sam est de 12 $, les 8 $ restants restent en crédit pour plus tard, avec un enregistrement clair de leur origine.
Le succès n’est pas seulement « plus de parrainages ». C’est une facturation prévisible et moins de disputes. Vous savez que ça marche quand les soldes de crédits sont faciles à expliquer, les factures correspondent au grand livre, et le support peut répondre sans deviner ni corriger manuellement.
Un programme de parrainage semble simple jusqu’au premier ticket : « Pourquoi je n’ai pas reçu mes crédits ? » La plupart du travail est de la politique, pas du code.
Commencez par le déclencheur. « Invitation envoyée » est trop tôt. « Inscription » est facile à exploiter avec des comptes jetables. Un compromis courant est une « conversion qualifiée » : email vérifié plus première facture payée, ou le premier paiement réussi après une période d’essai. Choisissez un déclencheur et gardez-le cohérent pour que votre grand livre reste propre.
Ensuite, fixez la valeur et les limites. Les crédits doivent sembler réels, mais ne pas devenir une machine à remises illimitées. Décidez si vous donnez un montant fixe (par exemple 20 $ de crédits) ou un pourcentage d’une facture, et plafonnez-le de manière simple à expliquer.
Les décisions qui évitent la plupart des confusions plus tard sont :
Les règles d’éligibilité comptent plus qu’on ne le pense. Si seuls les plans payants comptent, indiquez-le. Si certaines régions sont exclues (taxe, conformité, promos), dites-le. Si les abonnements annuels qualifient mais pas les mensuels, dites-le. Pour une plateforme comme Koder.ai avec plusieurs paliers, décidez à l’avance si les montées en gamme payantes depuis un gratuit comptent, et si les contrats entreprise sont gérés manuellement.
Rédigez le texte visible par l’utilisateur avant de lancer. Si vous ne pouvez pas expliquer chaque règle en deux courtes phrases, les utilisateurs vont mal l’interpréter. Restez ferme mais calme : « Nous pouvons retenir des crédits en cas d’activité suspecte » est plus clair (et moins agressif) qu’une longue liste de menaces.
Choisissez un identifiant primaire et traitez tout le reste comme preuve secondaire. Les options les plus propres sont un jeton de lien de parrainage (facile à partager), un code court (facile à taper), et une invitation envoyée à un email spécifique (meilleur pour les invitations directes). Choisissez-en un comme source de vérité pour que l’attribution reste prévisible.
Capturez cet identifiant le plus tôt possible et conservez-le tout au long du parcours. Un jeton de lien est généralement capturé sur la page d’atterrissage, stocké en stockage first-party, puis renvoyé à l’inscription. Pour le mobile, passez-le via le flux d’installation d’application quand vous le pouvez, mais supposez que vous le perdrez parfois.
Suivez un petit ensemble d’événements qui correspondent à vos règles métier. Si votre objectif est « est-ce que c’est devenu un client payant » (et non juste « ont-ils cliqué »), un ensemble minimal suffit :
referral_click (token vu)account_signup (nouvel utilisateur créé)account_verified (email/téléphone vérifié)first_paid_invoice (premier paiement réussi)qualification_locked (conversion acceptée et ne changera plus)Les changements d’appareil et les cookies bloqués sont normaux. Pour les gérer sans tracking intrusif, ajoutez une étape de réclamation lors de l’inscription : si un utilisateur arrive avec un token, attachez-le au nouveau compte ; sinon, autorisez la saisie d’un code de parrainage une fois pendant l’onboarding. Si les deux sont présents, conservez la valeur saisie en premier comme primaire et stockez l’autre comme preuve secondaire.
Enfin, gardez une timeline simple par parrainage que le support peut lire en une minute : parrain, compte parrainé (une fois connu), statut actuel, et le dernier événement significatif avec horodatages. Quand quelqu’un demande « pourquoi je n’ai pas reçu de crédits ? » vous pourrez répondre par des faits du type « l’inscription a eu lieu, mais la première facture payée n’a jamais eu lieu », au lieu de supposer.
Les programmes de parrainage cassent généralement quand le modèle de données est vague. Le support demande « qui a parrainé qui ? » La facturation demande « le crédit a-t-il déjà été émis ? » Si vous ne pouvez pas répondre sans fouiller les logs, le modèle doit être resserré.
Stockez la relation de parrainage comme un enregistrement de première classe, pas comme une conjecture dérivée des clics.
Une configuration simple et débogable ressemble à :
id, referrer_user_id, referred_user_id, created_at, source (lien d’invite, coupon, manuel), status, status_updated_atreferral_id, invite_code_id ou campaign_id, first_seen_ip_hash, first_seen_user_agent_hashworkspace_id, owner_user_id, created_atworkspace_id, user_id, role, joined_atGardez la table referrals petite. Tout ce que vous pourriez regretter de collecter plus tard (IP brute, user agent complet, noms) doit être évité ou stocké seulement comme hash à courte durée avec une politique de rétention claire.
Rendez les statuts explicites et mutuellement exclusifs : pending (inscrit, pas encore éligible), qualified (a rempli vos règles), credited (crédit émis), rejected (contrôles échoués), reversed (crédit repris après remboursement/chargeback).
Décidez de la précédence une fois, puis faites-la respecter dans la base pour que l’application ne puisse pas créditer deux fois par erreur. Au minimum :
referred_user_id)credited par compte parrainéreferral_id choisiSi vous supportez des équipes, décidez si le parrainage s’attache à une inscription personnelle ou à la création d’un workspace. Ne tentez pas de faire les deux. Une approche viable est d’attacher le parrainage au compte utilisateur, tandis que les vérifications d’éligibilité regardent si cet utilisateur (ou leur workspace) est devenu abonné payant.
Si vous voulez moins de bugs de facturation et moins de tickets support, utilisez un grand livre (ledger), pas un simple champ « solde de crédits ». Un nombre de solde peut être écrasé, arrondi ou mis à jour deux fois. Un grand livre est un historique d’entrées que vous pouvez toujours additionner.
Limitez les types d’entrées et rendez-les non ambigus : earn (attribuer), spend (appliqué à une facture), expire, reversal (rétrocession), et ajustement manuel (avec note et approbateur).
Chaque entrée doit être lisible par les ingénieurs et le support. Stockez des champs cohérents : montant, type de crédit (ne pas utiliser « USD » si les crédits ne sont pas de l’argent), texte de raison, événement source (comme referral_signup_qualified), IDs sources (utilisateur, utilisateur parrainé, abonnement ou facture), horodatages, et created_by (système ou admin).
L’idempotence compte plus que prévu. Le même webhook ou job peut s’exécuter deux fois. Exigez une clé d’idempotence unique par événement source pour pouvoir retenter sans attribuer deux fois des crédits.
Rendez cela explicable à l’utilisateur. Quand quelqu’un demande « pourquoi ai-je reçu 20 crédits ? » vous devez pouvoir montrer quel parrainage l’a déclenché, quand il a été posté, s’il expire, et si une rétrocession a eu lieu plus tard. Si un ami upgrade, ajoutez une entrée earn liée à cet événement d’upgrade. Si le paiement est remboursé, postez une entrée reversal liée à l’événement de remboursement.
Supposez que la plupart des gens sont honnêtes et que quelques-uns essaieront des astuces évidentes. L’objectif est d’arrêter les abus faciles, garder des règles claires et éviter de bloquer de vrais clients partageant un Wi‑Fi ou une carte familiale.
Commencez par des blocages fermes que vous pouvez justifier. N’accordez pas de crédits lorsque le parrain et le parrainé sont clairement la même personne, comme le même user ID, le même email vérifié, ou la même empreinte de méthode de paiement. Les règles sur le domaine d’email peuvent aider, mais restez ciblé. Bloquer toutes les inscriptions d’un domaine d’entreprise peut nuire à des équipes légitimes.
Ajoutez ensuite une détection légère pour les boucles et les inscriptions massives. Vous n’avez pas besoin d’un scoring de fraude parfait au jour 1. Quelques signaux forts attrapent la plupart des abus : de nombreuses inscriptions depuis le même appareil en peu de temps, réutilisation d’une même plage d’IP en quelques minutes, la même carte utilisée pour plusieurs faux comptes, beaucoup de comptes qui ne vérifient jamais l’email, ou des cycles rapides d’annulation/repurchase après application des crédits.
Exigez une action qualifiante avant que les crédits ne deviennent utilisables (par exemple : email vérifié + une facture payée, éventuellement après une courte période de grâce). Cela arrête les bots et le churn du plan gratuit qui génèrent du bruit.
Ajoutez des limites de débit et des cooldowns autour des liens de parrainage et des rédemptions, mais gardez-les discrets jusqu’à ce qu’ils soient nécessaires. Si un lien est utilisé 20 fois en une heure depuis le même réseau, mettez en pause les récompenses et signalez-le.
Quand vous intervenez, gardez l’expérience calme. Marquez les crédits comme en attente tant que le paiement n’est pas confirmé, affichez une raison simple quand les récompenses sont retardées (évitez le blâme), offrez un moyen simple de contacter le support, et orientez les cas limites vers une revue manuelle plutôt que d’interdire automatiquement.
Exemple : une équipe startup partage une IP de bureau. Trois collègues s’inscrivent via le même parrainage le même jour. Avec vérification + paiement qualifiant et un cooldown basique, ils gagnent toujours les crédits après paiement, tandis que les pics bot-like sont retenus pour revue.
Les programmes de parrainage paraissent simples jusqu’à ce que l’argent suive un mauvais chemin : un remboursement, un chargeback, une facture annulée, ou un compte qui change de propriétaire. Si vous concevez ces cas à l’avance, vous évitez des utilisateurs en colère et de longs fils de support.
Traitez les crédits comme quelque chose que l’on gagne sur la base d’un résultat payé, pas seulement d’une inscription. Définissez ensuite une politique de rétrocession liée aux événements de facturation.
Un jeu de règles que le support peut expliquer :
Les remboursements partiels sont là où les équipes restent coincées. Choisissez une approche et tenez‑y‑vous : rétrocession proportionnelle (reverser 30 % du crédit pour un remboursement de 30 %) ou rétrocession complète (tout remboursement révoque tout le crédit). La proportionnelle est plus équitable mais plus complexe à expliquer et tester. La rétrocession complète est plus simple, mais peut sembler sévère.
Les transitions essai→payant doivent aussi être explicites. Une approche courante est de garder les crédits en attente pendant l’essai, puis de les verrouiller seulement après que la première facture payante réussie soit réglée (et éventuellement après une courte période de grâce).
Les gens changent d’emails, fusionnent des comptes ou passent de l’usage personnel à un workspace d’équipe. Décidez de ce qui suit la personne et de ce qui suit le compte payant. Si un workspace est l’abonné, les crédits appartiennent souvent à ce workspace, pas à un membre qui pourrait partir.
Si vous supportez les fusions de comptes ou les transferts de propriété d’équipe, enregistrez un événement d’ajustement plutôt que de réécrire l’historique. Chaque rétrocession ou correction manuelle doit inclure une note lisible par le support comme « Chargeback sur la facture 10482 » ou « Transfert de propriétaire workspace approuvé par support ». Sur des plateformes comme Koder.ai où les crédits s’appliquent aux abonnements, ces notes permettent de répondre à « pourquoi mes crédits ont changé ? » en une seule recherche.
La partie la plus difficile n’est pas de suivre les parrainages. C’est de faire en sorte que les crédits se comportent de la même façon lors des reconductions, des upgrades, des downgrades et des questions fiscales.
D’abord, décidez où les crédits peuvent être utilisés. Certaines équipes appliquent les crédits uniquement à la prochaine facture nouvelle. D’autres permettent aux crédits de couvrir toute facture ouverte (impayée). Choisissez une règle et affichez-la dans l’UI pour que les gens ne soient pas surpris.
Ensuite, verrouillez l’ordre des opérations. Une approche prévisible est : calculer les charges d’abonnement (y compris la proratisation), appliquer les remises, calculer la taxe, puis appliquer les crédits en dernier. Appliquer les crédits en dernier garde la logique fiscale cohérente et évite les disputes sur la réduction des montants imposables dans certaines juridictions. Si votre réglementation fiscale exige un ordre différent, documentez-le et écrivez des tests.
La proratisation est l’endroit où les bugs de facturation apparaissent généralement. Si quelqu’un upgrade en milieu de cycle, créez un article de prorata (charge ou crédit) et traitez‑le comme tout autre ligne. Appliquez ensuite les crédits au total de la facture, pas aux lignes individuelles.
Gardez des règles de facture strictes :
Exemple : un utilisateur upgrade en milieu de mois et reçoit une charge de prorata de 12 $. Son total de facture devient 32 $ après remises et taxes. S’il a 50 $ de crédits de parrainage, vous appliquez 32 $, mettez la facture à 0 $ et conservez 18 $ pour la prochaine reconduction.
Traitez le programme de parrainage comme une petite fonctionnalité de facturation, pas comme un gadget marketing. L’objectif est la cohérence ennuyeuse : chaque crédit a une raison, un horodatage, et un chemin clair vers la prochaine facture.
Choisissez un événement de conversion et une règle de crédit. Par exemple : un parrainage ne se qualifie que lorsque l’utilisateur invité devient abonné payant et que son premier paiement est validé.
Construisez le MVP autour d’un chemin bout en bout : capture d’un token ou code de parrainage à l’inscription, qualification au moment du succès du paiement (pas quand l’utilisateur saisit la carte), écriture d’une entrée de grand livre avec une clé d’idempotence unique, et application des crédits à la prochaine facture dans un ordre prévisible.
Décidez tôt de la source de vérité. Soit votre fournisseur de facturation est la source de vérité et votre application la reflète, soit votre grand livre interne est la source de vérité et la facturation ne reçoit que « appliquer X crédits sur cette facture ». Mixer les deux crée souvent des tickets « mes crédits ont disparu ».
Ajoutez des outils d’administration avant d’ajouter plus de règles de parrainage. Le support doit pouvoir chercher par utilisateur, code de parrainage et facture, puis voir une timeline : invite, inscription, qualification, crédits accordés, crédits dépensés, et rétrocessions. Incluez les ajustements manuels et exigez toujours une courte note.
Ensuite, ajoutez l’UX utilisateur : une page de parrainage, une ligne de statut pour chaque invite (pending, qualified, credited), et un historique des crédits qui correspond aux factures.
Enfin, ajoutez du monitoring : alertez sur des pics soudains de parrainages, des taux élevés de rétrocessions (remboursements ou chargebacks), et des motifs inhabituels comme de nombreux comptes partageant le même appareil ou méthode de paiement. Cela garde les contrôles d’abus fermes sans pénaliser les utilisateurs normaux.
Exemple : si quelqu’un partage un parrainage Koder.ai avec son équipe, il doit voir les crédits apparaître seulement après le premier abonnement payant réussi, et ces crédits doivent réduire automatiquement la prochaine reconduction, pas nécessiter un coupon manuel.
La plupart des programmes de parrainage échouent côté facturation, pas marketing. Le moyen le plus rapide de générer des tickets est de rendre les crédits imprévisibles : les utilisateurs ne savent pas pourquoi ils les ont reçus, quand ils s’appliqueront, ou pourquoi une facture est différente.
Un piège courant est de construire avant que les règles soient claires. Si « parrainage qualifié » est vague (essai commencé, premier paiement, maintien payant 30 jours), vous finirez par négocier les crédits au cas par cas et émettre des remboursements pour rendre les gens indemnes.
Un autre problème fréquent est d’utiliser un champ unique et mutable « solde de crédits ». Cela paraît simple jusqu’aux retries, remboursements, changements de plan ou ajustements manuels. Alors le chiffre dérive et vous ne pouvez pas expliquer son historique.
L’idempotence est souvent oubliée aussi. Les fournisseurs de paiement renvoient des webhooks, les workers retentent des jobs, et les utilisateurs cliquent deux fois. Si l’action « attribuer crédit » n’est pas idempotente, vous générerez des crédits en double et ne le remarquerez qu’en voyant le chiffre d’affaires altéré.
Les calculs de crédit peuvent aussi être faux même si les totaux semblent corrects. Appliquer les crédits avant les taxes, ou ignorer les règles de prorata, peut produire des factures qui ne correspondent pas à ce que le système de paiement attend. Cela mène à des reçus discordants, des paiements échoués et une réconciliation pénible.
Les contrôles anti-fraude peuvent aussi être trop stricts. Bloquer par IP, appareil ou domaine sans voie d’appel arrête de vrais parrainages (colocataires, collègues, équipes sur le même réseau) et nuit discrètement à la croissance.
Cinq signaux d’alerte à surveiller :
invite_id, conversion_id) pour prévenir les duplications.Exemple : un utilisateur Koder.ai en Pro upgrade, gagne un crédit de parrainage, puis downgrade. Si votre système utilise un champ de solde unique et applique les crédits avant la proratisation, la prochaine facture peut sembler incorrecte même si le total est proche. Un grand livre et un ordre d’application fixe évitent que cela ne se transforme en long fil de support.
Avant de livrer, effectuez quelques vérifications qui attrapent la plupart des problèmes de facturation et de support tôt.
Exemple : Maya invite Noah. Noah s’inscrit via l’invite de Maya, commence un essai, puis passe en Pro et paie 30 $. Votre système marque cette facture comme qualifiée et crée une entrée de crédit pour Maya (par exemple : 10 $ de crédit d’abonnement).
À la prochaine reconduction de Maya, son sous-total de facture est de 30 $. Votre étape de facturation applique jusqu’à 10 $ depuis ses crédits disponibles, donc la facture affiche 30 $ sous-total, -10 $ crédit, et 20 $ dû. Le grand livre de Maya contient une entrée pour gain (+10 $) et une pour dépense (-10 $ appliqué à la facture #1234).
Si Noah demande ultérieurement un remboursement pour ce premier paiement, le système ajoute une entrée de reversal qui retire le crédit gagné de Maya (ou enregistre un débit correspondant). Si un crédit a déjà été utilisé, la prochaine facture facture la différence au lieu de réécrire l’historique.
Deux prochaines étapes qui maintiennent l’élan sans briser la confiance :
Prototyper le flux complet dans un court document de planification : attribution, qualification, entrées de grand livre, application aux factures, et rétrocessions.
Tester des scénarios fixes dans un bac à sable : essai→payant, remboursement après utilisation du crédit, upgrade et downgrade en milieu de cycle, et un ajustement admin.
Si vous voulez avancer vite sans perdre le contrôle de la logique de facturation, Koder.ai inclut Planning Mode plus des snapshots et rollback, ce qui peut vous aider à itérer sur le flux de parrainage jusqu’à ce que les calculs de factures restent cohérents. Vous pouvez faire tout le passage dans la plateforme à koder.ai, puis exporter le code quand vous êtes prêt.
Referral credits reduce what you owe on future invoices (or extend your subscription time).
They are not cash to a bank account, not gift cards, and not a promise of a payout later. Think of them like store credit that shows up on billing.
A common default is: the referral qualifies after the referred user completes a first successful paid invoice (often after email verification, and sometimes after a short grace period).
Avoid qualifying on “invite sent” or “signup” alone, because those are easy to game and hard to defend in disputes.
Use one primary source of truth, typically a referral link token or short code.
Best practice is:
Use explicit, mutually exclusive statuses so support can answer questions quickly:
pending: signup exists, not yet eligiblequalified: met the rules (e.g., first paid invoice)credited: credit was issuedA single “balance” field gets overwritten, retried, or double-updated and becomes impossible to audit.
A ledger is a list of entries you can always add up:
That makes billing explainable and debuggable.
Make the “award credit” action idempotent by using a unique key per source event (for example, the first paid invoice ID).
If the same webhook or background job runs twice, the second run should safely do nothing, rather than issuing duplicate credits.
Start with simple, explainable blocks:
Then add light abuse controls without punishing normal users:
Define a clear reversal policy tied to billing events:
For partial refunds, pick one rule and stick to it:
A predictable default is:
Rules that reduce confusion:
A minimal MVP that still stays supportable:
After that, add UI and admin tools before adding complicated reward tiers.
rejected: failed checks or ineligiblereversed: credit clawed back after refund/chargebackKeep a timestamp for the last status change.