Dlaczego Twój sklep traci klientów przez złe webhooki? 3 błędy
Webhooki to jeden z tych elementów infrastruktury, które działają w tle i rzadko zwracają uwagę – dopóki coś się nie zepsuje. A gdy się zepsuje, konsekwencje bywają bolesne: utracone zamówienia, zdublowane płatności, opóźnienia w realizacji. W małym e-commerce błędy w webhookach mogą zniszczyć zaufanie klientów, którego budowanie trwało miesiącami.
W tym artykule pokażę trzy typowe błędy, które widzę u klientów, i podpowiem, jak ich uniknąć.
1. Brak obsługi błędów i retry
Większość systemów wysyła webhooka, a jeśli odpowiedź jest błędna – po prostu zapomina o zdarzeniu. To błąd kardynalny. Wyobraź sobie: klient składa zamówienie, płaci, a Ty nie otrzymujesz powiadomienia. System nie aktualizuje stanu magazynowego, nie wysyła potwierdzenia, a klient czeka. Po godzinie dzwoni z pretensjami.
Co robić?
Każdy webhook powinien mieć mechanizm ponawiania (retry) z rosnącymi odstępami czasowymi – np. 1 minuta, 5 minut, 30 minut. Po wyczerpaniu prób – alert do administratora. Dodatkowo warto logować każdą próbę i odpowiedź.
Przykład z życia:
Klient (sklep z odzieżą) stracił 15% zamówień w Black Friday, bo jego bramka płatności wysyłała webhooki raz, a sklep nie sprawdzał, czy dotarły. Po wdrożeniu retry i monitoringu problem zniknął.
2. Brak weryfikacji autentyczności
Webhooki są często atakowane – jeśli nie weryfikujesz, skąd przychodzą, możesz przetwarzać fałszywe zdarzenia. Ktoś może podmienić status płatności, zmienić adres dostawy, a nawet anulować zamówienie.
Co robić?
Każdy webhook powinien zawierać podpis – np. HMAC z tajnym kluczem. Odbiorca musi zweryfikować nagłówek (np. X-Signature) przed przetworzeniem. Bez tego jesteś narażony na ataki.
Przykład z życia:
Widziałem sklep, który przez brak weryfikacji otrzymywał fałszywe webhooki „payment.captured” – system wysyłał towar bez faktycznej płatności. Straty: kilkanaście tysięcy złotych.
3. Brak idempotentności
Idempotentność oznacza, że przetworzenie tego samego webhooka wielokrotnie daje ten sam efekt. Bez niej, jeśli webhook dotrze dwa razy (np. z powodu retry), możesz zdublować zamówienie, wysłać dwa razy ten sam e-mail, naliczyć podwójną płatność.
Co robić?
Każde zdarzenie powinno mieć unikalny identyfikator (event_id). Zanim przetworzysz, sprawdź w bazie, czy już ten identyfikator obsłużyłeś. Jeśli tak – odpowiedz sukcesem, ale nie wykonuj akcji ponownie.
Przykład z życia:
Sklep z elektroniką wysyłał dwa potwierdzenia zamówienia i dwa razy pobierał pieniądze, bo system płatności retransmitował webhooka (błąd sieci). Klienci wściekli, zwroty, obsługa ręczna. Po dodaniu idempotentności – spokój.
Podsumowanie
Webhooki to potężne narzędzie, ale wymagają solidnego fundamentu: retry, weryfikacja i idempotentność. Zbagatelizowanie któregokolwiek z tych elementów prędzej czy później odbije się na Twoich klientach i finansach. Zainwestuj czas w poprawne skonfigurowanie – to się opłaca.
A jeśli potrzebujesz pomocy przy audycie lub wdrożeniu – JurskiTech chętnie spojrzy na Twoją architekturę.
