Dopóki klient płaci przelewem bankowym, rozliczenie jest proste: jedna wpłata, jeden numer faktury w tytule, księgowa dopina to w ERP w pięć sekund. Kiedy dołączasz Przelewy24, PayU albo Stripe — nagle nic się nie zgadza. I to nie jest wina systemu; to inny model danych.
Widzimy to u klientów regularnie. Firma otwiera sklep internetowy albo portal B2B, włącza trzy popularne bramki płatności, w tydzień ma zamówienia. Po miesiącu księgowa przychodzi z pytaniem: dlaczego na koncie bankowym jest 48 wpłat zbiorczych, a w ERP mamy 312 zamówień, i jak to teraz uzgodnić. Odpowiedź nie jest w ERP i nie jest w bramce — jest w tym, że nikt nie zaprojektował warstwy pośredniej, która łączy jedno z drugim.
Bramka płatności online to nie jest kolejny rachunek bankowy. To osobny system z własną logiką, własnymi opłatami i własnym rytmem wypłat. Jeśli potraktujesz ją jako „jeszcze jedno konto do zaimportowania w Optimie", po trzech miesiącach będziecie mieć 40–60 tysięcy złotych w pozycji „do wyjaśnienia".
Dlaczego to się rozjeżdża
W tradycyjnym modelu klient wpłaca 1 230,00 zł na twoje konto, w tytule wpisuje FV/2026/0421, księgowa importuje wyciąg MT940 do Comarch Optima i parowanie dzieje się automatycznie. Jeden do jednego. Problem bramki polega na tym, że ten model przestaje działać na trzech poziomach jednocześnie.
Poziom pierwszy — wypłata netto, nie brutto. Klient płaci 1 230,00 zł kartą przez Stripe. Na twoje konto wpływa 1 190,65 zł, bo Stripe potrącił 3,2% prowizji. ERP widzi, że faktura była na 1 230,00 — i parowanie się nie dzieje, bo kwoty się nie zgadzają. Jeżeli zrobisz mapowanie „ignoruj różnice do 5%", pogubisz się przy pierwszym chargeback'u, który też wejdzie jako „różnica do 5%".
Poziom drugi — wypłata zbiorcza, nie per transakcja. PayU i Przelewy24 w domyślnym planie dla MŚP wypłacają raz dziennie albo raz na dwa dni, zbiorczo. Dostajesz 12 437,22 zł przelewem, który reprezentuje 54 transakcje z dwóch dni, pomniejszone o prowizje, pomniejszone o jeden zwrot i jeden chargeback. W tytule jest „Rozliczenie PayU 2026-10-24". Zero numerów faktur. Rozpar to ręcznie.
Poziom trzeci — walutowe i międzynarodowe. Stripe wypłaca ci w EUR albo w USD, jeżeli włączysz obsługę kart zagranicznych. ERP w PLN. Przewalutowanie następuje w banku z kursem z chwili wpłaty, a nie z chwili zamówienia. Różnica kursowa to osobna linia w rachunku zysków i strat — ERP tego sam nie policzy, bo nie wie, jaki kurs był „oczekiwany".
Każdy z tych poziomów osobno da się ogarnąć ręcznie w arkuszu. Trzy jednocześnie, przy 300 zamówieniach miesięcznie, nie dają się ogarnąć. Trzeba zrobić integrację.
Trzy elementy, które musisz spiąć
Dobrze zrobiona integracja bramki z ERP to trzy osobne mechanizmy — nie jeden skrypt, który „wszystko synchronizuje". Jeden mechanizm = jedna odpowiedzialność.
- Webhook statusu płatności. Bramka woła twój endpoint w momencie, gdy płatność się udała, nie udała, została zwrócona, albo klient zrobił chargeback. To jest sygnał „coś się zmieniło na tej konkretnej transakcji" — i powinien aktualizować konkretne zamówienie w ERP, nie całą zbiorczą paczkę. Webhook musi być idempotentny: ta sama bramka potrafi wysłać ten sam event trzy razy, jeśli przez chwilę nie dostanie odpowiedzi 200. Trzy razy nie znaczy trzy razy księgujemy — znaczy raz, a potem ignorujemy duplikaty.
- Raport dzienny bramki. Przelewy24, PayU, Stripe i tpay wszystkie udostępniają API albo CSV ze szczegółowym rozliczeniem — jedna linia na transakcję, z prowizją, VAT-em prowizji, zwrotem, chargebackiem. Ten raport to twoje źródło prawdy do księgowania wszystkich kosztów bramki. Jest „płasko" i brzydko, ale jest kompletny.
- Parowanie wyciągu bankowego z raportem bramki, nie z zamówieniem. To jest cała sztuczka. ERP nie powinien próbować parować wpłaty 12 437,22 zł z 54 zamówieniami jednocześnie. Powinien parować 12 437,22 zł z raportem bramki za 2026-10-24 — a raport bramki osobno już wie, jakie zamówienia zawierał, bo widział to przez webhook. Trzy etapy, trzy osobne rozliczenia, każdy po jednym kryterium.
Kiedy ułożysz te trzy mechanizmy osobno, chargeback z Przelewy24, który spływa dwa tygodnie po transakcji, nie wysadza już w powietrze zamknięcia miesiąca — bo wiesz, do której transakcji on się odnosi i jak go odzwierciedlić w ERP.
Konkretny przykład z życia
U jednego z naszych klientów — 28-osobowego sklepu internetowego z meblami do domu i ogrodu — bramki płatności były podłączone od początku: Przelewy24 jako główna, PayU dla rat 0%, Stripe dla klientów zagranicznych. Comarch Optima jako ERP, WooCommerce jako sklep, integracja sklep–ERP po API. Co miesiąc 450–600 zamówień, obrót w okolicy 480 tys. zł brutto.
Przed uporządkowaniem rozliczanie wyglądało tak: księgowa raz w tygodniu importowała wyciąg bankowy do Optimy, oglądała zbiorcze wpłaty z bramek i ręcznie dopasowywała je do zamówień, patrząc na raporty w panelach Przelewy24 i PayU osobno. Prowizje księgowała ryczałtem na podstawie noty księgowej, którą bramki wystawiały raz w miesiącu. Zwroty i chargebacki pojawiały się losowo — czasem jako minus na wpłacie zbiorczej, czasem jako osobny przelew wychodzący. Pozycja „do wyjaśnienia" w zestawieniu zawsze miała 15–25 pozycji, łącznie 20–35 tys. zł co miesiąc.
Problem nasilał się na końcu kwartału, bo niewyjaśnione pozycje się kumulowały. W marcu i czerwcu 2026 roku na dwa dni przed zamknięciem kwartału trzeba było zrobić „inwentaryzację bramek" — czyli dyrektor finansowy spędzał cztery–sześć godzin ze księgową na dopasowywaniu niespiętych transakcji. Co dwa kwartały 20–30 tys. zł trafiało na konto różnic kursowych i prowizji, bo już nikt nie potrafił tego przypisać do konkretnych zamówień.
Przebudowa trwała sześć tygodni i zmieściła się w budżecie 32 tys. zł. Założyliśmy prosty middleware (jedna mała aplikacja .NET na ich serwerze), który odbiera webhooki ze wszystkich trzech bramek, zapisuje stan każdej transakcji w bazie, codziennie ściąga raporty rozliczeniowe z API bramek i generuje do Optimy trzy osobne dokumenty księgowe: fakturę sprzedaży (zamówienie), notę za prowizję bramki (koszt) i dokument KASOWY wpłaty zbiorczej, który paruje się z wyciągiem bankowym 1:1. Zwroty i chargebacki są odzwierciedlone jako korekty, podpięte do oryginalnej transakcji.
Po trzech miesiącach pozycja „do wyjaśnienia" spadła z 20–35 tys. do 0,5–1,5 tys. zł miesięcznie — głównie z tytułu zaokrągleń kursowych przy Stripe EUR–PLN. Zamknięcie kwartału przestało wymagać „inwentaryzacji bramek". Księgowa odzyskała około 6–8 godzin tygodniowo, które wcześniej szły na ręczne parowanie. Dyrektor finansowy po raz pierwszy wiedział, ile naprawdę kosztują ich płatności online — wyszło 3,8% obrotu, czyli ok. 18 tys. zł miesięcznie, głównie na PayU rata 0%, która jest przerzucana na sklep.
Trzy pułapki, które widujemy najczęściej
Są trzy wzorce, przez które integracje bramek z ERP się rozpadają po pół roku. Każdy łatwo ominąć, jeżeli się o nim wie wcześniej.
- „Zamówienie = faktura = wpłata", bez pamięci o prowizji. Firma księguje w ERP tylko fakturę sprzedaży i wpłatę w kwocie netto po prowizji, bo „różnica to prowizja bramki". To działa — do pierwszej kontroli skarbowej, która pyta, dlaczego VAT od tych 3,2% prowizji nigdzie nie figuruje. Prowizja bramki to osobny koszt, osobna faktura (bramka musi ci ją wystawić), osobny VAT. ERP musi widzieć obie strony.
- Webhook bez idempotencji. Zdarza się, że bramka wyśle ten sam event dwa razy — bo pierwsza odpowiedź z twojego endpointu przyszła z opóźnieniem i system uznał, że nie dotarła. Jeżeli twój middleware nie sprawdza, czy ta transakcja już nie była przetworzona, zaksięgujesz dwie faktury za jedną sprzedaż. Idempotencja = zapisujesz ID eventu w bazie, drugi raz go nie przetwarzasz, odpowiadasz 200.
- Testowanie na „oczekujących" zamiast na webhooku zakończonym. Czasem programista zaciąga ze sklepu wszystkie zamówienia ze statusem „pending" i wrzuca do ERP, bo chce, żeby „było widać od razu". Potem klient porzuca płatność, bramka nie wysyła webhooka, w ERP zostaje faktura, której nikt nie opłaci. Zasada: fakturę w ERP tworzysz dopiero po webhooku
PAID, nigdy wcześniej.
Każda z tych pułapek daje się rozwiązać kilkoma liniami kodu w middleware — pod warunkiem, że przewidzisz je przed startem, a nie po pierwszym kwartale rozliczeń.
Co zrobić w tym miesiącu
Jeżeli obracasz w bramkach powyżej 100 tys. zł miesięcznie i nie masz integracji z ERP, to prawdopodobnie już płacisz podatek niewiedzy w postaci niewyjaśnionych pozycji i nieuchwyconych kosztów prowizji. Zacznij od trzech kroków, które da się zrobić bez dużego projektu.
- Weź ostatnie trzy miesiące — ile razy księgowa coś „ręcznie dopasowywała" i jaka jest aktualna wartość pozycji „do wyjaśnienia". Jeżeli to więcej niż 1% miesięcznego obrotu, integracja się zwróci w pół roku.
- W panelu bramek sprawdź, czy webhook jest w ogóle włączony — i gdzie wskazuje. U połowy klientów, do których trafiamy, webhook kieruje jeszcze na starą domenę sklepu, bo nikt tego nie przestawił po migracji dwa lata temu.
- Pobierz z panelu bramki raport rozliczeniowy za jeden miesiąc w formacie CSV. Spójrz, jakie pola tam są — kwota brutto, prowizja, VAT prowizji, status, ID zamówienia. To są dokładnie te dane, które powinny trafić do ERP, i to jest minimalny kształt integracji.
Po tych trzech krokach już wiesz, czy problem w ogóle istnieje, i jaki ma rozmiar.
Co dalej
Płatności online nie są trudne same w sobie — są trudne, bo mają inny model danych niż bankowość. Jeżeli potraktujesz bramkę jako „jeszcze jeden rachunek do zaimportowania", będziesz co miesiąc tracić czas i pieniądze. Jeżeli zbudujesz warstwę pośrednią, która tłumaczy język bramki na język ERP, przestanie to boleć.
To nie jest duży projekt. Dla małej firmy to dwa–sześć tygodni pracy jednej osoby plus prosty middleware. Dla większej, z kilkoma kanałami sprzedaży i kilkoma bramkami, miesiąc do trzech. Zwrot zazwyczaj w półroczu — głównie na odzyskanym czasie księgowej i na tym, że przestajesz dolewać na konto „różnic" sumy, które powinny być kosztem konkretnej transakcji.
Jeżeli chcesz, żebyśmy spojrzeli na twoją konfigurację — bramki, sklep, ERP, aktualny sposób rozliczania — pokazujemy u siebie, gdzie są dziury i w jakim rzędzie wielkości się mieszczą. Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Bramka płatności to nie wyciąg bankowy. To osobny system z własną logiką — i jeżeli ERP tego nie wie, co miesiąc płacicie za to niewiedzą, a nie prowizją.