Tworzysz kod rabatowy w Stripe, raz przypisujesz go partnerowi w naszym panelu i już działasz. Kod jedzie w samym payloadzie Stripe — przy pierwszej płatności i przy każdym odnowieniu — więc prowizje księgują się bez SDK, bez wdrożenia i bez ciasteczka, które może zjeść adblock.
Stripe · RevenueCat · Adapty — web i mobile w jednej księdze. My liczymy prowizje; pieniądze zostają u Ciebie i to Ty płacisz partnerom.
Trzy drogi. Zacznij od góry.
Kod rabatowy
Link polecający
„Skąd o nas wiesz?”
Wszystkie trafiają do tej samej księgi.
Zwykle wygląda to tak: zimne wiadomości i stała stawka płacona, zanim ktokolwiek wie, czy post cokolwiek sprzeda. Tutaj publikujesz program raz, twórcy zgłaszają się do Ciebie, a płacisz im z przychodu, który faktycznie przynieśli.
Ustawiasz stawkę prowizji i warunki, po czym wystawiasz program w katalogu PolyReach. Konfigurujesz raz, działa dalej.
Twórcy przeglądający katalog widzą Twoje warunki i zgłaszają się, jeśli ich odbiorcy pasują. Bez zimnych wiadomości, bez gonienia za odpowiedzią, bez negocjowania stawki z góry.
Czytasz każde zgłoszenie i decydujesz sam. Akceptujesz twórców, których widownia pasuje do produktu, resztę pomijasz.
Każdy twórca dostaje link albo kod. Sprzedaż przypisuje się przez Twoje webhooki Stripe, RevenueCat lub Adapty, skierowane na PolyReach.
Prowizja czeka przez okres zwrotów, potem staje się wymagalna. Płacisz udział w pieniądzach, które już wpłynęły — nigdy z góry.
i to się nakręca
Partner, który zarabia, publikuje dalej, a że warunki są jawne, kolejny twórca trafia do programu bez żadnego polecenia.
Szukasz twórców po prywatnych wiadomościach, a większość nigdy nie odpisuje.
Ustalasz stałą stawkę, zanim ktokolwiek wie, czy post cokolwiek sprzeda.
Post wychodzi i nikt nie potrafi powiedzieć, ile realnie zarobił.
Twórcy znajdują Twój program w katalogu i sami się zgłaszają.
Zarabiają tylko na płatnościach, które faktycznie doszły do skutku, więc nie płacisz nic z góry.
Każdą prowizję można powiązać z konkretną płatnością, która ją wywołała.
Załóżmy, że założyciel aplikacji do liczenia kalorii wystawia program z jasną stawką. Zgłaszają się twórcy fitnessowi i kulinarni, bo ich odbiorcy i tak codziennie liczą kalorie. Założyciel akceptuje trzech. Każdy zarabia tylko na subskrypcjach, które zaczęli jego odbiorcy, a każda prowizja jest powiązana z tą płatnością.
Wystawienie programu nic nie kosztuje. Prowizję płacisz dopiero wtedy, gdy klient Ci zapłacił.
Wystaw swój programAtrybucja
Ułożone według tego, jak mało musisz zbudować. Można je łączyć — pierwszy odpalisz dziś po południu, kolejne dołożysz, kiedy zechcesz.
Tworzysz w Stripe kod promocyjny — TOMEK20, 20% taniej — i raz przypisujesz go partnerowi w panelu PolyReach. Stripe sam wpisuje ten kod do payloadu, więc każda płatność, której on dotknie, jest przypisana. Bez SDK, bez wdrożenia, bez code review, bez czekania na programistę.
Księguje się przy pierwszej płatności i przy każdej kolejnej fakturze odnowienia
Nie zgubi się przez wyczyszczone ciasteczka, adblocka ani zmianę urządzenia
Format, który widownia influencera już zna: „użyj TOMEK20 i masz 20% taniej”
Kod możesz przypisać w dowolnym momencie — sprzedaże sprzed przypisania doksięgują się automatycznie.
Partner udostępnia swój link. Jeden tag script na Twojej stronie zapamiętuje go w ciasteczku first-party na Twojej własnej domenie, a jedna linijka przekazuje go do metadanych sesji Stripe Checkout.
Bez zależności, bez build stepu, dokładnie jedno ciasteczko
Wygrywa pierwsza atrybucja — późniejszy link nie nadpisze wcześniejszego
Kliknięcie liczy się jeszcze przed przekierowaniem, więc widzisz, które linki działają
Pytanie, które i tak warto zadawać. W webie to jedno wywołanie z tego samego snippetu; w aplikacji mobilnej ustawia jeden atrybut subskrybenta w RevenueCat albo Adapty — i od tej pory każdy webhook zakupu, odnowienia i zwrotu niesie odpowiedź ze sobą.
Bez deep linków i bez fingerprintingu — bezpieczne dla recenzji App Store
Działa też jako analityka pozyskania, nawet bez ani jednego partnera
Ustawiasz raz przy rejestracji; odnowienie za dwa lata nadal trafi do tego samego partnera
Na mobile to ankieta jest właściwą drogą — Apple nie ma pola na kod rabatowy w procesie zakupu subskrypcji. Kody ofertowe App Store nadal można przypisać partnerowi jako dodatkowy, deterministyczny sygnał.
Niezależnie od tego, którą drogą przyszła sprzedaż, ląduje w tej samej księdze, u tego samego partnera i w walucie, w której faktycznie zapłacono.
To samo, tylko w pieniądzach
Cała mechanika na konkretnych liczbach. Stawkę i okres ochronny ustawiasz sam — poniżej nasze domyślne.
Tomek udostępnia TOMEK20
Jego widownia dostaje 20% taniej. On ma kod do powiedzenia na głos, a nie link śledzący do tłumaczenia.
Ktoś wykupuje subskrypcję
Plan za 10,00 $/mies. z użytym kodem: Stripe pobiera 8,00 $ i wpisuje kod promocyjny do faktury.
Tomek zarabia 2,40 $
30% z 8,00 $, które faktycznie wpłynęły — prowizję liczymy od kwoty zapłaconej, nigdy od ceny katalogowej.
I znowu 2,40 $ w kolejnym miesiącu
Faktura odnowienia niesie ten sam rabat, więc każda płatność dalej księguje się na Tomka tak długo, jak długo klient zostaje.
30 dni okresu ochronnego
Jeśli klient zrobi zwrot w tym oknie, clawback lustrzany do pierwotnego wpisu zeruje kwotę — te pieniądze nigdy nie stały się należne.
Ty płacisz, my księgujemy
Przelew, PayPal, cokolwiek już używasz. Klikasz „Oznacz jako opłacone” i obie strony widzą tę samą historię.
Nasze domyślne: 30% prowizji i 30 dni okresu ochronnego. Okres ochronny ustawiasz dla całego programu, stawkę możesz nadpisać dla pojedynczego partnera.
Od polecenia przez partnera po pieniądze w jego kieszeni — a obie strony czytają dokładnie te same liczby.
Klient przychodzi od partnera
Używa kodu rabatowego partnera, klika jego link albo wskazuje go w kroku „skąd o nas wiesz?”.
Kupuje subskrypcję
8,00 $/mies.
Subskrypcja miesięczna
Wykupuje subskrypcję tak jak każdy inny — atrybucja jest już doczepiona do płatności.
Webhook trafia do PolyReach
Twoje płatności
PolyReach
zakup · odnowienie · zwrot
Twoja platforma płatnicza i tak raportuje każdy zakup, odnowienie i zwrot — PolyReach po prostu słucha.
Księga nalicza prowizję
+ prowizja z każdej płatności
Każda płatność dokłada % partnera — automatycznie, z okresem ochronnym i clawbackiem, jeśli pieniądze wrócą.
Partner widzi to od razu
+2,40 $
e-mail + panel na żywo
Jego prywatny panel aktualizuje się na żywo, a e-mail mówi dokładnie, ile właśnie zarobił.
Partnerom płacisz bezpośrednio i klikasz „Oznacz jako opłacone” — PolyReach pilnuje uczciwej matematyki po obu stronach i nigdy nie dotyka pieniędzy.
Podłączasz raz. PolyReach nasłuchuje zdarzeń zakupu, odnowienia i zwrotu, które Twoja platforma płatnicza i tak wysyła — nic nie zmienia się ani w Twoim checkoucie, ani w tym, jak dostajesz pieniądze.
Stripe
DziałaWeb i SaaS. Kod rabatowy, link polecający albo wskazanie w ankiecie — wszystkie trzy trafiają do tej samej księgi, a podpisane webhooki obejmują odnowienia, zwroty i spory.
RevenueCat
DziałaSubskrypcje w App Store i Google Play. Aplikacja ustawia jeden atrybut subskrybenta przy rejestracji, a każdy webhook niesie go dalej.
Adapty
BetaDruga ścieżka mobilna. Ten sam model webhooków zakupu / odnowienia / zwrotu co RevenueCat, więc wpasowuje się prosto w tę samą księgę.
Narzędzia paywallowe nie potrzebują własnej integracji — odpowiadają za UI, a nie za rozliczenia. Jeśli Twój paywall stoi na RevenueCat, zdarzenia zakupu, których słuchamy, i tak już lecą, więc prowizje liczą się bez dotykania paywalla.
Konfigurujesz raz. Używasz jednej strony albo obu.
Program afiliacyjny
Cykliczna prowizja tak długo, jak klient płaci — a nie jednorazowa wzmianka. Atrybucja bierze się z webhooków płatności, które i tak wysyłasz, a w Stripe może to być kod rabatowy, pod który nie napiszesz ani linijki kodu. Partnerom płacisz bezpośrednio i klikasz „Oznacz jako opłacone” — my nigdy nie dotykamy pieniędzy.
Analityka atrybucji
Nie chcesz jeszcze nikomu płacić? Ta sama jednoklikowa ankieta działa jak czysta analityka: zobacz, jaki procent nowych użytkowników przyszedł z TikToka, Google, App Store czy od znajomego — prosto w Twoim onboardingu, bez żadnych dodatkowych SDK. Prowizje włączysz później, gdy będziesz gotów.
Program afiliacyjny nie jest wymagany — statystyki atrybucji działają same.
Narzędzie #2 — Analityka atrybucji
To samo pytanie w onboardingu (jedno tapnięcie) działa jak czysta analityka pozyskania. Bez dodatkowych SDK, bez fingerprintingu — po prostu uczciwy rozkład źródeł każdego nowego subskrybenta, prosto w Twojej aplikacji.
Działa nawet bez płatnych partnerów — czysta analityka od pierwszego dnia
Twórcy, App Store, Google, poczta pantoflowa — jeden widok
Prowizje włączysz później, bez dotykania kodu
Nowi subskrybenci wg źródła
Twórcy (partnerzy)
41%
TikTok
24%
Google / Wyszukiwarka
17%
App Store (przeglądanie)
12%
Znajomy / poczta pantoflowa
6%
Przykład na żywo — Twoje realne liczby pojawią się, gdy użytkownicy przechodzą onboarding.
Nie dlatego, że nie chcą ambasadorów — tylko przez to, co stoi na drodze.
SDK, skrypt śledzący, domena przekierowań, release. Temat ląduje więc w roadmapie za wszystkim, co dowozi przychód w tym kwartale, a twórca, który sam się zgłosił, dostaje „wkrótce”.
Stripe Connect to KYC, SCA, spory i odpowiedzialność platformy — gigantyczny narzut, żeby zapłacić czterem twórcom po kilkaset miesięcznie.
Adblocki, ochrona przed śledzeniem, wyczyszczona przeglądarka, zakup dokończony na innym urządzeniu. Każde z tych zdarzeń po cichu psuje atrybucję, a zauważa to partner.
Na pytanie „ile mi wisisz?” nie powinno się odpowiadać zrzutem ekranu. A gdy przyjdzie zwrot, albo bierzesz stratę na siebie, albo odzyskujesz pieniądze ręcznie — obie rozmowy są niewygodne.
Krótkie odpowiedzi — każdej pilnuje kod, a nie odpowiedź supportu.
Zwrot przychodzi tym samym webhookiem i tworzy ujemny wpis lustrzany wobec pierwotnej prowizji — nigdy kwotę odczytaną z payloadu zwrotu. Dziedziczy datę okresu ochronnego oryginału, więc para zeruje się w tym samym koszyku, zamiast zmuszać Cię do proszenia partnera o zwrot pieniędzy.
Odwracany tak samo. Spór w Stripe niesie wyłącznie payment intent, a prowizja jest kluczowana na fakturze — dlatego każde zdarzenie zapisuje oba identyfikatory, a odwrócenie dopasowuje się po którymkolwiek z nich. Bez tego chargeback na subskrypcji kosztowałby Cię sprzedaż i zostawiał prowizję do zapłaty.
Nie. Każda prowizja wynika ze zdarzenia wysłanego przez Twojego dostawcę płatności, a lista zdarzeń pokazuje każde z nich: typ zdarzenia u dostawcy, kwotę, walutę, partnera, któremu je zaksięgowano, i sygnał, który je przypisał. Salda za każdym razem sumujemy z księgi — nie ma licznika, który mógłby się rozjechać.
Walut nigdy nie dodajemy do siebie. Partner zarabiający w EUR i USD widzi dwa salda, a nie jedną błędną liczbę, a waluty bez części groszowej pokazujemy takimi, jakie są — ¥3 000 to nie ¥30.
Na obu, w jednej księdze. Stripe obsługuje web i SaaS, RevenueCat App Store i Google Play, Adapty to druga ścieżka mobilna. Founder z aplikacją i planem webowym ma jedną listę partnerów i jedno saldo na walutę.
Kiedy zdecydujesz. PolyReach wylicza, co jest do wypłaty po okresie ochronnym, Ty wysyłasz pieniądze tak, jak wysyłasz je zwykle, i klikasz „Oznacz jako opłacone”. Bez KYC, bez Stripe Connect, bez odpowiedzialności platformy — PolyReach nigdy nie dotyka tych środków.
Sami tego używamy
Płacimy 30% od każdej płatności za subskrypcję, cyklicznie, tak długo, jak klient zostaje — dokładnie tę stawkę, którą sugerujemy Tobie, w tej samej księdze i z tym samym 30-dniowym okresem ochronnym. Ogłoszenie wisi w naszym marketplace i możesz do niego aplikować.
Ta sama ścieżka Stripe, którą dostajesz Ty — na własnym programie ją testujemy
Ta sama księga, te same okresy ochronne i clawbacki, z których płaciliby Twoi partnerzy
Ten sam link do portalu, który otworzyliby Twoi twórcy
Gdybyśmy nie przepuścili przez to własnych prowizji, nie prosilibyśmy o to Ciebie.
Trzy kroki. Żaden nie dotyka kodu Twojej aplikacji.
Nazwa, platforma płatnicza, stawka prowizji i okres ochronny. Sugerujemy 30% cyklicznie i 30 dni — na takich warunkach prowadzimy własny program.
Do Stripe, RevenueCat albo Adapty. To ekran ustawień w panelu Twojej platformy płatniczej — jedyny krok integracyjny, jaki tu jest, i nie wymaga SDK, release'u ani code review.
Wklej przy partnerze adres kodu promocyjnego ze Stripe i wyślij mu prywatny link do portalu. Kolejna sprzedaż z rabatem przypisze się sama — i każde jej odnowienie też.
Przy ścieżce z kodem rabatowym — nie. Tworzysz kod promocyjny w Stripe, przypisujesz go partnerowi w PolyReach i każda płatność z tym kodem jest przypisana, łącznie z odnowieniami. Poza PolyReach ruszasz wyłącznie ekrany ustawień: tworzysz kod promocyjny w Stripe i wklejasz z powrotem jeden adres webhooka. Bez SDK, bez wdrożenia, bez code review. Linki polecające i pytanie „skąd o nas wiesz?” to opcjonalne dodatki: tag script i jedna linijka w checkoucie.
Jedno i drugie odwraca się automatycznie. Zwrot tworzy ujemny wpis lustrzany wobec pierwotnej prowizji i dziedziczy jej okres ochronny, więc oba wpisy się zerują. Spór w Stripe dopasowujemy zarówno po payment intent, jak i po identyfikatorze faktury, bo obiekt sporu nigdy nie niesie faktury — bez tego chargeback na subskrypcji nie odwróciłby niczego. Prowizje czekają dodatkowo w okresie ochronnym (domyślnie 30 dni), zanim staną się wypłacalne, więc większość zwrotów rozlicza się, zanim cokolwiek jest należne.
Nie — celowo. PolyReach to warstwa atrybucji i księgi: wylicza dokładnie, ile jesteś winien każdemu partnerowi po okresach ochronnych i clawbackach. Płacisz przelewem, PayPalem albo czymkolwiek innym, a potem klikasz „Oznacz jako opłacone”. Bez KYC, bez Stripe Connect, bez odpowiedzialności platformy i bez Twoich pieniędzy na cudzym koncie.
Tak, w tej samej księdze. Mobile działa na RevenueCat (App Store i Google Play) albo Adapty: aplikacja pyta, kto polecił użytkownika, ustawia jeden atrybut subskrybenta, a od tej pory każdy webhook zakupu, odnowienia i zwrotu niesie go dalej. Bez deep linków, bez fingerprintingu, bezpiecznie dla recenzji App Store. Apple nie ma pola na kod rabatowy w procesie zakupu, więc na mobile pewną ścieżką jest ankieta — kody ofertowe App Store można przypisać partnerowi jako dodatkowy, deterministyczny sygnał.
Każda prowizja wynika ze zdarzenia wysłanego przez Twojego dostawcę płatności i każde takie zdarzenie widzisz na liście: typ zdarzenia u dostawcy, kwotę, walutę, partnera, któremu je zaksięgowano, i sygnał, który je przypisał. Salda sumujemy z księgi, zamiast je przechowywać, walut nigdy nie mieszamy, a zdarzenia z sandboxa są oznaczone i trzymane poza realnymi saldami. Twój partner czyta te same liczby co Ty, z tych samych wierszy.
Prywatny portal pod magic linkiem: salda oczekujące, do wypłaty i wypłacone w podziale na waluty, liczbę zaksięgowanych subskrybentów, pojedyncze wpisy prowizji i clawbacków, historię wypłat oraz Twój brief promocyjny z materiałami, które wgrałeś. Tylko do odczytu, bez rejestracji, bez danych Twoich klientów — a link możesz w każdej chwili unieważnić albo wygenerować od nowa.
Tak. Program ambasadorski PolyReach działa na PolyReach — 30% od każdej płatności za subskrypcję, cyklicznie, z tym samym 30-dniowym okresem ochronnym, który dostaje każdy founder. Ogłoszenie jest w naszym marketplace partnerów, w którym możesz umieścić też swój program, jeśli chcesz, żeby twórcy Cię znaleźli.
Tak. Stripe Checkout w trybie płatności jednorazowej jest wyceniany, przypisywany po kodzie rabatowym lub linku polecającym i cofany przy zwrocie dokładnie tak samo jak płatność subskrypcyjna — partner po prostu zarabia raz na sprzedaż, a nie na odnowieniach. Ustaw „Co sprzedaje ten program” na zakupy jednorazowe, a każda powierzchnia widziana przez partnera (ogłoszenie w katalogu, panel partnera, e-maile) mówi to uczciwie, zamiast obiecywać odnowienia, których nigdy nie będzie.
© 2026 PolyReach. Wszelkie prawa zastrzeżone.
contact@polyreach.app