Integracja z ERP, płatnościami i kurierami to nie jedna usługa, a trzy osobne połączenia, które można wdrażać niezależnie. ERP odpowiada za dane i magazyn, operator płatności za pieniądze, kurier za logistykę. W Hrubieszowie i okolicy większość sklepów to firmy kilkuosobowe, więc kolejność wdrożeń ma większe znaczenie niż wybór technologii — najpierw spina się to, co odciąża najbardziej. Poniżej znajdziesz progi decyzyjne, listę kontrolną i błędy organizacyjne, które najczęściej wydłużają wdrożenie.
W praktyce „integracja” to nie jedna usługa, a trzy niezależne połączenia, które można wdrażać w dowolnej kolejności i rozliczać osobno.
Drugie rozróżnienie to kierunek przepływu. Integracja jednostronna to eksport zamówień ze sklepu do ERP plikiem CSV lub XML — tania, szybka, ale nic nie wraca. Dwukierunkowa synchronizuje dodatkowo stany magazynowe, statusy i faktury z powrotem do sklepu. Jest droższa i wymusza decyzję: kto wygrywa, gdy ERP ma 3 sztuki, a sklep sprzedał 4? Bez tej odpowiedzi wdrożenie kończy się nadspzedażą i ręcznym gaszeniem pożarów.
Najczęstsze zestawy w MŚP to WooCommerce + Subiekt GT, PrestaShop + Comarch Optima — tu punktem wyjścia bywa dokumentacja deweloperska PrestaShop — oraz sklep pisany na zamówienie + enova. Na większym rynku liczba łączników rośnie, bo dochodzą kanały marketplace i osobne magazyny; różnicę widać w artykule o integracjach z ERP, płatnościami i kurierami w Lublinie.
Próg orientacyjny to 20 zamówień miesięcznie. Ręczne przepisanie jednego zamówienia do ERP to 5–8 minut: wpisanie danych klienta, towarów, wygenerowanie faktury, etykiety i maila z trackingiem. Przy 20 zamówieniach daje to 2–3 godziny miesięcznie, przy 100 — już 9–13 godzin, czyli realny etat w małej firmie.
Warto policzyć też koszt błędu, bo on nie zniknie po zatrudnieniu kolejnej osoby. Literówka w adresie oznacza ponowną wysyłkę (15–25 zł plus czas), zdublowana faktura to korekta i robota dla księgowości, a wysyłka do złego klienta — zwrot, przestój towaru i często przepadek płatności za przesyłkę. Przy 3–4 takich zdarzeniach miesięcznie ręczna obsługa przestaje być „darmowa”.
Zanim podejmiesz decyzję, sprawdź cztery rzeczy: sezonowość (szczyt sprzedaży potrafi być trzykrotnie wyższy od średniej), liczbę SKU, liczbę kanałów sprzedaży i liczbę magazynów. Sam wzrost liczby zamówień to najmniej ważny sygnał — problem zaczyna się wtedy, gdy ręcznie trzeba uzgadniać stany między dwoma kanałami.
| Sytuacja | Zamówienia / mies. | Co się opłaca | Od czego zacząć |
|---|---|---|---|
| Mały sklep, jeden kanał | do 20 | ręczna obsługa, sama bramka płatności | płatności online + etykiety kurierskie |
| Rosnący sklep, jeden magazyn | 20–100 | integracja jednostronna sklep → ERP | eksport zamówień, potem faktury |
| Wielokanałowy (Allegro + sklep) | 100+ | integracja dwukierunkowa | ERP jako źródło prawdy o stanach |
| Sklep sezonowy | szczyt 3× średnia | integracja kurierska + ERP | automatyzacja etykiet przed szczytem |
Subiekt GT to najczęstszy wybór w polskich MŚP, głównie dlatego, że integruje się przez Sferę (biblioteka COM) i ma najwięcej gotowych łączników do WooCommerce i PrestaShop. Kosztem jest środowisko: Sfera działa na Windows, wymaga zainstalowanego i licencjonowanego Subiekta z bazą w tle. Subiekt nexo oferuje Sferę dla nexo oraz REST API w nowszych wersjach — dostępność zależy od edycji i wykupionej licencji, więc trzeba to sprawdzić przed wyceną.
Comarch Optima zwykle wymaga osobno płatnej licencji na API oraz środowiska pośredniczącego (middleware), które tłumaczy format sklepu na format ERP. Daje to stabilność i kontrolę, ale podnosi budżet startowy i wydłuża wdrożenie. WF-Mag i enova są lżejsze i tańsze w utrzymaniu, ale mają mniej gotowych łączników — częściej pisze się integrację pod konkretny sklep. To nie wada samego systemu, tylko wyższy koszt pracy custom.
Przed decyzją sprawdź cztery cechy API: czy jest to REST, SOAP czy wymiana plików (CSV, XML, directory drop), czy dostawca udostępnia sandbox do testów bez ruszania produkcji, czy dokumentacja jest po polsku i aktualna dla twojej wersji, oraz jaki jest limit wywołań w ramach licencji. Pytanie kontrolne na koniec: kto jest źródłem prawdy o stanie magazynowym — sklep czy ERP? Odpowiedź musi być jedna. Sąsiednie wdrożenia w mniejszych miejscowościach opisaliśmy m.in. w tekście o integracjach z ERP, płatnościami i kurierami w Bełżcu.
| System | Typowy sposób integracji | Gotowe łączniki | Na co uważać |
|---|---|---|---|
| Subiekt GT | Sfera (COM), Windows | najwięcej na rynku | wymaga uruchomionej aplikacji i bazy w tle |
| Subiekt nexo | Sfera dla nexo, REST w nowszych wersjach | tak | zakres API zależy od edycji i licencji |
| Comarch Optima | API na osobnej licencji + middleware | przez pośrednika | dodatkowy koszt licencji i warstwy pośredniej |
| WF-Mag / enova | REST lub pliki wymiany | rzadko | więcej pracy custom, mniej dokumentacji |
W polskim sklepie realny wybór to cztery bramki: Przelewy24, PayU, tpay i Stripe. Trzy pierwsze obsługują cały krajowy zestaw metod — BLIK, karty, przelew online, raty, płatność przy odbiorze — i mają API REST z webhookami. Stripe ma sens, gdy sprzedajesz za granicę, prowadzisz subskrypcje albo potrzebujesz zapisanej karty klienta.
Prowizje mieszczą się zwykle w przedziale 1–2,5% od transakcji, a przy kartach dochodzi opłata stała: od kilkudziesięciu groszy do około 1 zł. Przy obrotach poniżej 20–30 tys. zł miesięcznie dostaniesz stawkę bliżej górnej granicy; powyżej 100 tys. zł operatorzy schodzą w dół, bo cennik jest negocjowalny. Sprawdź trzy dodatkowe pozycje: opłatę za wypłatę środków na konto, opłatę za postępowanie chargebackowe (rząd 30–50 zł) i koszt zwrotu środków klientowi.
BLIK traktuj jako obowiązek, nie dodatek — klient, który nie widzi tej metody, często nie kończy zakupu. Wszystkie cztery bramki obsługują BLIK, więc jego brak to decyzja konfiguracyjna, nie ograniczenie techniczne.
Najwięcej wdrożeń psuje sposób potwierdzania zapłaty. Nie ustawiaj statusu „opłacone” na podstawie powrotu klienta na stronę sukcesu — ten adres da się wywołać ręcznie. Status zmienia wyłącznie webhook: operator wysyła POST z podpisanym ładunkiem, Ty weryfikujesz podpis, kwotę i walutę, i dopiero wtedy oznaczasz zamówienie. Odpytywanie API co 30 sekund to plan B — przy 500 zamówieniach dziennie to tysiące zbędnych zapytań i maile opóźnione o kilka minut.
Testuj na sandboxie operatora, z kartami testowymi i wymuszaniem statusu odrzucenia, nigdy na produkcji kwotą 1 zł. Zwroty, w tym częściowe, wywołuj przez API i od razu przekazuj do ERP, inaczej faktura korygująca rozjedzie się ze stanem magazynowym. Przy chargebacku liczy się czas: operator daje zwykle kilka dni na odpowiedź, a komplet dokumentów waży więcej niż opis słowny. Kolejność wdrożeń w mniejszych sklepach opisaliśmy przy okazji integracji z ERP, płatnościami i kurierami w Narolu.
| Bramka | Dla kogo | Prowizja (rząd wielkości) | BLIK | Na co uważać |
|---|---|---|---|---|
| Przelewy24 | sklepy krajowe, szeroki wybór metod | ok. 1,0–2,2% | tak | prowizja zależy od obrotu, negocjuj przy wzroście |
| PayU | sklepy krajowe, większe wolumeny | ok. 1,2–2,5% | tak | osobno płatne postępowanie chargebackowe |
| tpay | małe sklepy, szybki start | ok. 1,2–2,3% | tak | niski próg wejścia, prostszy panel zwrotów |
| Stripe | sprzedaż zagraniczna, subskrypcje | karty krajowe od ok. 1,5% + opłata stała, zagraniczne wyżej | tak | najlepiej udokumentowane webhooki i karty testowe |
InPost to domyślny wybór przy sprzedaży do Paczkomatów i integruje się przez ShipX API. Potrzebujesz tokenu wygenerowanego w panelu przewoźnika — osobny dostaniesz dla środowiska testowego; potwierdź aktualne zasady, bo przewoźnicy je zmieniają. Przesyłkę tworzysz jednym żądaniem: dane odbiorcy, kod punktu, gabaryt, usługa, format etykiety. Uwaga na limity zapytań: przy generowaniu 200 etykiet w pętli API zacznie zwracać błędy 429, więc wsadź opóźnienia albo kolejkę.
DPD, DHL, GLS i Poczta Polska dają zwykle dwie drogi: API (DPD WebAPI, DHL24 lub DHL Parcel API, GLS Web API, Poczta e-Nadawca) albo pliki CSV/XML wgrywane w panelu przewoźnika. CSV ma sens do około 20–30 paczek dziennie — wdrożysz szybciej, ale ktoś musi klikać. Powyżej tego progu API zwraca się w pierwszych tygodniach. Uwaga: część przewoźników wymaga osobnego zlecenia odbioru, dlatego „etykieta” i „odbiór” to dwie różne rzeczy do zautomatyzowania.
Etykiety: PDF (A6) drukujesz na zwykłej drukarce, ZPL idzie na drukarkę termiczną, zwykle 203 dpi i rolka 100×150 mm. ZPL generuje się szybciej i nie wymaga otwierania PDF-a dla każdej paczki.
Punkty odbioru: w checkoucie osadzasz widget mapy (np. Geowidget InPost), klient wybiera punkt, a jego kod zapisujesz w polu zamówienia i przekazujesz do API. Widget dociąga zewnętrzny skrypt — jeśli ładuje się synchronicznie w <head>, psuje LCP na mobile i konwersję bardziej niż brak mapy, dlatego sprawdź Core Web Vitals po wdrożeniu.
Statusy mapuj na statusy sklepu i wysyłaj maile automatycznie: „nadana”, „w drodze”, „do odbioru w punkcie”, „doręczona”. Każdy mail tylko raz, po kluczu zdarzenia z API, bo webhooki i polling potrafią zwrócić ten sam status kilka razy. Etykiety zwrotne załatw od razu przy podpisywaniu umowy — dopisanie ich później oznacza zmianę cennika i kolejny etap wdrożenia. Negocjuj cztery liczby: stawkę zależną od wolumenu miesięcznego, koszt odbioru, prowizję za pobranie oraz opłatę za gabaryt B i paczki powyżej 31,5 kg.
| Przewoźnik | Typowa droga integracji | Punkty odbioru | Etykiety | Na co uważać |
|---|---|---|---|---|
| InPost | ShipX API (REST), token + środowisko testowe | Paczkomaty, widget mapy | PDF, ZPL | limity zapytań, kod punktu w polu zamówienia |
| DPD | DPD WebAPI albo pliki CSV | punkty DPD Pickup | PDF, ZPL | zakres API zależy od podpisanej umowy |
| DHL | DHL24 lub DHL Parcel API, CSV | punkty DHL POP / Service Point | PDF, ZPL | dwie linie produktowe, łatwo wybrać złą |
| GLS | GLS Web API / E-Service, CSV do odbioru | punkty GLS | PDF, ZPL | zlecenie odbioru często osobnym plikiem |
| Poczta Polska | e-Nadawca (XML/WSDL), CSV | punkty odbioru i skrytki | wolniejsze odpowiedzi, warto kolejkować |
Są trzy wzorce. Punkt-punkt: każdy moduł rozmawia z drugim bezpośrednio — najszybszy start dla jednego sklepu, ale każda nowa para systemów to nowy kod, a dwa sklepy i dwie firmy kurierskie dają już osiem ścieżek do utrzymania. Middleware: własna usługa, przez którą przechodzi cała komunikacja; sklep wysyła jedno zdarzenie, usługa rozdziela je do ERP i przewoźników. Droższa na starcie, ratuje przy drugim i trzecim kanale sprzedaży. Trzeci wariant to gotowy moduł w sklepie (PrestaShop, WooCommerce), który sam obsługuje płatności i etykiety — działa, dopóki nie pojawi się nietypowy ERP albo własny proces magazynowy.
Mapowanie pól to miejsce, w którym wdrożenia stoją najdłużej:
Gdy API kuriera leży 30 minut, checkout nie może czekać. Zlecenie ląduje w tabeli kolejki (status: oczekuje / błąd), próby co 1, 2, 4, 8 i 16 minut, a po piątej nieudanej oznaczasz błąd ręczny i wysyłasz alert. Klient nie dostaje maila „wysłane”, dopóki paczka nie ma nadania.
Idempotencja to nie buzzword, tylko zabezpieczenie przed duplikatami faktur. Webhook płatności potrafi przyjść dwa razy i jest to normalne zachowanie operatora. Klucz to para: identyfikator zamówienia plus typ zdarzenia, wymuszona unikalnym indeksem w bazie.
Od pierwszego dnia loguj żądanie i odpowiedź (bez danych karty i pełnych danych osobowych), kod HTTP, czas odpowiedzi i identyfikator korelacji. Alerty: brak webhooka płatności 15 minut po zamówieniu, błędy 5xx powyżej 5% w kwadransie, zamówienia starsze niż 30 minut bez etykiety, dzienne porównanie stanów sklep–ERP. Logi trzymaj 30–90 dni. Ten sam układ stosujemy w integracjach z ERP, płatnościami i kurierami w Biłgoraju.
| Wzorzec | Kiedy sensowny | Koszt utrzymania | Główne ryzyko |
|---|---|---|---|
| Punkt-punkt | jeden sklep, jeden ERP, jeden kurier | niski na starcie, rośnie z każdą parą systemów | bałagan przy zmianie ERP lub przewoźnika |
| Middleware | dwa kanały sprzedaży i więcej | wyższy na starcie, niższy przy rozbudowie | wymaga kogoś, kto utrzyma usługę i kolejkę |
| Moduł w sklepie | standardowy proces, bez nietypowego ERP | najniższy, jeśli moduł jest wspierany | ograniczenia przy własnej logice magazynowej |
Widełki poniżej to typowe przedziały dla sklepu zatrudniającego 1–10 osób. Godziny obejmują pracę programisty, testy i wdrożenie — bez czasu, który po Twojej stronie zajmuje przygotowanie danych i podjęcie decyzji.
Stawki na rynku polskim: freelancer 60–140 zł/h netto, agencja 130–260 zł/h netto. Różnica to nie „narzut”, a projekt, testy, faktura, osoba zastępowalna i SLA. Przykład: 40 h synchronizacji przy 150 zł/h to 6 000 zł, przy 250 zł/h — 10 000 zł.
Utrzymanie: licz 15–25% wartości wdrożenia rocznie. SLA obejmuje monitoring webhooków, czas reakcji (np. 4 h w dni robocze), okno serwisowe, poprawki błędów własnego kodu i aktualizacje pod zmiany API mieszczące się w tej samej wersji. Poza SLA zostają: nowe integracje, nowy kurier, licencje API ERP, limity zapytań i opłaty za etykiety.
| Zakres | Godziny | Koszt przy 150 zł/h | Koszt przy 250 zł/h |
|---|---|---|---|
| Eksport zamówień do ERP (Subiekt) | 20–40 h | 3 000–6 000 zł | 5 000–10 000 zł |
| Pełna synchronizacja dwukierunkowa | 60–120 h | 9 000–18 000 zł | 15 000–30 000 zł |
| Płatności – gotowy moduł | 4–12 h | 600–1 800 zł | 1 000–3 000 zł |
| Płatności – integracja custom | 20–40 h | 3 000–6 000 zł | 5 000–10 000 zł |
| Kurier – jeden operator | 8–16 h | 1 200–2 400 zł | 2 000–4 000 zł |
| Kurierzy – kilku + mapa punktów | 24–48 h | 3 600–7 200 zł | 6 000–12 000 zł |
Te problemy nie wynikają z „trudnej technologii”, a z ustaleń, których nikt nie zrobił na starcie. Każdy da się wytropić przed podpisaniem umowy.
Punkty poniżej są tak sformułowane, żebyś mógł je sprawdzić bez znajomości kodu — wystarczy zadać pytanie wykonawcy i zanotować odpowiedź.
Wsparcie lokalne ma znaczenie przy punkcie 15. Z Zamościa do Hrubieszowa jest około 50 km trasą 74, czyli mniej więcej godzina jazdy. To realna różnica wobec wykonawcy z drugiego końca Polski: awarię na produkcji można obejrzeć na miejscu tego samego dnia, a nie przez zdalny pulpit. Podobny układ kilometrów i podobne pytania opisaliśmy przy integracjach z ERP, płatnościami i kurierami w Biłgoraju, gdzie także pracuje się hybrydowo: zdalnie na co dzień, na miejscu przy wdrożeniu i awarii.
Traktowanie integracji jako jednego projektu: ERP, płatności i kurierzy wrzucone do jednego worka i jednego terminu.
Jak wykryć: W ofercie lub ustaleniach nie ma podziału na etapy, a pytanie „od czego zaczynamy?” kończy się odpowiedzią „od wszystkiego naraz”.
Jak naprawić: Rozbij zakres na trzy osobne elementy i ustal kolejność. Zwykle najpierw płatności (najmniejszy zakres, najszybszy efekt), potem kurierzy, na końcu ERP, który zależy od licencji i API po stronie systemu księgowego.
Brak decyzji, kto jest źródłem prawdy o stanie magazynowym — sklep czy ERP.
Jak wykryć: Po dwóch–trzech tygodniach od wdrożenia stany w sklepie i w ERP zaczynają się różnić, a nikt nie potrafi wskazać, która liczba jest prawdziwa.
Jak naprawić: Zapisz to na piśmie przed startem prac. W praktyce źródłem prawdy jest zwykle ERP, jeśli magazyn i sprzedaż stacjonarna są w nim prowadzone, a sklep dostaje tylko synchronizację stanów.
Integracja płatności oparta na cyklicznym odpytywaniu API zamiast webhooków.
Jak wykryć: Zamówienia wiszą ze statusem „oczekuje na płatność” mimo opłacenia, a status zmienia się dopiero po ręcznym odświeżeniu lub po interwencji klienta.
Jak naprawić: Wymagaj od operatora webhooków i sprawdź, czy są ponawiane przy błędzie po stronie sklepu. Odpytywanie API zostaw jako mechanizm awaryjny, nie jako podstawę działania.
Testowanie integracji płatności od razu na produkcji, na prawdziwych zamówieniach.
Jak wykryć: Pierwsza transakcja po wdrożeniu to realne zamówienie klienta, a nie test w środowisku sandbox.
Jak naprawić: Ustal z operatorem dostęp do sandboxa i kart testowych, przeć testy płatności udanej, nieudanej i zwrotu. Dopiero po nich przełącz na tryb produkcyjny. Zakres środowisk testowych opisuje dokumentacja WooCommerce: https://woocommerce.com/documentation/woocommerce/
Pominięcie zwrotów i etykiet zwrotnych w zakresie integracji z kurierem.
Jak wykryć: Obsługa generuje etykiety zwrotne ręcznie w panelu kuriera, a klient czeka na maila z linkiem dłużej niż dzień.
Jak naprawić: Dopisz zwroty do zakresu przed podpisaniem umowy z kurierem, razem z cennikiem etykiet zwrotnych i sposobem ich wystawiania przez API.
Brak logów i alertów — nikt nie wie, że integracja przestała działać.
Jak wykryć: Pierwszą osobą, która zauważa problem, jest klient dzwoniący z pytaniem, gdzie jest jego paczka.
Jak naprawić: Ustal, gdzie zapisują się logi wymiany danych i kto dostaje powiadomienie przy błędzie. Nawet prosty alert mailowy przy nieudanej synchronizacji skraca przestój z dni do minut.
Trzy integracje to trzy osobne decyzje: ERP odpowiada za dane, operator płatności za pieniądze, kurier za logistykę — i każde z nich można wdrożyć w innym momencie. Poniżej około 20 zamówień miesięcznie ręczna obsługa bywa tańsza niż wdrożenie, ale przy sprzedaży wielokanałowej lub kilku magazynach koszt błędów ręcznych rośnie szybciej niż koszt integracji. Największym ryzykiem nie jest technologia, a brak ustaleń: kto jest źródłem prawdy o stanie magazynowym, kto opłaca licencję na API i kto reaguje, gdy połączenie padnie. Zapisz te trzy odpowiedzi przed pierwszym spotkaniem z wykonawcą — skrócą wdrożenie bardziej niż jakikolwiek wybór technologii.
Nie ma jednej liczby, bo każdy z trzech obszarów ma inny czas. Płatności to zwykle kwestia dni, jeśli operator ma gotową wtyczkę. Kurierzy to kilka dni na samo generowanie etykiet, dłużej jeśli dochodzą punkty odbioru i zwroty. ERP jest najbardziej zmienny — czas zależy głównie od tego, czy dostęp do API jest w Twojej licencji i czy jest dokumentacja. Dlatego pytaj o harmonogram dla każdego obszaru osobno, a nie o jeden termin dla całości.
Nie. W większości przypadków da się spiąć to, co już masz — Subiekt, Optimę, WF-Mag czy enovę — przez API, pliki wymiany albo dedykowany łącznik. Wymiana ERP bywa uzasadniona wtedy, gdy dostawca nie udostępnia dostępu do danych w żadnej formie albo licencja na API jest nieproporcjonalnie droga wobec skali sprzedaży.
Tak, to jeden z najczęstszych zestawów w polskich MŚP. Połączenie realizuje się przez Sferę albo gotowy łącznik, który pobiera zamówienia ze sklepu i odsyła stany magazynowe oraz dokumenty. Najważniejsze pytanie przed startem brzmi: czy magazyn jest prowadzony w Subiekcie, czy w sklepie — od tego zależy kierunek synchronizacji i to, kto nadpisuje czyje dane.
Formalnie nie, praktycznie tak. Polski klient traktuje BLIKA jako domyślną metodę płatności i jego brak bywa odbierany jako brak zaufania do sklepu. Przy wyborze operatora sprawdź nie tylko prowizję, ale też to, czy BLIK jest dostępny w standardzie i czy działa poprawnie na telefonie — bo tam realizuje się większość takich płatności.
Każdy z głównych operatorów udostępnia środowisko sandbox z kartami testowymi. Testy warto rozłożyć na kilka scenariuszy: płatność udana, płatność odrzucona, płatność porzucona i zwrot. Dopiero po nich przełączasz integrację na tryb produkcyjny. Zakres środowisk testowych w WooCommerce opisuje dokumentacja: https://woocommerce.com/documentation/woocommerce/
Bez logów i alertów dowiesz się o tym dopiero od klienta — zwykle w poniedziałek. Dlatego ustal przed wdrożeniem, gdzie zapisuje się historia wymiany danych i kto dostaje powiadomienie przy błędzie. Warto też ustalić, czy zamówienia, które nie przeszły, da się ponowić jednym kliknięciem, czy trzeba je wprowadzać ręcznie.
Można i często tak jest najsensowniej. Płatności i kurierzy dają szybki efekt i nie wymagają decyzji o źródle prawdy o magazynie. ERP dokłada się etapem później, gdy wiadomo już, jak wygląda codzienna praca z zamówieniami. Jak ten sam temat rozkłada się na większym rynku, opisaliśmy w artykule o integracjach w Lublinie: https://dropdigital.pl/integracje-erp-platnosci-kurierzy-lublin
Jeśli chcesz ustalić, od którego obszaru zacząć w swoim sklepie, napisz do nas krótko: jaki masz ERP, ilu operatorów płatności i z jakimi kurierami pracujesz. Odpowiemy, co da się wdrożyć etapami i czego w Twoim przypadku nie warto robić na siłę.