Retour aux intégrations

Tracking affilié Paddle

Construisez un programme affilié Paddle autour d'événements MoR, pas d'hypothèses cookie.

Paddle est un bon fit billing pour les SaaS européens. RefCampaign n'expose pas encore de connecteur Paddle natif comme disponibilité générale ; cette page définit donc le modèle d'événements à utiliser pour évaluer ou préparer l'intégration.

Notes d'implémentation

1

Ce qu'il faut capturer depuis Paddle

Capturez l'identité client, le produit ou prix, le montant, la devise, le statut d'abonnement et l'issue de remboursement. Le clic affilié doit être résolu côté serveur avant de créditer le revenu.

2

Différence avec le tracking Stripe-native

Stripe peut être consommé directement par RefCampaign aujourd'hui. Paddle demande une couche de mapping explicite pour appliquer les mêmes règles d'attribution et de clawback sans prétendre que le connecteur est déjà natif.

3

Où être strict

Rendez les transaction IDs idempotents, excluez les événements test des calculs de payout et exigez que les remboursements mettent à jour l'état commission avant le prochain cycle de paiement.

Questions fréquentes

RefCampaign a-t-il un connecteur Paddle natif aujourd'hui ?

Pas comme connecteur produit disponible généralement. Le chemin Stripe-native est l'intégration principale aujourd'hui ; Paddle doit d'abord être évalué via un modèle d'événements mappés.

Paddle peut-il quand même fonctionner pour le tracking affilié ?

Oui, si checkout, abonnement, remboursement et annulation sont mappés dans un flux d'attribution serveur avec des transaction IDs idempotents.