{"id":2206,"date":"2026-06-19T11:00:39","date_gmt":"2026-06-19T11:00:39","guid":{"rendered":"https:\/\/news.jurskitech.pl\/blog\/uncategorized\/dlaczego-webhooki-w-e-commerce-rujnuja-twoje-dane\/"},"modified":"2026-06-19T11:00:39","modified_gmt":"2026-06-19T11:00:39","slug":"dlaczego-webhooki-w-e-commerce-rujnuja-twoje-dane","status":"publish","type":"post","link":"https:\/\/news.jurskitech.pl\/blog\/warto-wiedziec\/dlaczego-webhooki-w-e-commerce-rujnuja-twoje-dane\/","title":{"rendered":"Dlaczego webhooki w e-commerce rujnuj\u0105 Twoje dane?"},"content":{"rendered":"<h2 id=\"dlaczegowebhookiwecommercerujnujtwojedane\">Dlaczego webhooki w e-commerce rujnuj\u0105 Twoje dane?<\/h2>\n<p>Webhooki to dzi\u015b standard w e-commerce. S\u0142u\u017c\u0105 do synchronizacji zam\u00f3wie\u0144 mi\u0119dzy sklepem a systemami ERP, powiadamiania klient\u00f3w o statusie przesy\u0142ki, aktualizacji stan\u00f3w magazynowych w czasie rzeczywistym. Brzmi pi\u0119knie. Problem w tym, \u017ce wi\u0119kszo\u015b\u0107 wdro\u017ce\u0144 webhook\u00f3w to tykaj\u0105ca bomba \u2013 prowadzi do uszkodzenia danych, podw\u00f3jnych zam\u00f3wie\u0144 i b\u0142\u0119d\u00f3w ksi\u0119gowych. W tym artykule poka\u017c\u0119 trzy najcz\u0119stsze b\u0142\u0119dy, jakie widz\u0119 u klient\u00f3w, oraz jak je naprawi\u0107.<\/p>\n<h3 id=\"bd1brakidempotencji\">B\u0142\u0105d 1. Brak idempotencji<\/h3>\n<p>Idempotencja to cecha, kt\u00f3ra sprawia, \u017ce wielokrotne wys\u0142anie tego samego \u017c\u0105dania nie powoduje wielokrotnych skutk\u00f3w. W przypadku webhook\u00f3w \u2013 je\u015bli Tw\u00f3j endpoint otrzyma to samo powiadomienie dwa razy, powinien je zignorowa\u0107. Wydaje si\u0119 oczywiste? A jednak w praktyce wiele sklep\u00f3w nie weryfikuje unikalno\u015bci zdarzenia.<\/p>\n<p>Przyk\u0142ad: Klient sk\u0142ada zam\u00f3wienie. Webhook o nowym zam\u00f3wieniu idzie do systemu CRM. System CRM dodaje zam\u00f3wienie. Problem pojawia si\u0119, gdy dostawca webhook\u00f3w (np. Shopify, WooCommerce) powt\u00f3rzy wysy\u0142k\u0119 \u2013 bywa, \u017ce z op\u00f3\u017anieniem sieciowym. Twoja aplikacja, nie widz\u0105c deduplikacji, tworzy drugi wpis. Skutek? Dwa zam\u00f3wienia od jednego klienta, kt\u00f3re potem trzeba r\u0119cznie scala\u0107. W skali setek zam\u00f3wie\u0144 dziennie \u2013 chaos.<\/p>\n<p><strong>Jak to naprawi\u0107?<\/strong><\/p>\n<p>Ka\u017cdy webhook powinien zawiera\u0107 unikalny identyfikator zdarzenia (event ID). Tw\u00f3j endpoint musi przechowywa\u0107 histori\u0119 przetworzonych ID-\u00f3w i odrzuca\u0107 duplikaty. Mo\u017cesz do tego u\u017cy\u0107 Redis z TTL lub bazy relacyjnej. Przyk\u0142ad w Node.js:<\/p>\n<pre><code class=\"javascript language-javascript\">async function handleWebhook(eventId, data) {\n  const exists = await db.get(\"processed:\" + eventId);\n  if (exists) return { status: 200, message: \"Already processed\" };\n  \/\/ przetwarzanie\n  await db.set(\"processed:\" + eventId, true, \"EX\", 86400); \/\/ TTL 24h\n}\n<\/code><\/pre>\n<h3 id=\"bd2brakwalidacjirda\">B\u0142\u0105d 2. Brak walidacji \u017ar\u00f3d\u0142a<\/h3>\n<p>Webhooki to otwarte drzwi. Je\u015bli nie weryfikujesz, sk\u0105d przychodzi \u017c\u0105danie, ka\u017cdy mo\u017ce wys\u0142a\u0107 fa\u0142szywe dane. Widzia\u0142em przypadki, gdzie z\u0142o\u015bliwy u\u017cytkownik wysy\u0142a\u0142 webhooki z fa\u0142szywymi zam\u00f3wieniami, co powodowa\u0142o nadpisywanie stan\u00f3w magazynowych. Inny przyk\u0142ad: webhook o anulowaniu zam\u00f3wienia wys\u0142any przez atakuj\u0105cego, kt\u00f3ry skutecznie blokowa\u0142 realizacj\u0119 prawdziwych zam\u00f3wie\u0144.<\/p>\n<p>Standardem jest weryfikacja podpisu (HMAC) lub tokena. Shopify podpisuje swoje webhooki nag\u0142\u00f3wkiem <code>X-Shopify-Hmac-Sha256<\/code>. WooCommerce ma filtr <code>woocommerce_webhook_delivery<\/code> z kluczem. Niestety wiele sklep\u00f3w tego nie sprawdza, bo \u201eprzecie\u017c i tak nikt nie zaatakuje, bo po co&#8221;. Po to, \u017ceby zepsu\u0107 Ci biznes.<\/p>\n<p><strong>Jak to naprawi\u0107?<\/strong><\/p>\n<p>Zawsze weryfikuj sygnatur\u0119. Przyk\u0142ad weryfikacji HMAC dla Shopify:<\/p>\n<pre><code class=\"javascript language-javascript\">const crypto = require('crypto');\n\nfunction verifyShopifyWebhook(req, secret) {\n  const hmac = req.get('X-Shopify-Hmac-Sha256');\n  const hash = crypto\n    .createHmac('sha256', secret)\n    .update(req.body, 'utf8')\n    .digest('base64');\n  return hmac === hash;\n}\n<\/code><\/pre>\n<p>Nie ufaj te\u017c adresowi IP nadawcy \u2013 mog\u0105 by\u0107 spoofowane. Zaufaj tylko podpisowi.<\/p>\n<h3 id=\"bd3brakobsugibdw\">B\u0142\u0105d 3. Brak obs\u0142ugi b\u0142\u0119d\u00f3w<\/h3>\n<p>Webhooki cz\u0119sto zawodz\u0105. Serwer docelowy mo\u017ce by\u0107 przeci\u0105\u017cony, baza offline, albo struktura danych si\u0119 zmieni. Standardowa implementacja: endpoint odbiera webhook, pr\u00f3buje co\u015b zrobi\u0107, je\u015bli b\u0142\u0105d \u2013 zwraca 500. A co dalej? Dostawca webhook\u00f3w (np. Stripe, Shopify) ponawia pr\u00f3b\u0119 po kilku sekundach, ale je\u015bli b\u0142\u0105d si\u0119 powtarza \u2013 po kilku pr\u00f3bach rezygnuje. W efekcie tracisz zdarzenia.<\/p>\n<p>Widzia\u0142em przypadek, gdzie sklep u\u017cywa\u0142 webhook\u00f3w Stripe do potwierdzania p\u0142atno\u015bci. Raz na jaki\u015b czas webhook przychodzi\u0142 z op\u00f3\u017anieniem lub duplikatem. System nie by\u0142 przygotowany na ponowienia \u2013 zwraca\u0142 500 przy duplikacie. Stripe po kilku nieudanych pr\u00f3bach uzna\u0142, \u017ce webhook jest martwy i przesta\u0142 go wysy\u0142a\u0107. Klienci p\u0142acili, ale zam\u00f3wienia nie by\u0142y potwierdzane. W skali miesi\u0105ca \u2013 kilkadziesi\u0105t utraconych zam\u00f3wie\u0144.<\/p>\n<p><strong>Jak to naprawi\u0107?<\/strong><\/p>\n<p>Tw\u00f3j endpoint powinien zawsze zwraca\u0107 200, nawet je\u015bli wewn\u0119trznie wyst\u0105pi\u0142 b\u0142\u0105d (np. baza nie odpowiada). Zapisuj zdarzenie w kolejce (np. RabbitMQ, SQS, Redis) i przetwarzaj asynchronicznie. Gdy przetwarzanie si\u0119 powiedzie \u2013 dopiero wtedy potwierdzaj. Je\u015bli si\u0119 nie powiedzie \u2013 loguj i alertuj. Nie blokuj dostawcy webhook\u00f3w.<\/p>\n<p>Przyk\u0142ad architektury z kolejk\u0105:<\/p>\n<ol>\n<li>Endpoint HTTP otrzymuje webhook \u2192 zwraca 200 \u2192 zapisuje surowe dane w kolejce.<\/li>\n<li>Worker odczytuje z kolejki \u2192 przetwarza (z idempotencj\u0105 i walidacj\u0105) \u2192 zapisuje do bazy.<\/li>\n<li>Je\u015bli przetwarzanie si\u0119 nie powiedzie \u2013 kolejka automatycznie ponowi pr\u00f3b\u0119 (z backoffem).<\/li>\n<\/ol>\n<p>Dzi\u0119ki temu nie tracisz \u017cadnego zdarzenia, nawet przy chwilowych problemach.<\/p>\n<h3 id=\"podsumowanie\">Podsumowanie<\/h3>\n<p>Webhooki to pot\u0119\u017cne narz\u0119dzie, ale wymagaj\u0105 solidnego fundamentu. Brak idempotencji prowadzi do duplikacji danych. Brak walidacji \u017ar\u00f3d\u0142a to ryzyko bezpiecze\u0144stwa. Brak obs\u0142ugi b\u0142\u0119d\u00f3w powoduje utrat\u0119 zdarze\u0144. Ka\u017cdy z tych b\u0142\u0119d\u00f3w kosztuje \u2013 czasem pieni\u0105dze, czasem zaufanie klient\u00f3w.<\/p>\n<p>W JurskiTech weryfikujemy webhooki u klient\u00f3w jako standardowy element audytu. Zbyt wiele firm instaluje gotowe integracje, nie my\u015bl\u0105c o konsekwencjach. A potem p\u0142aci za to godzinami r\u0119cznej pracy.<\/p>\n<p>Je\u015bli prowadzisz e-commerce i u\u017cywasz webhook\u00f3w \u2013 mo\u017ce warto sprawdzi\u0107, czy przypadkiem nie siedzisz na bombie?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dlaczego webhooki w e-commerce rujnuj\u0105 Twoje dane? Webhooki to dzi\u015b standard w e-commerce. S\u0142u\u017c\u0105 do synchronizacji zam\u00f3wie\u0144 mi\u0119dzy sklepem a systemami ERP, powiadamiania klient\u00f3w o statusie przesy\u0142ki, aktualizacji stan\u00f3w magazynowych w czasie rzeczywistym. Brzmi pi\u0119knie. Problem w tym, \u017ce wi\u0119kszo\u015b\u0107 wdro\u017ce\u0144 webhook\u00f3w to tykaj\u0105ca bomba \u2013 prowadzi do uszkodzenia danych, podw\u00f3jnych zam\u00f3wie\u0144 i b\u0142\u0119d\u00f3w ksi\u0119gowych.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[776,4,683,349],"class_list":["post-2206","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-ai-e-commerce","tag-automatyzacja","tag-bezpieczenstwo-ai","tag-webhooki"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2206","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2206"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2206\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2206"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2206"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2206"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}