Dlaczego webhooki w e-commerce rujnują Twoje dane?
Webhooki to dziś standard w e-commerce. Służą do synchronizacji zamówień między sklepem a systemami ERP, powiadamiania klientów o statusie przesyłki, aktualizacji stanów magazynowych w czasie rzeczywistym. Brzmi pięknie. Problem w tym, że większość wdrożeń webhooków to tykająca bomba – prowadzi do uszkodzenia danych, podwójnych zamówień i błędów księgowych. W tym artykule pokażę trzy najczęstsze błędy, jakie widzę u klientów, oraz jak je naprawić.
Błąd 1. Brak idempotencji
Idempotencja to cecha, która sprawia, że wielokrotne wysłanie tego samego żądania nie powoduje wielokrotnych skutków. W przypadku webhooków – jeśli Twój endpoint otrzyma to samo powiadomienie dwa razy, powinien je zignorować. Wydaje się oczywiste? A jednak w praktyce wiele sklepów nie weryfikuje unikalności zdarzenia.
Przykład: Klient składa zamówienie. Webhook o nowym zamówieniu idzie do systemu CRM. System CRM dodaje zamówienie. Problem pojawia się, gdy dostawca webhooków (np. Shopify, WooCommerce) powtórzy wysyłkę – bywa, że z opóźnieniem sieciowym. Twoja aplikacja, nie widząc deduplikacji, tworzy drugi wpis. Skutek? Dwa zamówienia od jednego klienta, które potem trzeba ręcznie scalać. W skali setek zamówień dziennie – chaos.
Jak to naprawić?
Każdy webhook powinien zawierać unikalny identyfikator zdarzenia (event ID). Twój endpoint musi przechowywać historię przetworzonych ID-ów i odrzucać duplikaty. Możesz do tego użyć Redis z TTL lub bazy relacyjnej. Przykład w Node.js:
async function handleWebhook(eventId, data) {
const exists = await db.get("processed:" + eventId);
if (exists) return { status: 200, message: "Already processed" };
// przetwarzanie
await db.set("processed:" + eventId, true, "EX", 86400); // TTL 24h
}
Błąd 2. Brak walidacji źródła
Webhooki to otwarte drzwi. Jeśli nie weryfikujesz, skąd przychodzi żądanie, każdy może wysłać fałszywe dane. Widziałem przypadki, gdzie złośliwy użytkownik wysyłał webhooki z fałszywymi zamówieniami, co powodowało nadpisywanie stanów magazynowych. Inny przykład: webhook o anulowaniu zamówienia wysłany przez atakującego, który skutecznie blokował realizację prawdziwych zamówień.
Standardem jest weryfikacja podpisu (HMAC) lub tokena. Shopify podpisuje swoje webhooki nagłówkiem X-Shopify-Hmac-Sha256. WooCommerce ma filtr woocommerce_webhook_delivery z kluczem. Niestety wiele sklepów tego nie sprawdza, bo „przecież i tak nikt nie zaatakuje, bo po co”. Po to, żeby zepsuć Ci biznes.
Jak to naprawić?
Zawsze weryfikuj sygnaturę. Przykład weryfikacji HMAC dla Shopify:
const crypto = require('crypto');
function verifyShopifyWebhook(req, secret) {
const hmac = req.get('X-Shopify-Hmac-Sha256');
const hash = crypto
.createHmac('sha256', secret)
.update(req.body, 'utf8')
.digest('base64');
return hmac === hash;
}
Nie ufaj też adresowi IP nadawcy – mogą być spoofowane. Zaufaj tylko podpisowi.
Błąd 3. Brak obsługi błędów
Webhooki często zawodzą. Serwer docelowy może być przeciążony, baza offline, albo struktura danych się zmieni. Standardowa implementacja: endpoint odbiera webhook, próbuje coś zrobić, jeśli błąd – zwraca 500. A co dalej? Dostawca webhooków (np. Stripe, Shopify) ponawia próbę po kilku sekundach, ale jeśli błąd się powtarza – po kilku próbach rezygnuje. W efekcie tracisz zdarzenia.
Widziałem przypadek, gdzie sklep używał webhooków Stripe do potwierdzania płatności. Raz na jakiś czas webhook przychodził z opóźnieniem lub duplikatem. System nie był przygotowany na ponowienia – zwracał 500 przy duplikacie. Stripe po kilku nieudanych próbach uznał, że webhook jest martwy i przestał go wysyłać. Klienci płacili, ale zamówienia nie były potwierdzane. W skali miesiąca – kilkadziesiąt utraconych zamówień.
Jak to naprawić?
Twój endpoint powinien zawsze zwracać 200, nawet jeśli wewnętrznie wystąpił błąd (np. baza nie odpowiada). Zapisuj zdarzenie w kolejce (np. RabbitMQ, SQS, Redis) i przetwarzaj asynchronicznie. Gdy przetwarzanie się powiedzie – dopiero wtedy potwierdzaj. Jeśli się nie powiedzie – loguj i alertuj. Nie blokuj dostawcy webhooków.
Przykład architektury z kolejką:
- Endpoint HTTP otrzymuje webhook → zwraca 200 → zapisuje surowe dane w kolejce.
- Worker odczytuje z kolejki → przetwarza (z idempotencją i walidacją) → zapisuje do bazy.
- Jeśli przetwarzanie się nie powiedzie – kolejka automatycznie ponowi próbę (z backoffem).
Dzięki temu nie tracisz żadnego zdarzenia, nawet przy chwilowych problemach.
Podsumowanie
Webhooki to potężne narzędzie, ale wymagają solidnego fundamentu. Brak idempotencji prowadzi do duplikacji danych. Brak walidacji źródła to ryzyko bezpieczeństwa. Brak obsługi błędów powoduje utratę zdarzeń. Każdy z tych błędów kosztuje – czasem pieniądze, czasem zaufanie klientów.
W JurskiTech weryfikujemy webhooki u klientów jako standardowy element audytu. Zbyt wiele firm instaluje gotowe integracje, nie myśląc o konsekwencjach. A potem płaci za to godzinami ręcznej pracy.
Jeśli prowadzisz e-commerce i używasz webhooków – może warto sprawdzić, czy przypadkiem nie siedzisz na bombie?
