Integracja partnerska RevenueCat: kompletny przewodnik.

Dlaczego webhook jest źródłem prawdy

Program partnerski płaci prawdziwe pieniądze, więc wyzwalaczem prowizji musi być coś, czego nie sfałszuje ani urządzenie klienta, ani twórca. Webhook RevenueCat ma dokładnie właściwe cechy:

• Działa serwer-serwer. Zdarzenia powstają w backendzie RevenueCat po tym, jak zweryfikował on bazową transakcję sklepu. Nic w binarce Twojej aplikacji nie potrafi takiego sfałszować.

• Już pokrywa oba sklepy. Jeden webhook niesie zdarzenia subskrypcji iOS i Androida w jednym formacie, więc warstwie partnerskiej jest obojętne, z którego sklepu pochodzi paragon.

• Niesie subscriber attributes. To zawias całej integracji: dowolne pary klucz-wartość ustawione na użytkowniku podróżują z każdym zdarzeniem o tym użytkowniku.

W InfluTo to jedna z dwóch wspieranych ścieżek weryfikacji — druga to bezpośrednia walidacja App Store Server API / Google Play dla aplikacji bez RevenueCat. Na aplikację wybierasz dokładnie jedną, nigdy obie: dwa źródła prawdy dla tych samych pieniędzy to przepis na błędy podwójnego liczenia.

Jak atrybucja jedzie webhookiem

Krok po kroku przez życie jednego poleconego użytkownika:

1. 1

   Kod dociera do SDK. Twórca udostępnia swój kod. Użytkownik instaluje Twoją aplikację i kod dociera do SDK — wpisany ręcznie albo przyniesiony przez link polecający.

2. 2

   SDK oznacza użytkownika w RevenueCat. SDK InfluTo zapisuje go jako subscriber attribute influto_code w RevenueCat. Od tego momentu tożsamość twórcy podróżuje z użytkownikiem wewnątrz samego RevenueCat. Kliknięcia w link twórcy zostały już zdeduplikowane i oznaczone pod kątem fraudu po stronie InfluTo; dopasowanie kodu jest za to deterministyczne — bez fingerprintingu, bez IDFA, bez promptu ATT.

3. 3

   Webhook odpala; konwersja powstaje. Gdy użytkownik subskrybuje, RevenueCat weryfikuje transakcję sklepu i wysyła webhook. InfluTo odczytuje ze zdarzenia influto_code, dopasowuje twórcę i tworzy konwersję.

Trzy zdarzenia, które się liczą

• INITIAL_PURCHASE. Pierwsza transakcja subskrypcyjna użytkownika. Tworzy konwersję i blokuje stawkę prowizji: stawka z chwili startu subskrypcji obowiązuje przez cały czas życia tego subskrybenta, więc zmiany stawki w trakcie kampanii nigdy po cichu nie przeceniają istniejących subskrybentów twórcy. Jeden krytyczny szczegół: sprawdzaj period type zdarzenia. Start okresu próbnego też przychodzi jako INITIAL_PURCHASE, a okres próbny to nie przychód — prowizja się od niego nie nalicza.

• RENEWAL. Silnik cykliczności. Każde zdarzenie odnowienia dolicza jedno naliczenie prowizji dopasowanemu twórcy. To tu użytkownik z okresu próbnego staje się prowizyjny: gdy próbny konwertuje na płatny, pojawia się płatna transakcja i prowizja rusza. Zasada utrzymująca wszystko w uczciwości jest prosta — prowizja podąża za zweryfikowanymi pieniędzmi, więc twórcy zarabiają na konwersjach z okresów próbnych, nigdy na ich startach. To oznacza też, że twórcy nie mogą farmić prowizji jednorazowymi zapisami na próbę — co chroni Twój depozyt i Twoje dane.

• CANCELLATION. Mechanizm uczciwości. Wyłączone auto-odnawianie oznacza, że odnowienia przestają przychodzić, a z nimi zatrzymuje się naliczanie. Zwrot oznacza, że pieniądze, od których naliczono Ci prowizję, się cofnęły — dlatego InfluTo wstrzymuje prowizję przez okno zwrotów, zanim stanie się wypłacalna. Dzięki wstrzymaniu zwrócona subskrypcja po prostu nigdy nie zostaje wypłacona; nie gonisz twórcy za pieniędzmi, które już wyszły. (Zdarzenia wygaśnięcia domykają cykl, gdy dostęp faktycznie się kończy.)

Konfiguracja w czterech krokach

1. 1

   Zainstaluj SDK i ustaw atrybut. Swift, Kotlin, Flutter albo React Native/Expo — open source na github.com/influto, około 5 minut. Zapisywanie influto_code ogarnia SDK; Ty tylko przekazujesz mu kod, z którym przyszedł użytkownik. Dokładne snippety per platforma: docs.influ.to/integrations/revenuecat.

2. 2

   Dodaj webhook w RevenueCat. W panelu RevenueCat dodaj InfluTo jako integrację webhookową ze swoim URL-em endpointa i nagłówkiem authorization. RevenueCat wspiera wiele integracji webhookowych na projekt, więc Twoje istniejące webhooki działają dalej bez zmian. Nagłówek auth traktuj jak sekret; InfluTo odrzuca nieuwierzytelnione zdarzenia, a sekret możesz zrotować, jeśli wycieknie.

3. 3

   Przetestuj w sandboxie. RevenueCat oznacza każde zdarzenie środowiskiem, więc zakupy sandbox są odróżnialne od produkcyjnych. Uruchom aplikację na sandboxowym koncie sklepu, użyj testowego kodu polecającego, dokończ subskrypcję sandbox i patrz, jak pojawia się przypisana konwersja. Jeśli masz podpiętego agenta AI przez MCP, influto_integration_status raportuje dokładnie, co platforma już widziała — aktywność SDK, zdarzenia webhooka, przypisane konwersje testowe — a influto_test_integration uruchamia kontrolę na żywo. Nie pomijaj tego: program po cichu zepsuty w dniu startu pali zaufanie twórców, którego nie odzyskasz.

4. 4

   Wystartuj. Zasil portfel depozytowy (zwrotny, przez Stripe), utwórz kampanię, zaproś twórców. Od tego momentu pipeline jest autonomiczny: zdarzenia przychodzą, prowizja się nalicza, a Stripe Connect płaci twórcom z portfela z minimum $1. Konfiguracja za darmo, 10% opłaty platformy od prowizji.

claude mcp add --transport http influto https://influ.to/mcp

Czego nie musisz zmieniać

Nic w Twojej istniejącej konfiguracji RevenueCat się nie rusza. Entitlementy, offeringi, paywalle, obecne webhooki i analityka — wszystko nietknięte. RevenueCat pozostaje Twoim źródłem prawdy o przychodzie; warstwa partnerska to jeden subscriber attribute plus jeden dodatkowy konsument webhooka. Jeśli kiedyś ją usuniesz, kasujesz integrację webhookową i zapisy atrybutu, a Twój stack subskrypcyjny jest dokładnie taki jak wcześniej. Krótsze, produktowe podsumowanie mieszka na stronie funkcji integracji RevenueCat, link poniżej — a skonfigurować możesz za darmo już dziś.