Co dokładnie łączy się w sklepie – mapa trzech integracji

Trzy integracje to trzy różne słowniki i trzy różne momenty w cyklu zamówienia. Najczęstszy błąd na etapie planowania polega na potraktowaniu ich jako jednego „podłączenia do sklepu”.

• ERP – magazyn, ceny, kontrahenci, faktury, dokumenty magazynowe (PZ, WZ), rezerwacje. Pytanie kontrolne: kto jest źródłem prawdy o stanie towaru – sklep czy ERP.
• Bramka płatności – autoryzacja, potwierdzenie zapłaty, zwrot, reklamacja i chargeback. Tu liczy się tylko status transakcji oraz czas, w jakim wraca do sklepu.
• Kurier – etykieta, nadanie, numer trackingowy, status doręczenia, zwrot do nadawcy. Tu liczy się kompletność adresu, waga i wymiary paczki.

Przepływ zamówienia: klient składa zamówienie → sklep zapisuje je u siebie i przekazuje kwotę do bramki → bramka autoryzuje płatność i odsyła status „opłacone” webhookiem → sklep przekazuje zamówienie do ERP, gdzie powstaje dokument sprzedaży i rezerwacja towaru → sklep lub ERP generuje etykietę i numer trackingowy → klient dostaje e-mail z linkiem do śledzenia. Każde ogniwo ma własny limit czasu i własny sposób zgłaszania błędów.

Co musi działać od startu? Bramka płatności i etykiety kurierskie – bez nich nie ma ani sprzedaży, ani wysyłki. ERP można dołożyć po 2–3 miesiącach sprzedaży, jeśli dzienne przepisywanie zamówień zajmuje mniej niż kilkanaście minut. Gdy zamówień jest kilkadziesiąt dziennie, ręczna praca zaczyna kosztować więcej niż wdrożenie.

Jak spiąć to technicznie, opisujemy przy okazji tematu integracji API w sklepie internetowym. Podstawy komunikacji sklepu z systemami zewnętrznymi znajdziesz też w dokumentacji dla deweloperów PrestaShop.

Integracja z ERP: Subiekt, Comarch, WAPRO, iFirma – co naprawdę się synchronizuje

Zanim padnie jakakolwiek kwota, trzeba ustalić, na czym pracuje księgowość i magazyn. Subiekt GT i Subiekt Nexo to dwa różne światy: GT opiera się na bazie Microsoft SQL i mechanizmach Sfery, Nexo ma własne API i model obiektowy. Comarch Optima, WAPRO i iFirma to kolejne zestawy możliwości. Ta różnica zmienia zakres pracy bardziej niż wybór platformy sklepu.

Lista danych, które realnie się wymieniają:

• z ERP do sklepu: stany magazynowe i dostępność, ceny oraz progi rabatowe, stawki VAT, jednostki miary, dane kontrahenta do faktury, numer faktury po wystawieniu;
• ze sklepu do ERP: zamówienie z pozycjami, ilościami, adresami, metodą dostawy i płatności, status opłacenia, dane do faktury lub paragonu.

Typowy kierunek: magazyn i ceny płyną z ERP do sklepu, zamówienie ze sklepu do ERP, a status płatności wraca do ERP, żeby dokument był rozliczony. Pełna dwustronna synchronizacja kartotek jest rzadsza i wyraźnie droższa.

Integracja online (API, webhooki) działa na żywo – stan zmienia się w ERP i po chwili widać go w sklepie. Integracja wsadowa to eksport i import pliku CSV lub XML uruchamiany co 5–15 minut przez harmonogram zadań. Wsad jest tańszy, ale przy towarze o szybkiej rotacji grozi nadspzedażą: dwa ostatnie egzemplarze mogą zejść w tym samym oknie czasowym.

Pytania do zadania przed wyceną: jaka dokładnie wersja i edycja ERP, czy jest dostęp do bazy lub API, czy system stoi lokalnie czy w chmurze, kto nim administruje i czy da się wystawić osobne konto techniczne. Punkt wyjścia do rozmowy o budżecie znajdziesz w naszym cenniku integracji z ERP, płatnościami i kurierami w Zamościu.

Płatności online: Przelewy24, PayU, Stripe, tpay – jak wybrać bez przepłacania

Bramkę wybiera się pod to, jak płacą Twoi klienci, nie pod to, która marka jest najgłośniejsza. Cztery kryteria, które realnie ważą:

• prowizja – inna dla karty, inna dla BLIK-a, inna dla szybkiego przelewu; zależy od obrotu i bywa negocjowalna, do tego dochodzi stała opłata miesięczna lub jej brak,
• metody płatności – BLIK i szybkie przelewy w pierwszej kolejności, karta w drugiej; przy sprzedaży zagranicznej dochodzi karta wielowalutowa,
• zwroty i reklamacje – zwrot musi dać się wykonać z panelu sklepu lub przez API, a nie wyłącznie ręcznie w panelu bramki,
• webhooki – podpisane, z ponowieniami i z obsługą idempotencji po stronie sklepu.

W praktyce polskich MŚP Przelewy24, PayU i tpay są naturalnym wyborem, gdy klient płaci głównie BLIKiem i szybkim przelewem, a rozliczenia są w złotych. Stripe dobrze wypada przy sprzedaży zagranicznej i płatnościach cyklicznych. Płatność za pobraniem to osobny przypadek: nie ma autoryzacji ani webhooka, więc sklep przez kilka dni nie wie, czy pieniądze wpłyną. Obsługuje się ją jako metodę dostawy z własną opłatą, a ERP musi dostać inny status niż przy zwykłej transakcji.

Pułapka, która wychodzi po kilku dniach: bramka nie odsyła webhooka o zwrocie. Na starcie wszystko wygląda dobrze, bo statusy ustawia się ręcznie. Potem zwrot z panelu bramki nie pojawia się w sklepie, w ERP zostaje niezaksięgowany, a klient dostaje wezwanie do zapłaty za towar, który już odesłał.

Test przed uruchomieniem: cztery scenariusze, wszystkie na produkcji, nie na sandboxie – transakcja z sukcesem, transakcja przerwana w połowie, zwrot środków, reklamacja. Sandbox nie pokaże różnic w komunikacji z prawdziwym bankiem. Punkt wyjścia do sprawdzenia konfiguracji znajdziesz w dokumentacji WooCommerce, a przykłady takich wdrożeń w regionie na stronie o integracjach z ERP, płatnościami i kurierami w Zwierzyńcu.

Kurierzy: InPost, DPD, DHL – automatyczne etykiety i tracking

Pełna integracja z kurierem to nie samo drukowanie etykiety. Spina cztery elementy: wygenerowanie etykiety, zlecenie odbioru kuriera, numer trackingowy i statusy przesyłki. W praktyce wygląda to tak: sklep wysyła do API kuriera dane paczki i dostaje z powrotem plik etykiety (PDF, a dla drukarek termicznych ZPL lub EPL) oraz numer trackingowy. Ten numer musi trafić w dwa miejsca – do wiadomości do klienta i do ERP, żeby wysyłka i faktura dotyczyły tego samego dokumentu.

• InPost – Paczkomaty 24/7 i kurier to dwa różne scenariusze w jednej umowie: inne gabaryty (A, B, C), inny cennik, inna etykieta. Paczkomat wymaga dodatkowo wyboru konkretnego punktu przez klienta w koszyku.
• DPD – usługa klasyczna i Predict (powiadomienie o oknie dostawy) to osobne pozycje w umowie. Jeśli Predict nie jest włączony, API odrzuci nadanie z tym kodem usługi.
• DHL – DHL Parcel i DHL Express to odrębne umowy, loginy i API. Express obsługuje przesyłki zagraniczne, ale nie nada paczki do paczkomatu.

Każdy kurier daje dostęp do API osobno: numer klienta (shipper ID), login, hasło lub token. To generujesz w panelu i wklejasz w konfigurację modułu – bez tego etykieta się nie wydrukuje. Uwaga: przy WooCommerce strefy wysyłki i metody dostawy są skonfigurowane niezależnie od modułu etykiet, co widać w dokumentacji WooCommerce – częsty powód zdziwienia przy pierwszej wysyłce.

Sytuacja graniczna: zamówienie z kilkoma paczkami. Gotowy moduł najczęściej trzyma jedno pole trackingowe na zamówienie. Gdy klient kupuje 40 kg, a Ty wysyłasz to w trzech paczkach, dostajesz trzy numery – klient ma dostać trzy, ERP musi znać trzy. Drugi przypadek to zamówienie wielokrotne: klient dokupuje po nadaniu, jest jedna faktura i kilka przesyłek, a moduł nadpisuje tracking.

Format wymiany: REST z JSON-em, SOAP z XML-em albo CSV wysyłany na FTP. W pliku jadą dane odbiorcy, waga, wymiary, gabaryt, kod usługi, pobranie, wartość ubezpieczenia i numer zamówienia referencyjnego. Warto zobaczyć próbkę, zanim podpiszesz umowę – brak pola na wymiary oznacza, że gabaryt wpiszesz ręcznie. Typowy zakres takiego wdrożenia opisujemy przy usłudze integracji z ERP, płatnościami i kurierami w Zamościu.

Jak działa integracja od środka: API, webhooki, middleware

API działa na zasadzie pytania: sklep pyta „jaki jest status zamówienia 1042?”, system odpowiada. Webhook to zgłoszenie: system sam wysyła do sklepu informację „zamówienie 1042 zostało opłacone”. Różnica jest praktyczna, nie akademicka. Płatności bez webhooków to albo klient czekający na potwierdzenie, albo cron odpywujący bramkę co kilka minut. Kurierzy bez webhooków to tracking aktualizowany dopiero przy eksporcie zamówień, czyli z opóźnieniem liczonym w godzinach.

Webhook musi mieć publiczny endpoint po HTTPS, odpowiadać kodem 200 w kilka sekund i weryfikować podpis lub nagłówki – inaczej ktoś może wysłać fałszywe zdarzenie „opłacone”. Sklep nie powinien przetwarzać zdarzenia w momencie jego odbioru: zapisuje je i przetwarza w kolejce. Warstwę Web Service i podłączanie zewnętrznych systemów opisuje dokumentacja PrestaShop dla deweloperów.

Middleware wchodzi wtedy, gdy ERP nie ma API. Przykład: Subiekt GT albo starsza wersja systemu księgowego, która umie tylko eksport i import plików. Middleware cyklicznie eksportuje zamówienia do CSV/XML, pilnuje mapowania pól, jednostek i stawek VAT, odbiera faktury i stany magazynowe. Gdy ERP ma REST lub SOAP – integracja idzie bezpośrednio, a middleware jest zbędnym ogniwem, które może się zepsuć.

Kolejka i ponawianie: klient zapłacił, ERP nie odpowiada. Zdarzenie trafia do kolejki, próba jest ponawiana typowo 3–5 razy z rosnącym odstępem, po przekroczeniu progu idzie alert do człowieka. Bez tego zamówienie istnieje w sklepie i nie istnieje w magazynie – a dowiesz się o tym od klienta, nie z systemu.

Log integracji to jedyne źródło prawdy przy awarii. Powinien zawierać znacznik czasu, typ zdarzenia, identyfikator zamówienia, kod odpowiedzi HTTP, czas odpowiedzi i treść żądania lub odpowiedzi. Praktyczna zasada: filtruj po kodach innych niż 2xx i patrz na czasy – jeśli rano 200 ms, a po południu 4 s, coś się dzieje. Jak układamy te połączenia w sklepach, opisujemy w sekcji integracje API.

Ile to trwa i ile kosztuje – realne widełki

Trzy scenariusze różnią się nie o 20%, a o rząd wielkości.

• Gotowy moduł plus konfiguracja: 4–16 godzin na jeden konektor (bramka płatności, kurier, ERP z gotowym modułem). Komplet trzech konektorów to zwykle 20–40 godzin. Wliczasz w to konto testowe, mapowanie statusów zamówienia i płatności oraz test zwrotu.
• Integracja na API: 40–120 godzin. Dochodzi obsługa webhooków, kolejki, logowanie, obsługa błędów i scenariusze brzegowe – częściowe płatności, zwroty, korekty.
• Integracja niestandardowa z ERP bez API: 120–300 godzin, a przy dwóch kierunkach wymiany i wielu magazynach bywa więcej. To głównie praca nad plikami, harmonogramem i odpornością na błędy.

Co wydłuża projekt najbardziej: brak środowiska testowego po stronie ERP (pracujesz na produkcji albo czekasz tygodniami na kopię bazy), brak dokumentacji od dostawcy ERP i odpowiedź „najpierw podpiszcie umowę, potem dokumentacja”, niestandardowe pola w sklepie (numer zamówienia u klienta B2B, NIP walidowany po stronie ERP), wiele magazynów, faktury korygujące, częściowe płatności i kilka walut.

Koszty stałe po wdrożeniu – to nie jest jednorazowy wydatek:

• abonament bramki płatności: stała opłata miesięczna zgodna z cennikiem operatora,
• prowizja od transakcji,
• opłaty za dostęp do API kuriera lub pakiet integracyjny zapisany w umowie,
• serwer, certyfikat SSL, zadania cron i kopie zapasowe.

Zasada rozliczenia: wycena na podstawie zakresu i liczby godzin, nie cennik z sufitu. Pytanie „ile kosztuje integracja z ERP” nie ma jednej odpowiedzi, bo wszystko zależy od tego, co ma się synchronizować, w którą stronę, jak często i co ma się dziać przy błędzie. Sensowna kolejność rozmowy jest właśnie taka – dopiero z tego wychodzą godziny. Wtedy porównujesz oferty na tym samym zakresie. Orientacyjne stawki i zakresy znajdziesz w cenniku integracji z ERP, płatnościami i kurierami.

Pułapki integracji i jak je wykryć, zanim klient je zauważy

Większość awarii integracji nie zatrzymuje sklepu. Sprzedaż idzie dalej, a błąd wychodzi dopiero na dokumencie albo w telefonie od klienta.

1. Mapowanie statusów płatności. W sklepie zamówienie ma status „Opłacone” (w PrestaShop to np. „Payment accepted”, w WooCommerce „processing” lub „completed”), a w ERP kontrahent i dokument powstają ze statusu „Nieopłacone”. Efekt: klient, który zapłacił, dostaje fakturę z odroczonym terminem i ponaglenie. Zanim wdrożysz, wypisz mapowanie 1:1 dla wszystkich statusów, także dla „Anulowane”, „Zwrot” i „Częściowy zwrot”. Test: jedno zamówienie za 1 zł z realną płatnością, potem zwrot.

2. Duplikaty zamówień. Bramka płatności ponawia webhook, gdy nie dostanie szybko kodu 200. Bez klucza idempotencji ERP utworzy drugie zamówienie i drugą fakturę. Rozwiązanie to unikalny indeks w tabeli logów po identyfikatorze zamówienia plus hash, a nie poleganie na sprawdzeniu „czy już istnieje”. Sygnał: dwie faktury i dwa dokumenty WZ dla jednego koszyka.

3. Rozjazd stanów magazynowych. Sprzedając w sklepie i na marketplace, synchronizacja co 30 minut przy 20 zamówieniach na godzinę nie wystarczy. Ustaw bufor (np. 2 szt.) i dzienny raport różnic. Sygnał: zamówienie przyjęte, produktu fizycznie nie ma.

4. Tracking po zmianie API kuriera. Zmiana wersji API albo nazwy pola (np. waybill → trackingNumber) potrafi wyłączyć numery w mailach. Mierz zgłoszenia „gdzie moja paczka” na 100 zamówień – wzrost o kilka punktów to alert.

5. Test regresyjny. Po każdej aktualizacji sklepu lub ERP przejdź stałą listę 6–8 scenariuszy: nowe zamówienie, zwrot, anulowanie, brak stanu, dwa kanały, etykieta, faktura korygująca. Zakres takich przepływów opisujemy w Integracje API.

Kiedy zlecić integrację, a kiedy wystarczy gotowy moduł

Reguła jest jedna: jeśli przepływ da się obsłużyć istniejącym modułem, nie płać za dedykowany kod.

Gotowy moduł wystarczy, gdy masz jeden sklep, jedno ERP z API (REST lub SOAP), standardowy przepływ zamówienie → faktura → WZ → etykieta i nie potrzebujesz własnych pól na dokumencie. Konfiguracja to zwykle kilka godzin: instalacja, klucze API, mapowanie statusów i metod dostawy, pierwszy test na zamówieniu za 1 zł. Zanim kupisz moduł „do wszystkiego”, sprawdź, czy obsługuje Twoją wersję sklepu – warto zajrzeć do dokumentacji dla deweloperów PrestaShop, bo tam widać, po których hookach moduł się podłącza.

Deweloper jest potrzebny, gdy ERP nie ma API (zostaje eksport CSV, widok bazodanowy albo pliki na FTP), na dokumencie musi pojawić się niestandardowe pole (numer partii, kod u operatora, podział na VAT OSS), sprzedajesz na kilku kanałach z jednej puli magazynu albo wymagasz rozliczenia godzinowego – np. etykieta musi wyjść do 13:00, żeby kurier zabrał paczkę tego samego dnia.

Utrzymanie. Ustal SLA, zanim podpiszesz cokolwiek: czas reakcji w dni robocze (np. 4 h), czas reakcji w weekend, kanał zgłoszeń, kto ma dostęp do logów. Bez tego „integracja nie działa” w piątek o 20:00 oznacza weekend straconych zamówień.

Deweloper kontra pośrednik. Praca bezpośrednio z osobą, która pisała integrację, skraca diagnozę z dni do godzin – nie płacisz za przekazywanie zgłoszenia przez kolejne ogniwo. Integracje z ERP, płatnościami i kurierami w Krasnobrodzie prowadzimy w takim modelu: od pierwszej rozmowy do utrzymania.

FAQ: pytania o integracje, które dostajemy najczęściej

Ile trwa integracja sklepu z ERP? Gotowy moduł i konfiguracja: 1–3 dni robocze. Dedykowany łącznik: 2–6 tygodni, jeśli ERP ma API, i dłużej, gdy trzeba pracować na plikach albo widokach bazy. Najdłużej schodzi nie na kod, a na ustalenie, które pole w sklepie odpowiada któremu polu w ERP.

Czy ERP musi mieć API? Nie musi, ale bez API rośnie zakres i koszt utrzymania. Zamiast webhooków działasz na eksporcie CSV, FTP albo harmonogramie co 15 minut. To działa, tylko wymaga pilnowania plików i kolejek.

Ile to kosztuje? Nie podajemy jednej kwoty, bo wycena zależy od liczby przepływów, liczby statusów i tego, czy ERP ma API. Rozbicie na pozycje znajdziesz w cenniku integracji w Zamościu, a orientacyjny koszt integracji w Zamościu zależy głównie od tego, czy płatności, ERP i kurier są łączone jednym zamówieniem.

Od czego zacząć, jeśli potrzebuję wszystkiego? Kolejność: płatności (żeby statusy były prawdziwe), potem ERP (magazyn i faktury), na końcu kurierzy (etykiety i tracking). Odwrotna kolejność kończy się etykietą dla zamówienia, którego nie ma w magazynie.

Kto reaguje, gdy integracja padnie w piątek wieczorem? To wynika z SLA ustalonego przed wdrożeniem. Warto zapisać w nim czas reakcji dla dni roboczych i dla weekendu, inaczej każda awaria zamienia się w poniedziałkowe sprzątanie.

Czy zwroty i korekty też się integrują? Tak, i to najczęściej pomijany przepływ. Zwrot musi wrócić na stan, wygenerować korektę i status w sklepie. Opisujemy to schematem FAQPage, zgodnie z dokumentacją Google o danych strukturalnych.

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

Lista kontrolna do odklikania

• Wersja i typ ERP — Ustal przed wyceną, czy pracujesz na Subiekcie GT czy Nexo, Comarch Optima, WAPRO czy iFirmie. Inna wersja to inny zakres pracy i inny sposób łączenia.
• Źródło prawdy dla stanów i cen — Zapisz wprost, który system jest nadrzędny. Domyślnie ERP – sklep tylko wyświetla i sprzedaje.
• Kierunki synchronizacji — Rozpisz osobno: co idzie z ERP do sklepu (magazyn, ceny) i co ze sklepu do ERP (zamówienie, kontrahent, status płatności).
• Częstotliwość synchronizacji — Sprawdź, ile pozycji magazynowych rotuje dziennie. Do kilkudziesięciu wystarczy import co kilkanaście minut, przy setkach potrzebne API.
• Mapowanie pól między systemami — Sprawdź, czy numer faktury, NIP kontrahenta i status płatności mają odpowiedniki po obu stronach. Brak mapowania to najczęstsza przyczyna duplikatów.
• Webhooki bramki płatności — Zapytaj dostawcę wprost, dla których zdarzeń wysyła webhooki i jak wygląda ponowienie po nieudanym wywołaniu.
• Metody płatności w ofercie — Sprawdź proporcje kart, BLIK-a i zwykłych przelewów w swojej historii sprzedaży. Od tego zależy, na czym naprawdę zależy klientom.
• Obsługa zwrotów i reklamacji — Przejdź całą ścieżkę zwrotu w panelu bramki i sprawdź, czy status wraca automatycznie do sklepu i do ERP.
• Cztery scenariusze testowe na produkcji — Sukces, przerwanie, zwrot, reklamacja – wszystkie na prawdziwej transakcji, nie na sandboxie. Wykonaj przed startem sprzedaży.
• Generowanie etykiety i zlecenie odbioru — Sprawdź, czy etykieta powstaje jednym kliknięciem z poziomu zamówienia i czy odbiór kuriera zleca się automatycznie.
• Zamówienia wielopaczkowe — Zrób test na zamówieniu, które realnie jedzie w dwóch paczkach. To najczęstsze miejsce, gdzie gotowy moduł się zatrzymuje.
• Format wymiany danych z kurierem — Ustal, czy integracja idzie przez CSV, XML czy API. Poproś o próbkę pliku, zanim podpiszesz umowę.
• Tracking wracający do klienta i do ERP — Sprawdź, czy numer trackingowy trafia jednocześnie do maila do klienta i do pola w ERP. Ręczne wklejanie nie działa przy większej skali.
• Monitoring błędów i osoba odpowiedzialna — Ustal, gdzie trafiają alerty o nieudanej synchronizacji i kto reaguje. Bez tego pierwszy błąd zauważy klient.

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