Nagrody i wypłaty

Nagrody w Kit

Nagrody i wypłaty są dołączone do każdej aktywnej subskrypcji Kit. Proces obejmuje pełną obsługę wypłat nagród, niezmienną księgę finansową i zarządzanie dokumentami podatkowymi opisane na tej stronie.

Kit pozwala uzależnić wypłatę od weryfikacji dokumentów podatkowych. Ustaw wymagania odpowiednie dla twojego programu, a zespół sprawdzi przesłane formularze przed wypłatą. Samo użycie tej funkcji nie ustala obowiązków podatkowych firmy. Formularz W-9 służy do przekazania płatnikowi numeru identyfikacji podatkowej i oświadczeń potrzebnych do raportowania (informacje IRS).

Niezmienna księga finansowa jest źródłem dokumentacji do audytu 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ć całą historię od rozwiązania zgłoszenia po potwierdzenie płatności w jednym eksporcie.

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.

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 poradniku Konfiguracja programu.

Dwie drogi do kwoty

Nagrodę można zatwierdzić od razu albo najpierw uzgodnić kwotę z zespołem. W obu przypadkach zatwierdzenie zapisuje nagrodę w księdze i powiadamia badacza.

Ścieżka	Jak działa	Kiedy jej użyć
Zatwierdzenie bezpośrednie	Administrator wpisuje kwotę i ją zatwierdza. Jeden krok. Opisane poniżej.	Kwota nie budzi wątpliwości, np. przy zgłoszeniu o niskiej ważności z nagrodą bliską dolnej granicy przedziału.
Najpierw propozycja, potem zatwierdzenie	Dowolny członek zespołu proponuje kwotę z uzasadnieniem. Pozostali członkowie zespołu popierają propozycję albo zgłaszają sprzeciw i proponują inną kwotę. Potem zatwierdza administrator.	Kwota budzi wątpliwości, jest nietypowo wysoka albo będzie punktem odniesienia dla kolejnych nagród.

Propozycje służą do konsultacji wewnątrz zespołu. Badacz ich nie widzi ani nie dostaje o nich powiadomień. Nie tworzą wpisów w księdze, nie uruchamiają wypłat i nie blokują zatwierdzenia nagrody. 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, a 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.

Aby zatwierdzić kwotę w tym formularzu, zapisz go. 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 zatwierdza 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”.
• Punkty karmy przyznane za nagrodę zostają odebrane. Rejestruje to zdarzenie „Bounty Revoked”.

Obowiązują dwa zabezpieczenia:

• Nagrody, której wypłata ma status Completed, nigdy nie można cofnąć.
• 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 zakładkach: Ready, Blocked, With Finance, Paid, Failed i All. Domyślnie otwiera się zakładka Ready.

Na górze umieszczono cztery kafelki podsumowania:

• Ready: zgłoszenia z zatwierdzoną nagrodą, dla których nie utworzono jeszcze wypłaty, które spełniają wymagania do wypłaty i środki można od razu przelać.
• Blocked: zgłoszenia z zatwierdzoną nagrodą, dla których nie utworzono jeszcze wypłaty, które nie spełniają jeszcze wymagań do wypłaty.
• 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 dzielą zgłoszenia z zatwierdzoną nagrodą i bez utworzonej wypłaty według tego, czy spełniają wymagania gotowości.

Wymagania do wypłaty

Przed wypłatą badacz musi podać dane do płatności. W ustawieniach programu możesz dodatkowo wymagać akceptacji umowy i weryfikacji dokumentu podatkowego:

• 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)

Jeśli program nie wymaga umowy lub dokumentu podatkowego, dany punkt jest automatycznie oznaczany jako spełniony.

Wypłata zależy 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.

Zablokowane wypłaty według badaczy

Zakładka Blocked to tablica ponagleń: zamiast płaskiej listy zablokowanych wypłat grupuje je według badacza, więc wysyłasz jednej osobie wspólne przypomnienie o wszystkich brakach. 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

Najpierw widać osoby, którym przypomnienie można wysłać teraz, potem te objęte karencją. W każdej z tych części grupy są uporządkowane od najdłużej czekającej wypłaty.

Każda grupa podaje też, ile ponaglenie faktycznie odblokuje, w postaci liczby „odblokowuje N wypłat / $X”. Liczba obejmuje 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, czyli krok po stronie twojego zespołu, nie jest liczone, bo e-mail do badacza go nie odblokuje. Liczba pokazuje więc wypłaty, które przypomnienie może odblokować.

Ponaglanie badacza

W zakładce Blocked kliknij Nudge przy grupie badacza, żeby wysłać temu badaczowi przypomnienie e-mailem. Ponaglanie wymaga 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ń.

Przy każdym braku e-mail zawiera link do odpowiedniego formularza: danych do wypłaty, dokumentu podatkowego lub umowy do konkretnego zgłoszenia. Jeśli badacz nie jest zalogowany, najpierw potwierdza logowanie. Wysłanie przypomnienia nie unieważnia jego dotychczasowego linku do logowania. Zamówienie nowego linku do logowania unieważnia jednak także linki z przypomnienia.

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, takie jak 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, kliknij Mark as Paid i wprowadź identyfikator 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

Osoba zlecająca płatność zwykle pracuje w finansach, a nie w bezpieczeństwie. Kit udostępnia dwie ściśle ograniczone ścieżki:

• Rola Finanse daje zalogowaną kolejkę wypłat dla badaczy i weryfikacji formularzy W-8/W-9. Pozwala rozpocząć, zakończyć, ponowić lub odnotować nieudaną wypłatę, ale nie daje dostępu do treści zgłoszeń, zatwierdzania nagród, ustawień wypłat ani pełnych eksportów.
• Skrzynka w rodzaju [email protected] służy osobom, które mają działać przez bezpieczny link bez konta Kit.

Zespół bezpieczeństwa nadal decyduje, czy przyznać nagrodę i w jakiej wysokości. Finanse realizują i rejestrują zatwierdzoną płatność.

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 identyfikator 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, gdy pozwala na to jego stan opisany powyżej, 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). Dane te widać 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 tymi samymi danymi o tym, 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 przez link dla finansów uruchamia zwykłe powiadomienie. Kit zapisuje dane podane przez osobę potwierdzającą. Nie stosuje wtedy opisanej niżej prośby o „drugą parę oczu”, przeznaczonej dla wypłat wykonanych w całości przez jednego użytkownika zespołu.
• 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 powiadomienie z oznaczeniami twojej firmy „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ł. Trzeba to zgłosić, oznaczając wypłatę jako nieudaną. 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.

Niepowodzenie mogą zapisać zarówno osoby z twojego zespołu, jak i z finansów. 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 pięcioma 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ć
Tej metody płatności nie można użyć dla tego odbiorcy	Wysyła badaczowi e-mail z prośbą o działające dane do wypłaty

Każdy powód poza Coś innego wysyła e-mail do badacza. Wiadomość opisuje przyczynę w zrozumiały sposób, przypomina, że pełna kwota wciąż jest zarezerwowana, i zawiera magic link prowadzący prosto do strony wypłaty. Nigdy nie cytuje notatki: komunikat portalu bankowego czy wewnętrzna referencja wpisana przez finanse lub zespół pozostaje wewnętrzna.

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

Wiersz przenosi się do zakładki Failed kolejki. Oś czasu zgłoszenia rejestruje niepowodzenie wyłącznie z kodem powodu; notatka nigdy na nią nie trafia. Księga dostaje wpis disbursement_failed, również z samym kodem.

Jak odczytać stan nieudanej wypłaty

Wiersz nieudanej wypłaty pomaga zdecydować, czy ponowić płatność, czy poczekać na badacza. Sprawdź, czy dane się zmieniły: ponowna płatność na to samo konto może znów zostać odrzucona.

Przy wysyłce Kit zapisuje metodę płatności i konto docelowe. Po niepowodzeniu porównuje je z obecnymi danymi badacza i pokazuje dokładnie jeden komunikat:

Komunikat w wierszu	Znaczenie	Co zrobić
Dane zmienione 2 dni temu · PayPal m•••@gmail.com → PayPal e•••@live.com	Obecne dane naprawdę różnią się od tych, dla których płatność się nie udała	Ponów
Ponownie zapisano 2 dni temu: te same dane, dla których płatność się nie udała	Badacz otworzył stronę wypłaty i zapisał ją bez zmian	Nie ponawiaj. Skontaktuj się z badaczem, bo prawdopodobnie nie zrozumiał, co poprawić
Te same dane co przy nieudanej płatności: ponowienie prawdopodobnie znów się nie uda	Od niepowodzenia nic nie zostało zmienione	Poczekaj albo przypomnij badaczowi
Badacz zapisał dane 3 dni temu: nie można potwierdzić, czy są inne	Płatność nie udała się, zanim Kit zaczął zapisywać dane do porównania. Wiadomo jedynie, że badacz coś zapisał	Ponowienie jest rozsądne, ale pozostaje przypuszczeniem, nie potwierdzeniem

Identyfikatory kont są zawsze zamaskowane. Jeśli przy wypłacie nie zapisano miejsca docelowego i nic nie wskazuje, że badacz zmienił dane, wiersz nie pokazuje żadnego z tych komunikatów. Nie ma wtedy danych do porównania.

Przycisk Retry kieruje się tym samym rozstrzygnięciem. Jest główną akcją w dwóch stanach, w których rzeczywiście zapisano świeże dane, i mniej wyróżnioną akcją drugorzędną w dwóch stanach, gdzie ponowienie skierowałoby płatność na to samo niedziałające konto.

Każda próba zostaje w historii. Ponowienie nie usuwa już płatności, która się nie udała. Wszystkie wcześniejsze próby pozostają osobnymi wierszami, np. Próba 1 odrzucona 12 dni temu · Odbiorca nie może przyjmować płatności. Od razu widać, że konto odrzuciło pieniądze po raz trzeci, a nie pierwszy. Historia prób jest widoczna na szerokim ekranie; na wąskim znika, żeby wiersze pozostały czytelne.

„Poproszono badacza” jest zapisem, nie założeniem. Wiersz Poproszono badacza · 3 dni temu pojawia się dopiero po faktycznym dostarczeniu e-maila i pokazuje czas wysyłki. Tuż po niepowodzeniu brak tego wiersza oznacza, że wiadomość nadal jest w drodze.

Powód „Coś innego”: kiedy poprosić o dane

Coś innego nie wysyła prośby o dane do badacza. Ten powód służy do spraw wymagających decyzji zespołu: wybierz go, gdy oznaczasz wypłatę jako nieudaną tylko po to, żeby odblokować odrzucenie zgłoszenia, albo przy wewnętrznej przyczynie niezwiązanej z danymi badacza.

Ta cisza dawniej była niewidoczna w kolejce i prawdziwe wypłaty potrafiły utknąć na tygodnie. Wiersz wyglądał jak każde inne niepowodzenie, więc nikt nie zauważał, że badacz nie dostał informacji. Teraz wiersze z powodem Coś innego mówią wprost Nie poproszono. „Coś innego” nie dociera do badacza i mają główny przycisk Poproś o nowe dane.

Kliknięcie wysyła tę samą prośbę o dane co pozostałe powody i zapisuje czas wysyłki. Wiadomość nie cytuje notatki ani nie podaje przyczyny. Informuje jedynie, że płatności nie udało się zrealizować, i prosi o działające dane. Przycisk ustępuje wtedy wierszowi Poproszono badacza.

Gdy odmawia sama metoda płatności

Dwa powody, Odbiorca nie może teraz przyjmować płatności i Tej metody płatności nie można użyć dla tego odbiorcy (w wierszu jako Metoda płatności nie jest obsługiwana), oznaczają odmowę po stronie metody, a nie błędnie wpisane dane badacza. Może nie mieć czego poprawiać.

To szczególnie ważne w programie oferującym tylko jedną metodę płatności, domyślnie sam PayPal. Badacz nie ma gdzie się przenieść, więc żadna korekta po jego stronie nie pomoże. W takim przypadku Kit raz wysyła e-mail administratorom CSIRT z nazwą badacza, kwotą, zgłoszeniem i czasem oczekiwania nagrody. Ten sam komunikat pojawia się w wierszu z linkiem do ustawień wypłat.

Co zrobić: włącz drugą metodę płatności, a potem poproś badacza o jej wybór przed ponowieniem. Jeśli jedna metoda jest świadomą zasadą programu, nie musisz nic robić. Powiadomienie jest ograniczone do jednego na program co 90 dni, więc podjęta decyzja nie wywoła kolejnych przypomnień po każdym niepowodzeniu.

Ponowne zlecanie

Ponowienie jest ręczne i dostępne tylko dla zespołu; badacz nie może go uruchomić. Tworzy nowe żądanie płatności z nową referencją i linkiem, a stary link potwierdzający przestaje działać. Referencja identyfikuje jedną próbę, nie nagrodę, więc nagroda opłacona za drugim podejściem uzgadnia się z drugą referencją.

Zastąpiona próba nie jest usuwana. Pozostaje w wierszu i księdze jako część historii podjętych działań.

stateDiagram-v2
    state "Processing" as Processing
    state "Failed" as Failed
    state "Researcher updates payout details" as Updated
    state "Processing (new disbursement)" as Retried

    [*] --> Processing: Initiate
    Processing --> Failed: Marked failed by your team or by finance
    Failed --> Updated: Researcher emailed — every reason but "Something else"
    Updated --> Retried: Retry
    Retried --> [*]: Mark paid

    note right of Retried
      Retry does not revive the failed payout.
      It starts a fresh one, so the old
      reference and link are dead — but the
      bounced attempt stays on the row.
    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ń. Potwierdzenie i prośba o dodatkowe sprawdzenie mają charakter informacyjny. Rozbieżność w księdze wymaga działania.

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 jakim identyfikatorem transakcji, jeśli został wpisany. 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 zwraca uwagę na istotne podwyższenie nagrody wypłaconej przez osobę, która sama ją zatwierdziła. 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. Przyczynę rozbieżności trzeba zbadać; samo powiadomienie jej nie ustala.

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 administratorów programu, z pominięciem osoby, która oznaczyła wypłatę jako opłaconą. Jeśli nie ma innych odbiorców, nie zostanie wysłane.

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. Pozostali uprawnieni administratorzy mogą więc otrzymać e-mail 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 spełnienie wymagań do wypłaty 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 każdym powodzie poza Coś innego Kit już poprosił badacza o nowe dane: nie pisz ponownie. Gdy świeże dane są zapisane, zleć wypłatę przyciskiem Retry

W przypadku niepowodzenia wypłaty księga zapisuje wpis disbursement_failed z kodem powodu, celowo bez notatki. 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. Zgłoszenie niepowodzenia przez same finanse nie wysyła niczego. Ręczny Retry staje się główną akcją, gdy badacz poda dane różniące się od tych, dla których płatność się nie udała. Pełny cykl opisuje 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.

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 listy wymagań do wypłaty 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 zobaczyć historię operacji finansowych. Do księgi można tylko dopisywać wpisy; istniejących nie można edytować 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ść. Potwierdzenie płatności lub zgłoszenie niepowodzenia przez link dla finansów nie jest przypisane do użytkownika Kit, dlatego jako wykonawca widnieje System. Imię i nazwisko podane przez osobę z finansów jest szyfrowane i 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 identyfikatorem transakcji
disbursement_failed	Wypłata zostaje oznaczona jako nieudana. Wpis zawiera jeden z pięciu 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 poradniku Wskaźniki i eksporty, 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ą po korekcie.
• 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 stosują wcześniejszy format: przechowują kwotę bezwzględną bez osobno zapisanego wyniku korekty. 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. Dla takich wpisów wynik korekty nie jest dostępny.

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 służy do sprawdzania zgodności zatwierdzonych nagród z wypłatami i liczy się inaczej niż zatwierdzona suma opisana w sekcji 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 zapisane wypłaty nie przekroczyły zatwierdzonych nagród”, 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.

Lista kontrolna

• 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
• Regularnie przeglądaj zakładkę Failed: zespół nie dostaje osobnego powiadomienia o każdej nieudanej wypłacie
• Przeczytaj wiersz przed kliknięciem Retry; jeśli dane się nie zmieniły, ponowienie trafi na to samo niedziałające konto
• Przy powodzie Coś innego użyj Poproś o nowe dane; ten powód sam nie dociera do badacza
• 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 prośbę o sprawdzenie wypłaty wykonanej przez jedną osobę mógł otrzymać ktoś inny
• 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 Wskaźniki i eksporty

Co dalej

• Propozycje nagród i głosowanie zespołu: uzgodnienie kwoty przed zatwierdzeniem nagrody
• Wskaźniki i eksporty: wskaźniki na pulpicie, eksporty dowodowe SOC 2 i karma badaczy
• Portal badacza: jak badacze przesyłają dane do wypłat i dokumenty podatkowe