Nagrody i wypłaty

Dlaczego to ważne

Nagrody i wypłaty wymagają dodatku VDP Add-on (49 USD/mies.). Odblokowuje on pełny proces wypłat nagród, niezmienną księgę finansową i zarządzanie dokumentami podatkowymi opisane na tej stronie.

Prawidłowa obsługa wypłat to zarówno kwestia utrzymania badaczy, jak i obowiązek zgodności regulacyjnej. Ręczne przelewy PayPal bez pobrania formularzy W-8BEN (osoby spoza USA) lub W-9 (osoby z USA) tworzą bezpośrednie ryzyko podatkowe wobec IRS dla Twojej firmy. Każda płatność na rzecz badacza stanowi zdarzenie podatkowe podlegające zgłoszeniu do urzędu, a brak dokumentacji podatkowej przenosi odpowiedzialność na Ciebie. Proces wypłat w Kit rozwiązuje ten problem, uzależniając wypłaty od konfigurowalnej checklisty gotowości obejmującej weryfikację dokumentów podatkowych.

Niezmienna księga finansowa jest głównym artefaktem dowodowym SOC 2 dla kontroli finansowych Twojego programu ujawniania podatności. Każde zatwierdzenie nagrody, każda wypłata nagrody i każda czynność dotycząca dokumentu podatkowego jest rejestrowana wraz z wykonawcą, znacznikiem czasu i kwotą. Audytorzy mogą zweryfikować pełny łańcuch kontroli — od rozwiązania zgłoszenia po potwierdzenie płatności — w ramach jednego eksportu.

Macierz nagród

Macierz nagród przypisuje przedziały kwotowe do poziomów ważności CVSS. Skonfiguruj ją w VDP > Program Settings > Bounty Matrix. Gdy członek zespołu oceni zgłoszenie za pomocą CVSS, sugerowany przedział nagrody jest automatycznie pobierany z macierzy i wstępnie wypełniany w formularzu zatwierdzenia.

Przedziały nagród są wyświetlane na publicznej stronie polityki ujawniania, aby badacze wiedzieli, czego się spodziewać przed przesłaniem zgłoszenia. Taka przejrzystość zmniejsza liczbę sporów i wyznacza jasne oczekiwania.

W przypadku programów opartych wyłącznie na uznaniu zostaw wszystkie poziomy na wartości 0 USD. Badacze zobaczą na stronie polityki komunikat „recognition only” zamiast kwot.

Pełne szczegóły konfiguracji macierzy opisano w Configuring Your Program.

Dwie drogi do kwoty

Do zatwierdzonej nagrody prowadzą dwie ścieżki i obie kończą się tym samym nieodwracalnym działaniem.

Ścieżka	Jak działa	Kiedy jej użyć
Zatwierdzenie bezpośrednie	Administrator wpisuje kwotę i ją zatwierdza. Jeden krok. Opisane poniżej.	Kwota jest oczywista — zgłoszenie niskiej ważności na dole swojego przedziału macierzy, znalezisko na granicy duplikatu, cokolwiek, o co nikt nie będzie się spierał.
Najpierw propozycja, potem zatwierdzenie	Dowolny członek zespołu kładzie kwotę na stole z uzasadnieniem. Koledzy zgadzają się albo sprzeciwiają z kwotami alternatywnymi. Potem zatwierdza administrator.	Kwota jest sporna, nietypowo wysoka albo tworzy precedens, z którego przy następnym zgłoszeniu ktoś Cię rozliczy.

Propozycje są doradcze i niewidoczne dla badacza: nic w propozycji nie powiadamia badacza, nie zapisuje niczego w księdze i nie rusza pieniędzy. Niczego też nie blokują — administrator może zatwierdzić bezpośrednio w każdej chwili, niezależnie od tego, czy propozycja jest otwarta. Zobacz Propozycje nagród i głosowanie zespołu.

Zatwierdzanie nagrody

Administratorzy mogą zatwierdzić nagrodę w dowolnym momencie, zanim zgłoszenie osiągnie status Paid. Dobrą praktyką jest poczekanie, aż zgłoszenie zostanie zwalidowane — najlepiej rozwiązane — żeby kwota odzwierciedlała potwierdzoną i ocenioną podatność.

Żeby zatwierdzić nagrodę:

1. Otwórz stronę szczegółów zgłoszenia
2. Kliknij Approve Bounty
3. Wypełnij formularz zatwierdzenia

Pole	Wymagane	Opis
Amount	Tak	Kwota nagrody, wstępnie wypełniona na podstawie macierzy nagród i poziomu ważności CVSS zgłoszenia.
Currency	Tak	Domyślnie USD. Musi odpowiadać walucie skonfigurowanej w programie.
Notes	Nie	Wewnętrzne notatki widoczne tylko dla Twojego zespołu. Szyfrowane w spoczynku.

Zatwierdzenie wymaga jawnego przesłania formularza — żadna kwota nie zostaje zatwierdzona, dopóki nie zapiszesz formularza. Po zatwierdzeniu:

• Wpis bounty_approved zostaje dodany do niezmiennej księgi
• Badacz otrzymuje powiadomienie za pośrednictwem szablonu e-mail Nagroda zatwierdzona
• Każda otwarta propozycja nagrody na zgłoszeniu zostaje zamknięta jako zastąpiona, a jej głosy zachowane jako zapis

Ostatni punkt warto zapamiętać, jeśli zespół korzysta z propozycji: bezpośrednie zatwierdzenie przy otwartej propozycji wypłaca kwotę, którą wpisano, a nie tę, o której dyskutował zespół — i kończy naradę. Gdy chcesz zatwierdzić proponowaną kwotę, zrób to z zakładki Nagroda na zgłoszeniu.

Cofanie nagrody

Odrzucenie zgłoszenia z zatwierdzoną nagrodą automatycznie ją cofa. Okno odrzucania wyświetla ostrzeżenie z kwotą, osobą zatwierdzającą i datą zatwierdzenia, a przycisk zatwierdzenia zmienia się na Dismiss & revoke $X bounty. Po cofnięciu:

• Wpis bounty_revoked zostaje dodany do niezmiennej księgi jako obciążenie — sumy zatwierdzonych i oczekujących nagród w księdze pomniejszają się o niego. Metadane wpisu rejestrują przyczynę odrzucenia, pierwotną osobę zatwierdzającą wraz z datą zatwierdzenia oraz ówczesny status wypłaty nagrody.
• E-mail o odrzuceniu informuje badacza, że wcześniej zatwierdzona nagroda została wycofana i nie zostanie wypłacona; standardową ścieżką odwoławczą pozostaje procedura odwołania. W portalu badacza zamiast karty nagrody pojawia się adnotacja „wycofana”.
• Karma przyznana za nagrodę zostaje odwrócona zdarzeniem karmy „Bounty Revoked”.

Obowiązują dwa zabezpieczenia:

• Nagrody, której wypłata ma status Completed, nigdy nie można cofnąć — co wypłacone, pozostaje wypłacone.
• Wypłata nagrody w toku (status Pending lub Processing) blokuje odrzucenie. Najpierw oznacz wypłatę jako nieudaną albo pozwól jej się zakończyć. Jako nieudaną można oznaczyć tylko wypłatę w statusie Processing — Pending to stan przejściowy trwający ułamek sekundy (zobacz Statusy wypłat), a nie stan, na którym da się cokolwiek zrobić.

Cofnięcie odrzucenia nie przywraca nagrody. Po ponownej walidacji zgłoszenia zatwierdź ręcznie nową nagrodę — interfejs zespołu wyświetla odpowiednie przypomnienie.

Proces wypłat nagród

Przejdź do VDP > Disbursements, aby zarządzać wypłatami nagród. Kolejka otwiera się na zestawie zakładek, dzięki czemu zawsze widzisz ten fragment pracy, który Cię interesuje: Ready, Blocked, With Finance, Paid, Failed i All. Domyślnie lądujesz na zakładce Ready.

Na górze umieszczono cztery kafelki podsumowania:

• Ready — zgłoszenia z zatwierdzoną nagrodą, dla których nie utworzono jeszcze wypłaty, gdzie checklista gotowości jest spełniona i środki można od razu przelać.
• Blocked — zgłoszenia z zatwierdzoną nagrodą, dla których nie utworzono jeszcze wypłaty, gdzie checklista gotowości nie jest jeszcze spełniona.
• In Progress — wypłaty już przekazane do finansów i czekające na potwierdzenie.
• Oldest Waiting — najstarsza pojedyncza niezapłacona zatwierdzona nagroda wciąż w toku. Pokazuje, ile dni czeka, badacza oraz kwotę, a także prowadzi bezpośrednim odnośnikiem do zakładki, w której znajduje się dany wiersz, żebyś mógł od razu zareagować.

Kwoty w różnych walutach nigdy nie są sumowane. Każdy kafelek pokazuje kwoty osobno dla każdej waluty, więc program płacący w USD i EUR widzi obie sumy obok siebie, zamiast bezsensownej łącznej liczby.

Zakładki Ready i Blocked to dwie połowy tego samego zbioru — zgłoszeń z zatwierdzoną nagrodą, ale bez utworzonej jeszcze wypłaty — podzielone według tego, czy checklista gotowości jest spełniona.

Checklista gotowości

Zanim wypłata nagrody może zostać zrealizowana, badacz musi spełnić wymagania checklisty gotowości. Wszystkie trzy elementy są konfigurowalne w ustawieniach wypłat programu:

• Dane do wypłaty przesłane — badacz wprowadził dane płatności (przelew bankowy, PayPal lub inna metoda) za pośrednictwem portalu badacza
• Umowa zaakceptowana — badacz zaakceptował umowę uczestnictwa w Twoim programie (jeśli program tego wymaga)
• Dokument podatkowy zweryfikowany — formularz W-8BEN lub W-9 badacza został przesłany i zweryfikowany przez Twój zespół (jeśli program wymaga dokumentów podatkowych)

Elementy nieaktywowane w ustawieniach programu są automatycznie oznaczane jako spełnione.

Checklista uzależnia wypłatę również od statusu zgłoszenia, co kontroluje opcja Require Verified Fix Before Payout w VDP > Program Settings > Payouts:

• Włączone (domyślnie) — nagrodę można wypłacić dopiero po tym, jak Twój zespół oznaczy poprawkę zgłoszenia jako zweryfikowaną. Nigdy nie płacisz za nierozwiązany błąd, ale badacze mogą czekać na wdrożenie poprawki.
• Wyłączone (płatność po walidacji) — wypłata odblokowuje się, gdy tylko zgłoszenie osiągnie status Validated, co jest normą branżową na platformach takich jak HackerOne i Bugcrowd. Badacze otrzymują płatność szybciej, a płatność jest oddzielona od zamknięcia zgłoszenia: zgłoszenie pozostaje otwarte po przelaniu pieniędzy i automatycznie zamyka się ze statusem Paid, gdy zostanie rozwiązane (lub gdy poprawka zostanie zweryfikowana). Opłaconych zgłoszeń nigdy nie można odrzucić, a weryfikacja poprawki staje się opcjonalnym krokiem QA — odnotuj ją, zanim zgłoszenie zostanie rozwiązane, w przeciwnym razie nie zostanie zarejestrowana.

Tablica ponagleń

Zakładka Blocked to tablica ponagleń: zamiast płaskiej listy zablokowanych wypłat grupuje je według badacza, więc ponaglasz daną osobę raz, a nie gonisz tego samego badacza po kilku wierszach. Anonimowe zgłoszenia, które nie mają przypisanego badacza, tworzą własną grupę „bez badacza”.

Każda grupa pokazuje:

• badacza (lub „anonimowy” w grupie bez badacza)
• ile z jego wypłat jest zablokowanych
• łączną należną kwotę, w rozbiciu na waluty
• które blokady obowiązują, w postaci plakietek blokad: Payout info, Tax document i Agreement
• ile dni czeka najstarsza wypłata w grupie

Grupy są uporządkowane najpierw według gotowości do ponaglenia — badacze, których możesz ponaglić już teraz, trafiają na górę — a następnie, w obrębie tej kolejności, według najdłuższego czasu oczekiwania.

Każda grupa podaje też, ile ponaglenie faktycznie odblokuje, w postaci liczby „odblokowuje N wypłat / $X”. Ta liczba jest celowo uczciwa: liczy tylko te zgłoszenia, w których każdy pozostały wymagany element może naprawić sam badacz (dane do wypłaty, dokument podatkowy, umowa). Zgłoszenie, które wciąż czeka na weryfikację poprawki — a to krok po stronie Twojego zespołu — nie jest liczone, bo e-mail do badacza go nie odblokuje. Liczba pokazuje, co ponaglenie naprawdę odblokuje, a nie pobożne życzenia.

Ponaglanie badacza

W zakładce Blocked kliknij Nudge przy grupie badacza, żeby wysłać temu badaczowi przypomnienie e-mailem. Ponaglanie wymaga dodatku VDP Add-on oraz uprawnienia do wypłat (disburse).

Jeden e-mail na badacza obejmuje wszystkie jego bieżące braki naraz — dane do wypłaty, dokument podatkowy oraz umowę do każdego zgłoszenia — zamiast osobnego e-maila dla każdej blokady. Badacz dostaje jedną, kompletną listę zadań.

Każda blokada w e-mailu to magic link prowadzący bezpośrednio do celu. Jedno kliknięcie uwierzytelnia badacza i przenosi go dokładnie na tę stronę, która usuwa dany brak: formularz danych do wypłaty, przesłanie dokumentu podatkowego lub umowę do konkretnego zgłoszenia. Ponieważ token jest bezstanowy, dotychczasowy magic link logowania badacza pozostaje ważny — ponaglenie nigdy go nie unieważnia.

Ponaglenia są ograniczane okresem karencji 3 dni dla każdej pary (konto, badacz). Jeśli w tym oknie już ponagliłeś danego badacza, przycisk informuje, że trwa karencja, zamiast wysłać wiadomość ponownie. Karencja działa osobno dla każdego konta: ponaglenie u jednego klienta nigdy nie wpływa na innego, nawet w przypadku badacza, który zgłasza do kilku programów.

Nudge pojawia się tylko wtedy, gdy badacz faktycznie może coś odblokować. Braki na poziomie zgłoszenia — zatwierdzenie nagrody, walidacja i weryfikacja poprawki — to zadanie Twojego zespołu i nigdy nie są przedmiotem ponaglenia; ponaglenie oferowane jest wyłącznie dla elementów, które badacz może naprawić sam.

Realizacja wypłaty

Kit nie wykonuje przelewów bankowych ani wywołań API płatności. Twój zespół obsługuje faktyczny transfer środków poza Kit (przelew bankowy, PayPal, kryptowaluty itp.). Kit śledzi cykl życia:

1. Gdy wszystkie elementy gotowości są spełnione, kliknij Initiate, aby przenieść wypłatę do statusu Processing
2. Wykonaj przelew za pośrednictwem swojego dostawcy płatności
3. Wróć do Kit i kliknij Mark as Paid — wprowadź referencję transakcji (np. identyfikator transakcji PayPal, numer potwierdzenia przelewu)
4. Wypłata przechodzi do statusu Completed, a zgłoszenie zmienia status na Paid (w programach z płatnością po walidacji zgłoszenie opłacone przed jego rozwiązaniem pozostaje otwarte i automatycznie zamyka się ze statusem Paid, gdy do tego dojdzie)

Potwierdzenie przez zespół finansowy

W większości firm osoba, która planuje płatność, pracuje w dziale finansów, a nie w bezpieczeństwie — pilnuje skrzynki w rodzaju [email protected] i nie ma konta w Kit. Przekazanie sprawy do finansów eliminuje tę lukę: Kit wysyła e-mailem zespołowi finansowemu wszystko, czego potrzebuje, żeby zaplanować płatność, a oni sami potwierdzają ją przez bezpieczny link.

Włącz tę funkcję, ustawiając Finance Email w VDP > Program Settings > Payouts. Zostaw to pole puste, żeby nadal rejestrować płatności ręcznie w Kit.

Gdy adres e-mail finansów jest skonfigurowany, kliknięcie Initiate wysyła pod ten adres również żądanie płatności zawierające:

• Odbiorcę (badacza), kwotę i metodę płatności — adresy PayPal są pokazywane w całości, a numery rachunków bankowych są maskowane do ostatnich czterech cyfr, przy czym pełne dane są dostępne tylko za linkiem potwierdzającym
• Referencję wypłaty do umieszczenia w tytule płatności, dzięki czemu uzgodnienie działa w obie strony
• Pochodzenie zatwierdzenia: kto i kiedy zatwierdził nagrodę oraz kto zainicjował wypłatę
• Bezpieczny link, ważny przez 90 dni, z dwiema czynnościami do wyboru: potwierdzeniem płatności albo zgłoszeniem, że się nie powiodła

Osoba z finansów otwiera link, widzi pełne dane płatności, realizuje płatność za pośrednictwem swojego dostawcy płatności, a następnie wprowadza referencję transakcji i swoje imię i nazwisko, żeby potwierdzić. Potwierdzenie kończy wypłatę dokładnie tak samo jak wewnętrzne Mark as Paid: wpis w księdze zostaje zapisany, zgłoszenie zmienia status na Paid, badacz otrzymuje automatyczne powiadomienie, a Twój zespół dostaje standardowe powiadomienie o zrealizowanej wypłacie. Jako osoba, która oznaczyła wypłatę jako opłaconą, występuje w nim ta osoba z finansów, która ją potwierdziła. Potwierdzenie rejestruje, kto potwierdził (imię, nazwisko i e-mail), kiedy oraz skąd (adres IP) — widoczne w wierszu wypłaty jako Confirmed by finance.

Jeśli płatność nie dojdzie do skutku, ta sama strona udostępnia pod formularzem potwierdzenia link Report a failed payment. Zgłoszenie zapisuje niepowodzenie z identycznym pochodzeniem — kto je zgłosił, kiedy i skąd — a wiersz wypłaty pokazuje je jako Payment bounced · Reported by …. Zobacz Gdy wypłata się nie powiedzie.

Kilka szczegółów wartych odnotowania:

• Odpowiedzi trafiają do człowieka. Adres reply-to w e-mailu to członek zespołu, który zainicjował wypłatę, więc pytania z finansów trafiają do kogoś, kto zna kontekst.
• Wyślij ponownie w dowolnej chwili. Wiersz wypłaty pokazuje, kiedy i dokąd wysłano żądanie, wraz z przyciskiem ponownego wysłania, który generuje świeży link.
• Wewnętrzna ścieżka pozostaje dostępna. Jeśli finanse odpowiedzą „gotowe, ref #123” e-mailem zamiast kliknąć link, Twój zespół nadal może ręcznie oznaczyć wypłatę jako opłaconą — link pokaże wtedy potwierdzenie „already recorded”.
• Link wygasa wraz z wypłatą. Po zakończeniu lub niepowodzeniu wypłaty link nie może już niczego potwierdzić ani zgłosić jako nieudane; pokazuje jedynie bieżący stan. Po niepowodzeniu zgłoszonym przez link finanse widzą własne pokwitowanie — kto zgłosił, kiedy, z jakiego powodu — oraz informację, żeby nie ponawiać płatności, bo przyjdzie świeże żądanie.
• Potwierdzenie z finansów liczy się jako druga para rąk. Płatność potwierdziła osoba spoza Twojego zespołu w Kit, więc osoba zatwierdzająca zawsze dostaje powiadomienie z potwierdzeniem, a opisana niżej „druga para oczu” nigdy nie ma tu zastosowania: płatność zaakceptował już ktoś inny niż osoba zatwierdzająca.
• Anulowania są ogłaszane, gdy to Twój zespół odwołuje płatność. Jeśli wysłano żądanie płatności, a Twój zespół później oznaczy wypłatę w Kit jako nieudaną, finanse dostają — od tego samego nadawcy z Twoją marką — powiadomienie „Płatność anulowana — nie płać”, żeby nikt nie przelał pieniędzy za wycofaną wypłatę. Gdy niepowodzenie zgłaszają przez link same finanse, żadne powiadomienie nie wychodzi — to one nam o nim powiedziały, a ich pokwitowanie już mówi, co będzie dalej.

Gdy wypłata się nie powiedzie

Kit nigdy nie przelewa pieniędzy, więc sam nie dowie się, że przelew nie doszedł. Ktoś musi to powiedzieć — i właśnie tym jest oznaczenie wypłaty jako nieudanej. To czysta księgowość: żadne środki się nie przemieszczają, nic nie jest zwracane, a zatwierdzona nagroda pozostaje nietknięta — pełna kwota wciąż jest zarezerwowana dla badacza.

Mogą to zapisać dwie osoby. Twój zespół używa przycisku Mark failed w wierszu wypłaty, co wymaga uprawnienia do wypłat (disburse). Finanse używają linku Report a failed payment na stronie potwierdzenia. Dzięki temu osoba, która ma przed sobą odrzucenie z banku, może je zapisać od razu, bez odsyłania sprawy najpierw do Twojego zespołu.

Obie ścieżki zadają to samo pytanie z tymi samymi czterema odpowiedziami:

Powód	Skutek dla badacza
Odbiorca nie może teraz przyjmować płatności	Wysyła badaczowi e-mail z prośbą o działające dane do wypłaty
Podane dane nie odpowiadały żadnemu istniejącemu kontu	Wysyła badaczowi e-mail z prośbą o działające dane do wypłaty
Płatność została wysłana, ale wróciła do nas	Wysyła badaczowi e-mail z prośbą o działające dane do wypłaty
Coś innego	Nie kontaktuje się z nikim — sprawa zostaje w triażu zespołu. Wymaga notatki, bo ta notatka to jedyny ślad, na którym Twój zespół będzie mógł się oprzeć

E-mail przy trzech pierwszych powodach opisuje przyczynę językiem zrozumiałym dla badacza, przypomina, że pełna kwota wciąż jest dla niego zarezerwowana, i zawiera magic link, który przenosi go prosto na stronę wypłaty. Nigdy nie cytuje notatki: cokolwiek wpisały finanse albo Twój zespół — komunikat błędu z portalu bankowego, wewnętrzną referencję — zostaje wewnątrz zespołu.

Zgłoszenia anonimowe nie mają zapisanego badacza, więc żaden e-mail nie jest możliwy niezależnie od wybranego powodu.

Co widzi Twój zespół. Wiersz przenosi się do zakładki Failed kolejki i niesie całą historię: plakietkę Payment bounced z powodem, Reported by …, gdy niepowodzenie zapisały finanse, wpisaną notatkę, Researcher asked for new details, gdy wyszedł e-mail do badacza, i New payout details on file, gdy badacz odpowie. Oś czasu zgłoszenia rejestruje niepowodzenie wyłącznie z kodem powodu — notatka nigdy nie trafia na oś czasu. Księga dostaje wpis disbursement_failed, również z samym kodem.

Ponowne zlecanie. Ponowienie jest ręczne i dostępne tylko dla zespołu — badacz nie może go wywołać. Przycisk Retry znajduje się w wierszu nieudanej wypłaty i pozostaje akcją drugorzędną, dopóki badacz nie poda świeżych danych; wtedy staje się akcją główną. To sygnał gotowości, a nie ozdoba: wcześniejsze ponowienie po prostu wyśle przelew jeszcze raz na to samo martwe konto.

Ponowienie wystawia nowe żądanie płatności z nową referencją i nowym linkiem. Stary link potwierdzający jest martwy, a szczegóły niepowodzenia znikają z kolejki razem z próbą, do której należały — zapis zostaje w księdze. To uściśla opisaną wyżej referencję: referencja identyfikuje jedną próbę, a nie nagrodę, więc nagroda opłacona za drugim podejściem uzgadnia się z drugą referencją.

stateDiagram-v2
    state "Processing" as Processing
    state "Failed" as Failed
    state "Badacz aktualizuje dane do wypłaty" as Updated
    state "Processing (nowa wypłata)" as Retried

    [*] --> Processing: Initiate
    Processing --> Failed: Oznaczona jako nieudana przez Twój zespół lub finanse
    Failed --> Updated: E-mail do badacza — tylko trzy pierwsze powody
    Updated --> Retried: Retry
    Retried --> [*]: Mark paid

    note right of Retried
      Ponowienie nie wskrzesza nieudanej wypłaty.
      Zaczyna nową, więc stara referencja
      i stary link są martwe.
    end note

Powiadomienia o zrealizowanej wypłacie

Gdy wypłata zostaje oznaczona jako opłacona, Kit informuje o tym Twój zespół. Między zgodą na wydanie pieniędzy a faktycznym przelewem zawsze mija trochę czasu i to powiadomienie domyka sprawę: osoba, która zatwierdziła nagrodę, dowiaduje się o zapłacie, nie musząc pilnować kolejki.

Są trzy rodzaje powiadomień i różnią się nie bez powodu. Dwa mają charakter informacyjny. Trzeci nie.

Rodzaj	Kto je otrzymuje	Kiedy się wysyła	Można wyłączyć?
Potwierdzenie	Członek zespołu, który zatwierdził nagrodę	Każda zrealizowana wypłata, chyba że sam oznaczył ją jako opłaconą	Tak
Druga para oczu	Administratorzy Twojego programu, poza osobą, która oznaczyła wypłatę jako opłaconą	Jedna osoba zatwierdziła, skorygowała i opłaciła tę samą nagrodę, a kwota istotnie wzrosła	Tak
Rozbieżność w księdze	Osoba zatwierdzająca oraz wszyscy administratorzy programu, poza osobą, która oznaczyła wypłatę jako opłaconą	Nagroda zapisana przy zgłoszeniu przestaje zgadzać się z historią w księdze	Nie

Potwierdzenie to zwykły przypadek i ten, który zobaczysz niemal za każdym razem. Osoba zatwierdzająca dostaje krótką notkę: kto oznaczył nagrodę jako opłaconą, na jaką kwotę, kiedy i z jaką referencją transakcji, jeśli została wpisana. Jeśli nagroda była w międzyczasie korygowana, notka podaje pierwotne zatwierdzenie oraz, osobno, kwotę po korekcie i osobę, która ją wprowadziła, żeby liczby zgadzały się od razu. Kiedy ta sama osoba zatwierdziła nagrodę i zamknęła wypłatę, nic nie wychodzi: nikogo nie trzeba informować o jego własnym działaniu. Jeśli osoba zatwierdzająca nie należy już do Twojego konta, potwierdzenie trafia zamiast tego do administratorów programu, więc sprawa i tak zostaje domknięta. Nic tutaj nie wymaga działania. To pokwitowanie.

Druga para oczu zamyka jedyną lukę, jaką potwierdzenie zostawia otwartą. Skoro wypłata zamknięta przez samą osobę zatwierdzającą nie generuje żadnej wiadomości, jedna osoba mogłaby zatwierdzić niewielką nagrodę, podnieść ją i wypłacić sobie samej, a nikt by o tym nie wiedział. Ten rodzaj powiadomienia przywraca widoczność takich sytuacji: jeśli zatwierdzenie, wszystkie korekty i płatność wykonała ta sama osoba, a ostateczna kwota jest istotnie wyższa od pierwotnie zatwierdzonej, Kit informuje pozostałych administratorów programu.

„Istotnie wyższa” nie oznacza z góry ustalonej liczby. Kit mierzy to względem ustawień Twojego programu:

• W programie z macierzą nagród kwota jest istotna, gdy przekroczy maksimum zadeklarowane dla ocenionego poziomu ważności zgłoszenia. Ruch w obrębie przedziału, na który macierz już zezwala, jest rutynowy i przechodzi bez powiadomienia.
• W programie opartym na uznaniu, bez macierzy, kwota jest istotna, gdy co najmniej się podwoiła i wzrosła o co najmniej wartość Minimum Payout (minimalna wypłata) Twojego programu. Jeśli ten próg jest ustawiony na zero, obowiązuje domyślne 50 USD z Kit. Oba warunki muszą być spełnione jednocześnie, więc 500 USD → 550 USD nie wywoła powiadomienia, 6 USD → 12 USD również nie, a 6 USD → 600 USD już tak.

Od testu istotności jest jeden wyjątek. Jeśli przy zgłoszeniu jest korekta zapisana przed 5 czerwca 2026, zatwierdzonej sumy nie da się odtworzyć z księgi (zobacz Jak czytać wpisy o korektach), więc Kit nie potrafi ocenić, czy kwota wzrosła istotnie. Wypłata przeprowadzona jednoosobowo w takim zgłoszeniu dostaje powiadomienie o drugiej parze oczu niezależnie od kwoty, a jego treść mówi tylko tyle, że nie brała w niej udziału druga osoba. Kit nigdy nie twierdzi, że nastąpił wzrost, którego nie potrafił zmierzyć.

Obniżki nigdy tego powiadomienia nie wywołują. Nie wywołuje go też rutynowa praca jednej osoby: poprawiona literówka, niewielka dopłata. Tak jest celowo. W wielu programach jeden aktywny administrator zupełnie legalnie prowadzi każdą wypłatę od początku do końca, a powiadomienie przy każdej korekcie nauczyłoby wszystkich ignorować to jedno, którego zignorować nie wolno. Zapisem takich wypłat pozostają księga i oś czasu zgłoszenia.

Treść jest rzeczowa, nie oskarżająca: kto co zatwierdził, kto skorygował kwotę i do jakiej wysokości, kto zapłacił, plus link do zgłoszenia. To prośba, żeby ktoś z zespołu rzucił okiem na zapis. Nie jest to ustalenie nieprawidłowości ani zarzut wobec osoby, która wykonała pracę.

Jedna konsekwencja, którą warto wziąć pod uwagę: jeśli program ma tylko jednego administratora i to on oznaczył wypłatę jako opłaconą, nie zostaje nikt, kogo można powiadomić, więc nic nie wychodzi. Jedynym zapisem są wtedy księga i oś czasu, a to dobry powód, żeby powołać drugiego administratora programu.

Rozbieżność w księdze to jedyny rodzaj powiadomienia, który oznacza, że naprawdę coś jest nie tak. Wysyła się, gdy kwota nagrody zapisana przy zgłoszeniu przestaje zgadzać się z sumą wynikającą z historii w księdze. Każda ścieżka w Kit zapisuje nagrodę i jej wpis w księdze razem (zatwierdzenie, korekta i cofnięcie zawsze zmieniają jedno i drugie naraz), więc przy normalnym korzystaniu z produktu to się nie zdarza. Rozbieżność oznacza, że dane zostały zmienione poza aplikacją.

Tego powiadomienia nie da się wyłączyć. Pomija ustawienia kategorii e-mail i nie zawiera linku do rezygnacji, bo nikt nie powinien móc wyciszyć sygnału o integralności zapisu finansowego. Trafia do osoby zatwierdzającej i do wszystkich administratorów programu, więc rozbieżność zawsze widzi ktoś inny niż osoba, która zamknęła wypłatę.

Jeśli takie powiadomienie do Ciebie dotrze, skontaktuj się z pomocą techniczną i nie próbuj uzgadniać kwot ręcznie. Traktuj je dokładnie tak samo jak naruszenie integralności księgi.

Jak te powiadomienia do Ciebie docierają:

• Powiadomienia w aplikacji dochodzą zawsze — wszystkie trzy rodzaje i do każdej osoby z listy odbiorców. Preferencje e-mail nie mają wpływu na dzwonek powiadomień.
• E-maile z potwierdzeniem i z prośbą o drugą parę oczu należą do kategorii Aktywność programu bezpieczeństwa w Preferencjach e-mail i powiadomień i są wstrzymywane na czas trybu urlopowego.
• E-maile o rozbieżności w księdze pomijają tę kategorię, ale respektują tryb urlopowy. To rozsyłanie do wszystkich administratorów programu gwarantuje, że alert dotrze do kogokolwiek również wtedy, gdy osoba zatwierdzająca jest na urlopie.

Statusy wypłat

Status	Znaczenie
Pending	Wiersz wypłaty istnieje, ale nie został zainicjowany. Initiate tworzy wiersz i w tym samym ruchu przenosi go dalej, więc Pending to stan przejściowy trwający ułamek sekundy, a nie stan kolejki — nagroda czekająca na checklistę gotowości nie ma jeszcze żadnej wypłaty i znajduje się na zakładce Blocked
Processing	Twój zespół zainicjował przelew poza Kit
Completed	Potwierdzono otrzymanie środków; referencja transakcji zapisana — zgłoszenie zamyka się ze statusem Paid, gdy tylko pozwoli na to jego cykl życia
Failed	Przelew nie doszedł do skutku. Przy trzech z czterech powodów niepowodzenia Kit już poprosił badacza o nowe dane — nie pisz do niego ponownie. Gdy świeże dane są zapisane, zleć wypłatę ponownie przyciskiem Retry

W przypadku niepowodzenia wypłaty księga zapisuje wpis disbursement_failed z kodem powodu — wpisana notatka jest z niego celowo pomijana. Finanse dostają e-mail o anulowaniu tylko wtedy, gdy niepowodzenie oznaczył Twój zespół, a do finansów wcześniej wysłano żądanie płatności; niepowodzenie zgłoszone przez same finanse nie wysyła niczego. Ponowne zlecenie to ręczny Retry w wierszu nieudanej wypłaty, który staje się główną akcją wiersza, gdy tylko badacz poda działające dane. Pełną pętlę opisuje sekcja Gdy wypłata się nie powiedzie.

Dokumenty podatkowe

Badacze przesyłają dokumenty podatkowe przez swój portal. Badacze z USA przesyłają W-9, badacze spoza USA — W-8BEN. Dokumenty są przechowywane z szyfrowaniem w spoczynku.

Twój zespół weryfikuje przesłane dokumenty w VDP > Tax Documents:

Status	Działanie
Pending	Dokument przesłany, oczekuje na Twoją weryfikację
Verified	Potwierdziłeś, że dokument jest prawidłowy — element checklisty gotowości jest spełniony
Rejected	Odrzuciłeś dokument — badacz otrzymuje powiadomienie i może przesłać nowy

Zarówno weryfikacja, jak i odrzucenie są rejestrowane w księdze na potrzeby audytu. Zdarzenia dotyczące dokumentów podatkowych są powiązane z najnowszym zgłoszeniem badacza, za które przyznano nagrodę, żeby zachować kontekst w księdze.

Księga

Przejdź do VDP > Ledger, aby wyświetlić niezmienny ślad audytu finansowego. Księga działa w trybie wyłącznie dopisywania: wpisów nie można edytować, modyfikować ani usuwać.

Każdy wpis rejestruje:

• Typ wpisu — co się wydarzyło
• Kwota — wartość w centach i walucie
• Wykonawca — członek zespołu, który wykonał czynność. Wpisy zapisane spoza Twojego zespołu — płatność potwierdzona albo niepowodzenie zgłoszone przez link dla finansów — nie mają za sobą użytkownika Kit i wyświetlają się jako System. To zachowanie oczekiwane, a nie luka: imię i nazwisko osoby z finansów trafia do zaszyfrowanego zapisu pochodzenia wypłaty i jest widoczne w wierszu kolejki jako Reported by …
• Znacznik czasu — data i czas utworzenia wpisu
• Referencja zgłoszenia — powiązane zgłoszenie podatności

Każdy wpis rejestruje jeden z następujących typów:

Typ wpisu	Kiedy jest tworzony
bounty_approved	Członek zespołu zatwierdza kwotę nagrody za zgłoszenie
bounty_adjusted	Członek zespołu koryguje kwotę nagrody przed wysłaniem płatności. Zapisana kwota to zmiana, a nie nowa suma — zobacz Jak czytać wpisy o korektach
bounty_revoked	Zgłoszenie z zatwierdzoną nagrodą zostaje odrzucone; cofnięcie liczy się jako obciążenie pomniejszające sumy księgi
disbursement_initiated	Członek zespołu przenosi wypłatę do statusu Processing
disbursement_completed	Członek zespołu oznacza wypłatę jako opłaconą wraz z referencją transakcji
disbursement_failed	Wypłata zostaje oznaczona jako nieudana. Wpis niesie jeden z czterech stałych kodów powodu; notatka tekstowa jest celowo pomijana w księdze — zobacz Gdy wypłata się nie powiedzie
tax_document_submitted	Badacz przesyła dokument W-8BEN lub W-9
tax_document_verified	Członek zespołu weryfikuje dokument podatkowy jako prawidłowy
tax_document_rejected	Członek zespołu odrzuca dokument podatkowy; badacz otrzymuje powiadomienie i może przesłać go ponownie

Księgę można filtrować według identyfikatora zgłoszenia, typu wpisu lub zakresu dat, żeby zawęzić wyniki. Skorzystaj z eksportu księgi w Metrics and Exports, aby wygenerować pakiety dowodowe SOC 2.

Jak czytać wpisy o korektach

bounty_adjusted to jedyny typ wpisu, którego kwota jest zmianą, a nie sumą. Każdy inny wpis rejestruje wartość bezwzględną: zatwierdzoną nagrodę, wypłaconą kwotę, cofniętą kwotę. Korekta zapisuje wyłącznie różnicę, jaką wprowadziła: dodatnią albo ujemną.

Ta różnica ma znaczenie przy uzgadnianiu. Nagroda 6 USD skorygowana do 600 USD zapisuje w bounty_adjusted kwotę 594 USD: to rozmiar korekty, a nie druga nagroda w wysokości 594 USD. Odczytana jako suma, jedna korekta zamienia zwykłą poprawkę literówki w pozorną nadpłatę.

Dlatego Kit wszędzie wyraźnie opisuje korekty i nigdy nie musisz się domyślać, który odczyt obowiązuje:

• Oś czasu zgłoszenia — pokazuje „Nagroda dostosowana do 600 USD”, czyli sumę wynikową, więc liczba widoczna przy zgłoszeniu to sama nagroda.
• Strona księgi — pokazuje zmianę z wyraźnym znakiem: +594 USD przy wzroście, -594 USD przy obniżce. Wiodący znak + znaczy „kwota zmieniła się o tyle”.
• Eksport księgi do CSV — zawiera zmianę, kolumnę mówiącą, czy dana kwota jest zmianą, czy wartością bezwzględną, oraz kolumnę z sumą, na jakiej korekta się zatrzymała.
• Eksport księgi do PDF oraz dossier zgłoszenia — drukują zmianę ze znakiem, a za nią sumę, którą dała, w postaci +594 USD -> 600 USD.
• Slack, jeśli program publikuje tam zdarzenia wypłat — komunikat o zrealizowanej wypłacie skorygowanej nagrody podaje pierwotne zatwierdzenie i sumę po korekcie, a nie samą zmianę.

Żeby odtworzyć aktualnie zatwierdzoną nagrodę z samej księgi: weź zatwierdzenie, dodaj każdą zapisaną po nim korektę, a na końcu odejmij ewentualne cofnięcie. Tę sumę Kit porównuje z kwotą zapisaną przy samym zgłoszeniu (zobacz Powiadomienia o zrealizowanej wypłacie).

Korekty zapisane przed 5 czerwca 2026 pochodzą z czasów przed tym schematem: trzymają wartość bezwzględną i nie mają zapisu sumy, którą dały. Kit oznacza je inaczej, zamiast zgadywać — oś czasu pokazuje „Nagroda dostosowana o”, w CSV rodzaj kwoty to unknown, a kolumna z sumą wynikową zostaje pusta. Starszy wpis nigdy nie jest przedstawiany jako coś, czego nie potrafi udowodnić.

Integralność księgi

Codzienne automatyczne sprawdzanie integralności weryfikuje spójność księgi. Przechodzi przez wszystkie wpisy w kolejności chronologicznej i prowadzi bieżące saldo — uznania (bounty_approved, bounty_adjusted) je zwiększają, a obciążenia (disbursement_completed, bounty_revoked) zmniejszają. Jeśli bieżące saldo kiedykolwiek spadnie poniżej zera, dany wpis zostaje oznaczony jako naruszenie.

Bieżące saldo to kontrola wypłacalności i liczy się inaczej niż zatwierdzona suma opisana w Jak czytać wpisy o korektach. Bieżące saldo odejmuje również zrealizowane wypłaty, bo pieniądze, które już wyszły z firmy, przestają być zobowiązaniem. Zatwierdzona suma ich nie odejmuje: zapłata nagrody nie zmienia tego, co zostało zatwierdzone. Bieżące saldo odpowiada na pytanie „czy finanse tego programu spinają się w czasie”, a zatwierdzona suma na pytanie „ile jest obecnie zatwierdzone przy tym zgłoszeniu”.

Każde naruszenie jest zgłaszane do systemu monitorowania błędów Kit (APM), aby zespół inżynieryjny mógł je zbadać — nie jest wysyłany e-mail do administratorów konta. Skontaktuj się z pomocą techniczną, jeśli podejrzewasz rozbieżność w księdze — nie próbuj rozwiązywać jej ręcznie.

W skrócie

• Skonfiguruj poziomy macierzy nagród z odpowiednimi przedziałami min/max dla akceptowalnego poziomu ryzyka
• Ustaw wymagania gotowości do wypłaty (dokumenty podatkowe, umowa) w ustawieniach wypłat programu
• Ustaw adres e-mail finansów, żeby żądania płatności trafiały do zespołu, który faktycznie planuje płatności
• Opublikuj przedziały nagród na stronie polityki ujawniania, zanim badacze zaczną przesyłać zgłoszenia
• Co tydzień sprawdzaj kolejkę wypłat (Disbursements) pod kątem oczekujących płatności
• Świadomie i regularnie przeglądaj zakładkę Failed — nieudana wypłata nie wysyła ani e-maila, ani powiadomienia w aplikacji
• Zanim odrzucisz zgłoszenie z wypłatą w toku, wybierz Coś innego — dzięki temu badacz nie dostanie prośby o dane do nagrody, którą właśnie wycofujesz
• Powołaj co najmniej dwóch administratorów programu, żeby wypłata prowadzona od początku do końca przez jedną osobę trafiła jednak do niezależnej weryfikacji
• Ustal z zespołem, kiedy nagroda przechodzi przez propozycję, a kiedy idzie prosto do zatwierdzenia — Kit tego nie wymusza
• Przy uzgadnianiu eksportu czytaj kwoty bounty_adjusted w księdze jako zmiany, a nie jako sumy
• Powiadomienie o rozbieżności w księdze traktuj jako sprawę do pomocy technicznej, a nie do ręcznej naprawy
• Niezwłocznie sprawdzaj i weryfikuj przesłane dokumenty podatkowe, żeby odblokować płatności dla badaczy
• Co kwartał eksportuj księgę jako dowód SOC 2 za pośrednictwem Metrics and Exports

Co dalej

• Propozycje nagród i głosowanie zespołu — zespołowa decyzja o kwocie, zanim stanie się pieniędzmi
• Metrics and Exports — wskaźniki KPI dashboardu, eksporty dowodowe SOC 2 i karma badaczy
• The Researcher Portal — jak badacze przesyłają dane do wypłat i dokumenty podatkowe