Czy Twój sklep e-commerce traci na złej strategii webhooków? 3 błędy
Webhooki to jeden z tych elementów infrastruktury, który działa w tle i rzadko budzi emocje – dopóki nie przestanie działać. W e-commerce są podstawą komunikacji między systemami: od płatności, przez fulfillment, po CRM. Ale paradoksalnie, właśnie dlatego, że są tak powszechne, wiele firm traktuje je po macoszemu. Efekt? Utrata danych, opóźnienia w zamówieniach, a nawet luki w bezpieczeństwie.
Z perspektywy praktyka widzę trzy błędy, które powtarzają się w sklepach średniej wielkości. Każdy z nich jest kosztowny – ale też każdy można łatwo naprawić.
1. Brak retry logic – czyli zaklinanie rzeczywistości
Większość platform do obsługi webhooków oferuje podstawowe mechanizmy ponawiania żądań. Mimo to w kodzie produkcyjnym regularnie widzę implementacje, które zakładają, że każde żądanie dotrze idealnie na czas. A rzeczywistość jest inna: serwery padają, kolejki się zapychają, a bazy danych bywają wolniejsze niż zwykle.
Kiedy webhook z bramki płatności nie dotrze do Twojego backendu, a nie masz żadnego mechanizmu ponawiania, możesz stracić informację o zamówieniu. Klient widzi pieniądze na koncie, ale Ty nie widzisz zamówienia. Wtedy zaczyna się ręczne szukanie – i nerwy.
Rozwiązanie? Proste: zaimplementuj retry z backoffem (np. wykładniczy – coraz dłuższe odstępy między próbami) i loguj każdą nieudaną próbę. W praktyce często wystarczy 3–5 ponowień w ciągu kilku minut. Dodatkowo warto mieć dashboard, który pokazuje, które webhooki nie docierają – wtedy możesz reagować, zanim klient zacznie narzekać.
Znam przypadek sklepu z odzieżą, który stracił około 2% zamówień miesięcznie właśnie przez to, że webhooki z bramki PayU nie były ponawiane. Po wdrożeniu retry z backoffem problem zniknął całkowicie. Koszt implementacji? Kilka godzin pracy programisty. Strata? Kilkadziesiąt tysięcy złotych miesięcznie.
2. Pomijanie walidacji – zaproszenie do ataku
Webhooki często błędnie traktowane są jako wewnętrzne API – zakładamy, że skądś przychodzą i są bezpieczne. Tymczasem webhook z bramki płatności może być podrobiony przez atakującego, jeśli nie zweryfikujesz sygnatury. A nawet jeśli nie jest podrobiony, może zawierać nieprawidłowe dane – np. zduplikowane ID zamówienia.
Zdarzyło mi się audytować sklep, który przyjmował webhooki od Stripe bez sprawdzania nagłówka Stripe-Signature. W efekcie każdy, kto znał URL webhooka, mógł wysłać fałszywe powiadomienie o płatności – i zamówienie było realizowane bez pieniędzy. Na szczęście w tamtym przypadku nikt nie wykorzystał tej luki, ale potencjał do nadużyć był ogromny.
Co robić? Zawsze sprawdzaj sygnaturę webhooka za pomocą tajnego klucza dostarczonego przez dostawcę. Dodatkowo waliduj dane wejściowe: unikalność ID, zgodność kwoty, status. To nie jest rocket science – to standard bezpieczeństwa, który powinien być domyślnie włączony.
3. Brak monitorowania – liczenie na Facebooka po awarii
Ostatni błąd to brak monitorowania i alertów. Webhooki działają w tle, więc często nie zdajesz sobie sprawy, że przestały działać. Klienci dzwonią z pytaniem „dlaczego zamówienie nie jest realizowane?”, a Ty zaczynasz szukać – i dopiero wtedy odkrywasz, że od 2 godzin żaden webhook nie przeszedł.
Pamiętam przypadek sklepu z elektroniką, który miał certyfikat SSL odnowiony automatycznie, ale zapomniał zaktualizować go w konfiguracji webhooka. Bramka płatności wysyłała żądania przez HTTPS, ale ich serwer nie miał już ważnego certyfikatu – wszystkie żądania były odrzucane. Stracone zostało około 6 godzin zamówień. Gdyby mieli alert na nieudane webhooki, dostaliby powiadomienie po 5 minutach i naprawiliby błąd w kwadrans.
Jak to zrobić dobrze? Użyj narzędzi takich jak Sentry, Datadog, albo nawet prosty skrypt monitorujący, który co minutę sprawdza, czy webhooki są przetwarzane. Ustaw alert dla spadku liczby udanych żądań o więcej niż 10% w ciągu godziny. Możesz też skorzystać z wbudowanych statystyk platformy webhookowej (np. Stripe ma dashboard z logami).
Podsumowanie
Webhooki to krwioobieg Twojego sklepu. Jeśli nie mają retry, walidacji i monitorowania, to tak, jakbyś prowadził sklep bez ochrony i bez informacji zwrotnej. Koszty są ukryte – utracone zamówienia, spadek zaufania klientów, ręczna praca – ale realne. Wdrożenie trzech prostych zabezpieczeń: retry z backoffem, weryfikacja sygnatury i monitoring, to inwestycja rzędu kilku godzin pracy developera. Zwrot jest natychmiastowy.
W JurskiTech.pl często spotykamy się z takimi przypadkami – niby drobiazg, a ciągnie za sobą poważne konsekwencje. Jeśli chcesz sprawdzić, jak wygląda Twoja strategia webhooków, chętnie rzucimy okiem. Ale nawet samodzielnie możesz zacząć od przejrzenia logów i dopisania kilku linijek kodu. Nie czekaj, aż awaria zmusi Cię do działania.
