#Die eine Einstellung entscheidet: Provision einmal, doppelt oder nie?
In den meisten Affiliate-Integrationen gibt es einen versteckten Schalter, den Gründer oft unbedacht umlegen. Er entscheidet, ob eine 9,99-€-Verlängerung Ihren Influencer einmal, zweimal oder gar nicht bezahlt.
Jede Abo-App benötigt einen Nachweis über den Kauf, bevor Provisionen fließen. Es gibt genau zwei Wege, diesen Nachweis zu erhalten: Entweder bitten Sie RevenueCat, das Ereignis an Sie weiterzuleiten, oder Sie fragen Apple und Google direkt. Beides funktioniert. Nichts davon ist „korrekter“. Das Problem: Beide Wege fragen letztlich dasselbe Backend ab. Wenn Sie beide gleichzeitig für denselben Kauf nutzen, erhalten Sie keine zweite Meinung, sondern stellen dieselbe Frage zweimal – und bezahlen für beide Antworten.
#So bestätigt jeder Weg den Zahlungseingang
Der RevenueCat-Weg ist ein Relay. Das SDK Ihrer App setzt ein Subscriber-Attribut – etwa einen Referral-Code –, wenn jemand über einen Affiliate-Link installiert. RevenueCat speichert dieses Attribut beim Abonnenten. Da dies vom SDK aus nur schreibbar und nach dem Setzen unveränderlich ist, kann niemand im Nachhinein die Zuordnung ändern. Bei Abschluss und jeder Verlängerung sendet RevenueCat einen Webhook mit diesem Attribut an Ihren Server. Attributionsdaten werden direkt in den INITIAL_PURCHASE- und RENEWAL-Events übertragen.
Store-Direct umgeht das Relay. Ihr Server fragt direkt bei Apples App Store Server API oder dem Google Play Service Account an: Hat diese Transaktion stattgefunden, ist sie gültig, ist sie noch aktiv? Apples Update 2025 fügte ein signiertes Transaktionsobjekt und neue Endpunkte hinzu, die speziell für diese serverseitige Prüfung entwickelt wurden – ohne Einbindung des Geräts oder Dritter.
Das sind keine zwei unabhängigen Wahrheitsquellen. RevenueCat fragt exakt dasselbe Apple- oder Google-Backend ab, das Sie selbst ansprechen würden. Es ist ein Wrapper, kein zweiter Kontrollpunkt.
#Die Rechnung, wenn man beides gleichzeitig nutzt
Die folgenden Zahlen sind ein illustratives Modell – keine echten InfluTo-Transaktionsdaten –, um die Mechanismen zu verdeutlichen, nicht um eine Fehlerquote zu belegen.
Der Instinkt, beides „zur Sicherheit“ laufen zu lassen, ist verständlich – Redundanz ist normalerweise gutes Engineering. Hier ist es jedoch falsch, weil es nichts Redundantes zu prüfen gibt: eine Transaktion, ein Eintrag im Hauptbuch bei Apple, zwei Türen, die danach fragen.
Nehmen wir ein 9,99-€/Monat-Abo bei 20 % Provision – also 2,00 € pro Verlängerung. Sind beide Wege aktiv, feuert der RevenueCat-Webhook bei der Verlängerung, Ihr System verbucht 2,00 € und markiert sie als bezahlt. Minuten später läuft Ihr Store-Direct-Job, prüft ebenfalls bei Apple, sieht dieselbe Verlängerung und – da nichts signalisiert, dass diese bereits gezählt wurde – verbucht weitere 2,00 €. Ein 9,99-€-Verkauf, 4,00 € gehen raus. Das passiert bei jeder Verlängerung, in jedem Zyklus, bis es jemand bemerkt.
Drehen wir den Spieß um: Nur Store-Direct ist aktiv, aber der Job erhält den Referral-Code nie, weil er nicht in den App Store Server API-Aufruf integriert wurde – diese Zuordnung muss explizit gebaut werden, Apples API liefert sie nicht nativ mit. Die Verlängerung findet statt. Apple bestätigt sie. Die Validierung gelingt. Aber nichts verknüpft die Transaktion mit einem Affiliate, also werden die fälligen 2,00 € nie generiert. Kein Fehler, kein fehlgeschlagener Job, nichts im Log, wonach man suchen könnte. Nur ein Influencer, der drei Monate später bemerkt, dass ein geworbener Abonnent nie auf der Abrechnung auftaucht.
Wenden Sie eines dieser Szenarien auf Dutzende Abonnenten und mehrere Abrechnungszyklen an, und die Lücke zwischen geschuldet und bezahlt ist kein Rundungsfehler mehr – in beide Richtungen, aus derselben Ursache: zwei Systeme (oder das falsche allein), die auf Daten schauen, die nie mehrdeutig waren.
#Wo welcher Weg auf unterschiedliche Weise scheitert
Kein Weg ist vor jedem Fehler gefeit – sie scheitern nur unterschiedlich. Zu wissen, welchem Risiko Sie ausgesetzt sind, ist wichtiger, als einen „Gewinner“ zu küren.
Rückerstattungen. RevenueCat-Webhooks sind systembedingt „at least once“-Zustellungen. Ein Refund-Event kann theoretisch doppelt ankommen – Ihre Clawback-Logik muss idempotent sein, sonst stornieren Sie eine Provision doppelt, die nur einmal ausgezahlt wurde. Store-Direct hat diese Eigenheit nicht, pusht aber auch keine Refunds an Sie – Sie müssen den Status aktiv abfragen.
Trial-to-Paid-Konvertierung. RevenueCat modelliert dies standardmäßig als einen durchgehenden Lebenszyklus. Store-Direct behandelt jeden Status als separate Abfrage, die Sie selbst zusammenführen müssen.
Family Sharing und Wiederherstellungen. Hier zahlt sich die Store-seitige Identität aus. Apples originalTransactionId und Googles purchaseToken bleiben über eine Wiederherstellung oder geteilte Käufe hinweg stabil – das ist der Identifikator, auf den sich beide Wege zur Deduplizierung stützen. So wird ein wiederhergestellter Kauf nicht fälschlicherweise einem neuen Referral-Code zugeordnet.
Migration während der Kampagne. Wenn Sie die Validierungswege mitten im laufenden Betrieb ohne saubere Umstellung wechseln, entsteht eine Lücke: Käufe im Übergangsfenster landen in keinem der beiden Systeme – oder in beiden.
#Wann Store-Direct gewinnt, wann RevenueCat gewinnt
Es gibt keinen universell „besseren“ Weg – der richtige hängt davon ab, was bereits in Ihrem Stack vorhanden ist.
Wählen Sie den RevenueCat-Webhook-Weg, wenn Sie RevenueCat bereits für Abos nutzen oder wenn Sie auf iOS und Android verkaufen und ein Dashboard für den Abonnentenstatus statt zwei separater Store-Integrationen wünschen. Sie tauschen die Abhängigkeit von einem Drittanbieter gegen weniger Installationsaufwand.
Wählen Sie Store-Direct, wenn Sie absolut keinen Drittanbieter-Abo-Manager im Anfragepfad zwischen Ihrer App und Apple oder Google haben möchten – manche Gründer benötigen das aus Compliance-, Latenz- oder Kontrollgründen – oder wenn Sie RevenueCat ohnehin nicht nutzen und es nur für die Attribution hinzuzufügen, wäre eine neue Abhängigkeit ohne weiteren Nutzen.
| Ihre Situation | Empfohlener Weg |
|---|---|
| Nutzen bereits RevenueCat für Abos | RevenueCat-Webhook |
| iOS + Android, wollen eine Abonnenten-Ansicht | RevenueCat-Webhook |
| Wollen keinen Drittanbieter im Kauf-Prüfpfad | Store-Direct |
| Kein RevenueCat, einfache Single-Plattform-App | Store-Direct |
#Die Entscheidung treffen, ohne Fehler zu machen
Wählen Sie einen Weg. Stellen Sie sicher, dass der andere vollständig deaktiviert ist – nicht nur „ungenutzt“. Das ist die ganze Entscheidung, und sie falsch zu treffen, kostet Geld – in beide Richtungen.
Bevor Sie live gehen: Überprüfen Sie, ob nur eine Validierungsquelle Provisionsereignisse in Ihr Hauptbuch schreibt. Testen Sie einen Refund und eine Wiederherstellung mit dem gewählten Weg und prüfen Sie, ob die Referral-Attribution den Übergang von Testphase zu Bezahl-Abo überlebt, falls Ihre App Testzeiträume anbietet. Beobachten Sie dann Ihren ersten echten Auszahlungszyklus genau – eine doppelte oder fehlende Provision am ersten Tag ist der günstigste Bug, den Sie je finden werden.
Was passiert, wenn ein doppeltes oder fehlendes Ereignis Ihr Hauptbuch erreicht, lesen Sie unter Stop Paying Influencers Twice on the Same Renewal und Pay Influencers by Revenue? One Purchase Could Pay Two. Wenn Sie auf InfluTo aufbauen, werden beide Validierungswege nativ unterstützt – die Plattform erzwingt genau einen aktiven Weg, sodass diese Art von Bug nicht versehentlich live gehen kann.
Kann ich später von RevenueCat zu Store-Direct wechseln, ohne meine Provisionshistorie zu verlieren?
Ja – bereits protokollierte Provisionsdatensätze bleiben an die Store-Transaktions-ID gebunden, die sie generiert hat, da sich diese Identität (Apples originalTransactionId oder Googles purchaseToken) beim Wechsel der Validierungswege nicht ändert. Wichtig ist nur, während des Umstellungsfensters nicht beide Wege gleichzeitig laufen zu lassen.
Funktioniert die Service-Account-Validierung von Google Play genauso wie die App Store Server API von Apple?
Der Mechanismus ist analog – ein Server-zu-Server-Credential erlaubt Ihnen, den Kaufstatus direkt bei Google abzufragen –, aber die Identifikatoren und API-Strukturen unterscheiden sich. Sie sind also nicht eins zu eins austauschbar, auch wenn die architektonische Rolle identisch ist.
Was passiert mit Käufen, die InfluTo bereits getrackt hat, wenn ich den aktuell aktiven Validierungsweg abschalte?
Bereits zugeordnete und bereits bezahlte Provisionen sind davon rückwirkend nicht betroffen. Das Abschalten eines Weges stoppt lediglich zukünftige Ereignisse aus dieser Quelle – genau deshalb müssen Sie bestätigen, dass der Ersatzweg vollständig live ist, bevor Sie den alten deaktivieren.