Konfiguracja jednolitej obsługi płatności dla wielu kanałów

Jednolita obsługa płatności dla wszystkich kanałów sprzedaży upraszcza rozliczenia i ułatwia bieżącą kontrolę nad wpływami.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie wspólnego systemu obsługi płatności dla wszystkich wykorzystywanych kanałów sprzedaży.

Dla kogo ma sens

Usługa jest przydatna dla firm sprzedających wielokanałowo, które chcą uprościć zarządzanie płatnościami.

Ile to trwa

Konfiguracja obsługi płatności mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Architektura wielokanałowej obsługi płatności i obieg danych

Wielokanałowy model sprzedaży (omnichannel) wymaga sprawnego i bezbłędnego przepływu informacji finansowych pomiędzy wieloma punktami styku z klientem a centralnym systemem ewidencji. W nowoczesnym przedsiębiorstwie sprzedaż prowadzona jest jednocześnie przez niezależne sklepy internetowe, internetowe platformy handlowe (marketplace), zamówienia telefoniczne i mailowe oraz stacjonarne punkty handlowe. Brak jednolitej konfiguracji płatności prowadzi do powstawania rozproszonych rejestrów, konieczności ręcznego weryfikowania wyciągów bankowych oraz opóźnień w realizacji zamówień.

Centralnym elementem jednolitej architektury jest zintegrowanie bramek płatniczych (Payment Gateway – systemów pośredniczących w bezpiecznym przesyłaniu danych transakcyjnych i autoryzacji płatności bezgotówkowych) z platformami e-commerce oraz systemami nadrzędnymi. Informacja o dokonaniu wpłaty jest przekazywana w czasie rzeczywistym za pomocą webhooków (webhook – mechanizm asynchronicznego przesyłania powiadomień HTTP o zdarzeniach pomiędzy serwerami). Po otrzymaniu potwierdzenia transakcji system integracyjny automatycznie aktualizuje status zamówienia, rezerwuje stany magazynowe i przekazuje dane do wystawienia dokumentu sprzedaży.

Obsługiwane platformy sprzedażowe, systemy ERP i bramki płatnicze

Konfiguracja obejmuje pełne spektrum narzędzi programistycznych i handlowych wykorzystywanych na rynku. Wdrażamy i unifikujemy płatności dla platform sklepowych, systemów magazynowo-księgowych oraz agregatorów płatności:

Platformy e-commerce: WooCommerce (system e-commerce oparty na silniku WordPress), PrestaShop (samodzielna platforma handlowa typu open-source), Magento / Adobe Commerce (zaawansowane środowisko sprzedaży internetowej), Shopify oraz Shoper.
Platformy marketplace: integracja ewidencji płatności z serwisów Allegro, Amazon, EmpikPlace, Erli oraz eBay za pośrednictwem integratorów wielokanałowych.
Systemy ERP (Enterprise Resource Planning – zintegrowane systemy zarządzania zasobami przedsiębiorstwa): InsERT GT (Subiekt GT, Rewizor GT), InsERT nexo (Subiekt nexo PRO, Rachmistrz nexo), Comarch ERP (Optima, XL), WAPRO ERP (WAPRO Mag, dawniej WF-Mag), Sage Symfonia oraz enova365.
Bramki i operatorzy płatności elektronicznych: PayU, Przelewy24, Autopay (dawniej Blue Media), Tpay, Stripe, imoje (system płatności banku ING), eService oraz Polskie ePłatności.
Płatności odroczone i ratalne: wdrażanie metod BNPL (Buy Now, Pay Later – model płatności odroczonych, takich jak PayPo, Twisto czy Klarna) oraz płatności ratalnych online zintegrowanych bezpośrednio z procesem zakupowym.

Warianty wdrożenia jednolitej obsługi płatności

W zależności od skali działalności, liczby kanałów sprzedaży oraz wykorzystywanego oprogramowania nadrzędnego stosuje się różne modele architektoniczne integracji płatności:

Wariant scentralizowany w systemie ERP: Wszystkie transakcje z bramek internetowych, platform handlowych oraz terminali stacjonarnych trafiają bezpośrednio do jednego rejestru rozrachunków w programie finansowo-księgowym (np. Subiekt nexo PRO lub Comarch ERP Optima). Zapewnia to natychmiastową spójność bilansową i automatyczne parowanie wpłat z wystawianymi fakturami lub paragonami.
Wariant oparty na integratorze sprzedaży: Wykorzystanie platformy integrującej (takiej jak BaseLinker – centralny system do zarządzania zamówieniami wielokanałowymi) jako głównego węzła weryfikacji wpłat. Statusy płatności są pobierane ze wszystkich kanałów do jednego panelu operacyjnego, a po zatwierdzeniu wpłaty zamówienie wraz z potwierdzonym statusem finansowym jest automatycznie przesyłane do programu magazynowego.
Wariant hybrydowy (online i offline): Połączenie sprzedaży internetowej ze stacjonarnymi terminalami płatniczymi POS (Point of Sale – elektroniczny terminal do obsługi kart w punkcie handlowym). Terminale są konfigurowane do pracy w trybie ECR (Electronic Cash Register – protokół bezpośredniej komunikacji komputera lub kasy fiskalnej z terminalem płatniczym), co eliminuje konieczność ręcznego wpisywania kwot przez sprzedawcę i automatycznie odnotowuje wpłatę w tym samym systemie, który obsługuje zamówienia internetowe.

Automatyzacja księgowania i rozliczania wyciągów bankowych

Ręczne wprowadzanie i weryfikowanie setek pojedynczych wpłat od operatorów płatności jest procesem czasochłonnym i narażonym na błędy rozliczeniowe. Istotnym elementem unifikacji obsługi płatności jest automatyzacja importu danych finansowych do modułów bankowych w programach ERP.

Wdrażamy automatyczny import wyciągów bankowych i raportów rozliczeniowych w formatach MT940 (międzynarodowy standard zapisu elektronicznych wyciągów bankowych SWIFT) oraz CAMT.053 (format wyciągu bankowego w strukturze XML zgodny ze standardem ISO 20022). Konfigurujemy reguły automatycznego parowania (tzw. matching płatności), które rozpoznają identyfikatory zamówień, numery transakcji bramki płatniczej oraz dane wpłacających.

System jest również konfigurowany pod kątem prawidłowego rozliczania prowizji pobieranych przez agregatorów płatności. Zamiast ręcznego korygowania różnic pomiędzy wartością zamówienia brutto a kwotą netto przekazaną przez operatora, tworzone są schematy automatycznego księgowania prowizji na dedykowane konta kosztowe na podstawie okresowych zestawień transakcyjnych.

Procedura wdrożenia i weryfikacji konfiguracji

Proces wdrażania jednolitej obsługi płatności realizowany jest w uporządkowanych etapach, co gwarantuje ciągłość sprzedaży i bezpieczeństwo operacji finansowych:

Etap 1: Audyt środowiska IT i analiza kanałów sprzedaży. Weryfikacja wersji silników sklepowych, modułów integracyjnych, bazy danych ERP oraz kont u operatorów płatności. Na życzenie klienta przed rozpoczęciem prac podpisywana jest bezpłatna umowa o zachowaniu poufności (NDA – Non-Disclosure Agreement).
Etap 2: Konfiguracja środowiska testowego. Uruchomienie bezpiecznych kont typu Sandbox (izolowane środowisko programistyczne umożliwiające symulację transakcji finansowych bez obciążania rzeczywistych środków) u wybranych operatorów płatności.
Etap 3: Implementacja kluczy API i sygnatur kryptograficznych. Konfiguracja interfejsów programistycznych, wdrożenie bezpiecznych kluczy autoryzacyjnych oraz sum kontrolnych HMAC (Hash-based Message Authentication Code – kryptograficzny kod uwierzytelniania wiadomości gwarantujący nienaruszalność danych transakcyjnych).
Etap 4: Konfiguracja adresów zwrotnych i powiadomień IPN. Ustawienie bezpiecznych adresów dla powiadomień IPN (Instant Payment Notification – automatyczne powiadomienie serwera o zatwierdzeniu wpłaty) oraz mapowanie statusów transakcji na odpowiednie statusy w systemie magazynowym.
Etap 5: Testy funkcjonalne pełnego cyklu transakcyjnego. Przeprowadzenie próbnych płatności różnymi kanałami (BLIK, karty płatnicze, szybkie przelewy elektroniczne, płatności odroczone), weryfikacja automatycznej zmiany statusów, testy procedury zwrotu środków (refunds) oraz weryfikacja poprawności zapisu w rejestrze finansowym ERP.
Etap 6: Uruchomienie produkcyjne i asysta techniczna. Przełączenie bramek w tryb produkcyjny, nadzór nad pierwszymi rzeczywistymi transakcjami oraz weryfikacja poprawności dobowych raportów rozliczeniowych.

Najczęstsze błędy przy próbach samodzielnej konfiguracji

Nieprawidłowe wdrożenie modułów płatności wielokanałowych prowadzi do problemów operacyjnych, zablokowanych zamówień oraz niezgodności w dokumentacji księgowej. Najczęściej spotykane błędy obejmują:

Błędna konfiguracja adresów webhook i powiadomień IPN: Jeśli serwer sklepu lub integratora nie może odebrać informacji zwrotnej od bramki (np. z powodu blokad sieciowych lub literówki w adresie URL), zamówienie pozostaje w statusie nieopłaconym mimo pobrania pieniędzy z konta klienta. Skutkuje to wstrzymaniem wysyłki towaru i koniecznością ręcznej interwencji.
Brak rozróżnienia subkont i walut rozliczeniowych: Przyjmowanie płatności w wielu walutach (EUR, USD, GBP, PLN) bez skonfigurowania dedykowanych rejestrów walutowych w ERP prowadzi do błędnych przeliczeń kursowych i powstawania sztucznych różnic bilansowych.
Niewłaściwa obsługa zaokrągleń groszowych: Niezgodność algorytmów obliczania podatku i sumy koszyka pomiędzy silnikiem sklepu a bramką płatniczą powoduje odrzucanie transakcji ze względu na błąd sumy kontrolnej (rozbieżność o 1 grosz).
Zapisywanie poufnych kluczy API w plikach jawnych: Przechowywanie kluczy prywatnych i haseł do bramek w publicznie dostępnych katalogach serwera WWW stwarza poważne ryzyko naruszenia bezpieczeństwa danych i nieautoryzowanego dostępu do operacji finansowych.
Brak mechanizmów zabezpieczających przed nadpisaniem konfiguracji: Modyfikowanie plików wtyczek płatności bezpośrednio w kodzie źródłowym zamiast stosowania dedykowanych haków (hooks) i mechanizmów nadpisywania powoduje utratę całej konfiguracji podczas automatycznej aktualizacji silnika sklepu.

Kiedy problem nie leży w bramce płatniczej, lecz w infrastrukturze

W wielu przypadkach nieprawidłowe działanie obsługi płatności nie wynika z awarii samego operatora transakcji, lecz z błędów w konfiguracji środowiska serwerowego lub oprogramowania pośredniczącego:

Agresywne buforowanie stron (cache): Zbyt restrykcyjna konfiguracja pamięci podręcznej na poziomie serwera WWW (np. moduły Varnish, LiteSpeed Cache lub usługi Cloudflare) może buforować dynamiczne identyfikatory sesji koszyka, co uniemożliwia wygenerowanie unikalnego linku do płatności dla klienta.
Blokady zapory sieciowej WAF (Web Application Firewall – zapora aplikacji internetowych filtrująca ruch sieciowy): Błędnie skonfigurowane reguły zapory mogą traktować automatyczne zapytania wysyłane przez serwery PayU, Przelewy24 czy Autopay jako próby ataków sieciowych i blokować ich adresy IP, uniemożliwiając odebranie potwierdzenia wpłaty.
Przeciążenia bazy danych i opóźnienia harmonogramu CRON: Zablokowane kolejki zadań systemowych na serwerze (CRON – harmonogram zadań wykonywanych w tle) opóźniają przetwarzanie transakcji i wymianę danych z systemem ERP, co sprawia wrażenie zawieszenia systemu płatności.
Błędy synchronizacji stanów magazynowych: Opóźnienia w wymianie danych pomiędzy ERP a sklepem mogą doprowadzić do przyjęcia zapłaty za produkt, który w rzeczywistości został już wyprzedany w innym kanale sprzedaży.

Bezpieczeństwo transakcji i zgodność ze standardami

Wdrożenie wielokanałowej obsługi płatności musi spełniać rygorystyczne wymagania prawne i technologiczne dotyczące ochrony danych finansowych:

Konfiguracja jest realizowana zgodnie ze standardem PCI DSS (Payment Card Industry Data Security Standard – międzynarodowy standard bezpieczeństwa danych w branży kart płatniczych). Wdrażane są mechanizmy bezpiecznego przekierowania i tokenizacji danych kartowych, dzięki czemu wrażliwe numery kart nie są przetwarzane ani przechowywane bezpośrednio na serwerze sklepu.

Zapewniamy pełną obsługę procedur silnego uwierzytelniania klienta SCA (Strong Customer Authentication – wymóg dwuskładnikowego potwierdzania tożsamości płatnika wynikający z unijnej dyrektywy PSD2) za pośrednictwem protokołów 3D Secure 2.2. Całość transmisji danych jest zabezpieczona nowoczesnymi protokołami szyfrowania TLS 1.3 (Transport Layer Security – protokół kryptograficzny zapewniający poufność przesyłanych danych).

Wdrażamy także mechanizmy chroniące formularze płatności przed atakami typu Carding (zautomatyzowane próby testowania skradzionych numerów kart przez boty internetowe), stosując niewidoczne zabezpieczenia antyspamowe oraz inteligentne limity zapytań (rate limiting).

Dodatkowe pytania klientów (FAQ)

Czy po zintegrowaniu płatności zwroty środków do klientów można zlecać bezpośrednio z systemu ERP lub BaseLinkera?

Tak, jest to możliwe pod warunkiem, że dany moduł integracyjny oraz interfejs API operatora płatności obsługują operacje zwrotne (refunds). Po skonfigurowaniu odpowiednich uprawnień kluczy API, wygenerowanie korekty dokumentu sprzedaży w programie ERP (np. Subiekt nexo lub Comarch Optima) lub zmiana statusu zamówienia na zwrócone w panelu integratora może automatycznie wysłać polecenie zwrotu środków do bramki płatniczej bez konieczności ręcznego logowania się do panelu operatora.

Jak rozwiązać problem rozbieżności kwot wynikających z potrącania prowizji przez operatora płatności?

Stosuje się model rozliczeń oparty na wirtualnych rejestrach bankowych w systemie ERP. Do rejestru przypisanego do danego operatora płatności wpływa pełna kwota brutto wynikająca z wartości zamówienia, co pozwala na pełne rozliczenie należności klienta. Prowizja potrącona przez operatora jest księgowana zbiorczym dokumentem kosztowym na podstawie okresowego zestawienia opłat generowanego przez bramkę płatniczą.

Czy konfiguracja jednolitej obsługi płatności wymaga wstrzymania bieżącej sprzedaży w sklepie internetowym?

Nie ma potrzeby wyłączania sklepu ani blokowania zakupów. Wszystkie prace konfiguracyjne, tworzenie reguł integracji oraz testy komunikacji API realizowane są w środowiskach testowych (Sandbox) lub na kopiach roboczych. Przełączenie na nowy mechanizm obsługi płatności odbywa się płynnie i nie zakłóca procesu składania zamówień przez klientów.

W jaki sposób chronione są dane logowania i klucze API podczas prac wdrożeniowych?

Konfiguracja prowadzona jest z zachowaniem najwyższych standardów bezpieczeństwa IT. Domyślnie nie prosimy o hasła do bankowości internetowej ani głównych kont administratora. Integracja opiera się na wygenerowanych kluczach API o ściśle określonych, minimalnych uprawnieniach niezbędnych do obsługi transakcji. Na życzenie klienta przed rozpoczęciem prac podpisywana jest bezpłatna umowa o zachowaniu poufności (NDA).

Czy w przyszłości będzie można łatwo dodać kolejny kanał sprzedaży lub nowego operatora płatności?

Architektura wdrożonego rozwiązania jest modułowa i w pełni skalowalna. Dołączenie nowego sklepu internetowego, uruchomienie sprzedaży na nowej platformie marketplace lub podłączenie dodatkowego terminala stacjonarnego polega na skonfigurowaniu nowego konektora w ramach istniejącego schematu wymiany danych, bez konieczności modyfikowania całej struktury księgowej.

Spójność i automatyzacja rozliczeń wielokanałowych w codziennej działalności

Prawidłowo skonfigurowana, jednolita obsługa płatności eliminuje bariery w skalowaniu sprzedaży wielokanałowej. Zapewnia natychmiastową weryfikację wpłat, przyspiesza proces pakowania i wysyłki towaru oraz gwarantuje pełną zgodność rejestrów finansowych z rzeczywistym stanem rachunków bankowych.

22 378 48 09