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

„Integracja” w liczbie pojedynczej to najczęstsze nieporozumienie w rozmowie z wykonawcą. W sklepie internetowym trzeba połączyć trzy niezależne systemy, z których każdy ma własne API, własne statusy i własny cykl aktualizacji.

• ERP, czyli system sprzedaży i księgowości — Subiekt, Comarch Optima, WAPRO, enova. Tu żyją kartoteki towarów, stany magazynowe i dokumenty sprzedaży. Wymiana idzie w dwie strony: sklep wysyła zamówienie, ERP zwraca numer dokumentu i realny stan magazynowy.
• Operator płatności — bramka odpowiada za autoryzację, potwierdzenie, zwrot i obsługę chargebacku. Zwraca statusy: nowa, potwierdzona, odrzucona, zwrócona.
• Operator logistyczny — kurier lub broker. Efektem są etykieta, numer przesyłki i strumień statusów śledzenia.

Koszt braku integracji policz sam. 60 zamówień dziennie przepisywanych ręcznie to około 90 minut pracy każdego dnia, czyli blisko 40 godzin miesięcznie. Do tego dochodzą pomyłki: literówka w adresie, podmieniony numer przesyłki, zdublowany dokument w księgowości — każda z nich oznacza telefon od klienta i kolejne minuty.

Integracja to nie jednorazowy eksport CSV raz na dobę. Eksport „od–do” bez sprzężenia zwrotnego to tylko połowa procesu: dopóki ERP nie odeśle informacji o rezerwacji towaru, a kurier nie zwróci statusu doręczenia, sklep nie wie, czy zamówienie jest realnie obsłużone. Wymiana musi być dwukierunkowa i cykliczna. Jeśli chcesz najpierw uporządkować pojęcia techniczne, przejrzyj nasze omówienie integracji API — pokazuje różnicę między API, webhookiem a plikiem wymiany.

Jak wygląda przepływ danych od zamówienia do przesyłki – krok po kroku

Pełny łańcuch wygląda tak:

1. Klient składa zamówienie. Sklep zapisuje rekord i nadaje mu własny identyfikator, np. 10432. Ten numer będzie kluczem parowania po wszystkich stronach.
2. Bramka potwierdza płatność. Do sklepu trafia webhook ze statusem „potwierdzona”. Pułapka numer jeden: brak weryfikacji podpisu i brak idempotencji — ten sam webhook potrafi przyjść dwa razy i drugi raz nadpisać poprawny status.
3. Sklep tworzy dokument w ERP. Przez API lub plik wymiany wysyła pozycje, dane nabywcy i ID zamówienia w polu referencji.
4. ERP zwraca numer dokumentu i magazyn. Np. fakturę 124/11/2025 oraz informację, z którego magazynu zeszła rezerwacja.
5. Sklep generuje etykietę u kuriera. Przekazuje adres, wagę i wymiary; w odpowiedzi dostaje numer przesyłki oraz etykietę w PDF lub ZPL.
6. Statusy wracają do klienta. Webhooki od kuriera (nadana, w doręczeniu, doręczona, próba doręczenia) aktualizują zamówienie i uruchamiają e-mail.

Webhooki są szybsze niż odpytywanie API (polling), ale mają wymagania: publiczny, stabilny endpoint po HTTPS, poprawny certyfikat, brak blokad po stronie WAF i odpowiedź 200 w kilka sekund. W PrestaShop logikę wpinamy w moduł obsługujący hooks — punkt wyjścia to dokumentacja dla deweloperów PrestaShop. Polling zostaw jako plan B: odpytuj co 5–15 minut, pamiętając o limitach zapytań. Kolejność webhooków nie jest gwarantowana, więc statusy porównuj po znaczniku czasu albo nadaj im hierarchię („doręczona” nie może zostać cofnięta do „nadana”).

Kluczem parowania rekordów jest ID zamówienia w sklepie — traktuj je jako nadrzędny identyfikator i przekazuj dalej w polu referencji lub komentarza. Numer dokumentu z ERP i numer przesyłki zapisuj jako pola dodatkowe, nigdy jako klucz główny.

ERP w polskim e-commerce: Subiekt, Optima, WAPRO, enova – co realnie da się połączyć

W polskim e-commerce najczęściej łączymy sklepy z Subiektem (GT i nexo), Comarch Optimą, WAPRO oraz enovą. Każdy z tych systemów da się połączyć, ale dróg jest trzy — i różnią się ryzykiem, nie tylko kosztem.

• Oficjalne API. Najstabilniejsza droga: wymiana przez udokumentowane mechanizmy producenta (np. InsERT Sfera) albo dedykowane moduły e-commerce. Aktualizacja ERP zwykle nie psuje integracji. Minus: licencje, czasem dodatkowe opłaty i ograniczenia wydajności przy dużym wolumenie dokumentów.
• Bezpośredni dostęp do bazy (SQL). Szybkie wdrożenie i pełna kontrola nad danymi. Ryzyko: schemat bazy zmienia się przy aktualizacjach i wersjach rocznych, a zapis do tabel z pominięciem logiki programu potrafi rozjechać dokumenty i stany magazynowe. Jeśli już — wyłącznie odczyt.
• Pliki wymiany (CSV, XML, EDI). Rozwiązanie dla starszych wersji bez API. Tanio, ale działa z opóźnieniem, nie waliduje danych w locie i nie zgłasza błędu: zły wiersz po prostu nie trafia do systemu.

Zakres synchronizacji ustal przed startem prac, bo każda pozycja to osobny scenariusz błędów. Jeśli pracujesz na WooCommerce, mechanikę zamówień i integracji opisuje dokumentacja WooCommerce — warto porównać ją z tym, co obiecuje dostawca ERP.

Od 2026 roku dochodzi KSeF. Harmonogram przewiduje obowiązek dla większości przedsiębiorców w tym okresie (dokładne terminy potwierdź w oficjalnych źródłach Ministerstwa Finansów). To zmienia projekt: ERP wystawia fakturę w KSeF, a integracja musi odebrać jej numer i status oraz zadbać, by klient dostał plik. Bez tego sklep wyśle zamówienie do ERP i uzna temat za zamknięty. Jak wygląda cały proces, opisujemy w artykule integracje z ERP, płatnościami i kurierami – co i jak.

Płatności online: PayU, Przelewy24, tpay – co sprawdzić przed wyborem bramki

Bramka płatności to nie tylko przycisk „Zapłać”. To przede wszystkim zestaw webhooków i statusów, które muszą zgadzać się ze statusami zamówienia w sklepie i w ERP. Zanim podpiszesz umowę, poproś operatora o dokumentację API i sprawdź dwie rzeczy: czy notyfikacje rozróżniają autoryzację (środki zablokowane) i potwierdzenie (pieniądze faktycznie pobrane) oraz czy istnieje osobne zdarzenie dla zwrotu. Jeśli wszystkie trzy wpisują się w jeden status „opłacone”, przy pierwszej reklamacji nie odtworzysz, co się stało z pieniędzmi.

Praktyczne mapowanie wygląda tak: autoryzacja nie tworzy w ERP żadnego dokumentu sprzedaży, jest tylko informacją w logu. Potwierdzenie tworzy dokument i wpis płatności. Zwrot wywołuje korektę faktury oraz przyjęcie towaru na stan. Chargeback to najczęściej wstrzymanie realizacji i należność wątpliwa – trzeba mieć na to gotowy scenariusz, bo działa inaczej niż zwykły zwrot.

• BLIK – zwykle jedna notyfikacja i szybkie potwierdzenie, najmniej pułapek w automatyzacji.
• Karty – możliwa ścieżka autoryzacja → potwierdzenie → zwrot, czyli dwa lub trzy wywołania API na jedno zamówienie.
• Raty – status pośredni „oczekuje na decyzję”, zamówienie nie może czekać na tym statusie w nieskończoność.
• Pay-by-link – link wysyłany e-mailem lub SMS-em; zdarza się, że nie ma webhooka po zapłacie i trzeba odpytywać API o status.

Zapytaj też o prowizję od transakcji i od zwrotu, koszt chargebacku, cykl wypłat (np. tygodniowy albo T+7) i kwotę progową wypłaty. Stawki się zmieniają i zależą od obrotu, więc bierz aktualny cennik operatora, a nie tabelę sprzed roku.

Kurierzy: InPost, DPD, DHL – etykiety, punkty odbioru i statusy przesyłek

U kuriera integrują się cztery rzeczy i każda ma swoją pułapkę. Pierwsza to etykieta: generowana z panelu sklepu, zapisywana jako plik przy zamówieniu, z wagą, wymiarami i numerem telefonu odbiorcy. Etykieta kupiona dla zamówienia, które nie zostało opłacone, to najczęstsza strata pieniędzy w tym projekcie – blokada powinna działać przed wywołaniem API kuriera, nie po.

Druga to zlecenie odbioru i protokół. Część firm wymaga wydrukowania protokołu zbiorczego, a pickup zamawia się przez API albo ręcznie. Godziny odbioru w danym regionie są sztywne – jeśli zamówienie wpada o 20:00, a pickup startuje rano, automat musi umieć przesunąć zlecenie na następny dzień, zamiast sypać błędami.

Trzecia to punkty odbioru i Paczkomaty. Wybór punktu musi się odbyć w koszyku, na etapie wyboru dostawy, a kod punktu trafia do zamówienia i na etykietę. Bez kodu paczka pojedzie pod adres domowy i klient zapłaci za dostawę, której nie chciał. Lista punktów jest aktualizowana przez kuriera – jeśli wczytasz ją raz i zamrozisz w bazie, po kilku miesiącach klienci będą wybierać punkty, które nie istnieją.

Czwarta to statusy i numery listów przewozowych. Numer powinien trafić do e-maila i do zamówienia automatycznie, a webhooki kuriera zmapowane na statusy sklepu: nadana, w drodze, gotowa do odbioru, doręczona, zwrot. Jeśli mapowanie stoi, klient dzwoni po trzech dniach po numer, który już istnieje w systemie.

Ile kosztuje integracja – rozbicie na godziny i etapy

Nie ma jednej ceny integracji, jest suma godzin w kilku etapach. Poniższe zakresy to orientacja dla sklepu z jednym kanałem sprzedaży i jednym magazynem – nie oferta. Jeżeli wykonawca podaje kwotę bez audytu, wycenia z sufitu.

• Audyt i mapowanie danych – 8–16 h. Spis systemów, mapowanie pól: SKU, stan, ceny, VAT, kontrahent, dokumenty i statusy.
• Integracja płatności – 12–24 h. Webhooki, statusy, zwroty, testy w środowisku piaskownicy operatora.
• Integracja kuriera – 10–20 h za pierwszego kuriera. Każdy kolejny to zwykle +6–12 h.
• Integracja ERP – 24–60 h. Największy rozrzut, bo tu siedzą stany magazynowe i dokumenty.
• Testy i dokumentacja – 12–24 h. Scenariusze błędów: brak odpowiedzi API, duplikat webhooka, zwrot po wysyłce.

Cena rośnie od czterech rzeczy: liczby kanałów (sklep, marketplace, B2B), liczby magazynów, niestandardowych stanów magazynowych (rezerwacje, kompletacja, stany wirtualne) oraz tego, czy trzeba pisać własny moduł. Zanim zlecisz pisanie od zera, sprawdź gotowe connectory – dla WooCommerce punktem startu jest dokumentacja WooCommerce, dla PrestaShop dokumentacja deweloperska PrestaShop. Własny moduł ma sens wtedy, gdy API ERP jest nietypowe albo logika stanów jest specyficzna dla firmy.

Utrzymanie to osobny budżet: monitoring webhooków (czy notyfikacje dochodzą, czy kolejka nie rośnie), aktualizacje API kurierów po zmianach po ich stronie, kopia danych przed każdą aktualizacją oraz SLA na reakcję – realnie 1–2 dni robocze na błąd krytyczny.

Pułapki, które ujawniają się po miesiącu – i jak je wykryć

Pierwszy miesiąc po wdrożeniu zwykle wygląda dobrze: zamówienia przechodzą, faktury się generują. Kłopoty pojawiają się przy kampanii promocyjnej albo po zmianie wersji API po stronie operatora. Cztery pułapki widać dopiero w danych.

Duplikaty zamówień przy powtórzonym webhooku. Operator płatności, który nie dostanie odpowiedzi 200 w kilka sekund, wyśle to samo zdarzenie ponownie. Bez zabezpieczenia sklep utworzy drugie zamówienie albo drugą fakturę. Lekarstwem jest idempotency key: zapisujesz identyfikator zdarzenia (payment_id, event_id) w tabeli z unikalnym indeksem, np. UNIQUE(payment_id). Druga próba odczytuje istniejący rekord i zwraca 200 bez żadnej akcji. Kontrola: raz w tygodniu porównaj liczbę zamówień w sklepie z liczbą dokumentów w ERP. Różnica 1–3% w dni promocyjne to sygnał, że webhooki się powtarzają. Mechanikę wtyczek, hooków i webhooków opisuje dokumentacja WooCommerce.

Rozjazd stanów magazynowych. Ten sam towar sprzedaje sklep, marketplace i handlowiec z ERP. Jeśli stany aktualizują się w obie strony, dwa zamówienia złożone w tej samej sekundzie nadpiszą się nawzajem i sprzedasz towar, którego nie ma. Zasada: jeden system nadrzędny, najczęściej ERP. Sklep tylko rezerwuje i pyta o dostępność, a nie prowadzi własnego stanu.

Limit czasu i retry u kurierów. API kuriera w godzinach szczytu potrafi odpowiadać 15–30 s. Wywołanie synchroniczne w koszyku oznacza, że klient czeka, a przy błędzie traci zamówienie. Zamiast tego kolejka zadań (Redis, RabbitMQ albo tabela zadań i cron) oraz retry z rosnącym opóźnieniem: 1 min, 5 min, 30 min. Limit czasu ustaw na 10–15 s, a nie na domyślne 30.

Kodowanie i polskie znaki. Plik CSV z ERP w Windows-1250 wczytany jako UTF-8 zamienia „Żółć” na krzaki i towar nie dopasuje się po nazwie. Ustal jedno kodowanie (UTF-8 bez BOM), jeden separator i format liczb, a test importu rób na towarze z ogonkami i myślnikiem.

Bydgoszcz i okolice – jak wygląda współpraca przy wdrożeniu

Pytanie „czy wykonawca musi być z Bydgoszczy” pada prawie przy każdej rozmowie. Krótka odpowiedź: nie, ale nie wszystko da się zrobić zdalnie. Podział wygląda tak.

• Zdalnie – cała warstwa programistyczna: moduł lub wtyczka, obsługa webhooków, mapowanie pól między sklepem a ERP, konfiguracja serwera (wersja PHP, limity pamięci i czasu wykonania, cron, kolejka zadań), testy na środowisku stagingowym na kopii bazy produkcyjnej, wdrożenie i monitoring.
• Na miejscu – audyt procesu magazynowego, czyli 2–4 godziny na przejście ścieżki od zamówienia do wydania paczki i sprawdzenie, kto czego używa, oraz szkolenie zespołu (2–3 godziny: obsługa panelu i reakcja, gdy zamówienie utknie w statusie błędu). Zdarza się też odbiór prac, jeśli w firmie jest osoba techniczna.

Praca zdalna nie zwalnia z zasad. Ustalamy je przed startem:

• Jeden kanał zgłoszeń (system ticketowy albo wspólny projekt) i SLA: reakcja do 4 godzin w dni robocze, do 1 godziny przy zdarzeniu krytycznym, czyli braku możliwości przyjęcia płatności. Wdrożenia wpisujemy w okno serwisowe poza godzinami szczytu sprzedaży.
• Dostęp do środowiska bez haseł w mailu. Konta imienne, menedżer haseł, klucze SSH, osobne konto do API ERP i do API kuriera. Testy zawsze na stagingu z kopią danych, nigdy bezpośrednio na produkcji.
• Dojazd na miejsce wyceniamy osobno. Koszt zależy od odległości i liczby wizyt, więc podajemy go w ofercie, a nie zgadujemy z góry.

Odległość ma mniejsze znaczenie niż to, czy wykonawca pracuje na stagingu, umie skonfigurować kolejkę zadań i zna twój system ERP. Cały zakres takiego projektu rozpisaliśmy w materiale o tym, jak wyglądają integracje z ERP, płatnościami i kurierami – co i jak.

Lista kontrolna przed startem integracji i co dalej

Kolejność wdrożenia nie jest obojętna. Najpierw płatności, potem kurierzy, na końcu ERP. Powód jest praktyczny: płatności i kurierzy nie zależą od ERP, więc działają już w pierwszym tygodniu, a każdy etap można cofnąć bez ruszania księgowości.

• Płatności: webhooki, idempotency key, mapowanie statusów transakcji, wystawianie faktur. 1–3 dni robocze.
• Kurierzy: mapowanie statusów, generowanie etykiet, pobranie, numery nadania. 3–7 dni roboczych.
• ERP: stany magazynowe, dokumenty, księgowość, mapowanie pól (numer zamówienia na numer dokumentu, koszt wysyłki jako pozycja faktury). 2–8 tygodni, bo najwięcej czasu zajmuje ustalenie pól, a nie kod.

Potem decyzja: dokupić kolejną wtyczkę czy zamówić własny moduł. Wtyczka ma sens, gdy jej funkcje pokrywają się z twoim procesem. Własny moduł rozważ, gdy: brakuje mapowania wymaganego przez ERP, po każdej aktualizacji sklepu wtyczka nadpisuje pliki i trzeba ją poprawiać, albo licencja mnoży się przez liczbę środowisk lub sklepów.

Policz to na kartce. 60 zamówień dziennie × 1,5 minuty ręcznego przepisania = 90 minut dziennie, czyli około 375 godzin rocznie przy 250 dniach pracy. Przy stawce 60 zł za godzinę to 22 500 zł. Jeśli własny moduł kosztuje 8 000 zł i 1 500 zł rocznie na utrzymanie, zwraca się w pierwszym roku. Jeśli różnica jest niewielka, zostań przy wtyczce – to też decyzja, tylko świadoma.

Punkt wyjścia to integracje API, orientacyjne stawki znajdziesz w cenniku integracji ERP, płatności i kurierów, a sposób liczenia nakładu na stronie o koszcie integracji. Techniczne podstawy budowy własnego modułu opisuje dokumentacja PrestaShop.

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

Lista kontrolna do odklikania

• Lista systemów i wersji — Zapisz wersję ERP, sklepu i modułów. Sprawdź, czy dostawca wspiera API w twojej wersji – przy starszych wydaniach to bywa główna blokada.
• Źródło prawdy dla cen i stanów — Ustal, czy ceny i stany idą z ERP do sklepu, czy odwrotnie. Bez tej decyzji rozjazdy pojawią się przy pierwszej promocji albo inwentaryzacji.
• Środowisko testowe — Zapytaj o sandbox dla ERP, bramki i kuriera. Jeśli go nie ma, testy odbędą się na produkcji – trzeba to wiedzieć przed startem, nie po.
• Limity API i kary za przekroczenie — Sprawdź limity zapytań na minutę i sposób rozliczania nadwyżek. Ma to znaczenie, gdy synchronizujesz stany magazynowe i obsługujesz kilkadziesiąt zamówień dziennie.
• Webhooki i ich stabilność — Zweryfikuj, czy endpoint sklepu jest publiczny, na HTTPS i działa po aktualizacji. Wymagaj logów zdarzeń i automatycznego ponawiania.
• Mapowanie statusów płatności — Rozpisz autoryzację, potwierdzenie, zwrot i chargeback na statusy sklepu oraz dokumenty w ERP. Każdy status musi mieć jednoznaczne przełożenie.
• Metody płatności — Ustal, które metody obsługujesz: BLIK, karty, raty, pay-by-link. Sprawdź, czy wszystkie mają taką samą logikę powiadomień, czy któraś wymaga osobnej ścieżki.
• Rozliczenia i prowizje — Zapytaj o czas wypłaty środków i sposób dokumentowania prowizji. Opłaty powinny trafiać do księgowości bez ręcznego dopisywania.
• Zwroty i korekty — Przećwicz scenariusz: klient zwraca towar, bramka zwraca pieniądze, ERP wystawia korektę. Ustal, kto inicjuje każdy krok i co dzieje się ze stanem magazynowym.
• Kurierzy i punkty odbioru — Sprawdź, czy wybór paczkomatu lub punktu jest dostępny w koszyku i czy kod punktu trafia do zamówienia oraz do ERP.
• Etykiety i protokoły odbioru — Ustal, czy etykietę generujesz z panelu sklepu, i kto umawia kuriera. Sprawdź, czy protokół odbioru powstaje automatycznie, czy trzeba go układać ręcznie.
• Statusy przesyłek do klienta — Zweryfikuj, czy numer listu przewozowego i zmiany statusu wysyłają się mailem automatycznie. Przy 60 zamówieniach dziennie ręczne wysyłanie numerów to strata czasu.
• KSeF i fakturowanie — Ustal, który system wystawia fakturę i jakie dane musi otrzymać z zamówienia. Aktualny harmonogram KSeF i zasady fakturowania potwierdź u księgowej lub w źródłach urzędowych.
• Testy i dokumentacja — Zapisz na piśmie scenariusze błędów: brak towaru, nieudana płatność, zwrot częściowy, brak odpowiedzi API. Ustal, kto reaguje i w jakim czasie, gdy integracja się zatrzyma.

Najczęściej zadawane pytania

Źródła i materiały

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