Przelewy24, PayU czy Stripe: płatności w automatyzacjach firmowych

W systemie rezerwacji, który zbudowaliśmy dla firmy z branży turystycznej, najwięcej czasu pochłonął nie kalendarz i nie formularz, tylko moduł dopasowywania wpłat. Osoba w biurze co rano otwierała historię z banku i szukała, do której rezerwacji pasuje przelew bez numeru w tytule. Dziś widzi listę „przelewy bez przypisania" z podpowiedziami, a jedno kliknięcie zamyka rozliczenie.

Płatności to miejsce, w którym błędy automatyzacji najszybciej wychodzą na zewnątrz. Zawieszony workflow w CRM zostaje problemem wewnętrznym; podwójnie zaksięgowana wpłata to mail od klienta, korekta faktury i telefon do księgowej. Dlatego zaczynamy od trzech pytań: skąd system dowiaduje się o płatności, co się stanie, gdy dowie się o niej dwa razy, i w jakiej jednostce trzymamy kwotę.

TL;DR: Przelewy24 i PayU to wybór na polski rynek detaliczny: BLIK, przelewy z ponad stu banków, szybkie wdrożenie. Stripe wygrywa przy subskrypcjach, sprzedaży cyfrowej i klientach zagranicznych. Źródłem prawdy o płatności jest zawsze webhook, nie powrót klienta na stronę „sukces". Przy fakturach B2B na kilkadziesiąt tysięcy złotych zwykły przelew z automatem dopasowującym wpłaty jest tańszy niż każda bramka.

Trzy bramki, trzy różne odpowiedzi

Prowizja rzadko rozstrzyga ten wybór. Rozstrzyga go to, kto płaci i za co.

Przelewy24 to najkrótsza droga do płatności od polskiego klienta detalicznego. Integracja sprowadza się do rejestracji transakcji (transaction/register), przekierowania klienta na panel transakcyjny i odebrania notyfikacji. Do tego zwroty przez API i osobne endpointy dla BLIK-a, w tym obciążanie kodem i aliasem zapisanym wcześniej przez klienta.

PayU ma najszerszy zestaw metod lokalnych w regionie i najmocniej rozbudowane płatności cykliczne. Model danych jest zamówieniowy: tworzysz zamówienie z pozycjami, własnym identyfikatorem extOrderId i adresem notifyUrl, a PayU informuje o kolejnych stanach.

Stripe to inna kategoria. Przy polskim koszyku zapłacisz więcej, ale dostajesz subskrypcje z fakturowaniem, ponawianie nieudanych obciążeń i dokumentację, na której da się pracować bez zgadywania. Zaskoczenie bywa jedno: BLIK i Przelewy24 są w Stripe metodami jednorazowymi, więc subskrypcję zbudujesz tam wyłącznie na karcie.

Prowizje: z czego składa się rachunek

Mechanika jest wszędzie ta sama: procent od kwoty transakcji, przy kartach zwykle plus stała kwota od sztuki. Rachunek zmieniają trzy rzeczy, o które prawie nikt nie pyta przy wyborze operatora.

• Mix metod płatności. Stawka za BLIK, przelew i kartę różni się w jednym cenniku. Jeśli 70% klientów płaci BLIK-iem, średnia prowizja wyjdzie inna niż z kalkulatora operatora.
• Stała kwota od transakcji. Przy koszyku 40 zł złotówka od płatności waży więcej niż cała część procentowa. Przy koszyku 4000 zł jest nieistotna.
• Karty spoza EOG i przewalutowanie. Kartę wydaną poza Europą przetworzysz drożej, a przy obcej walucie dochodzi marża za konwersję. Obciążenia zwrotne kosztują osobno i bywają wielokrotnością zwykłej prowizji.

Stripe publikuje cennik dla Polski otwarcie i na sierpień 2026 wygląda on tak: karty europejskie 1,5% + 1 zł (premium 1,9% + 1 zł), karty spoza Europy 3,25% + 1 zł, BLIK 1,6% + 1 zł, Przelewy24 jako metoda 1,9% + 1 zł, przewalutowanie dodatkowe 2%, obciążenie zwrotne 90 zł, moduł subskrypcyjny 0,7% wolumenu. Przelewy24 i PayU pracują na stawkach umownych, negocjowanych od wolumenu i branży. W porównaniach cenników BLIK i przelewy wypadają w okolicach 1,5–2%, a karty w okolicach 1,2–2% plus ok. 30 gr od transakcji, ale swoją stawkę i tak zobaczysz dopiero w ofercie. Abonamentu zwykle nie ma: płacisz od obrotu.

Jeszcze jedno przy rozliczeniach: Przelewy24 i PayU wystawią polską fakturę VAT za prowizje, a usługę Stripe kupujesz od podmiotu irlandzkiego, więc prowizje rozliczasz przez odwrotne obciążenie. Niech księgowość dowie się o tym przed pierwszym rozliczeniem, a nie po.

Webhook jest jedynym źródłem prawdy

To zdanie powtarzam przy każdym wdrożeniu płatności. Klient po zapłaceniu wraca na Twoją stronę pod adres typu /dziekujemy i ten powrót nie jest informacją o płatności: klient może zamknąć przeglądarkę przed przekierowaniem, stracić zasięg albo wpisać ten adres ręcznie. Jeżeli na tej podstawie nadajesz dostęp lub oznaczasz rezerwację jako opłaconą, prędzej czy później oddasz towar za darmo.

Informacja o płatności przychodzi osobnym kanałem: operator wysyła żądanie HTTP na adres, który mu wskazałeś (jeśli ta mechanika jest dla Ciebie nowa, zacznij od wyjaśnienia, czym jest webhook). Każdy z operatorów robi to inaczej:

• Przelewy24 wysyła notyfikację JSON na adres urlStatus, niezależnie od tego, czy klient wrócił na urlReturn, i tylko dla transakcji poprawnie opłaconych. Po jej odebraniu musisz wywołać transaction/verify. To nie jest opcjonalny krok bezpieczeństwa: bez weryfikacji transakcja nie zostaje potwierdzona, a pieniądze zostają po stronie klienta jako przedpłata. Autentyczność sprawdzasz podpisem SHA-384 z identyfikatora sesji, kwoty, waluty i klucza CRC.
• PayU notyfikuje przy każdej zmianie statusu zamówienia: PENDING, WAITING_FOR_CONFIRMATION, COMPLETED, CANCELED. Oczekuje odpowiedzi 200, a przy innym kodzie ponawia próby przez nawet 72 godziny. Podpis siedzi w nagłówku OpenPayU-Signature.
• Stripe podpisuje zdarzenia nagłówkiem stripe-signature, który weryfikujesz na surowym ciele żądania (typowa pułapka: middleware parsujący JSON po cichu zmienia payload i psuje weryfikację). Podpis ma domyślną tolerancję 5 minut, co blokuje odtwarzanie starych żądań. Na odpowiedź 2xx Stripe czeka około 10 sekund, potem ponawia z rosnącym odstępem nawet przez 72 godziny.

Wzorzec, który stosujemy zawsze: sprawdź podpis, zapisz zdarzenie, odpowiedz 200, resztę zrób asynchronicznie. Endpoint generujący PDF przed odpowiedzią zacznie przy pierwszym wolniejszym dniu zbierać ponowienia i produkować duplikaty.

Idempotencja: ten sam webhook przyjdzie dwa razy

Wszystkie te systemy działają w modelu „co najmniej raz": dostarczenie jest gwarantowane, jednokrotność już nie. To samo zdarzenie potrafi przyjść dwa razy, a zdarzenia bywają dostarczone w innej kolejności, niż zaszły. Jeżeli handler nie jest na to przygotowany, klient dostaje dwie faktury, dwa maile i jedno pytanie, czy pobraliście podwójnie.

Cztery rzeczy, które to zamykają:

1. Unikalny klucz zdarzenia w bazie. Zapisuj identyfikator zdarzenia (u Stripe event.id, u pozostałych identyfikator sesji lub zamówienia z typem zdarzenia) w kolumnie z ograniczeniem unikalności. Duplikat wtedy nie wejdzie, bo baza go nie wpuści.
2. Najpierw zapis, potem akcja. Sprawdzenie „czy już przetworzyłem" i samo przetwarzanie muszą być jedną transakcją, inaczej dwie równoległe dostawy przejdą przez nie jednocześnie.
3. Sprawdzanie stanu, nie tylko zdarzenia. Zanim oznaczysz rezerwację jako opłaconą, sprawdź, czy nie jest już opłacona. To działa nawet wtedy, gdy identyfikatory się rozjadą.
4. Klucz idempotencji przy wysyłce. Gdy to Ty wysyłasz żądanie do operatora, dołóż nagłówek klucza idempotencji. Stripe zapamiętuje wynik pierwszego takiego żądania i przy powtórce zwraca ten sam rezultat zamiast tworzyć drugą płatność. Zwroty w PayU działają analogicznie.

„Najdroższy błąd w rozliczeniach to nie zgubiona płatność, tylko zaksięgowana dwa razy. Zgubioną klient zgłosi sam i odzyskujemy ją w pięć minut. Po podwójnej idzie mail o nadpłacie, korekta faktury i telefon do księgowej, a zaufanie do systemu spada bardziej niż po godzinie przestoju." — Mikołaj Brunka, założyciel NoCodeWork

Kwoty trzymaj w groszach

Kwoty w naszych systemach są liczbami całkowitymi w groszach, bo liczby zmiennoprzecinkowe gubią końcówki, a przy pieniądzach kończy się to rozjazdem raportu z wyciągiem bankowym.

Wszystkie trzy bramki działają zresztą tak samo: Przelewy24 przyjmuje kwotę w groszach jako liczbę całkowitą (1,23 PLN to 123), Stripe operuje najmniejszą jednostką waluty (10,99 zł to 1099), PayU podaje ceny w najniższej jednostce waluty, gdzie 1000 oznacza 10 zł. Trzymając grosze u siebie, nie konwertujesz niczego na granicy systemu, a to w konwersjach powstają błędy o grosz.

W module rezerwacyjnym dołożyliśmy drugą zasadę: kwota wpłacona i kwota należna to dwa osobne pola, a saldo liczy się z nich w locie. Nie ma flagi „opłacone" ustawianej ręcznie, bo taka flaga zawsze w końcu rozjedzie się z rzeczywistością.

Co dzieje się po płatności: faktura, dostęp, mailing

Wartość automatyzacji siedzi w łańcuchu, który następuje po płatności, i w większości firm wygląda podobnie: webhook potwierdza wpłatę, system oznacza zamówienie albo rezerwację jako opłaconą, powstaje dokument sprzedaży, klient dostaje potwierdzenie z fakturą i dostępem, a kontakt trafia na właściwą listę mailingową i do CRM.

Przy dokumencie sprzedaży dochodzi obowiązek, o którym trzeba pamiętać już na etapie projektu: KSeF jest obowiązkowy dla czynnych podatników VAT ze sprzedażą powyżej 200 mln zł od 1 lutego 2026, a dla wszystkich pozostałych od 1 kwietnia 2026. Faktura wystawiana automatycznie po płatności musi trafić tam jako dokument ustrukturyzowany, więc integracja idzie przez program fakturowy obsługujący KSeF, a nie przez generowanie PDF-a. Cały proces rozkładamy na części w artykule o automatyzacji faktur i księgowości.

Dwie zasady ratują ten łańcuch przy pierwszej awarii. Każdy krok musi dać się powtórzyć osobno i bez skutków ubocznych, bo system fakturowy kiedyś odpowie błędem. I kolejność: najpierw daj klientowi to, za co zapłacił, potem załatwiaj sprawy wewnętrzne. Klient przeżyje fakturę po dwóch godzinach, ale nie przeżyje dostępu do kursu następnego dnia. Ten sam webhook uruchomi też automatyczne generowanie ofert i umów, jeśli po płatności powstają dokumenty z indywidualną treścią.

Płatności cykliczne i nieudane obciążenia

Płatność cykliczna to zawsze ten sam schemat w dwóch aktach. Pierwszą transakcję inicjuje klient, potwierdzając zgodę na kolejne obciążenia, a operator zwraca token. Kolejne obciążenia inicjuje sprzedawca tym tokenem, bez udziału klienta. Danych karty nie przechowujesz u siebie i nie powinieneś chcieć.

• Stripe ma najbardziej dojrzały moduł subskrypcyjny: cykl rozliczeniowy, faktury, proraty przy zmianie planu i automatyczne ponawianie nieudanych obciążeń. Terminy ponowień dobiera model uczony na danych z całej sieci Stripe, a Ty ustalasz politykę, na przykład kilka prób rozłożonych na dwa tygodnie.
• PayU obsługuje płatności automatyczne z tokenu karty, a jako jedyny w stawce oferuje cykliczny BLIK: po pierwszej transakcji potwierdzonej kodem zapisujesz token PAYID i obciążasz klienta później, kwotami i w odstępach, jakie ustalisz. Dwa ograniczenia trzeba znać: maksymalna kwota pojedynczego obciążenia to 2000 zł, a nieudanych obciążeń system nie ponawia automatycznie. Usługa wymaga aneksu do umowy, a odpowiedzialność za transakcje oszukańcze przechodzi na sprzedawcę.
• Przelewy24 nie ma subskrypcji w rozumieniu Stripe, ale ma cegiełki do ich zbudowania: alias BLIK, obciążenie aliasem i transakcje one-click. Harmonogram i logika należności zostają po Twojej stronie.

Nieudane obciążenia nie są w subskrypcjach przypadkiem brzegowym, tylko normalnym ruchem: karty wygasają, limity się kończą, banki odrzucają transakcje. Minimalna obsługa, którą wdrażamy, ma cztery elementy: ponowienie po kilku dniach zamiast natychmiast, wiadomość do klienta z linkiem do aktualizacji metody płatności, ograniczoną liczbę prób i zawieszenie usługi po ich wyczerpaniu. Automat obciążający konto piętnaście razy w trzy dni potrafi zablokować kartę klienta i skończyć reklamacją.

Zwykły przelew i automatyczne dopasowywanie wpłat

Bramka bywa najgorszym możliwym wyborem, a w poradnikach o płatnościach ten wątek zwykle nie istnieje.

Policz na kwotach. Faktura B2B na 30 000 zł przez bramkę przy 1,9% to 570 zł oddane operatorowi za coś, co przelewem kosztuje zero. Prowizja procentowa ma sens przy szybkiej sprzedaży detalicznej, gdzie kupujesz wygodę i konwersję. Przy dużych, rzadkich fakturach kupujesz tę wygodę bardzo drogo.

Dochodzą powody formalne. Przy fakturach powyżej 15 000 zł między firmami, obejmujących towary i usługi z załącznika nr 15 do ustawy o VAT, obowiązuje mechanizm podzielonej płatności, a sankcja za jego pominięcie to 30% kwoty podatku. Przy przelewach powyżej 15 000 zł trzeba też pilnować, żeby rachunek kontrahenta był na białej liście podatników VAT. To świat przelewu bankowego, nie bramki. Podobnie jest, gdy klient płaci po terminie z faktury albo z konta firmowego, do którego dostęp ma tylko księgowość.

Jak to robimy. Dane o wpłatach wchodzą do systemu z banku: wyciągiem w formacie MT940 lub camt.053 zgodnym z ISO 20022, a w części banków przez integrację API. Operacja przychodząca ląduje w tabeli wpłat, po czym system dopasowuje ją do należności po kilku sygnałach naraz: numerze dokumentu lub rezerwacji z tytułu przelewu, kwocie, nazwie wpłacającego i dacie. Dopasowania jednoznaczne zamykają się same. Reszta trafia na listę „przelewy bez przypisania" z podpowiedziami, a człowiek jednym kliknięciem potwierdza właściwą. Przy dużym wolumenie wpłat dokłada się rachunki wirtualne: każdy klient dostaje własny numer subkonta i dopasowanie staje się jednoznaczne z definicji.

Efekt w firmie turystycznej jest niepozorny, a zmienia rytm dnia: zamiast przeglądać historię rachunku i szukać wzrokiem, biuro przegląda krótką listę wyjątków. Reszta rozliczyła się bez człowieka. To ten sam wzorzec, co w systemach budowanych pod konkretny proces: automat robi rutynę, człowiek rozstrzyga sytuacje niejednoznaczne.

Najlepiej działa układ mieszany: klient detaliczny płaci zaliczkę BLIK-iem przez bramkę, klient firmowy dostaje fakturę z terminem i płaci przelewem, a obie ścieżki kończą się w tym samym miejscu.

Na co uważać

• Testowanie tylko ścieżki szczęśliwej. Sprawdź klienta, który zamknął przeglądarkę, płatność odrzuconą, notyfikację przychodzącą dwa razy i zwrot. Te cztery przypadki generują większość zgłoszeń po wdrożeniu.
• Endpoint webhooka bez zabezpieczenia. Adres, na który operator wysyła notyfikacje, jest publiczny, więc bez weryfikacji podpisu każdy może wysłać spreparowane potwierdzenie płatności. Traktujemy to tak poważnie jak bezpieczeństwo całej automatyzacji.
• Cicha awaria po Twojej stronie. Gdy serwer odpowiada błędem, operator ponawia, ale nie w nieskończoność. Po wyczerpaniu prób zdarzenie przepada, a płatność zostaje nierozliczona. Potrzebny jest alert i procedura ręcznego odtworzenia.
• Zwroty pominięte w projekcie. Zwrot to nie „minus płatność", tylko osobny dokument i osobna ścieżka w automatyzacji. Zaprojektuj ją od razu, bo pierwszy zwrot przyjdzie szybciej, niż myślisz.
• Logika płatności rozsypana po kodzie. Zmiana operatora oznacza wtedy przepisanie połowy integracji. Trzymaj jedną warstwę tłumaczącą zdarzenia bramki na własne („płatność potwierdzona", „zwrot wykonany").

FAQ

Którą bramkę płatniczą wybrać do polskiego sklepu?

Do sprzedaży detalicznej w Polsce najbliżej jest do Przelewy24 albo PayU: mają BLIK, przelewy z ponad stu banków i polskie faktury za prowizje. Stripe wybieraj, gdy sprzedajesz subskrypcje, produkty cyfrowe albo masz klientów zagranicznych płacących kartą. Duże faktury B2B najtaniej rozliczysz zwykłym przelewem z automatycznym dopasowaniem wpłat.

Czy mogę uznać płatność za zaksięgowaną, gdy klient wróci na stronę „dziękujemy"?

Nie. Powrót na stronę potwierdzenia nie jest informacją o płatności: klient może zamknąć przeglądarkę przed przekierowaniem albo wejść pod ten adres ręcznie. Jedynym źródłem prawdy jest webhook od operatora, ze zweryfikowanym podpisem. W Przelewy24 dochodzi obowiązkowe wywołanie transaction/verify, bez którego transakcja nie zostaje potwierdzona, a środki zostają u klienta jako przedpłata.

Dlaczego ten sam webhook przychodzi dwa razy?

Bo bramki działają w modelu „co najmniej raz": gwarantują dostarczenie, ale nie jednokrotność. Ponowienie następuje po timeoucie, błędzie po Twojej stronie albo problemie sieci i potrafi trwać nawet 72 godziny. Rozwiązaniem jest idempotencja: zapisuj identyfikator zdarzenia w kolumnie z ograniczeniem unikalności i sprawdzaj stan obiektu przed jego zmianą.

Czy da się zrobić subskrypcję na BLIK-u?

Tak, ale tylko u operatora, który to obsługuje. PayU umożliwia cykliczny BLIK: po pierwszej transakcji potwierdzonej kodem zapisujesz token i obciążasz klienta później, przy limicie 2000 zł na pojedynczą transakcję i bez automatycznego ponawiania nieudanych obciążeń. W Stripe BLIK i Przelewy24 są metodami jednorazowymi, więc subskrypcję zbudujesz tam wyłącznie na karcie.

Jak automatycznie dopasować przelewy do faktur i zamówień?

Zaciągasz operacje z banku wyciągiem MT940 lub camt.053 albo integracją API, a potem dopasowujesz je po numerze dokumentu z tytułu przelewu, kwocie, nazwie wpłacającego i dacie. Jednoznaczne dopasowania zamykają się automatycznie, pozostałe trafiają na listę wyjątków do zatwierdzenia jednym kliknięciem. Przy dużej liczbie wpłat problem znika prawie całkowicie po wdrożeniu rachunków wirtualnych, gdzie każdy klient wpłaca na własny numer subkonta.

Podsumowanie

Wybór bramki jest najprostszą decyzją w całym temacie. Przelewy24 i PayU obsłużą polskiego klienta detalicznego, Stripe obsłuży subskrypcje, sprzedaż cyfrową i zagranicę. Różnica w prowizji rzadko decyduje o rentowności, a dopasowanie do modelu sprzedaży decyduje o tym, ile pracy zostanie ludziom.

Trudniejsze jest to, co dzieje się po kliknięciu „zapłać": webhook z weryfikacją podpisu zamiast powrotu na stronę sukcesu, idempotencja napisana przed wdrożeniem, kwoty w groszach i łańcuch, w którym każdy krok da się powtórzyć osobno. Cztery decyzje na kilka godzin przy projektowaniu, które oszczędzają tygodnie tłumaczeń później.

Ostatnia rzecz, zanim odruchowo podepniesz bramkę: przy fakturach B2B na kilkadziesiąt tysięcy złotych zwykły przelew z automatem dopasowującym wpłaty jest tańszy, zgodniejszy z przepisami i dla klienta wygodniejszy. Bramka to narzędzie do sprzedaży szybkiej i detalicznej, a nie domyślny sposób przyjmowania pieniędzy.

Chcesz ustalić, którą ścieżkę płatności zbudować u siebie i co da się rozliczać bez człowieka? Umów bezpłatną konsultację — powiemy wprost, jeśli w Waszym przypadku wystarczy wtyczka do sklepu i żadne wdrożenie nie jest potrzebne.

Przeczytaj również

• Jak zautomatyzować faktury i księgowość w firmie
• Kiedy gotowy CRM przestaje wystarczać: customowy CRM w praktyce
• Automatyczne generowanie ofert i umów z AI
• Agent AI do dokumentów: faktury, umowy, OCR i obieg akceptacji