Integracja z ERP, płatnościami i kurierami w Narolu to nie jedna wtyczka, a trzy osobne połączenia: system sprzedaży, operator płatności i przewoźnik. Każde ma własne API, własne statusy i własny sposób na błędy, a spina je jeden proces zamówienia. Gdy wypadnie którykolwiek element, klient zauważy to najszybciej — jako brak potwierdzenia płatności, brak faktury albo brak numeru przesyłki. Poniżej rozkładamy ten proces na siedem kroków, pokazujemy typowe pułapki i podajemy widełki czasowe oraz kosztowe wdrożenia.
Integracja z ERP, płatnościami i kurierami to w praktyce trzy niezależne połączenia, które spotykają się w jednym miejscu — w zamówieniu. ERP odpowiada za stany magazynowe i dokumenty, operator płatności za autoryzację przelewu, BLIK-a lub karty, kurier za etykietę i numer śledzenia. Każde z nich ma inne API, inne uwierzytelnianie i inaczej raportuje błędy.
W Narolu i okolicach — Lubaczów, Zamość, Tomaszów Lubelski — ten układ powtarza się niemal identycznie: jedna hala magazynowa przy siedzibie, jeden sklep internetowy, brak działu IT. To upraszcza integrację, bo nie ma rezerwacji stanów z kilku kanałów, ale przenosi całą odpowiedzialność na biuro, które rano ręcznie przepisuje zamówienia i drukuje etykiety. Ten sam schemat powtarza się w sąsiednich gminach, m.in. przy integracjach w Bełżcu i integracjach w Józefowie.
Najczęstszy błąd: szukanie jednej wtyczki „do integracji”. Rynek wygląda tak, że każdy moduł obsługuje jedną warstwę — dodatek ERP wysyła dokument, dodatek płatności obsługuje webhooki, a etykiety generuje osobny moduł kurierski. Jeśli nie mają wspólnego identyfikatora zamówienia (tego samego numeru lub ID), połączenie ich w łańcuch kończy się duplikatem faktury albo dwiema etykietami na jedną paczkę.
| Warstwa | Co obsługuje | Typowe API / plik | Co najczęściej się psuje |
|---|---|---|---|
| ERP | Stany magazynowe, dokument magazynowy, faktura | Sfera, REST API, XML/CSV, zapytania SQL | Mapowanie SKU, koszt dostawy jako pozycja vs usługa, numeracja dokumentów |
| Płatności | Autoryzacja, potwierdzenie, zwroty | Webhook z podpisem, REST API | Poleganie tylko na powrocie klienta, brak idempotencji webhooka |
| Kurier | Etykieta, zlecenie odbioru, tracking | InPost ShipX, DPD, DHL, PDF/ZPL | Domyślna waga i gabaryt, brak zwrotnego numeru śledzenia |
Cały proces spina jeden identyfikator zamówienia. Poniżej siedem kroków w kolejności, w jakiej powinny się wykonywać.
Przed wdrożeniem warto sprawdzić dokumentację techniczną — PrestaShop opisuje m.in. statusy zamówień i webhooki, a zapisywanie całego łańcucha w jednym module porządkuje kolejność zdarzeń. Ten sam przepływ firmom z jednym magazynem opisaliśmy przy integracjach w Biłgoraju.
| Krok | Kto odpowiada | Typowa awaria |
|---|---|---|
| 1. Zamówienie | Sklep | Niespójny dobór płatności i przewoźnika (np. etykieta przy nieskasowanej przedpłacie) |
| 2. Płatność | Operator płatności | Brak webhooka, nieidempotentne zdarzenia, zamówienia zawieszone na statusie oczekiwania |
| 3. Przekazanie do ERP | Moduł / middleware | Błędne mapowanie SKU i kosztu dostawy, duplikaty dokumentów po ponowieniu |
| 4. Stan i faktura | ERP | Numeracja niezgodna ze sklepem, faktura przed potwierdzoną płatnością |
| 5. Etykieta | Kurier | Zła waga i gabaryt, brak zlecenia odbioru, dopłaty korygujące |
| 6. Tracking | Sklep + kurier | Numer nie wraca do zamówienia, klient dzwoni po status |
| 7. Zwroty | ERP + operator | Brak korekty faktury, ręczne zwroty płatności, rozjazd stanów magazynowych |
Metoda integracji zależy mniej od nazwy ERP, a bardziej od tego, czy system ma API i na jakiej licencji pracuje.
Od najbezpieczniejszej metody: REST API, webhooki, kolejki, pliki wymiany, bezpośredni dostęp do bazy. Kolejka daje ponowienia i log zdarzeń — widać, co i kiedy poszło do ERP. Pliki wymiany co 5–15 minut sprawdzają się, gdy ERP nie ma API, ale trzeba pilnować blokad pliku, żeby dwa procesy nie importowały tego samego dokumentu.
Middleware opłaca się, gdy masz dwa źródła zamówień (sklep plus marketplace), więcej niż jeden magazyn albo chcesz mieć jeden panel logów i ręczne ponawianie. Własny moduł w PrestaShop lub WooCommerce wystarcza przy jednym sklepie i jednym ERP, gdzie zakres jest zamknięty. Warto pamiętać, że moduł dla WooCommerce opiera się na REST API i webhookach, a dokumentacja WooCommerce to dobry punkt startowy, jeśli ERP nie ma API i trzeba pisać własny adapter. Podobne konfiguracje opisaliśmy przy integracjach w Lublinie.
| ERP | Metoda integracji | Na co uważać |
|---|---|---|
| Subiekt GT | Sfera (COM), pliki XML/CSV | Licencja, praca na Windows, stabilność przy dużej liczbie zamówień |
| Subiekt nexo | Sfera dla nexo, API sieciowe | Zakres licencji, praca zdalna wymaga otwartego dostępu |
| Comarch Optima | API, wymiana dokumentów | Limity licencji i konektorów, import dużych paczek dokumentów |
| WF-Mag | Zapytania SQL, pliki wymiany | Zmiany struktury bazy po aktualizacji psują integrację |
| WAPRO | Bazy SQL, moduły wymiany | Blokady plików przy dwóch równoległych procesach |
Wybór operatora płatności sprowadza się do trzech pytań: jakie metody ma zobaczyć klient, ile realnie kosztuje transakcja i czy API obsługuje zwroty oraz webhooki bez ręcznej pracy.
Prowizje i koszty – orientacyjnie. Cenniki są negocjowalne i zmieniają się, więc przed decyzją poproś operatora o ofertę policzoną dla twojego obrotu. Rząd wielkości: przelewy i BLIK w Przelewy24 oraz tpay to zwykle najtańsza pozycja (ok. 1–2% od transakcji), karty drożej (ok. 1,9–2,9%), PayU podobnie, a Stripe przy kartach EOG to około 1,5% plus stała opłata za transakcję – karty spoza EOG są wyraźnie droższe. Stripe wygrywa przy subskrypcjach i płatnościach w walutach, P24/tpay/PayU – przy polskim rynku i BLIK-u.
Metody a konwersja. BLIK to dziś pozycja obowiązkowa; jego brak w koszyku to jedna z najczęstszych przyczyn porzucenia zakupu. Pay-by-link przydaje się w B2B przy dużych koszykach i zamówieniach wystawianych ręcznie z ERP. Raty mają sens od koszyka ok. 1000 zł – poniżej tego progu tylko rozbudowują formularz.
Webhooki i statusy. Operator przysyła zdarzenia typu pending, paid, cancelled, refund. Nie wrzucaj ich wprost do bazy – zrób jedno mapowanie (plik konfiguracyjny albo tabela słownikowa) na stany ERP: nowe, opłacone, wysłane, zwrot. Zmiana operatora to wtedy podmiana mapy, a nie przepisywanie kodu. Jeśli sklep stoi na WooCommerce, punktów zaczepienia szukaj w dokumentacji WooCommerce.
Testy. Minimum: sandbox, płatność testowa, wymuszona odmowa autoryzacji, zwrot pełny i częściowy. Sprawdź, czy po zwrocie ERP cofa dokument sprzedaży, czy tylko dopisuje korektę.
Pułapka: brak idempotencji. Webhooki są ponawiane, gdy nie odpowiesz w kilka sekund. Bez klucza idempotencji (ID transakcji operatora z unikalnym indeksem w bazie) jedna płatność potrafi wygenerować dwa zamówienia i dwie faktury. Ten sam mechanizm opisaliśmy przy wdrożeniach dla firm z regionu, m.in. w materiale o integracjach z ERP, płatnościami i kurierami w Lublinie.
| Status u operatora | Znaczenie | Akcja w ERP |
|---|---|---|
| pending | płatność rozpoczęta, brak potwierdzenia | zamówienie wstrzymane, bez faktury |
| paid | środki zaksięgowane | wystaw fakturę, przekaż do wysyłki |
| cancelled | płatność nieudana lub porzucona | anuluj, zwolnij rezerwację stanu |
| refund | zwrot pełny albo częściowy | korekta faktury i stanu magazynowego |
Każdy przewoźnik ma własne API, ale schemat jest ten sam: tworzysz przesyłkę, generujesz etykietę, zamawiasz kuriera, odbierasz statusy i numer śledzenia.
InPost ShipX to najczęściej wybierane API w polskim e-commerce. Zakładasz organizację, dostajesz token i definiujesz usługi: Paczkomat, kurier, punkty odbioru. Etykiety wracają jako plik PDF w formacie etykiety logistycznej – drukarkę termiczną konfiguruje się raz, potem podmienia się tylko szablony. W dokumentacji PrestaShop szukaj tego typu połączeń w sekcji modułów i hooków: PrestaShop Developer Documentation.
DPD, DHL24, GLS. Działają podobnie, ale różnią się technicznie – część opiera się na starszych usługach sieciowych, część na nowszych REST-ach. Wszystkie pozwalają na etykietę, tracking i zamówienie kuriera, ale pola adresowe, kody usług i opcje pobrania są inne. Bez warstwy pośredniej w twoim kodzie nie da się tego sprowadzić do jednego uniwersalnego mapowania.
Mapowanie usług. Ustal w sklepie: gabaryt paczki (Paczkomat ma sztywne wymiary A/B/C), wagę, pobranie, ubezpieczenie do wartości towaru. Jeśli ERP liczy wagi zbiorcze, dolicz opakowanie – 0,3–0,5 kg rozjazdu potrafi przenieść przesyłkę do wyższej strefy cenowej.
Automatyczne etykiety po płatności. Etykieta ma powstawać po potwierdzeniu płatności, a nie po kliknięciu pracownika. Trigger: status zamówienia zmienia się na opłacone → zadanie w kolejce → API przewoźnika → PDF i numer śledzenia zapisany w ERP oraz wysłany mailem. Kolejkę z ponowieniami zrób od razu, bo API kurierów miewa okna niedostępności.
Pułapka: adresy. Brak walidacji kodu pocztowego i numeru domu to najczęstsze źródło odrzuconych etykiet. Kod zapisany jako „05500” zamiast „05-500”, brak numeru mieszkania, Paczkomat wpisany w pole ulicy – to wszystko wraca jako błąd dopiero przy tworzeniu przesyłki. Normalizuj dane przed wysłaniem i waliduj już w formularzu.
| Przewoźnik | Co daje API | Na co uważać |
|---|---|---|
| InPost ShipX | Paczkomaty, kurier, punkty odbioru, etykiety PDF | gabaryty A/B/C i sztywne limity wymiarów |
| DPD | etykiety, tracking, zamówienie kuriera | kody usług i pola adresowe inne niż u konkurencji |
| DHL24 | etykiety, tracking, pobranie | starsza technologia usług sieciowych |
| GLS | etykiety, tracking, zamówienie kuriera | format danych wejściowych wymaga warstwy mapującej |
Realna wycena wychodzi z godzin, nie z gotowych „pakietów”. Zakres prac to zwykle 20–80 godzin, a stawka rynkowa dla integracji e-commerce w Polsce to 120–250 zł/h netto. Stawka zależy od tego, czy pracuje junior na gotowym module, czy senior pisze własny łącznik do ERP.
Rozbicie godzinowe. Podłączenie bramki płatności i jednego kuriera na gotowych modułach to 20–30 godzin. Dołożenie ERP (mapowanie towarów po SKU/EAN, stanów magazynowych, klientów, faktur i numeracji dokumentów) to kolejne 30–60 godzin. Wielowalutowość, kilka magazynów i niestandardowe statusy zamówień dodają 20 godzin i więcej.
Trzy poziomy wdrożenia. Prosty sklep z jedną bramką i jednym kurierem: 3 000–8 000 zł. Średni, z ERP i dwoma–trzema przewoźnikami: 8 000–20 000 zł. Zaawansowany, z wielomagazynowością i nietypową logiką dokumentów: 20 000 zł i wyżej.
Licencje, moduły i API. Dostęp do API kurierów zwykle nie jest fakturowany osobno – płacisz za nadania zgodnie z umową handlową. Bramka płatności nie ma opłaty miesięcznej, rozlicza się prowizją od transakcji. Gotowe moduły do PrestaShop i WooCommerce kosztują typowo 200–1 500 zł jednorazowo albo kilkadziesiąt złotych miesięcznie w abonamencie. Traktuj to jako zakres rynkowy, nie cennik konkretnego wydawcy – kwoty potwierdź u dostawcy modułu przed podpisaniem zamówienia.
Utrzymanie i SLA. 300–1 500 zł miesięcznie. W tym powinien być monitoring webhooków, reakcja na zmiany w API operatora, aktualizacje modułów i test po każdej aktualizacji sklepu. Bez tego pierwsza zmiana po stronie przewoźnika oznacza ręczne wystawianie etykiet przez pół dnia. Schemat wdrożenia dla podobnych firm opisaliśmy też przy okazji integracji ERP, płatności i kurierów w Krasnobrodzie.
| Wariant wdrożenia | Godziny | Koszt netto |
|---|---|---|
| Prosty: 1 bramka + 1 kurier | 20–35 h | 3 000–8 000 zł |
| Średni: bramki + 2–3 kurierów + ERP | 35–70 h | 8 000–20 000 zł |
| Zaawansowany: magazyny, waluty, nietypowe dokumenty | 70–80 h i więcej | 20 000 zł i więcej |
Najdroższe błędy w integracjach nie wynikają z tego, że API nie działa. Wynikają z tego, że nikt nie sprawdził zachowania systemu w sytuacji nietypowej – a takie sytuacje zdarzają się codziennie.
Te scenariusze przećwicz przed startem, niezależnie od wolumenu zamówień – integracje z ERP, płatnościami i kurierami w Biłgoraju prowadzimy według tego samego schematu testów. Zachowanie wtyczek i webhooków w sklepie opisuje dokumentacja WooCommerce.
Checklista jest krótka, ale każdy punkt trzeba domknąć przed pierwszym prawdziwym zamówieniem. Odhaczaj po kolei.
Jeden punkt pominięty na tym etapie kosztuje potem kilka dni pracy, bo poprawki robi się już na żywym ruchu.
Kolejność prac jest zawsze taka sama, zmienia się tylko skala.
Firmy z Narola, Zamościa, Lublina i okolic obsługujemy zdalnie, a gdy trzeba – na miejscu; analogiczne wdrożenia prowadziliśmy m.in. w ramach integracji z ERP, płatnościami i kurierami w Lublinie. Napisz, jaki masz ERP i sklep – powiemy, czy spięcie zajmie 3 tygodnie, czy trzeba zaplanować 6.
| Etap | Czas | Efekt |
|---|---|---|
| Audyt | 1–2 dni | Lista systemów, wersji, wolumenów i znanych ryzyk |
| Projekt | 3–5 dni | Mapowanie pól, lista zdarzeń, wybór webhook/cron |
| Development | 2–6 tygodni | Działające połączenia ERP, płatności i kuriera |
| Testy | 3–5 dni | Potwierdzona idempotencja, stany w obie strony, zwroty |
| Wdrożenie + monitoring | 1–2 dni | Produkcja z alertami i kolejką błędów |
| Opieka | stała | SLA reakcji 4 h / 24 h, przegląd logów raz w miesiącu |
Traktowanie ERP, płatności i kurierów jako jednej integracji do kupienia w jednym module.
Jak wykryć: W sklepie działa jeden moduł, który udaje wszystko naraz, a w logach nie da się rozdzielić błędów płatności od błędów wysyłki.
Jak naprawić: Rozdziel integracje na trzy warstwy z osobnymi logami i osobnym ponawianiem. Punktem wspólnym ma być numer zamówienia i status, nie jeden wspólny plik konfiguracyjny.
Brak idempotencji przy webhookach płatności, co kończy się duplikatami zamówień i faktur.
Jak wykryć: W ERP widać dwa dokumenty dla jednego zamówienia albo klient dostaje dwie faktury po ponowieniu webhooka przez operatora.
Jak naprawić: Zapisuj identyfikator transakcji w bazie przed utworzeniem dokumentu i odrzucaj powtórzone zdarzenia. Klucz idempotencji oparty na ID transakcji plus numerze zamówienia załatwia większość przypadków.
Wystawianie faktury w ERP przed potwierdzeniem płatności.
Jak wykryć: W rejestrze faktur pojawiają się dokumenty dla zamówień ze statusem pending lub anulowanych.
Jak naprawić: Faktura ma powstawać dopiero po statusie paid. Dla płatności za pobraniem ustal osobną, jawną regułę i opisz ją w dokumentacji procesu.
Brak rezerwacji stanów magazynowych w momencie złożenia zamówienia.
Jak wykryć: Sklep sprzedaje towar, którego fizycznie nie ma, a stany w sklepie rozjeżdżają się z Subiektem lub Comarch Optima.
Jak naprawić: Zrób rezerwację przez API ERP już przy złożeniu zamówienia, z czasem wygaśnięcia dla nieopłaconych koszyków. Zdejmowanie stanu dopiero przy wystawieniu dokumentu końcowego to za późno.
Ręczne generowanie etykiet i kopiowanie numerów trackingowych z panelu kuriera.
Jak wykryć: Codziennie ktoś loguje się do panelu InPost, DPD lub DHL i wkleja numery przesyłek do sklepu.
Jak naprawić: Generuj etykietę automatycznie po potwierdzeniu płatności, a numer trackingowy zapisuj webhookiem w zamówieniu. Ręczna praca ma zostać tylko przy wyjątkach.
Brak walidacji adresu i kodu pocztowego przed przekazaniem danych do API kuriera.
Jak wykryć: Etykiety są odrzucane, przychodzą dopłaty korektowe, a część przesyłek wraca do nadawcy.
Jak naprawić: Waliduj format i pola obowiązkowe dla wybranej usługi, osobno dla paczkomatu i osobno dla kuriera. Testuj formularz danymi granicznymi, nie tylko poprawnym adresem.
Nie da się dobrze spiąć ERP, płatności i kurierów, jeśli traktuje się to jak jedną wtyczkę. Kolejność jest zawsze ta sama: potwierdzona płatność, dokument w ERP, etykieta u przewoźnika, tracking w sklepie. Zacznij od jednej integracji, przetestuj ją na środowisku testowym i dopiero wtedy dokładaj kolejną. Mechanika jest identyczna niezależnie od tego, czy pracujesz w Narolu, czy w podobnej skali w Bełżcu, Biłgoraju lub Lublinie — zmienia się tylko lokalny układ magazynu i przewoźników.
Nie. To trzy niezależne integracje: ERP odpowiada za stany i dokumenty, operator płatności za autoryzację i zwroty, kurier za etykietę i tracking. Łączy je jeden proces zamówienia i wspólny identyfikator. Można je wdrażać etapami, ale każda ma własne API, własne limity i własne sposoby na błędy.
Typowy zakres to 20–80 godzin pracy, zależnie od liczby integracji i od tego, czy ERP udostępnia wygodne API. Subiekt GT i nexo to zwykle najdłuższa część, bo integracja idzie przez Sferę, API albo pliki wymiany. Do tego dochodzą testy, migracja kartotek i dokumentacja.
Da się, jeśli masz jedną parę sklep–ERP i jednego przewoźnika — wtedy wystarczy moduł do sklepu. Middleware zaczyna się opłacać przy dwóch kanałach sprzedaży, kilku magazynach albo gdy ERP nie ma wygodnego API. Wtedy lepiej trzymać logikę poza sklepem, bo zmiana platformy nie wymusza pisania integracji od zera.
Kryteria to koszt transakcji przy Twoim obrocie, dostępność BLIK-a i płatności odroczonych, jakość webhooków oraz to, czy dostaniesz środowisko testowe. Stripe bywa wygodny przy sprzedaży zagranicznej i subskrypcjach, polscy operatorzy przy BLIK-u i szybkich przelewach. Aktualne stawki sprawdzaj bezpośrednio w cenniku operatora — zmieniają się i zależą od negocjacji, więc nie ma sensu opierać decyzji na kwotach z blogów.
Potrzebujesz kolejki i ponawiania: nieudane zlecenie etykiety ma zostać zapisane i powtórzone, a nie zniknąć. Zamówienie powinno mieć czytelny status, który mówi, że płatność jest potwierdzona, ale etykieta czeka na wygenerowanie. Bez tego jedna awaria API oznacza ręczne przeszukiwanie zamówień i opóźnione wysyłki.
Realistycznie 300–1500 zł netto miesięcznie, jeśli chcesz mieć monitoring błędów, aktualizacje modułów i reakcję na zmiany w API. Dostawcy płatności i kurierzy zmieniają swoje interfejsy kilka razy w roku i potrafi to zatrzymać wysyłki. Utrzymanie to nie koszt serwera, a koszt tego, że ktoś faktycznie reaguje.
Jeśli chcesz sprawdzić, ile zajmie spięcie Twojego sklepu z Subiektem, Comarch Optima, WF-Magiem lub WAPRO i jednym operatorem płatności, napisz do nas — powiemy wprost, co da się zrobić od razu, a co wymaga osobnego etapu. Możemy zacząć od krótkiej rozmowy technicznej, bez zobowiązań.