Automatyczne oznaczanie zamówień jako opłacone w BaseLinkerze przyspiesza ich realizację i ogranicza ręczną weryfikację płatności.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie w BaseLinkerze reguł automatycznego oznaczania zamówień jako opłacone na podstawie zaksięgowanych wpłat.

Dla kogo ma sens

Usługa jest przydatna dla firm korzystających z BaseLinkera, które chcą przyspieszyć proces realizacji opłaconych zamówień.

Ile to trwa

Konfiguracja automatycznego oznaczania 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.

Źródła danych o płatnościach w środowisku BaseLinker

Automatyzacja procesów magazynowych i logistycznych wymaga bezbłędnego przekazywania informacji o stanie rozliczeń z poszczególnych kanałów sprzedaży. BaseLinker pobiera dane o płatnościach z kilku niezależnych źródeł, a każde z nich wymaga dedykowanej metody synchronizacji:

Bramki płatności online – systemy pośredniczące w transakcjach elektronicznych, takie jak PayU, Przelewy24, Autopay, Tpay, Stripe, PayPal, Klarna czy BLIK. Informacje o zaksięgowaniu środków trafiają do systemu natychmiast po autoryzacji transakcji za pośrednictwem webhooków (mechanizmów sieciowych wysyłających automatyczne powiadomienia o zdarzeniach z zewnętrznego serwera w czasie rzeczywistym).
Platformy typu marketplace – serwisy handlowe, w tym Allegro, Amazon, eBay, Erli, Empik Marketplace oraz Kaufland. Dane o rozliczeniu zamówienia są pobierane bezpośrednio przez interfejs API (Application Programming Interface, czyli zestaw reguł umożliwiających bezpośrednią wymianę danych między różnymi programami komputerowymi) i zapisywane w szczegółach zamówienia w BaseLinkerze.
Sklepy internetowe – silniki e-commerce takie jak WooCommerce, PrestaShop, Shopify, Magento, Shoplo czy Shoper. W tym przypadku status płatności jest przekazywany z bazy sklepu do panelu zarządzania zamówieniami za pomocą dedykowanych wtyczek synchronizujących lub bezpośrednich zapytań API.
Tradycyjne przelewy bankowe – wpłaty realizowane bezpośrednio na firmowe rachunki bankowe. Dane o przelewach są wprowadzane do BaseLinkera poprzez import elektronicznych wyciągów bankowych (w formatach MT940, XML camt.053 lub CSV) bądź za pośrednictwem automatycznych integratorów bankowości elektronicznej.
Przesyłki płatne przy odbiorze (COD, Cash on Delivery) – płatności gotówką lub kartą realizowane u kuriera. Rozliczenie następuje na podstawie raportów zwrotu pobrań generowanych przez firmy kurierskie (takie jak InPost, DPD, DHL, Poczta Polska, GLS czy FedEx) po przekazaniu środków na konto nadawcy.

Architektura automatycznych akcji i warunków logicznych

Sercem automatyzacji w BaseLinkerze jest moduł automatycznych akcji (Automated Actions). Pozwala on na zdefiniowanie precyzyjnych schematów postępowania, które uruchamiają się samoczynnie w odpowiedzi na określone zdarzenia systemowe bez konieczności ręcznego sprawdzania każdego zamówienia przez pracownika.

Prawidłowo zaplanowany schemat składa się z trzech powiązanych ze sobą elementów:

Zdarzenie wyzwalające (Trigger) – moment, w którym system rozpoczyna analizę zamówienia. Do najczęściej stosowanych zdarzeń należą: pobranie nowego formularza opcji dostawy (FOD, czyli formularza w serwisie Allegro zawierającego wybrane metody wysyłki i płatności), odnotowanie wpłaty w zamówieniu, zmiana statusu płatności przez bramkę zewnętrzną lub zaimportowanie nowego wyciągu bankowego.
Warunki logiczne (Conditions) – zestaw filtrów weryfikujących, czy dane zamówienie kwalifikuje się do automatycznej zmiany. Sprawdzane są między innymi: zgodność wpłaconej kwoty z łączną wartością brutto zamówienia, rodzaj wybranej formy płatności (płatność z góry kontra pobranie), bieżący status realizacji oraz brak blokad systemowych.
Wykonywane akcje (Actions) – operacje realizowane natychmiast po spełnieniu wszystkich warunków logicznych. Obejmują one zmianę flagi zamówienia na „Opłacone”, przeniesienie zamówienia do kolejnego statusu (na przykład „Do pakowania” lub „Gotowe do wysyłki”), wygenerowanie dokumentu sprzedaży, utworzenie listu przewozowego oraz wysłanie wiadomości potwierdzającej do kupującego.

Warianty konfiguracji oznaczania płatności w praktyce

Wdrożenie automatycznego oznaczania zamówień wymaga dostosowania logiki systemu do profilu działalności firmy, wykorzystywanych kanałów sprzedaży oraz specyfiki oferowanego asortymentu. W praktyce stosuje się kilka odmiennych wariantów konfiguracyjnych:

Wariant dla sprzedaży wielokanałowej (Omnichannel) – w firmach łączących sprzedaż na platformach marketplace z własnym sklepem internetowym konfiguruje się oddzielne reguły dla każdego źródła. Dla platformy Allegro, gdzie płatności przez Allegro Finanse (w tym Allegro Pay i płatności ratalne) są autoryzowane niemal natychmiast, zamówienie po pobraniu pełnego formularza FOD jest od razu oznaczane jako opłacone i przekazywane do kompletacji magazynowej. Dla zamówień ze sklepu internetowego reguła oczekuje na zwrotny sygnał z bramki płatności (na przykład PayU lub Przelewy24), a w przypadku braku wpłaty w określonym czasie wysyła automatyczne przypomnienie z bezpośrednim linkiem do ponowienia transakcji.

Wariant z automatyczną weryfikacją wyciągów bankowych – przeznaczony dla firm obsługujących zamówienia hurtowe (B2B) lub transakcje o wyższej wartości, w których kontrahenci preferują tradycyjne przelewy bankowe. W tym modelu konfiguruje się cykliczny import plików wyciągów (format MT940 lub format XML camt.053). System analizuje tytuł przelewu pod kątem obecności numeru zamówienia lub numeru faktury proforma, porównuje kwotę transakcji z saldem zamówienia i po dopasowaniu automatycznie oznacza wpłatę oraz przesuwa zamówienie do realizacji.

Wariant zintegrowany z systemem magazynowo-sprzedażowym ERP – stosowany w środowiskach, w których zamówienia są synchronizowane z zewnętrznymi programami handlowymi, takimi jak InsERT GT/nexo (Subiekt), Comarch ERP (Optima, XL), WAPRO ERP (WAPRO Mag), Sage Symfonia czy enova365. W tym scenariuszu zmiana statusu na „Opłacone” w BaseLinkerze stanowi impuls do wygenerowania dokumentu końcowego w programie ERP (Enterprise Resource Planning, czyli zintegrowanym systemie do zarządzania zasobami i procesami przedsiębiorstwa), takiego jak faktura imienna, faktura bez VAT lub paragon, a także zarejestrowania operacji w module finansowym.

Wariant z obsługą zamówień zagranicznych (Cross-border) – wdrożenie uwzględniające wiele walut rozliczeniowych (między innymi EUR, USD, GBP, CZK) oraz integracje z zagranicznymi operatorami płatności (takimi jak Stripe, Klarna, PayPal czy Adyen). Reguły automatyczne weryfikują zgodność waluty wpłaty z walutą zamówienia oraz monitorują ewentualne różnice kursowe, aby uniknąć błędnego oznaczenia zamówienia w przypadku niepełnego pokrycia kwoty z powodu przewalutowania.

Błędy popełniane przy samodzielnej konfiguracji reguł

Nieprawidłowo ustawione reguły automatyczne w BaseLinkerze mogą prowadzić do poważnych zakłóceń w pracy magazynu oraz strat finansowych. Do najczęstszych problemów konfiguracyjnych należą:

Oznaczanie zamówień jako opłacone bez weryfikacji kwoty – utworzenie reguły bazującej wyłącznie na fakcie zarejestrowania jakiejkolwiek wpłaty, bez sprawdzenia, czy wpłacona suma pokrywa całą wartość zamówienia brutto. Skutkuje to realizacją i wysyłką towaru w sytuacji, gdy kupujący wpłacił jedynie część należności (na przykład przy pomyłce w przelewie tradycyjnym).

Powstawanie pętli zdarzeń i dublowanie dokumentów – zdefiniowanie reguł, które wzajemnie się wyzwalają (na przykład zmiana statusu płatności wywołuje zmianę statusu zamówienia, co z kolei ponownie wymusza weryfikację płatności). W efekcie system potrafi wygenerować wielokrotne etykiety kurierskie, zduplikować dokumenty sprzedaży lub wysłać do klienta serię powtarzających się powiadomień e-mail.

Brak obsługi zamówień łączonych i rozdzielanych – sytuacja, w której kupujący składa dwa oddzielne zamówienia, płaci za nie łącznie jednym przelewem, a następnie prosi o połączenie paczek. Jeśli reguły nie uwzględniają zamówień scalonych, wpłata zostaje przypisana tylko do jednego z nich, a drugie pozostaje zablokowane ze statusem informującym o braku środków.

Ignorowanie różnic groszowych i zaokrągleń podatkowych – drobne rozbieżności w wyliczeniach podatku lub cen jednostkowych między silnikiem sklepu a BaseLinkerem (często rzędu 1 grosza) mogą spowodować, że system zaklasyfikuje wpłatę jako niedopłatę i wstrzyma automatyczne oznaczanie zamówienia.

Błędne mapowanie statusów bramek płatności – ustawienie automatycznego oznaczania na podstawie statusu informującego jedynie o rozpoczęciu transakcji (Pending) zamiast statusu potwierdzającego jej pełne zakończenie (Completed lub Settled). W takim przypadku zamówienie zostaje oznaczone jako opłacone nawet wtedy, gdy klient porzuci proces płatności w oknie banku.

Kiedy problem z oznaczaniem leży poza BaseLinkerem

Zdarzają się sytuacje, w których brak oznaczenia zamówienia jako opłacone nie wynika z błędnej konfiguracji w panelu BaseLinkera, lecz z czynników zewnętrznych. Prawidłowa diagnostyka wymaga odróżnienia awarii konfiguracji od zakłóceń w infrastrukturze współpracującej:

Opóźnienia po stronie operatorów płatności – przerwy techniczne lub opóźnienia w przetwarzaniu transakcji przez bramki płatnicze i systemy bankowe (na przykład harmonogramy sesji rozliczeniowych Elixir, opóźnienia w systemie BLIK czy prace serwisowe w bankowości elektronicznej). W takich przypadkach webhook z potwierdzeniem wpłaty dociera z kilkugodzinnym opóźnieniem.

Blokady komunikacji sieciowej na serwerze sklepu – zapory sieciowe (firewall) lub mechanizmy ochrony przed atakami (takie jak Cloudflare czy moduły WAF – Web Application Firewall, czyli zapory aplikacji internetowych filtrujące ruch sieciowy) na serwerze sklepu internetowego mogą blokować przychodzące powiadomienia POST z bramek płatności lub uniemożliwiać BaseLinkerowi pobranie zaktualizowanego stanu bazy danych.

Przetrzymywanie weryfikacji przez platformy marketplace – wewnętrzne mechanizmy bezpieczeństwa serwisów handlowych (na przykład weryfikacja antyfraudowa w Allegro Finanse, Amazon Seller Central czy eBay Managed Payments), które tymczasowo wstrzymują zatwierdzenie środków do momentu zakończenia procedury sprawdzającej.

Błędy we wtyczkach i modułach sklepowych – nieaktualne wersje wtyczek integracyjnych w sklepach WooCommerce, PrestaShop czy Magento, które nie rejestrują numeru identyfikacyjnego transakcji (Transaction ID) w standardowych polach bazy danych, przez co BaseLinker nie ma możliwości odczytania statusu rozliczenia.

Dodatkowe pytania klientów (FAQ)

Czy system potrafi automatycznie obsłużyć płatności odroczone i ratalne?

Tak. Płatności odroczone (takie jak PayPo, Klarna, Twisto, Allegro Pay czy Comfino) z perspektywy sprzedawcy są traktowane jako opłacone natychmiast po ich zaakceptowaniu przez operatora finansowego. Operator bierze na siebie ryzyko rozliczenia z kupującym i przesyła informację o pokryciu pełnej kwoty zamówienia, co pozwala na natychmiastowe automatyczne oznaczenie zamówienia i rozpoczęcie kompletacji przesyłki.

Co dzieje się w przypadku wystąpienia nadpłaty lub niedopłaty?

Konfigurację projektuje się tak, aby precyzyjnie reagowała na anomalie finansowe. W przypadku niedopłaty (nawet o symboliczną kwotę) zamówienie nie jest oznaczane jako w pełni opłacone, lecz trafia do dedykowanego statusu „Niedopłata”, a system może automatycznie wygenerować wiadomość e-mail do klienta z prośbą o dopłatę różnicy. W przypadku nadpłaty zamówienie może zostać oznaczone jako opłacone, a informacja o kwocie do zwrotu zostaje zarejestrowana w polach dodatkowych zamówienia dla działu księgowości.

Jak BaseLinker radzi sobie z przelewami tradycyjnymi, w których klient podał błędny tytuł?

Podczas automatycznego importu wyciągów bankowych system w pierwszej kolejności szuka dokładnego numeru zamówienia lub numeru dokumentu w tytule wpłaty. Jeżeli tytuł jest niejednoznaczny (na przykład zawiera jedynie nazwisko kupującego lub nazwę towaru), transakcja nie zostaje przypisana automatycznie, aby uniknąć pomyłki. Nierozpoznana wpłata trafia na listę wpłat do ręcznego sparowania, co pozwala pracownikowi na jednoznaczne przyporządkowanie środków do właściwego zamówienia.

Czy automatyczne oznaczenie wpłaty może od razu wywołać wydruk etykiety i dokumentu sprzedaży?

Tak. Automatyczne akcje w BaseLinkerze mogą być łączone w sekwencje wieloetapowe. W momencie zmiany statusu na „Opłacone” system może jednocześnie przesłać zlecenie wystawienia dokumentu do zewnętrznego programu księgowego (lub wygenerować dokument wewnętrzny), wysłać zlecenie nadania do kuriera, utworzyć list przewozowy oraz przekazać zadanie wydruku na drukarkę termiczną za pośrednictwem modułu BaseLinker Printer (aplikacji umożliwiającej bezpośredni wydruk dokumentów i etykiet z chmury na lokalnych drukarkach).

Czy wdrożenie automatyzacji wymaga przerwania bieżącej sprzedaży w sklepie?

Nie. Konfiguracja reguł automatycznych, mapowanie statusów oraz testy integracji są przeprowadzane w tle, bez zakłócania bieżącej obsługi zamówień i bez przestojów w działaniu sklepu czy kont marketplace. Nowe reguły są aktywowane dopiero po ich dokładnym przetestowaniu na próbnych zamówieniach.

Kompleksowe wdrożenie i stabilność procesów obsługi płatności

Prawidłowe skonfigurowanie automatycznego oznaczania zamówień jako opłacone w BaseLinkerze eliminuje powtarzalną pracę ręczną, skraca czas realizacji przesyłek i minimalizuje ryzyko pomyłek przy wysyłce towaru. Precyzyjne dopasowanie zdarzeń, warunków logicznych oraz integracji z zewnętrznymi bramkami płatności i programami handlowymi zapewnia stabilne funkcjonowanie całego łańcucha e-commerce, niezależnie od liczby spływających zamówień.

22 378 48 09

BaseLinker — konfiguracja automatycznego oznaczania zamówień jako opłacone