Faut-il ajouter un programme de parrainage ?
Décider entre attribution, commission en espèces ou crédits avant d’activer le suivi first-touch du starter.
Sushi SaaS fournit la plomberie du parrainage, pas un programme d’affiliation prêt à opérer. Il est désactivé par défaut. Une fois activé, il attribue un nouveau compte et enregistre une récompense pending après paiement ; il ne vérifie pas les affiliés, ne verse pas d’argent, n’accorde pas de crédits et ne marque pas un payout terminé.
Le parcours livré
- Un utilisateur connecté crée un code court (généralement huit caractères) et partage
/i/<code>. - Le visiteur ouvre le lien ; l’application stocke l’UUID du parrain dans un cookie
refde 30 jours et redirige vers l’accueil. - Après connexion, le client envoie le cookie à l’endpoint d’attribution.
- Le service réclame le parrain une seule fois. L’auto-parrainage est refusé et les appels concurrents convergent vers la première attribution réussie.
- Un paiement éligible crée une commission pending. Une unicité en base rend le replay webhook inoffensif.
L’utilisateur voit son lien et son résumé sur my-invites. L’opérateur inspecte les lignes sur la page admin affiliates, mais elle est en lecture seule : ce n’est pas un workflow de paiement.
L’exemple prend le maximum entre 5 000 unités monétaires mineures et 20 % du paiement. Pour un USD à deux décimales, 5 000 signifie 50 $. Ce n’est pas un taux recommandé.
Voir src/config/affiliate.ts au commit 7580470 et src/services/affiliate.ts.
Choisissez le programme avant le code
| Objectif | Action |
|---|---|
| Aucun parrainage | Gardez enabled: false ; retirez ensuite pages, routes, tables et provider pour alléger le produit |
| Attribution seulement | Gardez first touch, cessez de créer et d’afficher des commissions et définissez les analytics conservables |
| Commission en espèces | Ajoutez éligibilité, identité/fiscalité, fraude, provider de paiement, états audités et rapprochement |
| Récompense en crédits | Ajoutez un grant idempotent au ledger ; changer seulement payoutType ne déplace aucun crédit |
| Last touch | Implémentez et testez une autre règle dans le service ; l’enum exporté seul ne change pas le first touch livré |
Le calcul prend en charge fixe, pourcentage, maximum et somme. L’attribution ne branche pas actuellement sur AttributionModel : first touch est le contrat implémenté.
Politiques à définir
- Quels achats sont éligibles et quand une récompense devient-elle payable ?
- Que se passe-t-il après remboursement, litige, annulation ou effacement de compte ?
- Quelle devise et quelle règle d’unité mineure ?
- Employés, clients existants ou même foyer peuvent-ils participer ?
- Le cookie exige-t-il un consentement dans vos régions ?
- Comment enquêter et corriger sans perdre l’audit ?
Un remboursement Stripe peut annuler une récompense encore pending, mais la récupération d’un payout terminé n’est pas implémentée. N’automatisez pas l’argent avant politiques et échecs.
Activation sûre
- Configurez et testez Stripe Billing.
- Remplacez fenêtre et valeurs d’exemple dans
src/config/affiliate.ts. - Construisez le workflow paiement/crédits et ses actions admin avant activation.
- Testez visite anonyme → inscription/connexion → first touch → paiement → replay → remboursement.
- Testez auto-parrainage, deux liens concurrents, expiration et événements simultanés.
Suivez Configurer les parrainages et récompenses d’affiliation pour la configuration et les vérifications, puis consultez Pages et opérations de la console pour la surface actuelle.