Integracje z ERP, płatnościami i kurierami w Lublinie to nie jedno wdrożenie, a trzy niezależne procesy, które można uruchamiać etapami. Najpierw porządkuje się pieniądze (płatności), potem logistykę (kurierzy), a na końcu spina stan magazynowy z ERP — chyba że to ERP jest źródłem prawdy o towarze, wtedy kolejność się odwraca. Poniżej znajdziesz część organizacyjną: błędy, które najczęściej blokują wdrożenie, checklistę do audytu procesu zamówienia i pytania, które warto zadać, zanim podpiszesz umowę z wykonawcą. Nie ma tu obietnic, że coś zintegruje się samo — jest lista rzeczy do sprawdzenia i kryteria decyzji.
„Integracja sklepu” to w praktyce trzy niezależne rury. Można je podłączać etapami, ale nie w jednym tygodniu — mieszanie ich w jednym projekcie to najczęstsza przyczyna opóźnień i niedomkniętych statusów zamówień.
| Warstwa | Co wychodzi ze sklepu | Co wraca do sklepu |
|---|---|---|
| Sprzedaż (PrestaShop / WooCommerce) | zamówienie, dane klienta, pozycje i kwoty | — tu jest źródło zamówienia |
| Pieniądze (operator płatności) | kwota, ID zamówienia, adres e-mail | potwierdzenie autoryzacji, status opłacone / anulowane |
| Logistyka i ERP (kurier, magazyn, ERP) | adres, waga, liczba paczek, lista pozycji | numer listu przewozowego, etykieta PDF, status doręczenia, stan magazynu |
Zanim zapłacisz za wdrożenie, rozrysuj na kartce ścieżkę jednego zamówienia. Nie „proces sprzedaży”, ale konkretne zdarzenia w kolejności: koszyk → płatność → zamówienie w sklepie → faktura lub paragon → kompletacja → etykieta kurierska → tracking do klienta → zwrot.
Przy każdym punkcie zadaj jedno pytanie: kto jest źródłem prawdy — sklep czy ERP? Jeśli gdziekolwiek odpowiedź brzmi „oba” albo „nie wiem”, dokładnie tam powstanie duplikat, zawieszony status albo podwójny dokument księgowy.
Najczęstsze luki, które widzimy przy audytach:
Test przed podpisem umowy: przepuść 10 zamówień, w tym dwa z płatnością odroczoną, jedno anulowane i jedno zwrócone. Wszystkie statusy muszą się domknąć bez ręcznej korekty w bazie. Podobną listę punktów styku przechodzimy przy wdrożeniach w firmach z regionu — zobacz, jak wyglądają integracje z ERP, płatnościami i kurierami w Biłgoraju.
Integracja z ERP to nie „podłączenie”, a uzgodnienie słowników. Cztery pola generują najwięcej sporów:
| Metoda synchronizacji | Kiedy wystarcza | Na co uważać |
|---|---|---|
| Eksport/import plików CSV lub XML co 30 min | do ok. 500–1000 zamówień miesięcznie, jeden kanał sprzedaży | opóźnienie stanów, brak obsługi anulowań między eksportami, nadpisywanie zmian |
| API REST/SOAP | gdy stany i ceny muszą być świeże w ciągu minut | limity zapytań, obsługa błędów 429/500, rotacja kluczy i uprawnień |
| Kolejka zdarzeń (webhooki) | kilka kanałów sprzedaży, wysoki wolumen, rezerwacje na bieżąco | kolejność zdarzeń, duplikaty, brakujące zdarzenia po awarii — konieczny retry |
Przy wyborze operatora patrz na pięć liczb, nie na logo. Pierwsza: prowizja od transakcji — karta zwykle 0,9–1,9%, BLIK często 0,3–0,6 zł od transakcji lub ok. 1%. Druga: koszt zwrotu i chargebacku; u części operatorów zwrot kosztuje tyle samo co płatność, u innych jest darmowy w ramach abonamentu. Trzecia: opłata za wypłatę środków na konto firmowe. Czwarta: koszt przewalutowania, jeśli sprzedajesz w EUR lub CZK — spread 1,5–3% zjada marżę szybciej niż prowizja. Piąta: abonament miesięczny, który ma sens dopiero przy kilkuset transakcjach.
Zakres metod: BLIK i karta to minimum. Apple Pay i Google Pay działają najczęściej w tym samym widżecie, więc dopisanie ich nie wymaga osobnej integracji — a poprawiają konwersję na mobile. Płatności odroczone (PayPo, PragmaPay) dokładaj wtedy, gdy koszyk B2C oscyluje w granicach 200–800 zł albo sprzedajesz B2B z terminem 14–30 dni. To osobna umowa i osobny webhook, nie „opcja w panelu”.
Technicznie najważniejsza jest kolejność zdarzeń. Status „opłacone” ustawiaj wyłącznie po zweryfikowanym webhooku z poprawnym podpisem (signature/checksum liczony z payloadu i sekretu), nigdy po powrocie klienta na stronę „dziękujemy” — klient może zamknąć przeglądarkę albo wrócić z zakładki po godzinie. Sposób obsługi webhooków w konkretnym silniku opisuje dokumentacja deweloperska PrestaShop. Surową odpowiedź zapisuj do logu razem z nagłówkami i czasem; to jedyny dowód w sporze z operatorem.
Idempotencja: ten sam webhook może przyjść dwa, trzy razy. Zapisz transaction_id jako unikalny indeks w bazie. Jeśli przyszedł znany transaction_id — kończ bez zmian: nie ruszaj statusu i nie wysyłaj ponownie maila. Unikalny indeks działa lepiej niż „sprawdź i zapisz” w kodzie, bo żądania przychodzą równolegle.
Kiedy zostawić minimum? Przelewy24 + BLIK + karta wystarczy przy małym koszyku i kliencie krajowym. BNPL dokładaj, gdy w statystykach widzisz porzucenia koszyka powyżej 300 zł. Sklepy w regionie — od Biłgoraja po Zwierzyniec — mają identyczny układ, różni je tylko skala.
| Kryterium | Co sprawdzić w umowie | Typowa pułapka |
|---|---|---|
| Prowizja | Stawka dla karty, BLIK, przelewu | Promocyjna stawka tylko dla nowych klientów |
| Zwroty | Koszt zwrotu i chargebacku | Zwrot kosztuje 100% prowizji transakcji |
| Waluty | Spread przewalutowania | 1,5–3% przy każdym rozliczeniu zagranicznym |
| Wypłata | Opłata za przelew na konto | Darmowa tylko raz w tygodniu |
| BNPL | Osobna umowa i webhook | Brak obsługi zwrotów częściowych |
Trzy scenariusze, trzy różne integracje. Punkt odbioru (Paczkomaty, punkty DPD Pickup, DHL POP) wymaga widżetu mapy i zapisania kodu punktu do zamówienia. Kurier pod adres potrzebuje walidacji adresu i zwykle numeru telefonu odbiorcy. Przesyłka gabarytowa — paleta, dłużyca, sprzęt AGD — to często zlecenie poza standardowym API, z własnym formularzem i ręczną wyceną.
Przez integrację musi przejść cały łańcuch, nie tylko etykieta: utworzenie przesyłki, wygenerowanie etykiety PDF (InPost, DPD) lub ZPL dla drukarki termicznej, pobranie numeru i linku śledzenia, zlecenie odbioru, a także anulowanie przesyłki — nieopłaconej lub zwrotu. Każdy z tych punktów ma osobny endpoint i osobne kody błędów, które trzeba zmapować na komunikaty zrozumiałe dla obsługi.
Mapa punktów to miejsce, gdzie najczęściej robi się krzywdę. Kod punktu (np. LUB01M) musi trafić do zamówienia zanim powstanie etykieta — inaczej pracownik przepisuje go ręcznie. Przy 10 zamówieniach dziennie to 30–60 minut pracy, a przy błędnym kodzie paczka wraca.
Kontekst Lubelszczyzny jest konkretny: w Lublinie kurierzy odbierają przesyłki w oknie popołudniowym, w mniejszych miejscowościach — jak Krasnobród czy Józefów — często jest jeden kurs dziennie, w godzinach przedpołudniowych. Obietnica „wysyłka tego samego dnia” ma sens tylko wtedy, gdy zamówienie jest opłacone i ma wygenerowaną etykietę przed godziną odbioru. W praktyce cutoff ustawia się na 10:00–11:00, a nie na godzinę zamknięcia sklepu.
| Scenariusz | Co musi przejść przez integrację | Gdzie najczęściej pęka |
|---|---|---|
| Punkt odbioru | Mapa punktów, kod punktu, etykieta | Kod punktu zapisany po wygenerowaniu etykiety |
| Kurier pod adres | Walidacja adresu, telefon, etykieta | Błędny kod pocztowy, brak numeru telefonu |
| Przesyłka gabarytowa | Wycena, zlecenie, często ręcznie | Brak wsparcia w standardowym API kuriera |
Pięć najczęstszych awarii ma wspólną cechę: nie widać ich na stronie sklepu, widać je dopiero w logach albo w mailu od klienta.
Duplikaty zamówień przy powtórzonym webhooku. Ten sam transaction_id w odstępie kilku sekund to retry operatora, nie nowa płatność. Wykrywanie: porównuj transaction_id i znacznik czasu — dwa zdarzenia w oknie do 5 sekund traktuj jako jedno. Trzeci taki sam wpis w dziennych logach to sygnał, że brakuje unikalnego indeksu w bazie.
Rozjazd stanów magazynowych. Dzienny raport rozbieżności: kolumny SKU, stan w sklepie, stan w ERP, różnica. Każdy wiersz z różnicą inną niż zero wymaga wyjaśnienia. Najczęstsze źródła: zwroty zaksięgowane po jednej stronie, rezerwacje w ERP niewidoczne w sklepie, anulowane zamówienia bez korekty stanu.
Zamówienia bez etykiety po 30 minutach od opłacenia. Cron co 5 minut sprawdza zamówienia w statusie „opłacone” bez numeru przesyłki. Jeśli po dwóch cyklach nadal brakuje etykiety — alert w panelu i mail do obsługi. Bez tego klient dowie się pierwszy.
Status „opłacone” dla przelewu, który nie wszedł. Testuj na sandboxie operatora: wyślij webhook z niepoprawnym podpisem i sprawdź, czy system go odrzuca. Równolegle loguj surowe odpowiedzi — bez nich spór z operatorem wygrywa ten, kto ma więcej danych.
Ciche ograniczenia API. Limity zapytań (np. 100 na minutę), tokeny wygasające po godzinie. Przy 500 zamówieniach cron co minutę zwróci 429 i część przesyłek nie powstanie. Rozwiązanie: kolejka zamiast pętli, backoff przy błędzie, odświeżanie tokenu przed wygaśnięciem i monitoring kodów 429 oraz 401. Ten sam schemat stosuje się w sklepach od Szczebrzeszyna po Frampol.
| Objaw | Gdzie szukać | Reakcja |
|---|---|---|
| Dwa maile po jednej płatności | Log webhooków: transaction_id + czas | Unikalny indeks na transaction_id |
| Stany różnią się o kilka sztuk | Dzienny raport sklep vs ERP | Wyjaśnić każdy wiersz z różnicą ≠ 0 |
| Brak etykiety po 30 min | Cron sprawdzający statusy zamówień | Alert w panelu + mail do obsługi |
| „Opłacone” bez wpłaty | Sandbox operatora, surowe odpowiedzi | Weryfikacja podpisu, test negatywny |
| Błędy 429 i 401 | Logi API kuriera i operatora | Kolejka, backoff, odświeżanie tokenu |
Godziny podane niżej to czas pracy dewelopera, a nie czas kalendarzowy od podpisania umowy. Do tego dochodzi twój czas: testy, decyzje, dane do migracji. W praktyce na każdą godzinę pracy wykonawcy wypada 15–20 minut po stronie klienta. Jeśli tego nie zaplanujesz, projekt stanie na etapie „czekamy na odpowiedź”.
Co podnosi widełki: nestandardowy ERP (własny, stary albo bez API — zostaje zrzut CSV/XML lub odczyt bazy w trybie tylko do odczytu); brak API u kuriera (zostaje panel i praca ręczna); wielojęzyczność i wielowalutowość; integracja z KSeF, jeśli ERP jej jeszcze nie obsługuje; migracja danych historycznych, która sama potrafi dodać 20–60 godzin.
Do kosztu jednorazowego dolicz koszt stały: abonamenty wtyczek i prowizję operatora płatności. To dwie osobne pozycje w budżecie i trzeba je policzyć razem z wdrożeniem, a nie po fakcie.
| Poziom | Zakres | Godziny robocze | Przy ok. 120 zł/h netto | Przy ok. 200 zł/h netto |
|---|---|---|---|---|
| Startowy | Płatności + 1 kurier | 20–40 | 2 400–4 800 zł | 4 000–8 000 zł |
| Rozszerzony | Płatności + 2 kurierzy + mapa punktów + maile | 40–80 | 4 800–9 600 zł | 8 000–16 000 zł |
| Pełny | ERP dwukierunkowo + kurierzy + płatności + raporty | 100–200 | 12 000–24 000 zł | 20 000–40 000 zł |
Listę przechodzisz dwa razy: przed podpisaniem zlecenia (punkty 1–8) i po wdrożeniu (9–12). Punkt, którego nie da się zamknąć na piśmie, jest zwykle miejscem, w którym projekt się rozjeżdża.
Punkt wyjścia to liczba zamówień miesięcznie i liczba kurierów. Do około 200 zamówień na miesiąc i jednego przewoźnika gotowe, płatne wtyczki zwykle wystarczają — kosztem jest abonament, nie praca dewelopera. Powyżej 200 zamówień i przy dwóch–trzech kurierach rośnie ryzyko: wtyczka robi 80% tego, czego potrzebujesz, a ostatnie 20% obchodzisz własnymi poprawkami, które sypią się przy każdej aktualizacji sklepu.
Kiedy własny moduł wygrywa. Zsumuj roczne abonamenty wszystkich wtyczek w łańcuchu: płatności, dwóch kurierów, mapa punktów, maile transakcyjne. Jeśli ta suma przez 12 miesięcy zbliża się do jednorazowego kosztu modułu plus 1–2 dni pracy rocznie na utrzymanie, własny moduł zaczyna być tańszy. Pamiętaj jednak, że ma koszt utrzymania: zmiany w PHP, aktualizacje rdzenia sklepu, zmiany w API operatorów i KSeF. Zapisz to w budżecie, zanim podejmiesz decyzję.
Pytania do wykonawcy, na które chcesz odpowiedź na piśmie: kto ma dostępy administracyjne po wdrożeniu i czy dostanę własnego użytkownika, a nie wspólny login; jaki jest czas reakcji na błąd i co jest w cenie, a co płatne osobno; czy są testy automatyczne i co pokrywają; czy kod leży w repozytorium klienta (GitHub, GitLab) i przechodzi na moje konto po zakończeniu; czy dostanę opis mapowania statusów i słownik SKU; czy wykonawca pracował już na mojej wersji PHP i sklepu. Przy PrestaShop punktem wyjścia są oficjalne devdocs PrestaShop — warto sprawdzić, czy wykonawca je zna, zanim podpiszesz umowę.
Zdalnie czy na miejscu. Około 90% pracy da się zrobić zdalnie. Wizyta w Lublinie realnie pomaga w trzech sytuacjach: gdy ERP stoi na serwerze w firmie i trzeba wejść do sieci wewnętrznej, gdy trzeba przeszkolić magazyn z generowania etykiet, gdy proces zamówienia ustala się na miejscu przy ludziach, którzy go wykonują. Jeden–dwa dni na miejscu potrafią skrócić projekt o tygodnie, bo decyzje zapadają od razu, a nie w mailach. Podobnie wygląda to przy integracjach z ERP, płatnościami i kurierami w Frampolu i w innych mniejszych firmach w regionie.
| Skala | Kurierzy | Rekomendacja | Główny koszt w 12 mies. |
|---|---|---|---|
| do ~200 zamówień/mies. | 1 | Wtyczki płatne | Abonamenty wtyczek, prowizje operatora |
| 200–1000 zamówień/mies. | 2–3 | Wtyczki plus praca dewelopera na stykach | Abonamenty + godziny dewelopera |
| powyżej 1000 zamówień/mies. lub ERP w środku | dowolna liczba | Własny moduł / integracja przez API | Praca wdrożeniowa + utrzymanie |
Wdrożenie startuje od ERP, bo uznaje się go za najtrudniejszy element.
Jak wykryć: Sprawdź harmonogram projektu: jeśli pierwszym zadaniem jest synchronizacja stanów magazynowych, a płatności i kurierzy są zaplanowane na później, projekt zwykle zatrzymuje się na pierwszym etapie.
Jak naprawić: Zacznij od płatności (najmniejszy zakres, najszybszy efekt), potem dodaj kurierów, a ERP na końcu. Odwrotna kolejność ma sens tylko wtedy, gdy bieżący stan magazynowy jest krytyczny i ERP musi być źródłem prawdy od pierwszego dnia.
Sklep uznaje zamówienie za opłacone po powrocie klienta na stronę z podziękowaniem.
Jak wykryć: Sprawdź, co realnie zmienia status na „opłacone”. Jeśli zmienia go wejście na adres powrotny, a nie webhook od operatora płatności, masz lukę. Test: zapłać BLIK-iem i zamknij przeglądarkę przed powrotem na stronę.
Jak naprawić: Status opłacenia ustawiaj wyłącznie na podstawie webhooka zweryfikowanego podpisem (signature). Powrót klienta traktuj jako element interfejsu, nigdy jako dowód wpłaty.
Brak idempotencji przy powtórzonych webhookach.
Jak wykryć: Włącz logi integracji i sprawdź, czy ten sam identyfikator transakcji przetworzony dwa razy generuje dwa maile do klienta i dwie zmiany statusu. Operatory płatności wysyłają powtórzenia, gdy nie dostaną potwierdzenia.
Jak naprawić: Zapisuj identyfikator transakcji w bazie i odrzucaj powtórzenia. Zmianę statusu zamówienia i zapis identyfikatora wykonuj w jednej transakcji bazodanowej, żeby nie dało się ich rozdzielić.
Statusy kuriera nie są mapowane na statusy sklepu.
Jak wykryć: Jeśli pracownik ręcznie ustawia „wysłane” i wkleja numer listu do treści maila, integracja nie domyka pętli — klient dowiaduje się o przesyłce tylko wtedy, gdy ktoś zdąży to zrobić.
Jak naprawić: Ustal mapowanie: przesyłka utworzona → „w realizacji”, nadana → „wysłane” plus mail z linkiem śledzenia, doręczona → „zakończone”. Numer i link pobieraj z API przewoźnika, nie przepisuj ręcznie.
Brak uzgodnionych słowników: SKU, EAN, jednostki, ceny netto i brutto.
Jak wykryć: Wyeksportuj 20 losowych produktów ze sklepu i z ERP i porównaj kolumny obok siebie: identyfikatory, jednostki miary, jednostki logistyczne, ceny, stawki VAT.
Jak naprawić: Ustal jeden identyfikator nadrzędny obecny po obu stronach (SKU albo EAN), zdefiniuj jednostki i opakowania zbiorcze oraz regułę, kto wygrywa przy cenie i promocji. Bez tego każda synchronizacja będzie nadpisywać dane w losową stronę.
Faktura z KSeF nie wraca do ERP i księgowość dubluje dokument.
Jak wykryć: Sprawdź, czy numer KSeF faktury wystawionej w sklepie pojawia się w ERP i czy ktoś nie wprowadza tej samej faktury drugi raz ręcznie na koniec miesiąca.
Jak naprawić: Dodaj do integracji pole z numerem KSeF i regułę: dokument wystawiony w sklepie trafia do ERP jako istniejący, a nie jako nowy. Terminy obowiązkowego KSeF potwierdź u swojego księgowego lub w źródłach Ministerstwa Finansów — nie zakładaj dat na pamięć.
Integracja jest projektem wyłącznie po stronie wykonawcy, bez właściciela w firmie.
Jak wykryć: Zadaj pytanie: kto po Twojej stronie podejmuje decyzję o mapowaniu statusów i kto testuje zamówienie kontrolne po każdej zmianie? Jeśli odpowiedź brzmi „nikt konkretny”, wdrożenie będzie się ciągnęło.
Jak naprawić: Wyznacz jedną osobę odpowiedzialną za proces i jedno miejsce z zapisanymi ustaleniami. Każda zmiana w integracji przechodzi przez tę osobę.
Integracje z ERP, płatnościami i kurierami w Lublinie układa się etapami, a nie jednym zamówieniem na całość. Najpierw zamknij pętlę płatności na webhookach, potem automatyczne etykiety i tracking, a ERP dołącz wtedy, gdy masz uzgodnione identyfikatory, jednostki i ceny. Najdroższe błędy nie są techniczne — to brak właściciela procesu i brak decyzji, kto jest źródłem prawdy o magazynie i cenie. Zacznij od rozpisania ścieżki zamówienia, a potem kupuj wdrożenie.
Od płatności, jeśli nie masz jeszcze pewnego potwierdzania wpłat. To najmniejszy zakres, najszybciej widoczny efekt i natychmiastowe ograniczenie ręcznej pracy. Od ERP zacznij wtedy, gdy bieżący stan magazynowy jest krytyczny i bez niego sprzedajesz towar, którego nie masz.
Tak, część wdrożeń działa na wymianie plików XML lub CSV, ale to rozwiązanie ma ograniczenia: opóźnienie, brak obsługi konfliktów i ręczne poprawki przy błędach. Jeśli producent oprogramowania udostępnia API, warto je wykorzystać, zwłaszcza przy dużym wolumenie zamówień. Zakres możliwości dla Twojej wersji ERP trzeba potwierdzić u dostawcy — nie zakładaj, że każda wersja ma to samo.
Tylko przez webhook od operatora płatności, zweryfikowany podpisem. Powrót klienta na stronę sklepu jest zdarzeniem kosmetycznym — klient może zamknąć przeglądarkę, stracić internet albo wrócić ręcznie. Dodatkowo zabezpiecz się przed powtórzonymi webhookami, żeby nie zmienić statusu dwa razy i nie wysłać dwóch maili.
Dla większości sklepów detalicznych zestaw: szybki przelew, BLIK i karta pokrywa większość transakcji i wystarcza na start. Płatności odroczone i BNPL mają sens, gdy koszyk jest droższy, a klient się waha — ale każda metoda to dodatkowa prowizja, obsługa zwrotów i kolejny webhook do przetestowania. Przy sprzedaży B2B rozważ osobno przelew z odroczonym terminem, bo tam klient i tak nie zapłaci kartą.
Trzy rzeczy: utworzenie przesyłki w systemie przewoźnika, wygenerowanie etykiety w formacie PDF lub ZPL oraz pobranie numeru i linku śledzenia, który trafia do klienta. Do tego mapowanie statusów przesyłki na statusy zamówienia. Osobne reguły potrzebne są dla punktów odbioru, przesyłek gabarytowych i przesyłek zagranicznych.
Nie ma jednej liczby, bo czas zależy od tego, ile pól trzeba uzgodnić, a nie od tego, ile systemów podłączasz. Najdłużej trwa ustalenie słowników: identyfikatorów, jednostek, cen i statusów. Jeśli ktoś podaje termin bez pytania o te ustalenia, traktuj to jako sygnał ostrzegawczy.
Obowiązkowy KSeF to element, który dotknie większość firm sprzedających w internecie, ale dokładne terminy dla Twojej sytuacji potwierdź u księgowego lub w źródłach Ministerstwa Finansów. Z punktu widzenia integracji ważne jest jedno: numer KSeF faktury sprzedażowej musi wrócić ze sklepu do ERP, inaczej księgowość wprowadzi ten sam dokument drugi raz.
Jeśli chcesz przejść przez audyt procesu zamówienia przed podpisaniem umowy na integracje, napisz do DropDigital — powiemy, co da się wdrożyć etapami, a czego nie warto ruszać na tym etapie.