Webhooki w e-commerce: 3 błędy, które kosztują klientów
Webhooki to jeden z tych elementów infrastruktury, które działają w tle i rzadko zwracają na siebie uwagę – dopóki coś nie pójdzie nie tak. W e-commerce odpowiadają za synchronizację między systemami: zamówienia, płatności, stany magazynowe, powiadomienia. Gdy zawodzą, efektem jest nie tylko frustracja zespołu IT, ale przede wszystkim utrata zamówień i zaufania klientów.
W ostatnich miesiącach widziałem kilka firm, które straciły znaczącą część przychodów właśnie przez źle skonfigurowane webhooki. Oto trzy najczęstsze błędy, które powtarzają nawet doświadczeni developerzy.
1. Brak mechanizmu ponawiania nieudanych wywołań
Standardowe webhooki są wysyłane raz. Jeśli odbiorca nie odpowiada (np. serwer tymczasowo niedostępny), wiadomość przepada. Wiele zakładając, że „to się nie zdarza” – ale w praktyce przy większym ruchu lub aktualizacjach systemu zdarza się często.
Przykład: Sklep e-commerce wysyła webhook do systemu logistycznego po złożeniu zamówienia. System logistyczny miał chwilowy outage (np. restart bazy). Klient otrzymał potwierdzenie zamówienia, ale towar nigdy nie został wysłany. Po kilku dniach klient dzwoni z reklamacją, a sklep musi anulować lub wysyłać ekspresowo, ponosząc koszty.
Rozwiązanie: Zaimplementuj kolejkę retry z wykładniczym czasem oczekiwania (np. 1s, 5s, 30s, 5min). Dodatkowo warto mieć monitoring i alerty, gdy wszystkie próby się nie powiodą. Wtedy można ręcznie interweniować.
2. Zbyt duża lub nieczytelna struktura danych
Webhooki często przesyłają całe obiekty z wieloma polami, które nie są potrzebne odbiorcy. To zwiększa objętość payloadu, spowalnia przetwarzanie i może powodować przekroczenie limitów rozmiaru żądania (np. u dostawców SaaS).
Z drugiej strony – zbyt mała struktura może zmuszać odbiorcę do wykonywania dodatkowych zapytań API w celu uzupełnienia danych, co multiplikuje liczbę wywołań i wydłuża czas reakcji.
Przykład: Webhook powiadamiający o nowej płatności przesyła cały obiekt zamówienia wraz ze wszystkimi produktami, adresami, historią statusów. Odbiorca potrzebuje tylko ID zamówienia i kwoty. Payload ma kilkaset KB, a po stronie odbiorcy jest odrzucany z powodu limitu 128 KB (np. u dostawcy Webhooków). Płatność nie zostaje zarejestrowana.
Rozwiązanie: Projektuj webhooki z myślą o minimalnym zestawie danych. Najlepiej wysłać tylko niezbędne ID i ew. kilka kluczowych pól, a odbiorca niech dociągnie resztę przez API, jeśli potrzebuje. Ustal ze swoimi partnerami limit rozmiaru i trzymaj się go.
3. Brak walidacji tożsamości nadawcy
Webhooki są często wysyłane z serwerów w chmurze, ale mogą być podrobione. Atakujący może wysłać fałszywy webhook np. z informacją o anulowaniu zamówienia, co zablokuje realizację prawdziwego. Albo powiadomić o płatności, która nie miała miejsca, powodując wysyłkę towaru bez pieniędzy.
Przykład: Sklep używa popularnego bramka płatności. Atakujący nasłuchuje i wysyła spreparowany webhook z fałszywym statusem „udana płatność”. System odbiera go, generuje zamówienie i wysyła towar. Klient nie płaci, a sklep traci produkt i pieniądze.
Rozwiązanie: Zawsze weryfikuj podpis webhooka (np. HMAC z kluczem sekretnym). Sprawdzaj też nagłówek User-Agent i inne charakterystyczne cechy. Nie ufaj żądaniu tylko dlatego, że jest HTTP POST. Warto też ograniczyć akceptowane źródła IP (jeśli możliwe) i logować wszystkie próby.
Podsumowanie
Webhooki są cichym bohaterem nowoczesnego e-commerce, ale tylko wtedy, gdy są poprawnie skonfigurowane. Brak retry, źle zaprojektowane payloady i brak bezpieczeństwa to kosztowne błędy. W JurskiTech regularnie pomagamy firmom audytować i poprawiać ich implementacje webhooków – często wystarczy kilka zmian, by znacząco zwiększyć niezawodność.
Sprawdź swoje webhooki, zanim one sprawdzą Ciebie.
