Jaka bramka płatności dla sklepu internetowego: Przelewy24, PayU, Tpay czy Stripe

Krótki werdykt: polski operator, Stripe albo żadna nowa bramka

O wyborze bramki decyduje to, co sprzedajesz, komu i na jakiej platformie. Porównanie prowizji przydaje się dopiero na samym końcu, kiedy zostaje dwóch kandydatów.

Jeżeli przyjmujesz płatności jednorazowe od klientów w Polsce, polski operator daje Ci w jednym miejscu to, czego polski klient szuka przy kasie: BLIK, przelew online, karty i portfele, a do tego raty albo płatność odroczoną. Przelewy24, PayU i Tpay mają te metody w ofercie, choć część z nich trzeba osobno włączyć, o czym piszę niżej. Każdy z tych trzech operatorów publikuje też własny moduł dla WooCommerce, więc w typowym sklepie integracja sprowadza się do instalacji, konfiguracji i porządnych testów.

Stripe ma sens, gdy sprzedaż nie opiera się na BLIK-u. Subskrypcje, klienci płacący kartami z różnych krajów i własna aplikacja, w której liczy się dokumentacja API, to jego mocne strony. Przy polskich metodach płatności ma natomiast ograniczenia, które trzeba znać przed decyzją: BLIK działa tam wyłącznie w złotych i dla klienta z Polski, a metoda Przelewy24 w Stripe nie obsługuje płatności cyklicznych ani zapisania metody płatności na później. Prowizje, wypłaty i fakturowanie przy Stripe rozpisuję osobno w przewodniku Stripe dla polskiej firmy.

Są też sytuacje, w których nowa bramka jest złym wyborem, i warto je nazwać wprost. Sklep na Shopify ma BLIK w Shopify Payments, a podłączenie zewnętrznej bramki ma tam własny koszt po stronie platformy, który wraz z kwotami opisuję w przewodniku o sklepie Shopify w Polsce. Sprzedaż firmom na fakturę z terminem płatności nie potrzebuje bramki, bo zwykły przelew na rachunek firmowy załatwia to samo bez prowizji operatora i bez dodatkowego ekranu. A jeśli zamówień jest kilka w miesiącu, zamiast integracji wystarczy link do płatności wysłany mailem: Stripe ma do tego Payment Links, a Przelewy24 i Tpay mają generator linku do płatności w swojej ofercie.

Dwie bramki naraz to też rozsądna opcja. BLIK i przelew może obsługiwać polski operator, a karty zagraniczne i subskrypcje Stripe. Płacisz za to drugą integracją, drugim zestawem powiadomień do obsłużenia i drugim raportem wypłat do uzgodnienia z księgowością, więc przy niewielkiej sprzedaży ta komplikacja zwykle się nie zwraca.

• Polski operator, gdyPrzyjmujesz płatności jednorazowe od klientów w Polsce, BLIK ma być główną metodą, sklep stoi na WooCommerce albo innej gotowej platformie i chcesz mieć raty lub płatność odroczoną u tego samego operatora co resztę metod.
• Stripe, gdySprzedaż opiera się na subskrypcji opłacanej kartą, sprzedajesz za granicę albo budujesz własną aplikację i potrzebujesz dobrej dokumentacji, środowiska testowego i przewidywalnego API.
• Żadna nowa bramka, gdyMasz sklep na Shopify z Shopify Payments, sprzedajesz firmom na fakturę z terminem albo przyjmujesz kilka płatności w miesiącu, które obsłuży link do płatności.

Metody płatności: co naprawdę dostajesz u każdego operatora

Listy metod w ofertach wyglądają prawie tak samo. Różnice wychodzą w szczegółach: co działa bez przekierowania, co trzeba osobno włączyć i co nie nadaje się do płatności cyklicznych.

BLIK podłączasz na jeden z dwóch sposobów. W wariancie z przekierowaniem klient przechodzi na stronę operatora i tam wpisuje kod. W wariancie, który Przelewy24 nazywają w dokumentacji BLIK level 0, pole na kod jest w Twojej kasie: najpierw rejestrujesz transakcję, a potem wywołujesz metodę obciążenia kodem, przekazując token z rejestracji i sześć cyfr wpisanych przez klienta. Tpay ma BLIK na stronie sklepu w ofercie, a Stripe przyjmuje kod we własnym formularzu płatności, choć jego Express Checkout Element BLIK-a nie obsługuje.

Przelew online, czyli pay-by-link, mają w ofercie wszyscy trzej polscy operatorzy. W Stripe szybki przelew dla polskiego klienta obsługujesz przez metodę Przelewy24, która ma tam wyraźne ograniczenia: brak płatności cyklicznych, brak ręcznego przechwycenia środków i rozliczenie trwające do dwóch dni roboczych. Stripe podaje przy tym, że przy tej metodzie nie będziesz mieć sporów kończących się obciążeniem zwrotnym, bo klient uwierzytelnia płatność w swoim banku.

Karty i portfele, czyli Apple Pay i Google Pay, mają wszyscy czterej. Różnica leży w tym, co trzeba zrobić, żeby zadziałały na Twojej stronie. W Przelewy24 samo przyjmowanie kart uruchamia się osobno, przez formularz aktywacji w centrum pomocy operatora, więc nie zakładaj, że karty zadziałają od pierwszego dnia po podpisaniu umowy. Po aktywacji standardowa płatność kartą przez panel operatora działa w podstawowej integracji, ale dodatkowe funkcje kartowe, czyli formularz karty w sklepie, płatność jednym kliknięciem i obciążenia cykliczne, nie są włączone domyślnie i w ich sprawie kontaktujesz się ze wsparciem technicznym. Według tej samej dokumentacji Apple Pay osadzone bezpośrednio w sklepie wymaga założenia identyfikatora sprzedawcy w Apple i weryfikacji domeny, więc przy zmianie domeny sklepu trzeba o tym pamiętać.

Raty i płatność odroczona to osobna kategoria, bo przy nich pieniądze za towar wypłaca sklepowi dostawca finansowania, a nie klient. BLIK Płacę Później opisuje to wprost: sklep dostaje pieniądze od razu, klient płaci w aplikacji banku po trzydziestu dniach, a jeśli nie zapłaci i nie odeśle towaru, całe ryzyko bierze na siebie dostawca usługi. Podobnie jest z Klarną w Stripe, gdzie ryzyko niespłaty ponosi Klarna. Szczegóły techniczne potrafią jednak zaskoczyć: w Przelewy24 metoda PayPo nie jest aktywna domyślnie, wymaga w rejestracji transakcji dodatkowych pól z imieniem i nazwiskiem klienta, miastem, kodem pocztowym i adresem, a środki z niej są wypłacane dopiero po otrzymaniu ich od PayPo, domyślnie w ciągu pięciu dni roboczych.

Metody płatności u czterech operatorów według ich ofert i dokumentacji, stan na 22 września 2026 r. Część metod wymaga osobnej aktywacji, więc przed podpisaniem umowy potwierdź, które zadziałają od pierwszego dnia.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

BLIK: kod, jedno kliknięcie i płatności powtarzalne

Bez BLIK-a trudno dziś otworzyć polski sklep, ale pod jedną nazwą kryją się trzy różne mechanizmy. Każdy stawia integracji inne wymagania.

Pierwszy mechanizm to zwykły kod z aplikacji bankowej. Dokumentacja Stripe podaje, że kod BLIK jest ważny przez dwie minuty, a od rozpoczęcia płatności klient ma sześćdziesiąt sekund na potwierdzenie jej w aplikacji; potem transakcja wygasa i trzeba poprosić o nowy kod. Dla projektu kasy wynika z tego jedno: między wpisaniem kodu a potwierdzeniem nie może być żadnego dodatkowego ekranu, a stan „czas minął” musi mieć własny, zrozumiały komunikat z przyciskiem do ponownej próby.

Drugi mechanizm to płatność jednym kliknięciem. W Przelewy24 przy pierwszej płatności kodem możesz zarejestrować alias: klient dostaje w aplikacji banku zaproszenie, a przy kolejnych zakupach płaci bez przepisywania kodu, tylko potwierdzając transakcję. Dokumentacja opisuje dwie pułapki. Po udanej transakcji odczyt aktualnego statusu aliasu może trwać do sześćdziesięciu sekund, bo statusy przetwarzane są asynchronicznie. A jeśli klient ma pod tym samym aliasem dwie aplikacje bankowe, obciążenie kończy się błędem z kodem HTTP 409 i listą alternatywnych kluczy, więc Twój interfejs musi pozwolić klientowi wybrać aplikację.

Trzeci mechanizm to płatności powtarzalne BLIK, czyli odpowiedź na subskrypcje. Po stronie klienta kolejne transakcje realizują się automatycznie albo po potwierdzeniu w aplikacji bankowej, a wszystko jest widoczne i do wyłączenia w aplikacji banku. Klient, który zmienia bank, musi utworzyć płatność powtarzalną od nowa w nowym banku, więc Twój system powinien umieć poprosić go o ponowną zgodę, zamiast po cichu przestać pobierać opłaty.

Po stronie sklepu szczegóły różnią się między operatorami. W Przelewy24 płatności cykliczne BLIK nie są włączone domyślnie i aktywuje się je przez kontakt ze wsparciem technicznym, a w żądaniu określasz częstotliwość, limit pojedynczego obciążenia, limit łączny, liczbę płatności i datę wygaśnięcia, z opcjonalnym sprawdzeniem, czy bank klienta w ogóle obsługuje tę usługę. W PayU usługa wymaga aneksu do umowy, a dokumentacja stawia trzy twarde warunki. Po pierwsze, nie każdy bank obsługuje BLIK cykliczny i wtedy rejestracja tokenu kończy się błędem. Po drugie, nieudane obciążenie, na przykład z braku środków, nie jest ponawiane automatycznie, bo ponowienie należy do sprzedawcy. Po trzecie, w tym modelu sprzedawca bierze na siebie odpowiedzialność za ewentualne nadużycia, a rejestracji z zerową kwotą nie da się wykonać, więc opłatę aktywacyjną, która nie jest zapłatą za usługę, trzeba klientowi zwrócić.

W Stripe zapisanie BLIK-a do ponownych obciążeń bez udziału klienta istnieje, ale płatności cykliczne tą metodą mają status prywatnej wersji zapoznawczej, więc abonament oparty na BLIK-u w Stripe planuj dopiero wtedy, gdy Stripe potwierdzi dostęp do tej funkcji na Twoim koncie. W Shopify Payments sprawa jest jeszcze prostsza: klienci nie mogą płacić BLIK-iem za zamówienia subskrypcyjne.

Płatności cykliczne i subskrypcje: kto prowadzi harmonogram

Subskrypcja to nie metoda płatności, tylko proces: zgoda klienta, token, harmonogram obciążeń, ponowienia po odmowie i anulowanie. Polski operator daje Ci zwykle token i wywołanie API, a cała reszta zostaje po Twojej stronie.

Karty w płatnościach cyklicznych działają wszędzie podobnie. Pierwsza płatność przechodzi przez 3-D Secure z udziałem posiadacza karty, a kolejne wykonujesz sam, na zapisanym tokenie. PayU opisuje to jako dwa typy obciążeń: pierwsze, z uwierzytelnieniem, i standardowe, przy których klienta nie ma, więc nie jest potrzebne ani 3-D Secure, ani kod CVV, a obciążenie może wykonać harmonogram po Twojej stronie o dowolnej porze. Zanim zaczniesz integrację, PayU każe skontaktować się z opiekunem albo przez formularz, bo usługa wymaga konfiguracji po stronie operatora.

Tu jest pułapka, której nie widać w ofertach. W Przelewy24 referencja karty uzyskana z płatności portfelem, czyli Google Pay, Apple Pay albo Visa Mobile, nie może posłużyć do płatności cyklicznych, a próba takiego obciążenia kończy się błędem i brakiem płatności. PayU dopuszcza natomiast pierwszą płatność cykliczną portfelem. Jeśli więc subskrypcję uruchamiasz przez Przelewy24, pierwszą płatność ustaw jako płatność kartą, a nie przyciskiem portfela, bo inaczej pierwsza odnowa nie przejdzie.

Kluczowe pytanie brzmi: kto prowadzi harmonogram. U polskich operatorów robi to Twój system. PayU pisze wprost, że przy BLIK-u cyklicznym to sprzedawca decyduje o częstotliwości i kwocie każdego obciążenia. Potrzebujesz więc własnego planu obciążeń, polityki ponowień, maili do klienta przy odmowie i porządnego anulowania. W Stripe dużą część tej pracy, w tym plany i ponawianie nieudanych obciążeń, przejmuje produkt Billing, co opisuję w przewodniku Stripe dla polskiej firmy.

Z tego wynika prosty podział. Jeśli sprzedajesz oprogramowanie w abonamencie ze zmianami planu, okresami próbnymi i klientami z kilku krajów, budowanie tego samodzielnie na tokenach polskiego operatora jest osobnym projektem i Stripe zwykle okaże się prostszy. Jeśli natomiast sprzedajesz stałą comiesięczną usługę polskim klientom, którzy chcą płacić BLIK-iem, polski operator z płatnościami powtarzalnymi BLIK pasuje lepiej niż Stripe. W WooCommerce dochodzi do tego warstwa sklepu: wtyczka Tpay obsługuje subskrypcje kartą tylko z dodatkowym rozszerzeniem, takim jak WooCommerce Subscriptions.

1. Zapis zgodyData, kwota, częstotliwość i treść warunków, na które klient się zgodził przy pierwszej płatności. Bez tego nie wyjaśnisz żadnej reklamacji.
2. Token z datą ważnościToken karty wygasa razem z kartą, a płatność powtarzalna BLIK ma własną datę wygaśnięcia i znika przy zmianie banku. Zaplanuj prośbę o odnowienie zgody, zanim token przestanie działać.
3. Harmonogram po Twojej stronieZadanie, które w dniu odnowienia tworzy obciążenie z unikalnym identyfikatorem, żeby ponowne uruchomienie nie pobrało opłaty dwa razy.
4. Polityka ponowieńIle prób, w jakich odstępach i co widzi klient po każdej odmowie. Operator tego za Ciebie nie zrobi.
5. Anulowanie w obie stronyKlient może usunąć płatność powtarzalną BLIK w aplikacji banku, a według BLIK nie zawsze oznacza to rezygnację z usługi w sklepie. Twój system musi to wykryć, na przykład po powiadomieniu o zmianie aliasu albo po liście aktywnych tokenów, i zapytać klienta, co dalej.

Potwierdzenie płatności: powiadomienia, weryfikacja i idempotencja

Najdroższy błąd w integracji bramki to zamówienie oznaczone jako opłacone, bo klient wrócił na stronę podziękowania. Powrót klienta niczego nie dowodzi; dowodem jest powiadomienie od operatora, sprawdzone po Twojej stronie.

W Przelewy24 ma to bezpośrednie skutki finansowe. Wynik transakcji przychodzi asynchronicznie na adres podany w parametrze urlStatus, a Twój system musi go potwierdzić wywołaniem transaction/verify. Dokumentacja stwierdza, że transakcja jest uznana za potwierdzoną dopiero po weryfikacji: jeśli klient zapłaci i wróci do sklepu, a sklep transakcji nie zweryfikuje, pieniądze nie trafią do sprzedawcy ani do rozliczeń i zostaną do dyspozycji klienta jako przedpłata. Dopóki weryfikacji nie ma, operator ponawia powiadomienie po 3, 5, 15, 30, 60, 150 i 450 minutach, z tolerancją około pięciu minut.

Przy Przelewy24 dochodzą trzy techniczne drobiazgi, które psują integracje. Suma kontrolna sign jest liczona algorytmem SHA-384 z kluczem CRC z panelu, ale jej składniki różnią się między rejestracją a weryfikacją: w weryfikacji w miejscu identyfikatora sprzedawcy merchantId jest identyfikator transakcji orderId. Kwoty przekazujesz jako liczby całkowite w groszach. A identyfikator transakcji trzymaj w kolumnie typu BIGINT, bo może przekroczyć zakres typu INT ze znakiem.

PayU wysyła powiadomienia tylko wtedy, gdy w zamówieniu podasz adres notifyUrl, i oczekuje odpowiedzi z kodem HTTP 200. Przy innym kodzie ponawia wysyłkę według harmonogramu, w którym dwudziesta, ostatnia próba przychodzi po 72 godzinach. Ten sam status może przyjść kilka razy, a dokumentacja zaleca, żeby po otrzymaniu statusu COMPLETED ignorować kolejne powiadomienia dla tego zamówienia. Autentyczność sprawdzasz podpisem z nagłówka OpenPayu-Signature, liczonym z treści powiadomienia i drugiego klucza.

Tpay oczekuje na powiadomienie o transakcji odpowiedzi z kodem HTTP 200 i treścią TRUE. Ponowienia idą gęsto, najpierw co minutę, potem co trzy i co dziesięć minut, dalej co godzinę, a na końcu po dwunastu i dwudziestu czterech godzinach. Jedna rzecz jest tu szczególnie zdradliwa: odpowiedź z kodem 404 zatrzymuje dalsze ponowienia, więc źle skonfigurowana ścieżka po wdrożeniu nowej wersji sklepu potrafi po cichu zgubić płatności. Podpis JWS w nagłówku X-JWS-Signature trzeba zweryfikować obowiązkowo, a listy adresów IP Tpay nie publikuje, bo są dynamiczne.

Stripe ponawia dostarczenie zdarzenia do trzech dni w trybie produkcyjnym i nie gwarantuje kolejności zdarzeń, więc Twój kod nie może zakładać, że najpierw przyjdzie jedno, a potem drugie. Duplikaty rozpoznajesz po identyfikatorze zdarzenia, a podpis z nagłówka Stripe-Signature sprawdzasz na surowej treści żądania, bo każda zmiana treści przez framework psuje weryfikację. Po swojej stronie żądań do API używasz kluczy idempotencji: Stripe zapisuje wynik pierwszego żądania z danym kluczem, także błędny, i zwraca go przy powtórzeniu, porównując parametry; nie zapisuje go tylko wtedy, gdy parametry nie przejdą walidacji albo żądanie koliduje z innym, wykonywanym równolegle. Klucze starsze niż doba Stripe może usuwać.

1. Sprawdź autentycznośćPodpis albo sumę kontrolną, zanim cokolwiek zapiszesz. Adres odbierający powiadomienia jest publiczny i każdy może wysłać na niego dowolną treść.
2. Zapisz identyfikator razIdentyfikator zdarzenia albo transakcji w kolumnie z ograniczeniem unikalności. Drugie takie samo powiadomienie ma zakończyć się grzecznym potwierdzeniem, a nie drugą fakturą.
3. Odpowiedz szybkoKod oczekiwany przez operatora zwracasz od razu, a wysyłkę maili, fakturę i magazyn przekazujesz do kolejki. Długa obsługa kończy się przekroczeniem czasu i ponowieniem.
4. Potwierdź po stronie operatoraW Przelewy24 to wywołanie weryfikacji. U pozostałych warto przed wydaniem towaru odpytać API o status zamówienia, zamiast ufać jednej wiadomości.
5. Zmieniaj stan tylko do przoduZamówienie opłacone nie może wrócić do oczekującego tylko dlatego, że starsze powiadomienie przyszło później. Na kolejność powiadomień nie licz u żadnego operatora.
6. Przetestuj awarięWyłącz na chwilę odbiór powiadomień w środowisku testowym i sprawdź, czy ponowienie domknie zamówienie. To jedyny test, który pokazuje, że integracja poradzi sobie z awarią na produkcji.

Jak czterej operatorzy potwierdzają płatność według ich dokumentacji, stan na 22 września 2026 r.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Zwroty pełne i częściowe: ustawa, API i pułapki

Zwrot ma dwie strony: obowiązek wobec konsumenta, który wynika z ustawy, i mechanikę operatora, która decyduje, czy da się go zrobić jednym kliknięciem, czy ręcznym przelewem.

Ustawa o prawach konsumenta daje Ci na zwrot czternaście dni od otrzymania oświadczenia o odstąpieniu od umowy i każe oddać wszystkie płatności, łącznie z kosztem dostarczenia towaru. Art. 33 tę kwotę ogranicza: jeśli klient wybrał droższą dostawę niż najtańszy zwykły sposób dostarczenia z Twojej oferty, na przykład kuriera ekspresowego, koszt dostawy zwracasz tylko do wysokości tej najtańszej opcji. Ważniejszy dla integracji jest art. 32 ust. 2: zwrot robisz takim samym sposobem zapłaty, jakiego użył konsument, chyba że wyraźnie zgodził się na inny sposób, który nie wiąże się dla niego z żadnymi kosztami. Zwrot przez bramkę nie jest więc wygodą, tylko domyślną ścieżką. Jeśli sam nie zaproponowałeś odbioru towaru, możesz wstrzymać zwrot do chwili otrzymania towaru albo dowodu jego odesłania, zależnie od tego, co nastąpi wcześniej.

W Przelewy24 zwrot zlecisz z panelu albo metodą transaction/refund. Do jednej transakcji możesz zlecić kilka zwrotów, byle ich suma nie przekroczyła kwoty transakcji, a wynik przychodzi asynchronicznie, jako osobne powiadomienie na adres wskazany w żądaniu. Żądanie niesie Twój unikalny identyfikator, a operator odrzuca zdublowane zlecenie, co jest dokładnie tym zabezpieczeniem, którego potrzebujesz, gdy obsługa kliknie przycisk dwa razy.

W PayU zwrot bez podanej kwoty jest zwrotem pełnym, a częściowy wymaga jawnego pola amount. Częściowych zwrotów do jednego zamówienia może być kilka, znowu do wysokości zamówienia, a jeśli zlecasz je częściej niż raz na sekundę, identyfikator extRefundId staje się obowiązkowy. Wynik przychodzi jako status FINALIZED albo CANCELED. Lista błędów zwrotu mówi sporo o tym, jak zaprojektować proces: zwrot zostanie odrzucony przy braku środków na rachunku, po upływie czasu dostępnego na zwrot, przy zbyt wielu próbach i wtedy, gdy ponownie użyty extRefundId przyjdzie z innymi parametrami niż za pierwszym razem.

Metoda płatności też zmienia przebieg zwrotu. W Stripe zwrot płatności Przelewy24 możesz zlecić w ciągu 180 dni od płatności, trwa do trzech dni roboczych, nie da się go anulować i trafia do klienta jako osobny przelew, nieopisany w wyciągu jako zwrot, więc warto klienta uprzedzić mailem. BLIK w Stripe obsługuje zwroty pełne i częściowe, realizowane zależnie od banku od razu albo w ciągu kilku godzin. Klarnę w Stripe zwrócisz do 180 dni po płatności.

• Zwrot potrzebuje saldaPayU odrzuca zwrot przy braku środków na rachunku, więc jeśli automatyczne wypłaty stale opróżniają saldo u operatora, zwrot może się nie udać. Ustawienia wypłat i zwrotów planuje się razem.
• Jeden zwrot, jeden identyfikatorZapisuj identyfikator zwrotu po swojej stronie, zanim wyślesz żądanie. Podwójne kliknięcie w panelu sklepu nie może oznaczać podwójnego zwrotu.
• Zwrot to także dokumentZwrot po wystawieniu faktury zwykle pociąga za sobą korektę, więc informacja o zakończonym zwrocie musi trafiać także do systemu, który wystawia dokumenty: w Przelewy24 to osobne powiadomienie o wyniku zwrotu, w PayU status FINALIZED albo CANCELED, a w Stripe zdarzenie o zakończeniu lub niepowodzeniu zwrotu.

Wypłaty, faktury i KSeF: co dzieje się po zapłacie

Pieniądze z bramki wpływają na konto zbiorczo, pomniejszone o prowizje i zwroty, więc przelewy od operatora rzadko dają się wprost przypisać do pojedynczych zamówień. Porządek robią identyfikatory zapisywane przy każdej płatności, a na nich opiera się potem także faktura i wysyłka do KSeF.

Pierwsza zasada rozliczeń: kwota przelewu od operatora to nie to samo co sprzedaż z danego okresu. Jeden taki przelew łączy wiele płatności, zwrotów i potrąceń, więc księgowość potrzebuje raportu, w którym każda pozycja ma swój identyfikator, kwotę i powiązanie z zamówieniem. Dlatego przy każdej płatności zapisuj po swojej stronie identyfikator nadany przez operatora, a do operatora wysyłaj własny, unikalny identyfikator zamówienia; w Przelewy24 tę rolę pełni sessionId, unikalny dla pojedynczej transakcji w systemie sprzedawcy.

Operatorzy różnią się tym, jak wyglądają wypłaty i raporty. W PayU każdy sklep założony w panelu ma osobne saldo, więc wypłaty ustawiasz osobno dla każdego z nich: ręcznie albo automatycznie, z minimalną kwotą wypłaty i liczbą dni, po których wypłata ma nastąpić. W Przelewy24 API udostępnia raport historii, który zwraca paczki, transakcje i zwroty z zakresu do 31 dni, przy czym tę funkcję włącza opiekun konta. Pierwszą wypłatę i cykl rozliczeń w Stripe omawiam w przewodniku o Stripe, do którego odsyłam na początku tego tekstu.

Z punktu widzenia sklepu najważniejsze jest, żeby uzgadnianie nie wymagało ręcznej pracy co miesiąc. Buduję to tak, że raport operatora jest pobierany automatycznie, łączony z zamówieniami po identyfikatorach i oznacza rozbieżności, zanim trafią do księgowości. Rozbieżności szukaj najpierw w trzech miejscach: zwrot zlecony poza sklepem, płatność bez zweryfikowanego powiadomienia i zamówienie utworzone dwa razy dla jednej płatności.

Jest jeszcze jedno pytanie, które trzeba zadać przed startem, a nie po kwartale: czy sprzedaż opłacona przez bramkę wymaga u Ciebie paragonu z kasy rejestrującej. Rozstrzygnij to z księgowością na podstawie przepisów o zwolnieniach z obowiązku stosowania kas, bo od odpowiedzi zależy, czy integracja ma wystawiać paragon i z jakich danych.

Z tych samych identyfikatorów korzysta fakturowanie. Zweryfikowana płatność tworzy zdarzenie, zdarzenie uruchamia wystawienie dokumentu dokładnie raz, z identyfikatorem płatności jako kluczem, a system fakturowy wysyła dokument do KSeF i zapisuje nadany numer przy zamówieniu. Bramka jest więc źródłem zdarzenia, a nie dokumentu. Jak działa sama integracja z KSeF i jak obsłużyć odrzucenie dokumentu, opisuję w przewodniku o integracji z KSeF przez API; przy Stripe uważaj dodatkowo na podwójne dokumenty, gdy faktury są włączone jednocześnie w Stripe i w polskim programie.

Shopify, WooCommerce i własny sklep: co zmienia platforma

Platforma sklepu zawęża wybór bramki mocniej niż cennik. Zanim porównasz operatorów, sprawdź, czy mają moduł do Twojej platformy i co ten moduł naprawdę obsługuje.

Na Shopify punktem wyjścia jest Shopify Payments, w którym BLIK jest jedną z lokalnych metod płatności. Warunki są konkretne: klient musi wpisać polski adres i wybrać złote jako walutę płatności, sklep musi mieć złotego jako walutę krajową albo rynek dla Polski w złotych, BLIK-iem nie opłacisz zamówienia subskrypcyjnego, nie da się ręcznie przechwycić środków, a spór klient może otworzyć w ciągu trzynastu miesięcy. Porównanie Shopify z WooCommerce pod kątem płatności znajdziesz w przewodniku Shopify czy WooCommerce.

W WooCommerce każdy z polskich operatorów ma własny moduł, ale zakres jest różny. Moduł Przelewy24 jest dostępny dla WooCommerce w wersjach 9.x do 11.x i obejmuje BLIK wewnątrz sklepu, BLIK jednym kliknięciem, Google Pay i Apple Pay wewnątrz sklepu, płatność kartą bez opuszczania sklepu, płatności jednym kliknięciem i rekurencyjne na kartach oraz obsługę wielu walut. Wtyczka PayU dla WooCommerce, publikowana przez PayU, udostępnia między innymi listę banków, kartę, BLIK, Google Pay, Apple Pay, raty, Klarnę, PayPo i Twisto, a wymaga PHP w wersji 7.4 lub nowszej.

Wtyczka Tpay ma warunek, który łatwo przeoczyć w sklepie wielowalutowym: wymaga złotego jako waluty sklepu. Obsługuje zwroty z panelu WooCommerce, a subskrypcje kartą tylko z dodatkowym rozszerzeniem, takim jak WooCommerce Subscriptions. Jeśli sprzedajesz w kilku walutach albo planujesz to w ciągu roku, sprawdź ten warunek przed podpisaniem umowy, a nie po wdrożeniu.

Przy własnym sklepie albo aplikacji decyduje jakość środowiska testowego i to, co musisz pokazać klientowi. Przelewy24 mają osobne środowisko testowe z własnym adresem API i zastrzegają, że nie wolno go używać do transakcji produkcyjnych, wymagają co najmniej TLS 1.2 i zalecają filtrowanie połączeń po adresach IP operatora. Jeśli klient wybiera metodę płatności już w Twoim sklepie i akceptuje regulamin Przelewy24 u Ciebie, musisz wyświetlić oświadczenie z linkami do regulaminu i obowiązku informacyjnego operatora, a pole akceptacji nie może być zaznaczone domyślnie. Zanim zaczniesz, sprawdź w dokumentacji swojego operatora, czy ma podobne wymagania dla kasy we własnym sklepie, i zapisz je w zakresie integracji API od początku, a nie jako poprawkę po odrzuceniu przez operatora.

Zakładanie konta: JDG, spółka i strona, która przejdzie weryfikację

Umowę z operatorem zawiera się szybko. Czas zjada weryfikacja firmy i strony sklepu, a ta może się zatrzymać na drobnym braku na stronie sklepu, na przykład na NIP-ie w złym formacie.

Weryfikacja nie jest złośliwością operatora. PayU tłumaczy ją wymogami technicznymi i prawnymi, przede wszystkim przepisami o przeciwdziałaniu praniu pieniędzy. Przed rejestracją w PayU przygotowujesz dokumenty rejestrowe firmy, numery PESEL reprezentantów i działającą stronę spełniającą wymagania operatora, a potem wykonujesz przelew weryfikacyjny z rachunku firmowego. Przy jednoosobowej działalności PayU dopuszcza rachunek prywatny, pod warunkiem że na potwierdzeniu widać Twoje nazwisko.

Przelewy24 rozpisują dokumenty według formy prawnej. Przy jednoosobowej działalności wystarcza skan dokumentu tożsamości właściciela. Przy spółce z ograniczoną odpowiedzialnością dochodzą skany dokumentów tożsamości reprezentantów, oświadczenia PEP beneficjentów rzeczywistych i ewentualnie dodatkowe dokumenty rejestrowe, a przy spółce cywilnej także umowa spółki i dokumenty wszystkich wspólników. Przy spółce z kilkoma udziałowcami zbierz te dokumenty, zanim złożysz wniosek.

Osobno sprawdzana jest strona sklepu. Przelewy24 wymagają NIP-u widocznego na stronie w formacie dziesięciu cyfr i zgodnego z tym przypisanym do konta, regulaminu z danymi sprzedawcy, warunkami płatności i dostawy oraz zasadami reklamacji i odstąpienia od umowy, polityki prywatności zgodnej z RODO i pola akceptacji warunków przez kupującego. Każda kategoria produktów musi mieć co najmniej jeden aktywny produkt ze zdjęciem, opisem i ceną. Po akceptacji konta regulamin trzeba uzupełnić o informację o operatorze płatności, przy kartach rozszerzoną o klauzulę o operatorze kart, a w stopce każdej podstrony pokazać flagi dostępnych metod płatności, przy kartach także znaki Visa i Mastercard. Stripe dla metody Przelewy24 wymaga na stronie adresu firmy, numeru podatkowego, numeru rejestrowego, zasad zwrotów, polityki prywatności i regulaminu, a do tego wyklucza z tej metody całe branże, między innymi dropshipping, usługi medyczne, agencje reklamowe i pośrednictwo w nieruchomościach.

Kolejność, która oszczędza najwięcej czasu, jest sprzeczna z intuicją. Najpierw kompletna strona z regulaminem, polityką prywatności i przykładowymi produktami, potem wniosek u operatora, a dopiero na końcu integracja. Sklep z gotową integracją, który czeka na weryfikację, bo w stopce brakuje NIP-u, to strata, której łatwo uniknąć.

• Dane firmy na stronieNazwa, adres, NIP w pełnym zapisie i numer rejestrowy, zgodne co do znaku z danymi podanymi operatorowi.
• Regulamin i prywatnośćRegulamin z płatnościami, dostawą, reklamacjami i odstąpieniem od umowy oraz osobna polityka prywatności, obie łatwo dostępne, na przykład w stopce.
• Kasa ze zgodąPole akceptacji regulaminu przy zamówieniu, niezaznaczone domyślnie.
• Oferta, którą widaćW każdej kategorii przynajmniej jeden aktywny produkt ze zdjęciem, opisem i ceną; tego wprost wymagają Przelewy24.

Jak wybrać: sześć pytań, które rozstrzygają sprawę

Zamiast rankingu proponuję sześć pytań. Odpowiedzi na nie zawężają wybór do jednego, najwyżej dwóch operatorów, zanim spojrzysz na stawki.

W tym przewodniku celowo nie ma tabeli prowizji: stawki zmieniają się, bywają promocyjne w pierwszym okresie i zależą od pakietu. Linki do aktualnych cenników wszystkich czterech operatorów są w źródłach na dole strony.

Integrację bramki buduję tak, że najpierw spisujemy, co ma się stać po opłaceniu, po zwrocie i po nieudanym obciążeniu, a dopiero potem wybieram operatora i piszę kod. Płatność, zwrot, faktura i wypłata zależą od siebie, więc projektuję je razem: błąd w jednym z tych miejsc wychodzi na jaw dopiero w następnym. Jeśli masz sklep na WooCommerce, a standardowy moduł operatora obsługuje wszystko, czego potrzebujesz, do samej bramki zwykle nie potrzebujesz programisty: wystarczy instalacja, konfiguracja i testy opisane wyżej. Jeśli chcesz przejść przez te pytania na swoim sklepie, zobacz, jak pracuję przy integracjach API, albo sprawdź widełki i przykładowy zakres integracji płatności w cenniku.

1. Co sprzedajesz i komu?Płatności jednorazowe od klientów w Polsce prowadzą do polskiego operatora. Subskrypcja kartą, klienci zagraniczni albo własna aplikacja przesuwają wybór w stronę Stripe.
2. Na jakiej platformie stoi sklep?Na Shopify zacznij od Shopify Payments. W WooCommerce sprawdź zakres modułu operatora i jego warunki, na przykład wymaganą walutę. Przy własnym sklepie oceń dokumentację API i środowisko testowe.
3. Czy potrzebujesz płatności cyklicznych i jaką metodą?Karta czy BLIK, stała kwota czy zmienna. Zapytaj operatora, czy usługa wymaga aneksu albo aktywacji przez wsparcie, i kto odpowiada za ponowienie nieudanego obciążenia.
4. Jak często robisz zwroty częściowe?Przy sprzedaży z częstymi zwrotami częściowymi liczy się API zwrotów, identyfikatory chroniące przed podwójnym zwrotem i to, czy zwrot nie zablokuje się na pustym saldzie.
5. Kto będzie utrzymywał integrację?Obsługa powiadomień, weryfikacja podpisów, kolejka i uzgadnianie wypłat to kod, który ktoś musi rozumieć za rok. Gotowy moduł zdejmuje z Ciebie większość tej pracy, własna integracja daje kontrolę kosztem utrzymania.
6. Dopiero teraz cennikPorównaj stawki dla swojego koszyka i swoich metod na aktualnych cennikach. Cenniki różnią się budową: Tpay sprzedaje pakiety, w tym jeden z miesięczną opłatą serwisową, pobieraną tylko w miesiącach z transakcjami, PayU i Przelewy24 publikują tabele stawek dla metod, a Stripe podaje stawki za metodę i indywidualną ofertę dla dużych wolumenów.

Pytania i odpowiedzi