Czym są integracje z ERP, płatnościami i kurierami w firmie

To trzy niezależne warstwy, nie jeden projekt. ERP (Subiekt, Comarch ERP Optima, WF-Mag, SAP Business One) pilnuje stanów magazynowych, wystawia faktury i przyjmuje zamówienia. Integracja płatności (Przelewy24, PayU, tpay, Stripe) autoryzuje transakcję i potwierdza, że środki faktycznie wpłynęły. Integracja kurierska (InPost, DPD, DHL, GLS) generuje etykietę, nadaje numer przesyłki i zwraca status doręczenia. Każdą warstwę da się wdrożyć osobno – najczęściej zaczyna się od płatności, bo zakres jest najmniejszy i efekty widać od razu.

Integracja natywna to moduł do PrestaShop albo wtyczka WooCommerce instalowana z panelu, z konfiguracją w kilku polach (klucz API, ID punktu, strefa wysyłki). Zaletą jest szybki start, wadą – każde ERP ma własny moduł i przy zmianie systemu konfigurację przepisujesz od zera. Takie wtyczki są opisane w dokumentacji WooCommerce. Integracja przez middleware to osobna usługa (własny serwis pośredniczący albo gotowy integrator) z kolejką zdarzeń i tabelą mapowania pól. Drożej na starcie, ale jedno miejsce do zmiany, gdy dojdzie drugi kanał sprzedaży.

Przykład z życia: piątek, 14:07, klient kupuje 2 sztuki. Sklep tworzy zamówienie (t=0) i przekazuje je do ERP. W ciągu 2–10 sekund ERP rezerwuje 2 sztuki i zwraca realny stan – jeśli na magazynie było 7, po rezerwacji system pokazuje 5 dostępnych. Bramka płatności autoryzuje transakcję i wysyła webhook. Kurier w tym momencie nie robi jeszcze nic: etykieta powstanie dopiero po statusie „spakowane”.

Koszt braku integracji policz na sekundach. Przy 30 zamówieniach dziennie i ok. 30 sekundach na przepisanie danych klienta, adresu i pozycji daje to 15 minut dziennie, czyli około 6–8 godzin miesięcznie. To praca, którą da się zautomatyzować. Cały proces poukładany warstwa po warstwie opisujemy w artykule o tym, jak działają integracje z ERP, płatnościami i kurierami.

Pełny przepływ zamówienia: sklep → ERP → płatność → kurier

Kolejność zdarzeń jest ważniejsza niż sama lista integracji. Typowy przepływ wygląda tak:

• t = 0 – sklep tworzy zamówienie, status „oczekiwanie na płatność”, e-mail do klienta.
• t + 2–10 s – dane lecą do ERP (API albo plik wymiany). ERP rezerwuje 2 sztuki i zwraca numer dokumentu oraz realny stan magazynowy.
• t + kilka sekund do minut – bramka płatności księguje transakcję i odsyła webhook. Sklep zmienia status na „opłacone / w realizacji”.
• t + pakowanie – magazyn ustawia „spakowane”. Dopiero to zdarzenie wywołuje API kuriera: powstaje etykieta PDF i numer przesyłki, zapisywany w polu tracking zamówienia.
• t + 1–3 dni – webhook przewoźnika zwraca „doręczone”, ERP dostaje informację o wydaniu towaru.

Najczęściej urywa się między drugim a trzecim punktem. Gdy płatność nie dojdzie (klient zamknął BLIK, przelew się nie zaksięgował), zamówienie wisi w statusie „oczekiwanie”, a towar jest zarezerwowany w ERP. Magazyn widzi zaniżony stan i nie sprzeda tych dwóch sztuk. Rozwiązanie: zadanie cron, które po 30–60 minutach dla płatności natychmiastowych (albo po 24 h dla przelewu tradycyjnego) odwołuje rezerwację i ustawia status „anulowane – brak płatności”. Bez tego po weekendzie powstaje sztuczny brak towaru.

Źródłem prawdy dla stanu magazynowego jest ERP, nie sklep. Sklep trzyma wyłącznie kopię, odświeżaną po każdej zmianie. Konfiguracja odwrotna – sklep nadrzędny, ERP jako kopiujący – kończy się sprzedażą towaru, którego fizycznie nie ma, i korektami oraz przeprosinami do klientów.

Statusy to osobny projekt. Trzy systemy mają trzy słowniki: sklep używa własnych statusów (w PrestaShop to identyfikatory order_state, w WooCommerce nazwy statusów), ERP ma dokumenty w buforze, potwierdzone i zafakturowane, a przewoźnik operuje statusami przesyłki. Mapowanie trzeba rozpisać w tabeli i przetestować na zamówieniu testowym. Warto zerknąć w dokumentację dla deweloperów PrestaShop przy własnych modułach, a integracje API są tematem naszego huba integracji API.

Integracja z ERP: API, pliki wymiany czy middleware

To decyzja o koszcie i opóźnieniu, nie o „nowoczesności”. Trzy warianty w praktyce:

• API REST/SOAP – najbardziej elastyczne. Zamówienie trafia do ERP w sekundach, stany wracają na bieżąco. Wymaga wystawionego API po stronie ERP i uwierzytelnienia (klucz, token, czasem VPN).
• Wymiana plików CSV/XML przez FTP lub katalog na serwerze – najtańsza. Sklep zapisuje plik zamówienia, ERP go importuje co 5–30 minut. Prosta w utrzymaniu, ale stany magazynowe są zawsze spóźnione.
• Middleware / kolejka zdarzeń – najdroższa, za to odporna na awarie. Jeśli ERP nie odpowiada, zdarzenia czekają w kolejce i zostaną przetworzone po restarcie, zamiast przepaść.

W polskich MŚP najczęściej spotkasz Subiekt GT i nexo (InsERT), Comarch ERP Optima, WF-Mag, SAP Business One oraz Fakturownia. Zakres możliwości różni się nawet między wersjami tego samego produktu, dlatego przed wyceną trzeba potwierdzić u dostawcy, jakie API (albo moduł integracyjny typu Sfera) jest dostępny w twojej licencji i czy pozwala na dostęp z zewnątrz. WF-Mag w wielu wdrożeniach kończy się na wymianie plików i to jest zupełnie wystarczające.

Kryteria wyboru: liczba zamówień na dobę, tolerancja opóźnienia synchronizacji oraz to, czy ERP działa w chmurze, czy on-premise. Przy serwerze lokalnym ktoś musi otworzyć firewall, wystawić stałe IP albo tunel VPN – i zostaje na dyżurze, gdy to padnie. Osobna pozycja to KSeF: obowiązkowe e-fakturowanie w 2026 r. i tak wymusi integrację sklepu lub ERP z systemem księgowym. Jeśli planujesz to na przyszły rok, sensowniej zaprojektować jedną integrację obejmującą faktury, niż dokładać drugą osobno.

Integracje płatności: BLIK, bramki, pay-by-link i obsługa nieudanych transakcji

Integracja płatności to nie „wklejenie klucza API”. Klucz to początek. Cała robota polega na obsłużeniu zdarzeń, które przychodzą asynchronicznie, niezależnie od tego, co w tym momencie robi klient w przeglądarce.

Webhook jest podstawą. Status „opłacone” ustawia żądanie POST z serwera bramki na Twój endpoint, a nie powrót klienta na stronę podziękowania. Ten powrót zawodzi w 5–15% przypadków: klient zamknął kartę, adblock zablokował skrypt, bank wrócił na innej karcie przeglądarki, telefon stracił sieć. Sklep, który opiera się wyłącznie na powrocie klienta, trzyma co dziesiąte zamówienie w statusie „oczekuje na płatność”, mimo że pieniądze są na koncie.

Metody. W B2C w Polsce pierwszym wyborem jest BLIK, dalej Przelewy24, PayU, Tpay i Autopay. Stripe ma sens, gdy sprzedajesz za granicę albo prowadzisz subskrypcje — karty i obsługa odnowień są tam wygodniejsze. Dla klientów B2B płacących z konta firmowego działa pay-by-link: generujesz link do konkretnej płatności i wysyłasz go mailem razem z proformą. Klient płaci zwykłym przelewem, a Ty i tak dostajesz webhook i wiesz, kiedy pieniądze wpłynęły.

Dwie rzeczy do zaprojektowania od początku:

• Idempotencja. Bramka może dostarczyć to samo zdarzenie dwa razy, np. gdy nie doczeka się odpowiedzi 200 w limicie czasu i ponowi próbę. ID transakcji bramki musi mieć unikalny indeks w bazie. Bez tego dostaniesz duplikat zamówienia albo duplikat faktury.
• Podpis webhooka. Bramki podpisują żądania (HMAC w nagłówku). Weryfikuj podpis przed zmianą statusu. Endpoint bez weryfikacji to otwarte drzwi — każdy może wysłać POST i oznaczyć zamówienie jako opłacone.

PSD2/SCA. Przy kartach bank może wymusić dodatkowe uwierzytelnienie. Klient wychodzi do banku i wraca — poinformuj go o tym wprost na ekranie płatności i zadbaj, żeby powrót trafiał na stronę zamówienia, nie na 404. Inaczej porzuci koszyk w połowie drogi.

Odzyskiwanie. Uruchom cron raz na dobę: pobierz z API bramki transakcje z ostatnich 24–48 godzin i porównaj z zamówieniami o statusie „oczekuje na płatność”. Gdzie bramka mówi „sukces”, a sklep nie — oznacz opłacone i wygeneruj fakturę. Kilkadziesiąt linii kodu, a ratuje przychód, którego nie zobaczysz w żadnym raportem.

Konfigurację webhooków i bramek po stronie sklepu opisuje dokumentacja WooCommerce, a punktem startu dla całego obszaru są integracje API.

Integracje kurierskie: InPost, DPD, DHL, a także GLS i Poczta

Zanim zadzwonisz do wykonawcy, zamknij temat umowy z kurierem. Dostęp do API jest zwykle powiązany z podpisaną umową i numerem klienta (InPost ShipX, DPD WebAPI, DHL24 i analogicznie u GLS czy Poczty). Bez tych danych nie wystawisz etykiety produkcyjnej, choćby kod był gotowy i przetestowany na sucho.

Każda integracja kurierska musi robić trzy rzeczy:

• generować etykietę (PDF do drukarki biurowej albo ZPL do termicznej),
• nadawać numer przesyłki i zapisywać go przy zamówieniu,
• pobierać statusy i aktualizować zamówienie — „wysłane”, „doręczone”, „zwrot do nadawcy”.

Jeśli zabraknie trzeciego punktu, pracownik i tak będzie codziennie wchodził na stronę kuriera i sprawdzał listę paczek ręcznie. To najczęstsza fałszywa oszczędność w tym obszarze.

Tryby pracy. Pełna automatyzacja przez API kontra półautomatyczne wgrywanie pliku CSV z listą paczek. CSV wystarcza, gdy wysyłasz kilkanaście–kilkadziesiąt paczek dziennie, masz jednego kuriera i nie potrzebujesz statusów w sklepie. Automatyzacja zwraca się, gdy paczek jest więcej, gdy pracuje kilka osób albo gdy klient ma widzieć status przesyłki w panelu zamówienia.

Paczkomaty i punkty odbioru. Pobierz listę punktów przez API i trzymaj ją w cache — odświeżanie raz na dobę wystarcza. Kod wybranego punktu zapisuj przy zamówieniu i waliduj przed zapisem: jeśli punkt został zamknięty albo kod jest nieaktualny, etykieta się nie wygeneruje, a zamówienie utknie w kolejce. Dobra praktyka: blokuj przycisk „Zapłać” do momentu potwierdzenia kodu punktu.

Zwroty i podmiany. Zapytaj wprost, czy API kuriera obsługuje etykiety zwrotne i kto za nie płaci. Nie zakładaj, że skoro jest etykieta nadania, to jest i zwrotna — to pytanie do przedstawiciela handlowego kuriera, nie do wykonawcy integracji.

Ile to kosztuje i ile trwa — realne widełki dla MŚP

Pytanie o koszt pada zwykle pierwsze, więc odpowiedz sobie na nie sam, jeszcze przed rozmową z wykonawcą. Widełki poniżej dotyczą typowego sklepu MŚP na PrestaShopie albo WooCommerce, bez przepisywania ERP.

• prosta integracja jednego kuriera przez gotowy moduł: 8–20 h,
• płatności z webhookami, idempotencją i reconciliation: 16–40 h,
• integracja ERP z niestandardowym mapowaniem pól: 40–120 h.

Czas kalendarzowy to inna liczba niż godziny. Dla zestawu ERP + płatności + kurier w typowym sklepie MŚP licz 3–6 tygodni. Połowa tego czasu to testy i uzgodnienia z kurierem: czekanie na dane dostępowe, na wzór etykiety, na odpowiedź opiekuna handlowego. Sam kod idzie szybciej niż otoczenie.

Testy. Środowiska sandbox są darmowe i nie generują prawdziwych kosztów wysyłki. Jeśli chcesz mieć drugą instancję sklepu, żeby testować integracje bez ryzyka dla produkcji, policz 2–5 h miesięcznie na jej utrzymanie — aktualizacje, kopie bazy, odświeżanie danych.

Własny moduł czy płatna wtyczka? Prosta reguła: podziel koszt budowy modułu przez miesięczny abonament wtyczki. Jeśli wychodzi 8–14 miesięcy, własny moduł wygrywa. Dotyczy to głównie nietypowych reguł — np. podziału zamówienia na kilka paczek, osobnych etykiet dla pozycji z różnych magazynów, własnej logiki stanów magazynowych. Przy zwykłym sklepie wtyczka jest tańsza i szybciej się aktualizuje, gdy kurier zmieni API.

Co wchodzi w wycenę: analiza procesu, mapowanie pól, kod lub konfiguracja modułu, testy, wdrożenie na produkcję, dokumentacja i krótkie szkolenie zespołu. Co jest poza: licencje ERP i moduły API po stronie ERP, opłaty kuriera (cennik i dopłaty), prowizje bramki płatniczej, koszt serwera i powiadomień SMS/mailowych. Te pozycje policz osobno — przy dużym obrocie prowizje potrafią w skali roku przewyższyć koszt samego wdrożenia.

Jeśli zamierzasz budować własny moduł do PrestaShop, punktem startu jest dokumentacja deweloperska PrestaShop — struktura modułu, hooki i kolejność wczytywania. Kolejność etapów opisaliśmy też w artykule o integracjach z ERP, płatnościami i kurierami.

Szczecin i okolice: jak wygląda wsparcie techniczne po wdrożeniu

Większość prac przy integracjach wykonuje się zdalnie i to jest normalne. Dostęp przez VPN do serwera, SSH, panel sklepu i logi wystarczają, żeby wdrożyć albo naprawić połączenie z ERP, bramką płatniczą czy API kuriera. Odległość między Szczecinem a wykonawcą nie zmienia niczego poza godziną, o której trzeba wstać. Znaczenie mają dwie inne rzeczy: strefa czasowa drugiej strony (jeśli ERP lub helpdesk pracują w innym czasie, okno wsparcia się rozjeżdża) oraz aktualny dostęp do VPN klienta — tokeny wygasają, konta serwisowe bywają blokowane, a 2FA potrafi zatrzymać diagnostykę na kilkadziesiąt minut.

Wizyta na miejscu faktycznie coś wnosi w trzech sytuacjach:

• praca przy serwerowni klienta — szafa rack, macierz, przełącznik, konsola KVM;
• magazyn i drukarki etykiet — Zebra, terminale kolektorów, sieć Wi-Fi, która „gubi” wydruki;
• szkolenie zespołu przy stanowisku pakowania — dwie godziny na miejscu są tańsze niż tydzień maili.

Umowa o opiekę techniczną musi mieć liczby, nie akapity o „elastycznym podejściu”: czas reakcji, czas obejścia problemu, czas naprawy i kanał zgłoszeń — helpdesk z numerem zgłoszenia, a nie mail do prezesa. Monitoring jest częścią SLA: alert, gdy webhooki płatności nie przychodzą dłużej niż 30 minut, gdy kolejka ERP przekracza próg (np. 50 wiadomości) albo rośnie przez 15 minut, gdy cron się nie wykonał, gdy API kuriera zwraca błędy 5xx. Zakres takich prac opisujemy przy usłudze integracje API.

Piątek, 18:00, etykiety się nie generują. Kolejność dla osób nietechnicznych: 1) sprawdź status płatności zamówienia; 2) zaloguj się ręcznie do panelu kuriera i sprawdź, czy działa; 3) sprawdź, czy zamówienie ma status kolejki do wysyłki; 4) wystaw etykietę ręcznie, żeby paczka nie czekała do poniedziałku; 5) zgłoś problem z numerem zamówienia i godziną zdarzenia. Reszta to robota wykonawcy.

Pułapki, które kosztują najwięcej — i jak je wykryć

Te błędy pojedynczo nie wyglądają groźnie. Kosztują, gdy trwają tygodniami i nikt ich nie mierzy.

Duplikaty zamówień i faktur. Objaw: klient klika „Zapłać” raz, a do ERP wpadają dwa zamówienia i dwie faktury. Przyczyna: brak idempotencji i powtórzony webhook po timeoucie — temat webhooków opisuje dokumentacja WooCommerce. Wykrycie: w bazie sklepu porównaj identyfikator sesji lub transakcji płatności, np. zapytaniem SELECT payment_id, COUNT(*) FROM orders GROUP BY payment_id HAVING COUNT(*) > 1. Każdy wynik to para do sprawdzenia i anulowania w ERP.

Rozjechane stany magazynowe. Objaw: sprzedajesz towar, którego nie ma. Wykrycie: nocny cron (np. 3:00) pobiera liczbę sztuk z ERP i ze sklepu, zapisuje różnice do CSV i wysyła raport mailem, jeśli różnica jest inna niż zero. Dla SKU o wysokiej rotacji tolerancja powinna wynosić zero.

Timeouty API kuriera w szczycie. Objaw: o 16:00 paczki nie mają etykiet, API zwraca 504. Rozwiązanie: nie wołaj API synchronicznie przy składaniu zamówienia — wrzuć zadanie do kolejki (Redis, RabbitMQ) i ponawiaj z rosnącym opóźnieniem (1 s, 2 s, 4 s, 8 s, maksymalnie 5 prób). Magazyn widzi status „w kolejce”, a etykieta pojawia się minutę później, nie nigdy.

Brak centralnego logu. Objaw: „nie wiem, czy zamówienie poszło do ERP”. Rozwiązanie: jeden log ze znacznikiem korelacji (numer zamówienia + identyfikator koszyka) i wpisem na każdym kroku: płatność → sklep → ERP → kurier.

Ciche błędy mapowania. Pole „uwagi do zamówienia” dłuższe niż 255 znaków zostaje ucięte w ERP razem z kodem rabatowym albo numerem paczkomatu. Waliduj długość przed wysyłką i loguj ostrzeżenie.

Testy na produkcji. Objaw: prawdziwe etykiety z prawdziwymi numerami przy testach. Rozwiązanie: sandbox kuriera lub konto testowe i przedrostek KLIENT-TEST w numerze zamówienia. Jak wygląda poprawnie zbudowany przepływ, opisujemy w artykule o integracjach z ERP, płatnościami i kurierami.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Liczba zamówień na dobę — Policz zamówienia z ostatnich 30 dni i podziel przez dni robocze. Poniżej 20 zamówień dziennie łatwiej zacząć od wymiany plików, powyżej 100 — od API.
• Tolerancja opóźnienia synchronizacji — Ustal, czy sprzedaż tego samego towaru w dwóch kanałach w ciągu 15 minut jest realnym ryzykiem. Jeśli tak, wymiana plików co 30 minut odpada.
• ERP w chmurze czy na serwerze w firmie — Sprawdź, gdzie stoi baza. Przy instalacji lokalnej ktoś musi udostępnić port lub postawić VPN — ustal z administratorem, kto i kiedy to zrobi.
• Właściciel stanu magazynowego — Zapisz na piśmie, że ERP jest źródłem prawdy, a sklep kopią. Bez tej decyzji każdy kolejny etap integracji będzie wracał do punktu wyjścia.
• Tabela mapowania statusów — Wypisz statusy sklepu, ERP i zdarzenia kuriera w jednej tabeli. Sprawdź, czy każdy status sklepu ma jasne przejście dalej i czy żaden nie kończy się bez akcji.
• Realnie używane metody płatności — Sprawdź w statystykach bramki udział BLIK i przelewów online. Wyłącz te metody, których nikt nie używa — każda to osobny scenariusz do przetestowania.
• Webhooki bramki na środowisku testowym — Wykonaj płatność testową, wyłącz kartę, nie wracaj na stronę sklepu i sprawdź, czy status zamówienia zmienił się sam w ciągu minuty.
• Scenariusz nieudanej płatności z zegarem — Zostaw nieopłacone zamówienie i zmierz, po ilu minutach rezerwacja w ERP znika. Jeśli nie znika, masz odpowiedź, dlaczego stany się rozjeżdżają.
• Zwroty i korekty — Sprawdź, czy integracja przenosi zwrot do ERP i czy korekta faktury wraca do sklepu. To najczęściej pomijany fragment wdrożenia.
• Dokumentacja API dostawcy ERP — Ustal wersję API, limity zapytań na minutę i sposób uwierzytelniania. Bez tego nie da się ocenić, czy integracja wytrzyma szczyt przedświąteczny.
• Logi i odtwarzalność — Sprawdź, czy po awarii połączenia da się odtworzyć, które zamówienia i faktury nie przeszły. Poproś o pokazanie przykładowego logu, nie o zapewnienie, że logi są.
• Monitoring i osoba odpowiedzialna — Ustal, kto dostaje alert, gdy kolejka rośnie albo API zwraca błędy. Integracja bez właściciela po stronie firmy działa do pierwszej awarii.
• KSeF i e-fakturowanie — Sprawdź, czy Twój ERP obsługuje wystawianie i wysyłkę faktur elektronicznych. Ten obowiązek i tak wymusi wymianę danych między sklepem a księgowością.
• Test poza godzinami pracy — Zrób jedno zamówienie w piątek po 20:00 i w sobotę. Sprawdź, czy etykieta, faktura i status w ERP powstały bez udziału człowieka.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – dane strukturalne
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja