Eine Provisionszahl wirkt auf den ersten Blick einfach: Zahlungsbetrag mal Prozentsatz. In der Praxis ist vorher zu klären, ob die Zahlung erfolgreich war, welcher Promotion Code verwendet wurde, welche Kampagne galt und ob der Betrag überhaupt provisionsberechtigt ist. Die CROPS SRM Affiliate Suite behandelt die Provision deshalb nicht als isolierte Rechenformel, sondern als Ergebnis einer nachvollziehbaren Ereigniskette. Diese Sichtweise schützt Betreiber und Partner vor vorschnellen oder unklaren Abrechnungen.
Zuerst muss die Zahlung eindeutig sein
Eine Provision kann nur auf einer tatsächlich relevanten Stripe-Zahlung beruhen. Der Webhook meldet Ereignisse, doch nicht jedes Ereignis ist automatisch eine neue abrechenbare Einlösung. Wiederholte Zustellungen, abgebrochene Checkouts oder Rückerstattungen müssen unterschieden werden. Die Ereignis-ID und der Zahlungsbezug dienen dazu, doppelte Verarbeitung zu verhindern.
Zusätzlich wird geprüft, ob ein bekannter Promotion Code und eine aktive Kampagne zugeordnet werden können. Fehlt diese Verbindung, darf das System keine Provision erfinden. Der Vorgang wird protokolliert und kann später untersucht werden.
Der relevante Betrag braucht klare Regeln
Je nach Stripe-Zahlung können Rabatte, Steuern, Gebühren oder Teilbeträge eine Rolle spielen. Das Projekt soll den für die Kampagne vorgesehenen Zahlungswert verwenden und sichtbar machen, worauf die Provision berechnet wurde. Ein positiver Betrag ist Voraussetzung. Eine Provision darf außerdem nicht höher sein als der zugrunde liegende relevante Zahlungsbetrag.
Diese Sicherheitsgrenze ersetzt keine betriebswirtschaftliche Kalkulation. Betreiber müssen selbst entscheiden, welcher Provisionssatz zu Marge und Leistung passt. Die Suite dokumentiert die Regel und wendet sie konsistent an.
Fester Betrag oder prozentuale Beteiligung
Für manche Angebote eignet sich ein fester Prämienbetrag. Bei unterschiedlich hohen Zahlungen kann eine prozentuale Provision sinnvoller sein. Beide Modelle sollen auf Kampagnenebene festgelegt werden. Dadurch kann ein Unternehmen einen Einführungskurs anders vergüten als eine hochpreisige Beratung.
Der gewählte Typ muss für Partner verständlich kommuniziert werden. Unklare Formulierungen wie „bis zu“ oder wechselnde Werte ohne dokumentierte Kampagne führen zu Konflikten. Die Suite unterstützt eine klare Zuordnung, kann aber keine unpräzise Geschäftsregel ausgleichen.
Einmalige Zahlung und Abonnement unterscheiden
Bei Abonnements ist zu entscheiden, ob nur die erste Zahlung oder auch spätere Abbuchungen berücksichtigt werden. Die Kampagne erhält dafür eine entsprechende Einstellung. Eine wiederkehrende Provision kann attraktiv sein, erzeugt aber langfristige Verpflichtungen und muss wirtschaftlich geplant werden.
Die technische Zuordnung späterer Zahlungen braucht einen stabilen Bezug zur ursprünglichen Empfehlung. Deshalb wird diese Funktion nicht als bloße Wiederholung des ersten Checkout-Ereignisses behandelt. Jede relevante Zahlung erhält ihren eigenen nachvollziehbaren Datensatz.
Statusstufen schaffen Kontrolle
Eine neu erkannte Provision sollte nicht sofort als bezahlt gelten. Vorgesehen sind Status wie neu, freigegeben, bezahlt oder abgelehnt. Der Betreiber kann Einlösungen prüfen, mögliche Rückerstattungsfristen berücksichtigen und erst danach eine Auszahlung vorbereiten.
Diese Stufen sind auch für Partner hilfreich. Sie sehen, ob eine Provision erkannt, bereits freigegeben oder abgeschlossen wurde. Eine Statusänderung sollte mit Zeitstempel dokumentiert werden, damit spätere Rückfragen beantwortet werden können.
Korrekturen müssen sichtbar bleiben
Im Alltag können Daten korrigiert werden müssen. Eine Zahlung wird zurückerstattet, eine Einlösung war nicht berechtigt oder ein Partnerdatensatz wurde falsch zugeordnet. Solche Fälle dürfen nicht durch stilles Überschreiben verschwinden. Stattdessen braucht es einen nachvollziehbaren Korrekturweg mit Begründung und Protokoll.
Auszahlungen dürfen nur auf freigegebenen, noch nicht bezahlten Beträgen beruhen. Eine bereits erledigte Position wird nicht erneut in eine neue Auszahlung aufgenommen. Diese Eindeutigkeit ist wichtiger als eine möglichst automatische Auszahlung ohne Prüfung.
Praxisfall: Prüfung vor der Freigabe
Angenommen, ein Partnercode wird bei einer Zahlung verwendet, deren Kampagne inzwischen pausiert wurde. Die technische Stripe-Zahlung ist dennoch echt. Die Suite muss jetzt unterscheiden, ob der Code zum Zahlungszeitpunkt noch gültig war oder ob die Einlösung gegen eine Regel verstieß. Eine einfache Prüfung des heutigen Status würde zu einem falschen Ergebnis führen.
Deshalb werden relevante Zeitpunkte und Regelstände gespeichert. Der Betreiber erhält die Zahlung zunächst als prüfbaren Vorgang und kann sie freigeben oder begründet ablehnen. Diese Vorgehensweise ist langsamer als eine blind automatische Gutschrift, aber deutlich belastbarer für beide Seiten.
Partneransicht ohne Rechenrätsel
Im Partnerbereich sollte nicht nur ein Endbetrag stehen. Sinnvoll sind Kampagne, Einlösungsdatum, zugrunde liegender Betrag, Provisionsart und aktueller Status. Sensible Kundendaten werden dabei nicht offengelegt. Der Partner kann nachvollziehen, warum eine Position noch offen ist, ohne Zugriff auf interne Stripe- oder Verwaltungsdetails zu erhalten. Diese transparente, aber begrenzte Darstellung reduziert Rückfragen und schützt zugleich die Privatsphäre der Käufer.
Währungsbezug
Bei mehreren Währungen werden Beträge nicht stillschweigend zusammengezählt. Auswertung und Auszahlung müssen den jeweiligen Währungsbezug erhalten, damit keine irreführende Gesamtsumme entsteht.
Saubere Rundung
Berechnete Werte werden nach der festgelegten Währung behandelt und nicht durch wechselnde Anzeigeformate verfälscht.
Eine faire Provisionsverwaltung entsteht aus geprüften Daten, klaren Regeln und sichtbaren Bearbeitungsständen. Die Suite soll Berechnungen beschleunigen, ohne die Verantwortung zu verschleiern. Für Partner wird dadurch erkennbar, wie ein Betrag zustande kam; Betreiber behalten die notwendige Freigabekontrolle.
