Webhooki w e-commerce: 3 błędy, które rujnują integracje
Webhooki to jeden z tych mechanizmów, które wydają się banalnie proste: system A wysyła żądanie HTTP do systemu B, gdy wydarzy się coś ważnego. W teorii – zero filozofii. W praktyce – to właśnie tutaj wiele sklepów e-commerce traci zamówienia, pieniądze i zaufanie klientów.
Obserwuję, że wdrożenia webhooków często wyglądają jak klecenie na szybko, bez myślenia o awariach, retry’ach czy bezpieczeństwie. A potem: zamówienie wpada, ale nie trafia do systemu magazynowego, płatność przechodzi, ale status nie jest aktualizowany, a klient dostaje maila z potwierdzeniem, którego nie powinien był dostać. Brzmi znajomo?
Poniżej trzy realne błędy, które regularnie widzę we wdrożeniach webhooków – i jak je naprawić, zanim zaczną kosztować.
Błąd #1: Brak retry i idempotentności
To najczęstszy grzech. Zakładasz, że każdy webhook dotrze idealnie. Rzeczywistość: sieć bywa kapryśna, serwer odbiorcy może być przeciążony, a baza danych akurat w trakcie backupu. Jeśli Twój webhook nie ma mechanizmu ponawiania (retry) i nie jest idempotentny (czyli wielokrotne przetworzenie tego samego zdarzenia daje ten sam skutek), to masz problem.
Przykład: Klient składa zamówienie, wysyłasz webhook do systemu ERP. ERP jest chwilowo niedostępny – webhook przepada. Zamówienie wisi w próżni: klient dostał potwierdzenie, ale towar nie został zarezerwowany, a Ty dowiadujesz się o tym dopiero przy wysyłce. Złe.
Rozwiązanie: Każdy webhook powinien mieć kolejkę retry z wykładniczym backoffem (np. po 1s, 10s, 100s) i limitem prób. Dodatkowo każde zdarzenie powinno mieć unikalne ID, które odbiorca sprawdza – jeśli już przetworzył to ID, ignoruje duplikat. To proste, a oszczędza nerwów.
Błąd #2: Brak walidacji podpisu
Webhooki to otwarte zaproszenie dla ataków, jeśli nie zabezpieczysz ich podpisem. Wyobraź sobie, że ktoś wysyła fałszywy webhook „zamówienie anulowane” do Twojego systemu, a Ty to akceptujesz. Albo jeszcze gorzej – „płatność zwrócona”.
Widziałem sklep, który używał webhooków z bramki płatności, ale nie weryfikował sygnatury. Wystarczyło, że ktoś poznał URL webhooka (często jest stały), żeby wywołać chaos. Na szczęście skończyło się na strachu, ale mogło skończyć się stratą pieniędzy.
Rozwiązanie: Zawsze weryfikuj podpis HMAC lub inne mechanizmy kryptograficzne dostarczone przez nadawcę. Sprawdzaj, czy żądanie pochodzi z zaufanego źródła. To kilka linijek kodu, a różnica między bezpieczeństwem a katastrofą.
Błąd #3: Zbyt wąskie logowanie i monitoring
Webhooki często działają w tle – dopóki działają, nikt o nich nie myśli. Problem w tym, że gdy przestają działać, dowiadujesz się od rozzłoszczonego klienta, a nie z logów. Firmy rzadko logują szczegóły żądań webhooków, a jeśli już, to tylko sukcesy. Błędy giną w czeluściach konsoli.
Przykład: Webhook od dostawcy płatności nagle zaczął przychodzić z opóźnieniem, bo zmienili endpoint. Twój system nie odnotował błędu, bo logowałeś tylko status 200. Przez tydzień zamówienia były realizowane z opóźnieniem, zanim ktoś to zauważył.
Rozwiązanie: Loguj każde żądanie webhooka – zarówno sukcesy, jak i błędy – z pełnym payloadem i nagłówkami. Ustaw alerty na spodziewane wzorce: jeśli w ciągu godziny nie przyszedł żaden webhook od kluczowego systemu, dostajesz powiadomienie. Monitoring to podstawa.
Podsumowanie
Webhooki to nie jest rocket science. Ale to jeden z tych elementów, który albo działa perfekcyjnie, albo cicho sypie gruz pod dywan. Wdrożenie retry, weryfikacja podpisu i porządne logowanie to trzy rzeczy, które od razu podniosą niezawodność Twojego e-commerce.
Jeśli prowadzisz sklep i opierasz się na automatyzacjach, ale nie masz pewności, czy Twoje webhooki są dobrze skonfigurowane – warto to sprawdzić. Z doświadczenia wiem, że te trzy błędy są najczęstsze i jednocześnie najłatwiejsze do naprawienia. A różnica w spokoju głowy jest ogromna.
