Empfehlungsprogramm in eine Abo-App einbauen: So geht's

Ein Empfehlungsprogramm klingt nach einem Wochenend-Feature: Jeder Nutzer bekommt einen Code, und wenn ein Freund sich anmeldet, gibt es eine Belohnung. Dann kommen die Fragen. Wie übersteht der Code eine Installation aus dem App Store? Wer wird bezahlt, wenn der Freund nur ein Probeabo startet? Was passiert, wenn er drei Wochen später sein Geld zurückbekommt? Und wer überweist eigentlich?

Dieser Leitfaden beantwortet die Fragen der Reihe nach. Der erste Teil ist anbieterneutral: die sieben Bausteine, die ein Empfehlungsprogramm für ein Abo-Produkt auf iOS, Android und im Web braucht, jeweils mit den Abwägungen. Der zweite Teil ist ein Durchlauf mit AppThunder Referrals als Beispielimplementierung – mit den echten Endpunkten und echtem Code.

Hinweis: Angaben zu Drittanbietern haben den Stand Oktober 2026 und sind mit ihrer Quelle verlinkt. Das ist ein technischer Leitfaden, keine Rechts- oder Steuerberatung. Wenn dein Programm in einer iOS-App läuft, lies auch unseren Leitfaden zu den App-Store-Regeln für Empfehlungsprogramme – ein bestimmtes Ergebnis im App Review kann niemand garantieren.

Die sieben Bausteine

Baustein	Welche Frage er beantwortet	Typischer Fehler
1. Codes	Wer empfiehlt?	Codes in der App erzeugen
2. Erfassung	Wie kommt der Code zum neuen Nutzer?	Darauf setzen, dass ein Link die App-Installation übersteht
3. Attribution	Welche Zahlung gehört zu welchem Code?	Installationen oder Anmeldungen zählen statt Zahlungen
4. Provisionsregeln	Wie viel, wie lange?	Keine Entscheidung zu brutto/netto und Währung
5. Haltefrist und Refunds	Wann ist eine Provision endgültig?	Auszahlen, bevor Refunds eintreffen
6. Auszahlung	Wer überweist?	Kein Protokoll, was eine Auszahlung abgedeckt hat
7. Betrugsschutz	Was darf nicht zählen?	Keine Prüfung auf Selbstempfehlung

1. Codes: einer pro Nutzer, auf dem Server erzeugt

Jede empfehlende Person bekommt einen Code, gespeichert beim Nutzerdatensatz. Dein Server erzeugt ihn beim ersten Bedarf und liefert danach den gespeicherten Code aus. Erzeuge Codes nie im Client.

• Eindeutiges Alphabet. Codes werden von Screenshots abgetippt. Lass 0/O und 1/I weg.
• Den Code an die Nutzer-ID binden, die dein Abrechnungssystem kennt. Identifiziert dein Abo-System Nutzer über eine App-User-ID, nimm dieselbe ID für die empfehlende Person – sonst kannst du Selbstempfehlungen nicht erkennen.
• Codes deaktivierbar machen. Ein Partner hört auf, ein Code landet auf einer Gutscheinseite: abschalten, ohne die Historie zu löschen.

2. Erfassung: wie der Code zum neuen Nutzer kommt

Kanal	Wie der Code ankommen kann	Deterministisch?
Web	?ref=CODE im Link, bis zur Anmeldung im Browser gespeichert	Ja, gleiches Gerät und gleicher Browser
iOS, App installiert	Universal Link oder URL-Schema mit dem Code	Ja
iOS, Neuinstallation	Der neue Nutzer tippt den Code ein	Ja
Android, Neuinstallation	Eingetippter Code oder Play Install Referrer	Ja
Alle	Abgleich von IP, Gerätemodell und Zeitpunkt („Fingerprinting“)	Nein – eine Schätzung

Auf iOS kann ein Link keinen Code durch eine App-Store-Installation tragen. Universal Links öffnen nur eine bereits installierte App. Die Kampagnenlinks in App Store Connect (ct=-Token) fließen in aggregierte App-Analytics mit Mindestschwellen; welcher Nutzer von wem eingeladen wurde, erfährt deine App daraus nicht. Auf Android liefert die Play Install Referrer API die Referrer-URL der Installation, sodass ein Code im Play-Store-Link beim ersten Start ankommen kann.

Das Muster, das überall funktioniert: Die Teilen-Nachricht enthält den Code selbst, nicht nur einen Link, und im Onboarding gibt es ein Feld „Hast du einen Empfehlungscode?“. Prüfe den Code gegen deinen Server, bevor du „angewendet“ anzeigst.

Fingerprinting schließt die Lücke nur auf dem Papier. Es ist probabilistisch – Provisionen darauf sind echtes Geld auf Vermutungen –, und es bringt Datenschutzpflichten mit, die ein Codefeld nicht hat.

Entscheide außerdem, was passiert, wenn jemand mit zwei verschiedenen Codes ankommt. First Touch (der erste Code gewinnt) ist leicht zu erklären und schwer von Gutscheinseiten in letzter Sekunde zu kapern. Wende dieselbe Regel im Browser und auf dem Server an.

3. Attribution: den Code an die Zahlung binden

Bei einem Abo-Produkt ist die Conversion weder die Installation noch die Anmeldung, sondern die Zahlung: die erste und, je nach deinen Regeln, die Verlängerungen. Der Code muss also dort liegen, wo dein Abrechnungssystem ihn zurückmeldet, wenn Geld eingeht:

• In-App-Abos: Abo-SDKs wie RevenueCat erlauben eigene Attribute am Abonnenten; laut RevenueCat-Doku sind sie unter anderem in Webhooks verfügbar.
• Stripe: Leg den Code beim Erstellen der Checkout Session in die Metadaten des Abos (subscription_data), dann trägt ihn jede Rechnung dieses Abos.
• Alles andere: Dein Backend speichert bei der Anmeldung „Nutzer X kam mit Code Y“ und meldet jede Zahlung selbst.

Drei Regeln halten das sauber:

1. Die erste Zuordnung gewinnt. Ein zweiter Code verschiebt einen zugeordneten Nutzer nicht.
2. Identitätswechsel nachziehen. Anonyme IDs werden zusammengeführt, Abos übertragen – RevenueCat schickt dafür ein TRANSFER-Event. Die Empfehlung muss mitwandern.
3. Testkäufe ignorieren. Sandbox- und Testmodus-Events erzeugen nie eine Provision.

4. Provisionsregeln

Regel	Beispiel	Passt für
Prozent, wiederkehrend, unbegrenzt	20 % jeder Zahlung	Creator und Partner, die dauerhaft bewerben
Prozent, wiederkehrend, begrenzt	20 % in den ersten 12 Monaten	Die meisten Abo-Apps – belohnt Bindung ohne lebenslange Verpflichtung
Festbetrag pro Conversion	10 $, wenn der Freund zum ersten Mal zahlt	Programme von Nutzer zu Nutzer

Zwei Entscheidungen, die oft fehlen:

• Brutto oder netto? Die Stores behalten eine Provision ein, im Web kommt die Umsatzsteuer dazu. Leg fest, ob sich der Prozentsatz auf das bezieht, was der Kunde gezahlt hat, oder auf das, was bei dir ankommt – und schreib es in deine Programmbedingungen.
• Eine Ledger-Währung. Kunden zahlen in vielen Währungen, ein Guthaben braucht eine. Der RevenueCat-Webhook etwa liefert price laut Doku als USD-Preis der Transaktion.

Ein kostenloses Probeabo ist eine Empfehlung, aber kein Umsatz: als zugeordnet markieren, nichts zahlen bis zur ersten echten Zahlung.

5. Haltefrist und Refunds

Refunds kommen nach dem Kauf. App-Store-Kunden beantragen sie später über reportaproblem.apple.com; bei Kartenzahlungen erlauben die Kartennetzwerke laut Stripe Anfechtungen normalerweise innerhalb von 120 Tagen. Wer Provisionen sofort auszahlt, zahlt irgendwann welche auf Geld, das nicht mehr da ist.

Die Antwort ist eine Haltefrist: Jede Provision startet als ausstehend, wird nach einer festen Zahl von Tagen freigegeben, und nur freigegebene Provisionen werden ausgezahlt. Ein Refund während der Frist storniert die Provision. Eine kurze Frist zahlt schneller aus, eine lange fängt mehr Refunds ab; für Monatsabos sind 30 Tage – ungefähr bis zur ersten Verlängerung – ein vernünftiger Start. Zwei Details:

• Pro Transaktion stornieren, nicht pro Abo. Ein Refund für März darf Januar und Februar nicht stornieren.
• Eine Kündigung ist kein Refund. Wer nicht verlängert, behält die bezahlten Monate – verdiente Provisionen bleiben.

6. Auszahlung

Option	Was das heißt
Selbst auszahlen	Exportieren, wer wie viel bekommt, per PayPal, Wise oder Überweisung zahlen, als bezahlt markieren
Plattform, die Empfehlende auszahlt	Weniger Handarbeit; du hängst vom Onboarding jedes Empfehlenden dort ab
In-App-Belohnungen	Gratismonate oder Guthaben – auf iOS über Apples Mechanismen (siehe unten)

Für ein kleines Programm reichen ein monatlicher Export und eine Sammelzahlung. Halte fest, welche Provisionen jede Auszahlung abgedeckt hat, damit sich ein später Refund zuordnen lässt, und kläre vor der ersten Auszahlung die steuerliche Seite in deinem Land.

7. Betrugsschutz

• Selbstempfehlungen gesperrt: gleiche Nutzer-ID, ein Alias davon oder gleiche E-Mail auf beiden Seiten
• Provisionen nur auf echte Zahlungen, nie auf Installationen oder Anmeldungen
• Sandbox- und Testmodus-Events ignoriert
• Haltefrist vor Auszahlung; Refunds stornieren Provisionen
• Die erste Zuordnung gewinnt
• Codes und geheime API-Schlüssel nur auf dem Server

Was darf die eingeladene Person bekommen?

Die einladende Person zu belohnen ist der Kern jedes Empfehlungsprogramms. Bei der eingeladenen Person wird es auf iOS heikel: Ein selbstgebauter Code, der Premium freischaltet, kollidiert mit Richtlinie 3.1.1 der App Review Guidelines – „Apps may not use their own mechanisms to unlock content or functionality“. Die Details stehen in unserem Leitfaden zu den App-Store-Regeln. Für einen Rabatt nimmst du die Werkzeuge der Stores:

• iOS: Angebotscodes für Abos – kostenlose oder vergünstigte Zeiträume, einlösbar per URL, in deiner App oder in den App-Store-Accounteinstellungen.
• Android: Promo-Codes von Google Play, die bei Abos ein Probeabo von 3 bis 90 Tagen geben.

Beides sind Rabatte, keine Attribution: Wer eingeladen hat, verraten sie nicht. Für die Provision brauchst du weiterhin deinen eigenen Empfehlungscode.

Durchlauf: Umsetzung mit AppThunder Referrals

AppThunder Referrals kostet pauschal 19 € pro Monat (netto, zzgl. USt.), ohne Umsatzbeteiligung. Ein Programm anzulegen ist kostenlos; bevor der erste Empfehlungscode erzeugt wird, muss eine Karte hinterlegt sein. Jedes Programm hat einen öffentlichen Schlüssel (pk_aff_…, unbedenklich in Apps und Webseiten – er kann nur Codes prüfen) und einen geheimen Schlüssel (sk_aff_…, nur fürs Backend). Die Beispiele nutzen pk_aff_xxx und sk_aff_xxx; die Basis-URL steht in deinem Dashboard.

Schritt 1: Regeln festlegen

Leg im Dashboard ein Programm an und wähle die Provisionsregel – ein Prozentsatz jeder Zahlung (für alle Monate oder eine feste Zahl) oder ein Festbetrag pro Conversion – sowie die Haltefrist (standardmäßig 30 Tage). Provisionen werden auf den Preis ohne Steuer berechnet, vor Store-Gebühren, in einem USD-Ledger; andere Währungen werden zum EZB-Referenzkurs des Zahlungstags umgerechnet.

Schritt 2: Den Code jedes Nutzers im Backend erzeugen

POST https://<project>.functions.supabase.co/aff-ref-api/codes
Authorization: Bearer sk_aff_xxx
Content-Type: application/json

{ "external_user_id": "<your user id>" }
→ { "code": "K7QM4XP" }

Wiederholte Aufrufe für denselben Nutzer liefern denselben Code; ohne hinterlegte Karte lautet die Antwort 402 payment_required. Nimm bei In-App-Abos die Nutzer-ID, die dein Abo-SDK kennt – die vergleicht die Prüfung auf Selbstempfehlung.

Schritt 3 (iOS): Code erfassen und an den Abonnenten hängen

Die Swift-Vorlage ist eine Datei zum Kopieren, kein Paket. Purchases ist das RevenueCat-SDK; die Vorlage nutzt RevenueCats Standardfunktionen für eigene Attribute und Webhooks, die jeder Entwickler einrichten kann – keine Partnerschaft, keine offizielle Integration. Das Wesentliche:

import UIKit
// + your subscription SDK's import (provides Purchases)

enum AppThunderRef {
    static let apiBase = URL(string: "API_BASE")!  // dashboard

    /// Checks a typed code before "applied" UI. Public key only.
    static func validateCode(_ code: String, done: @escaping (Bool) -> Void) {
        var url = URLComponents(url: apiBase.appendingPathComponent("codes/\(code)"), resolvingAgainstBaseURL: false)!
        url.queryItems = [URLQueryItem(name: "public_key", value: "pk_aff_xxx")]
        URLSession.shared.dataTask(with: url.url!) { data, _, _ in
            let json = data.flatMap { try? JSONSerialization.jsonObject(with: $0) as? [String: Any] }
            done(json?["valid"] as? Bool ?? false)
        }.resume()
    }

    /// Attaches the code to the subscriber as the attribute `at_ref`.
    static func applyCode(_ code: String) {
        Purchases.shared.attribution.setAttributes(["at_ref": code])
    }
}

Ruf validateCode aus dem Onboarding-Feld auf (done läuft auf einer Hintergrund-Queue – für die UI auf die Main-Queue wechseln), zeig „angewendet“ und ruf dann applyCode auf. Die vollständige Vorlage enthält zusätzlich share, das das Teilen-Menü mit Use my code K7QM4XP: https://yourapp.com/?ref=K7QM4XP öffnet – so übersteht der Code die Installation. Die Vorlagen für Kotlin, React Native und Flutter machen dasselbe. Im App-Code steht kein geheimer Schlüssel: Alles, was in einer App ausgeliefert wird, lässt sich extrahieren.

Schritt 4: Kauf-Events anbinden

• Abo-Webhook (In-App). Trag die Webhook-URL aus deinem Dashboard in die Webhook-Einstellungen deiner Abo-Plattform ein, dazu den Authorization-Header-Wert, den das Dashboard einmalig anzeigt. Erstkäufe, Verlängerungen und Käufe ohne automatische Verlängerung erzeugen Provisionen; ein Refund (Kündigungsgrund CUSTOMER_SUPPORT) storniert die Provision dieser Transaktion, ein Teil-Refund kürzt sie; eine normale Kündigung nicht; Sandbox-Events werden ignoriert; ein TRANSFER verschiebt die Empfehlung.
• Stripe (Web). Leg in deinem Stripe-Dashboard einen Webhook-Endpunkt für invoice.paid, invoice_payment.paid, charge.refunded, charge.dispute.created und charge.dispute.closed an, trag sein Signing Secret in den Programmeinstellungen ein und leg den Code als at_ref in die Abo-Metadaten (Schritt 5). Eine Anfechtung setzt die Provision bis zur Entscheidung aus; Teil-Refunds kürzen sie.
• REST-API (jede andere Abrechnung). Registriere die Empfehlung bei der Anmeldung mit POST /referrals (code, referee_external_id) – die eigene ID oder E-Mail der empfehlenden Person ergibt 422 self_referral_blocked – und melde dann jede Zahlung:

POST https://<project>.functions.supabase.co/aff-ref-api/events
Authorization: Bearer sk_aff_xxx
Content-Type: application/json

{ "external_user_id": "<your user id>", "amount": 29.00, "currency": "usd",
  "provider_event_id": "inv_1042", "group_ref": "inv_1042" }

provider_event_id macht den Aufruf idempotent; schickst du eine andere currency, wird amount zum EZB-Referenzkurs in USD umgerechnet. Ein Refund ist derselbe Aufruf mit negativem amount, neuer provider_event_id und der group_ref des Verkaufs (die group_ref eines Verkaufs ist standardmäßig seine eigene provider_event_id). Ein Teilbetrag kürzt die Provision um diesen Anteil.

Schritt 5 (Web): Snippet und Checkout

Das Dashboard erzeugt ein <script>-Snippet für jede Seite, auf der ein Empfehlungslink landen kann. Es liest ?ref=, behält den ersten Code 90 Tage lang im localStorage dieses Geräts und stellt window.AppThunderRef bereit. Es enthält nur den öffentlichen Schlüssel und kann selbst keine Provision erzeugen:

// browser
const code = window.AppThunderRef.getCode();   // null if none
// send `code` to your server with the signup form, as referredBy

// your server (Node, Stripe Billing)
const session = await stripe.checkout.sessions.create({
  mode: 'subscription', /* line_items, success_url … */
  subscription_data: { metadata: { at_ref: req.body.referredBy } },
});

Bei der ersten bezahlten Rechnung mit gültigem Code legt der Stripe-Webhook Empfehlung und Provision an; Verlängerungen kommen über denselben Webhook. Läuft deine Website in einer App, die mit AppThunder gebaut ist, funktioniert das Snippet unverändert in der Web-View der App.

Schritt 6: Zahlen anzeigen, auszahlen

GET /members/{external_user_id}/stats liefert { "referrals": n, "earned_usd": x }. Der Aufruf braucht den geheimen Schlüssel, also rufst du ihn von deinem Server für den angemeldeten Nutzer auf. Nach der Haltefrist exportierst du die freigegebenen Provisionen (PayPal Mass Pay, Wise-Batch oder CSV), zahlst deine Empfehlenden aus und markierst den Stapel als bezahlt.

Checkliste vor dem Start

• Ein Code pro Nutzer, auf dem Server erzeugt
• Codefeld im Onboarding; die Teilen-Nachricht enthält den Code
• Code am Abonnenten bzw. am Stripe-Abo, nicht nur an deinem Anmeldedatensatz
• Provisionsregel, Währung und brutto/netto in deinen Programmbedingungen
• Haltefrist gesetzt; Refunds stornieren pro Transaktion
• Geheimer Schlüssel nur im Backend
• Rabatte für Eingeladene über Apple-Angebotscodes oder Google-Play-Promo-Codes
• Programm in den Notes for Review in App Store Connect beschrieben

Wo AppThunder Referrals passt

AppThunder Referrals deckt die Bausteine 1 bis 5 ab und die Buchhaltung von Baustein 6: serverseitig erzeugte Codes, Vorlagen zum Kopieren für Swift, Kotlin, React Native, Flutter und Web, Attribution über Abo-Webhook, Stripe-Webhook oder REST-API, Provisionsregeln, eine einstellbare Haltefrist, Refunds, die Provisionen stornieren, Sperre für Selbstempfehlungen und Auszahlungs-Exporte. Die Attribution ist ausschließlich deterministisch – eine Empfehlung zählt, wenn tatsächlich ein Code ankommt, ohne Device-Fingerprinting oder Wahrscheinlichkeits-Matching. 19 € pro Monat pauschal, ohne Umsatzbeteiligung, monatlich kündbar.

Was es nicht macht:

• Geld bewegen. AppThunder hält und überweist nie Geld; du zahlst deine Empfehlenden anhand des Exports aus, die Steuerseite bleibt bei dir.
• Deferred Deep Links. Bei einer iOS-Neuinstallation tippt der neue Nutzer den Code ein – die Folge davon, kein Fingerprinting zu betreiben.
• Ein SDK liefern. Du kopierst eine Vorlage und pflegst diesen Code selbst.
• Ausgezahlte Provisionen zurückholen. Refunds und verlorene Anfechtungen stornieren oder kürzen Provisionen, bis du sie als bezahlt markierst; danach klärst du das mit der empfehlenden Person selbst.
• Eingeladene belohnen. Rabatte für den Freund laufen über Apple-Angebotscodes oder Google-Play-Promo-Codes, die du in den Store-Konsolen einrichtest.

FAQ

Kann ein Empfehlungslink eine App-Store-Installation überstehen? Nicht deterministisch. Universal Links öffnen nur eine installierte App, Kampagnenlinks speisen nur aggregierte Analytics. Pack den Code in die Teilen-Nachricht und lass den neuen Nutzer ihn eintippen.

Sollte ich auf ein Probeabo Provision zahlen? Zähl das Probeabo als zugeordnete Empfehlung, zahl aber erst, wenn die erste echte Zahlung eingeht.

Wie lang sollte die Haltefrist sein? Lang genug für den Zeitraum, in dem die meisten deiner Refunds eintreffen. Für Monatsabos sind 30 Tage ein vernünftiger Start.

Kann ich den geheimen Schlüssel verschleiert in die App packen? Nein. Alles, was in einer App ausgeliefert wird, lässt sich extrahieren. Die App bekommt den öffentlichen Schlüssel, der Codes prüft und sonst nichts.

Brauche ich RevenueCat für AppThunder Referrals? Nein. Die mobilen Vorlagen nutzen das RevenueCat-SDK für das Abonnenten-Attribut, aber jedes Backend kann stattdessen die REST-API nutzen, und Web-Produkte können den Stripe-Webhook verwenden.