29 paź 2025·7 min
Projekt systemu kredytów za polecenia dla subskrypcji SaaS
Projekt systemu kredytów za polecenia dla SaaS: śledź polecenia, blokuj nadużycia i stosuj kredyty do subskrypcji z jasnymi zasadami i audytowalnym rejestrem.
Projekt systemu kredytów za polecenia dla SaaS: śledź polecenia, blokuj nadużycia i stosuj kredyty do subskrypcji z jasnymi zasadami i audytowalnym rejestrem.
Program kredytów za polecenia to funkcja rozliczeniowa, nie funkcja płatności. Nagroda to kredyt na koncie, który zmniejsza przyszłe należności (lub wydłuża czas subskrypcji). To nie są pieniądze przelane na konto bankowe, nie są to karty podarunkowe ani obietnica, że ktoś „dostanie wypłatę” później.
Dobry system odpowiada na jedno pytanie za każdym razem: „Dlaczego następna faktura tego konta jest mniejsza?” Jeśli nie potrafisz tego wyjaśnić w jednym lub dwóch zdaniach, pojawią się zgłoszenia do wsparcia i spory.
System kredytów za polecenia składa się z trzech części: ktoś zaprasza nowego klienta, jasne zasady decydują kiedy to zaproszenie się liczy (konwersja), a kredyty są naliczane i stosowane do przyszłych faktur subskrypcyjnych.
Czym nie jest: wypłatą gotówkową, niejasną zniżką która zmienia liczby bez zapisu, ani systemem punktowym, który nigdy nie łączy się z fakturami.
Kilka zespołów zależy od tych szczegółów. Osoby polecające chcą widzieć co zarobili i kiedy to się zastosuje. Poleceni użytkownicy chcą wiedzieć co dostają i czy to wpływa na ich plan. Wsparcie musi szybko rozwiązać „mój kredyt zniknął”. Finanse potrzebują sum zgodnych z fakturami i możliwych do audytu.
Przykład: Sam poleca Priyę. Priya zaczyna płatny plan. Sam zarabia $20 w kredytach, które zmniejszają jego następną fakturę o maksymalnie $20. Jeśli następny rachunek Sama wyniesie $12, pozostałe $8 zostaje jako kredyt na później, z jasnym zapisem skąd pochodzi.
Sukces to nie tylko „więcej poleceń”. To przewidywalne rozliczenia i mniej kłótni. Wiesz, że to działa, gdy salda kredytów da się łatwo wyjaśnić, faktury zgadzają się z księgą, a wsparcie odpowiada na pytania bez zgadywania lub ręcznych poprawek.
Program poleceń brzmi prosto, aż pojawią się pierwsze zgłoszenia: „Dlaczego nie dostałem kredytów?” Większość pracy to polityka, nie kod.
Zacznij od triggera. „Wysłano zaproszenie” to za wcześnie. „Zarejestrowano” łatwo jest nadużyć przez konta jednorazowe. Popularne kompromisowe rozwiązanie to „kwalifikowana konwersja”: weryfikacja e-mail + pierwsza opłacona faktura, albo pierwsza udana płatność po okresie próbnym. Wybierz jeden trigger i trzymaj się go, aby księga pozostała czysta.
Następnie ustal wartość i limity. Kredyty powinny wydawać się realne, ale nie stać się maszynką do nieograniczonych zniżek. Zdecyduj, czy dajesz stałą kwotę (np. $20 kredytu) czy procent faktury, i nałóż limit, który potrafisz wyjaśnić w jednym zdaniu.
Decyzje, które zapobiegają większości niejasności później, to:
Zasady kwalifikowalności mają większe znaczenie niż ludzie się spodziewają. Jeśli liczą się tylko płatne plany — powiedz to. Jeśli niektóre regiony są wyłączone (podatek, zgodność, promocje) — powiedz to. Jeśli plany roczne kwalifikują, a miesięczne nie, powiedz to. Dla platformy takiej jak Koder.ai z wieloma poziomami zdecyduj wcześniej, czy upgrade z darmowego na pro kwalifikuje i czy umowy enterprise obsługiwane są ręcznie.
Spisz teksty widoczne dla użytkownika zanim wypuścisz funkcję. Jeśli nie potrafisz wyjaśnić każdej reguły w dwóch krótkich zdaniach, użytkownicy jej nie zrozumieją. Trzymaj ton stanowczy, ale spokojny: „Możemy wstrzymać kredyty w przypadku podejrzanej aktywności” jest jaśniejsze (i mniej wrogie) niż długa lista gróźb.
Wybierz jeden główny identyfikator i traktuj wszystko inne jako dowód wspierający. Najczystsze opcje to token linka polecającego (łatwy do udostępnienia), krótki kod (łatwy do wpisania) oraz zaproszenie wysłane na konkretny e-mail (najlepsze dla bezpośrednich zaproszeń). Wybierz jedno jako źródło prawdy, aby atrybucja była przewidywalna.
Złap ten identyfikator jak najwcześniej i noś go przez całą ścieżkę. Token linku zwykle rejestruje się na stronie docelowej, zapisuje w first-party storage, a potem przesyła przy rejestracji. W mobilu przekaż go przez proces instalacji aplikacji, gdy to możliwe, ale zakładaj, że czasem go stracisz.
Śledź niewielki zestaw zdarzeń zgodny z regułami biznesowymi. Jeśli celem jest „czy to stało się płacącym klientem” (a nie tylko „czy kliknął”), wystarczy minimalny zestaw:
referral_click (token widziany)account_signup (utworzono nowe konto)account_verified (e-mail/telefon zweryfikowany)first_paid_invoice (pierwsza udana płatność)qualification_locked (konwersja zaakceptowana i już się nie zmienia)Zmiany urządzeń i zablokowane ciasteczka są normalne. Aby sobie z tym poradzić bez nachalnego śledzenia, dodaj krok roszczenia (claim) podczas rejestracji: jeśli użytkownik przychodzi z tokenem, dołącz go do nowego konta; jeśli nie — pozwól wpisać krótki kod polecający raz podczas onboardingu. Jeśli oba są obecne, zachowaj najwcześniej złapane jako główne i zapisz drugi jako dowód dodatkowy.
Na koniec — trzymaj prostą oś czasu dla każdego polecenia, którą wsparcie przeczyta w minutę: osoba polecająca, konto polecone (gdy znane), aktualny status i ostatnie znaczące zdarzenie z znacznikami czasu. Kiedy ktoś zapyta „dlaczego nie dostałem kredytów?”, możesz odpowiedzieć faktami typu „rejestracja była, ale pierwsza opłacona faktura nigdy nie nastąpiła” zamiast zgadywać.
Programy poleceń zwykle zawodzą, gdy model danych jest niejasny. Wsparcie pyta „kto kogo polecił?” Rozliczenia pytają „czy kredyt już został wydany?” Jeśli nie potrafisz odpowiedzieć bez grzebania w logach, model wymaga dopracowania.
Przechowuj relację polecenia jako rekord pierwszorzędny, nie jako pochodną zgadywaną z kliknięć.
Proste, możliwe do debugowania ustawienie wygląda tak:
id, referrer_user_id, referred_user_id, created_at, source (invite link, coupon, manual), status, status_updated_atreferral_id, invite_code_id or campaign_id, first_seen_ip_hash, first_seen_user_agent_hashworkspace_id, owner_user_id, created_atworkspace_id, user_id, role, joined_atUtrzymuj tabelę referrals małą. Wszystko, czego pożałujesz później (surowe IP, pełny user agent, imiona), powinno być unikane lub przechowywane tylko jako krótkotrwałe hashe z jasną polityką retencji.
Uczyń statusy explicite i wzajemnie wykluczające: pending (zarejestrowano, jeszcze nie kwalifikuje), qualified (spełniono reguły), credited (przyznano kredyt), rejected (nie przeszedł kontroli), reversed (kredyt cofnięty po zwrocie/chargebacku).
Zdecyduj o kolejności priorytetów raz, potem wymuś ją w bazie tak, żeby aplikacja nie przyznała kredytu dwa razy. Minimum:
referred_user_id)credited na polecone kontoreferral_idJeśli obsługujesz zespoły, zdecyduj czy polecenie przypisuje się do osobistej rejestracji, czy do tworzenia workspace. Nie próbuj robić obu naraz. Praktyczne podejście to przypiąć polecenie do konta użytkownika, a warunki kwalifikowalności sprawdzają, czy ten użytkownik (lub jego workspace) stał się płacącym subskrybentem.
Jeśli chcesz mniej błędów rozliczeniowych i mniej zgłoszeń, użyj księgi (ledger), a nie jednego pola „saldo”. Pole saldo można nadpisać, zaokrąglić lub zaktualizować dwa razy. Księga to historia wpisów, które zawsze możesz zsumować.
Utrzymuj typy wpisów ograniczone i jednoznaczne: earn (przyznanie), spend (użyte na fakturze), expire (wygaśnięcie), reversal (cofnięcie), manual adjustment (ręczna korekta z notatką i zatwierdzającym).
Każdy wpis powinien być czytelny dla inżynierów i wsparcia. Przechowuj spójne pola: amount, credit type (nie „USD”, jeśli kredyty nie są gotówką), tekst powodu, zdarzenie źródłowe (np. referral_signup_qualified), identyfikatory źródłowe (użytkownik, polecone konto, subskrypcja lub faktura), znaczniki czasu i created_by (system lub admin).
Idempotencja ma większe znaczenie niż się wydaje. Ten sam webhook lub zadanie w tle może wykonać się dwa razy. Wymagaj unikalnego klucza idempotencyjnego dla zdarzenia źródłowego, aby móc bezpiecznie ponawiać bez wielokrotnego przyznawania kredytów.
Uczyń to zrozumiałym dla użytkownika. Kiedy ktoś pyta „dlaczego dostałem 20 kredytów?” powinieneś pokazać, które polecenie to wywołało, kiedy wpis się pojawił, czy wygasa i czy nastąpiło późniejsze cofnięcie. Jeśli znajomy awansuje plan, dodajesz wpis earn powiązany z tym zdarzeniem. Jeśli płatność zostanie zwrócona, dodajesz wpis reversal związany ze zdarzeniem zwrotu.
Zakładaj, że większość ludzi jest uczciwa, a kilku spróbuje oczywistych trików. Celem jest zatrzymanie łatwych oszustw, jasne reguły i unikanie blokowania prawdziwych klientów korzystających z tej samej sieci Wi‑Fi czy wspólnej metody płatności.
Zacznij od twardych blokad, które możesz uzasadnić. Nie przyznawaj kredytów, gdy referrer i polecony są oczywiście tą samą osobą — ten sam user ID, ten sam zweryfikowany e-mail lub ten sam fingerprint metody płatniczej. Reguły oparte na domenie e-mail mogą pomagać, ale trzymaj je wąsko. Blokowanie wszystkich rejestracji z domeny firmy może zaszkodzić legalnym zespołom.
Dodaj lekkie wykrywanie pętli i masowych rejestracji. Nie potrzebujesz idealnego scoringu fraudowego od pierwszego dnia. Kilka silnych sygnałów złapie większość nadużyć: wiele rejestracji z tego samego urządzenia w krótkim oknie, częste użycie z tego samego zakresu IP w minutach, ta sama karta używana do wielu „nowych” kont, dużo kont które nigdy nie weryfikują e-maila, lub szybkie wzorce anuluj-i-powtórz po zastosowaniu kredytów.
Wymagaj akcji kwalifikującej przed możliwością użycia kredytów (np. zweryfikowany e-mail plus opłacona faktura, opcjonalnie po krótkim okresie karencji). To zatrzymuje boty i churn darmowego poziomu generujący szum.
Dodaj limity i cooldowny wokół linków polecających i realizacji kredytów, ale trzymaj je dyskretne do czasu użycia. Jeśli link użyty jest 20 razy w godzinę z tej samej sieci, wstrzymaj przyznawanie nagród i oznacz do sprawdzenia.
Gdy interweniujesz, zachowaj doświadczenie spokojne. Oznacz kredyty jako pending dopóki płatność się nie rozliczy, pokaż prosty powód opóźnienia (unikaj oskarżeń), zaoferuj łatwy kontakt z wsparciem i kieruj przypadki brzegowe do ręcznej weryfikacji zamiast automatycznego banowania.
Przykład: zespół startupowy dzieli jeden adres IP. Trzech współpracowników rejestruje się przez to samo polecenie tego samego dnia. Przy kwalifikacji po opłaceniu i podstawowym cooldownie nadal otrzymają kredyty po wystawieniu faktur, podczas gdy botopodobne zrywy zostaną wstrzymane do przeglądu.
Programy poleceń wydają się proste, dopóki pieniądze nie pójdą „w złą stronę”: zwrot, chargeback, faktura unieważniona lub konto zmienia właściciela. Jeśli zaprojektujesz te przypadki wcześniej, unikniesz złych użytkowników i długich wątków wsparcia.
Traktuj kredyty jako coś, co się zarabia na podstawie wyników płatniczych, nie tylko rejestracji. Następnie zdefiniuj politykę cofnięć powiązaną ze zdarzeniami billingowymi.
Zasady, które wsparcie potrafi wyjaśnić:
Częściowe zwroty to miejsce, gdzie zespoły się gubią. Wybierz jedno podejście i trzymaj się go: cofnięcie proporcjonalne (cofnij 30% kredytu przy 30% zwrocie) lub pełne cofnięcie (każdy zwrot cofa cały kredyt). Proporcjonalne jest sprawiedliwsze, ale trudniejsze do wyjaśnienia i testowania. Pełne cofnięcie jest prostsze, ale może wydawać się surowe.
Przejścia z trialu do płatności też powinny być jawne. Popularne podejście to trzymać kredyty w stanie pending podczas trialu, a zafiksować je po pierwszej pomyślnej płatności (opcjonalnie po krótkim okresie karencji).
Ludzie zmieniają e-maile, scalają konta lub przechodzą z użycia osobistego do workspace zespołowego. Zdecyduj co „podąża” za osobą, a co za płacącym kontem. Jeśli subskrybentem jest workspace, kredyty często należą do workspace, nie do członka, który może odejść.
Jeśli wspierasz scalanie kont lub transfer własności zespołu, zapisuj zdarzenie korekty zamiast przepisywać historię. Każde cofnięcie lub ręczna korekta powinna zawierać notatkę przyjazną dla wsparcia, np. "Chargeback on invoice 10482" lub "Workspace owner transfer approved by support." Na platformach takich jak Koder.ai, gdzie kredyty stosują się do subskrypcji, takie notatki pozwalają odpowiedzieć na „dlaczego moje kredyty się zmieniły?” jednym wyszukaniem.
Najtrudniejsza część to nie śledzenie poleceń. To sprawienie, by kredyty zachowywały się tak samo przy odnowieniach, upgrade'ach, downgrade'ach i podatkach.
Najpierw zdecyduj, gdzie można używać kredytów. Niektóre zespoły stosują je tylko do następnej nowej faktury. Inne pozwalają używać kredytów na dowolną otwartą (nieopłaconą) fakturę. Wybierz jedną regułę i pokaż ją w UI, aby użytkownicy się nie zdziwili.
Następnie ustal kolejność operacji. Przewidywalne podejście to: oblicz opłaty subskrypcji (włącznie z proration), zastosuj zniżki, oblicz podatek, potem zastosuj kredyty na końcu. Stosowanie kredytów na końcu utrzymuje logikę podatkową spójną i unika sporów o to, czy kredyty obniżają podstawę opodatkowania w danym kraju. Jeśli prawo/podatek wymaga innej kolejności, udokumentuj to i napisz testy.
Proration to miejsce, gdzie pojawiają się błędy rozliczeniowe. Jeśli ktoś awansuje w połowie cyklu, stwórz pozycję proration (opłata lub kredyt) i traktuj ją jak każdą inną pozycję. Następnie stosuj kredyty do sumy faktury, a nie do pojedynczych pozycji.
Utrzymuj zasady fakturowania ścisłe:
Przykład: użytkownik awansuje w połowie miesiąca i dostaje $12 proration charge. Suma faktury po zniżkach i podatkach to $32. Jeśli ma $50 kredytów poleceniowych, zastosujesz $32, ustawisz należność faktury na $0 i zostawisz $18 na następne odnowienie.
Traktuj program poleceń jako małą funkcję billingową, nie widget marketingowy. Celem jest nudna spójność: każdy kredyt ma powód, znacznik czasu i jasną ścieżkę do następnej faktury.
Wybierz jedno zdarzenie konwersji i jedną regułę przyznawania. Na przykład: polecenie kwalifikuje się tylko wtedy, gdy zaproszony użytkownik zostanie płacącym subskrybentem i pierwsza płatność się zaksięguje.
Zbuduj MVP wokół ścieżki end-to-end: złap token lub kod przy rejestracji, uruchom kwalifikację gdy płatność powiedzie (nie gdy użytkownik wpisze kartę), zapisz wpis w księdze z unikalnym kluczem idempotencyjnym i stosuj kredyty do następnej faktury w przewidywalnej kolejności.
Zdecyduj wcześnie, co jest źródłem prawdy. Albo twój dostawca rozliczeń jest źródłem prawdy i aplikacja je odzwierciedla, albo twoja wewnętrzna księga jest źródłem prawdy, a rozliczenia jedynie otrzymują „zastosuj X kredytów na tej fakturze.” Mieszanie obu zwykle generuje zgłoszenia „moje kredyty zniknęły”.
Dodaj narzędzia administracyjne zanim rozbudujesz reguły poleceń. Wsparcie musi wyszukiwać po użytkowniku, kodzie polecającym i fakturze, a potem widzieć oś czasu: invite, signup, qualification, kredyty przyznane, kredyty użyte i cofnięcia. Dołącz ręczne korekty i zawsze wymagaj krótkiej notatki.
Potem dodaj UX dla użytkownika: stronę poleceń, linię statusu dla każdego zaproszenia (pending, qualified, credited) oraz historię kredytów zgodną z fakturami.
Na koniec dodaj monitoring: alerty przy nagłych skokach poleceń, wysokim wskaźniku cofnięć (zwroty lub chargebacki) i nietypowych wzorcach jak wiele kont z tej samej metody płatniczej. To utrzymuje kontrolę nadużyć bez krzywdzenia normalnych użytkowników.
Przykład: jeśli ktoś udostępnia polecenie Koder.ai swojemu zespołowi, powinien zobaczyć kredyty pojawiające się dopiero po pierwszej pomyślnej płatności i te kredyty powinny automatycznie pomniejszyć następne odnowienie, a nie wymagać ręcznego kuponu.
Większość programów poleceń zawodzi w obszarze billingowym, nie marketingowym. Najszybsza droga do zgłoszeń to sprawić, by kredyty wydawały się nieprzewidywalne: użytkownicy nie wiedzą, dlaczego je dostali, kiedy się zastosują lub dlaczego faktura wygląda inaczej.
Częsta pułapka to budowanie zanim reguły są jasne. Jeśli „kwalifikowane polecenie” jest niejednoznaczne (rozpoczęcie trialu, pierwsza płatność, utrzymanie płatnego planu przez 30 dni), skończysz negocjować kredyty przypadek po przypadku i wydawać zwroty, aby naprawić sytuacje.
Innym częstym problemem jest używanie jednego mutowalnego pola „saldo kredytów”. Wygląda to prosto, dopóki nie masz powtórzeń, zwrotów, zmian planów lub ręcznych korekt. Wtedy liczba zaczyna odbiegać i nie można wyjaśnić skąd się wzięła.
Idempotencja też jest często pomijana. Dostawcy płatności powtarzają webhooki, pracownicy retry'ują zadania, użytkownicy klikają dwa razy. Jeśli akcja „przyznaj kredyt” nie jest idempotentna, wygenerujesz duplikaty i zauważysz to dopiero, gdy przychody będą niezgodne.
Matematyka kredytów też może być błędna mimo że sumy się zgadzają. Stosowanie kredytów przed podatkiem lub ignorowanie zasad proration daje faktury, które nie zgadzają się z oczekiwaniami systemu płatniczego. To prowadzi do niezgodnych paragonów, nieudanych płatności i bolesnej rekonsyliacji.
Kontrole fraudowe mogą też być zbyt surowe. Blokowanie po IP, urządzeniu lub domenie bez ścieżki odwoławczej zatrzymuje prawdziwe polecenia (współlokatorzy, współpracownicy, zespoły w tej samej sieci) i cicho hamuje wzrost.
Pięć czerwonych flag do obserwacji:
invite_id, conversion_id) zapobiegającego duplikatomPrzykład: użytkownik Koder.ai na planie Pro awansuje w połowie miesiąca, zarabia kredyt poleceniowy, potem downgrade'uje plan. Jeśli system używa jednego pola salda i stosuje kredyty przed proration, następna faktura może wyglądać dziwnie nawet gdy suma jest zbliżona. Księga plus stała kolejność zastosowania zapobiegają przekształceniu tego w długi wątek wsparcia.
Zanim wypuścisz funkcję, przeprowadź kilka kontroli które wyłapią większość problemów billingowych i wsparciowych wcześnie.
Przykład: Maya zaprasza Noaha. Noah rejestruje się z zaproszenia Mai, zaczyna trial, potem awansuje na Pro i płaci $30. Twój system oznacza tę fakturę jako kwalifikującą i tworzy wpis kredytowy dla Mai (np. $10 kredytu subskrypcyjnego).
Przy następnym odnowieniu Mai, jej subtotal faktury to $30. Twój krok rozliczeniowy stosuje do $10 z dostępnych kredytów, więc faktura pokazuje $30 subtotal, -$10 kredyt i $20 do zapłaty. Księga Mai ma jeden wpis earn (+$10) i jeden wpis spend (-$10 zastosowane do faktury #1234).
Jeśli Noah później zażąda zwrotu za swoją pierwszą płatność, system doda wpis reversal, który usuwa przyznany Mai kredyt (lub wprowadzi odpowiadający debet). Jeśli jakiś kredyt został już użyty, następna faktura obciąża różnicę zamiast przepisywać historię.
Dwa następne kroki, które utrzymają tempo bez łamania zaufania:
Zrób prototyp pełnego przepływu w krótkim dokumencie planistycznym: atrybucja, kwalifikacja, wpisy księgi, zastosowanie do faktur i cofnięcia.
Przetestuj stałe scenariusze w sandboxie: trial→paid, zwrot po użyciu kredytu, upgrade i downgrade w połowie cyklu oraz ręczna korekta administracyjna.
Jeśli chcesz działać szybko bez utraty kontroli nad logiką rozliczeń, Koder.ai zawiera Planning Mode plus snapshots and rollback, które pomogą iterować nad przepływem poleceń aż matematyka faktur będzie stała. Możesz przeprowadzić całą pracę wewnątrz platformy na koder.ai, a potem wyeksportować kod gdy będziesz gotowy.
Kredyty za polecenia zmniejszają to, co jesteś winien na przyszłych fakturach (lub wydłużają czas subskrypcji).
To nie jest gotówka przelana na konto bankowe, nie są to karty podarunkowe ani obietnica wypłaty pieniężnej. Traktuj je jak kredyt sklepowy, który pojawia się w rozliczeniach.
Częstym domyślnym wyborem jest: polecenie kwalifikuje się po tym, jak polecony użytkownik ma pierwszą pomyślną opłaconą fakturę (często po weryfikacji e-mail, czasem po krótkim okresie karencji).
Unikaj kwalifikowania na podstawie samego „wysłania zaproszenia” lub samego „rejestracji”, bo to łatwo nadużyć i trudniej to bronić w sporach.
Użyj jednego źródła prawdy, zwykle tokenu w linku polecającym lub krótkiego kodu.
Dobre praktyki:
Używaj wyraźnych, wzajemnie wykluczających się statusów, aby wsparcie mogło szybko odpowiedzieć:
pending: rejestracja istnieje, jeszcze nie kwalifikujequalified: spełnione reguły (np. pierwsza opłacona faktura)Jedno pole „saldo” łatwo się nadpisuje, powtarza lub podwójnie aktualizuje i staje się nieaudytowalny.
Księga to lista wpisów, którą zawsze możesz zsumować:
To sprawia, że rozliczenia są wyjaśnialne i możliwe do debugowania.
Spraw, by akcja „przyznaj kredyt” była idempotentna, używając unikalnego klucza dla zdarzenia źródłowego (np. ID pierwszej opłaconej faktury).
Jeżeli ten sam webhook lub zadanie uruchomi się dwukrotnie, drugi przebieg nie powinien nic zmieniać zamiast przyznawać podwójny kredyt.
Zacznij od prostych, łatwych do wyjaśnienia blokad:
Następnie dodaj lekkie kontrole nadużyć bez karania normalnych użytkowników:
Zdefiniuj jasną politykę cofania związaną ze zdarzeniami billingowymi:
Dla częściowych zwrotów wybierz jedno podejście i się go trzymaj:
Przewidywalny domyślny porządek to:
Zasady redukujące nieporozumienia:
Minimalne MVP, które nadal jest obsługiwalne:
Potem dodaj UI i narzędzia administracyjne zanim rozbudujesz reguły nagród.
creditedrejected: nie przeszedł kontroli lub niekwalifikujereversed: kredyt cofnięty po zwrocie/chargebackuPrzechowuj też znacznik czasu ostatniej zmiany statusu.