Najlepsze moduły płatności dla PrestaShop: pełne porównanie

Bazowe prowizje i status utrzymania modułów sprawdzono względem aktualnych cenników dostawców; przed podjęciem decyzji zweryfikuj bieżące stawki, bo zmieniają się i przy większych wolumenach podlegają negocjacjom.

Wpisz w wyszukiwarkę „najlepszy moduł płatności dla PrestaShop”, a dostaniesz ścianę opinii, zwykle napisanych przez kogoś, kto sam sprzedaje dany moduł. Uczciwe ujęcie wygląda inaczej: nie istnieje jeden najlepszy moduł płatności, istnieje właściwy wybór dla Twoich rynków, średniej wartości zamówienia i tego, jak często chcesz wracać do panelu administracyjnego w kolejnym roku. Celowo skupiamy się na wyborze i obsłudze modułów, nie na przeglądzie zwyczajów płatniczych w każdym kraju, bo ten temat omawiamy osobno i linkujemy tam, gdzie ma to znaczenie.

Co naprawdę porównujesz: bramka płatności jest modułem PrestaShop

Każda z poniższych opcji działa w Twoim sklepie jako moduł płatności PrestaShop. To ważniejsze, niż sugeruje marketing, ponieważ to moduł, nie marka, decyduje o tym, jak wygląda płatność dla klienta i ile pracy serwisowej zostaje po Twojej stronie. Dwie rzeczy odróżniają dobry moduł płatności od źródła problemów:

• Jak wyświetla się w procesie płatności. Nowoczesne moduły rejestrują się w hooku paymentOptions (w PrestaShop 1.6 był to stary hook displayPayment) i zwracają jeden lub więcej obiektów PaymentOption. Dzięki temu jeden moduł może pokazać kilka metod, kartę, iDEAL, BLIK, jako osobne przyciski na etapie płatności. Słaby moduł wyrzuca link przekierowujący i psuje wizualny przebieg zamówienia.
• Kto utrzymuje go przy życiu. Moduł płatności komunikuje się z zewnętrznym API, które zmienia się według harmonogramu dostawcy, nie Twojego. Gdy PayPal albo Stripe zmienia wersję API, utrzymywany moduł dostaje aktualizację i płatności nadal działają; porzucony moduł potrafi zawieść po cichu w najgorszym możliwym momencie. „Najlepszy” częściowo oznacza więc: nadal aktywnie utrzymywany.

Rzeczywiste porównanie ma więc trzy wymiary: prowizję od transakcji, rynki odblokowywane przez moduł oraz obciążenie administracyjne, które zostawia w panelu sklepu. Będziemy patrzeć na wszystkie trzy naraz.

Jeśli nigdy nie widziałeś, jak taki hook wygląda w głównej klasie modułu, poniżej jest cały kontrakt, metoda, która decyduje o tym, co klient zobaczy na etapie płatności:

// In your_module.php – the modern hook every maintained gateway uses.
public function hookPaymentOptions($params)
{
    if (!$this->active) {
        return [];
    }

    $option = new \PrestaShop\PrestaShop\Core\Payment\PaymentOption();
    $option
        ->setModuleName($this->name)
        ->setCallToActionText($this->l('Pay by card'))
        ->setAction($this->context->link->getModuleLink(
            $this->name, 'validation', [], true
        ));
    // A single module can return several PaymentOption objects –
    // one per method (card, iDEAL, BLIK) – as separate buttons.
    return [$option];
}

Tu widać konkretną różnicę: moduł zwracający czystą tablicę obiektów PaymentOption integruje się z natywnym etapem płatności; moduł, który zamiast tego wypisuje surowy link przekierowujący, psuje układ i trudno go później sensownie przestawić. Oceniając moduł, właśnie takie zachowanie warto sprawdzić na testowym zamówieniu w środowisku stagingowym.

Najważniejsze moduły płatności w skrócie

Poniższa tabela to krótka odpowiedź. Prowizje się zmieniają i przy określonym wolumenie zwykle podlegają negocjacjom, więc traktuj podane wartości jako publicznie dostępny europejski punkt odniesienia z momentu pisania, przed decyzją sprawdź aktualne stawki na stronie cennika dostawcy. „Liczba metod” oznacza metody, które pojedynczy moduł może pokazać w Twoim procesie płatności.

Każde z tych rozwiązań zasługuje na więcej niż jeden wiersz tabeli. Przygotowaliśmy osobne, praktyczne poradniki dla dwóch modułów, które najczęściej trafiają do sklepów, pełny przewodnik po konfiguracji Stripe w PrestaShop oraz Mollie jako wielometodowej bramki płatności, a także bezpośrednie porównanie, jeśli wybierasz między dwiema najbardziej rozpoznawalnymi nazwami: Stripe kontra PayPal. Dla rynku polskiego konfiguracja jest osobnym zadaniem: Przelewy24 dla PrestaShop.

Agregator czy moduły pojedynczych metod: decyzja ukryta pod główną decyzją

Zanim wybierzesz marki, wybierz model. Sprzedawcy korzystający z PrestaShop, którzy mylą się na tym etapie, kończą z zaśmieconym krokiem płatności i problematycznym utrzymaniem. Są dwa modele:

Moduł agregatora (Mollie, Stripe)

Jeden moduł instaluje się raz, łączy z jednym panelem i pokazuje wiele metod płatności jako osobne przyciski w procesie płatności. Co to oznacza dla Ciebie? Jeden zestaw webhooków do utrzymania, jeden ekran rozliczeń, jedna rzecz do aktualizacji po zmianie API, a daną metodę możesz włączyć albo wyłączyć w konfiguracji modułu bez instalowania czegokolwiek nowego. Dla większości sklepów to właściwy wybór domyślny, bo koszt operacyjny metody płatności leży głównie w jej utrzymaniu, a nie w samej prowizji transakcyjnej.

Moduł pojedynczej metody (dedykowany Bizum, samodzielna lokalna bramka)

Jeden moduł, jedna metoda. Zwykle dlatego, że ta metoda nie jest dostępna przez agregatora w Twoim regionie albo bezpośrednia integracja obniża prowizję przy dużym wolumenie. Kompromis jest realny: każdy dodatkowy moduł płatności to kolejny hook w tym samym procesie płatności, kolejny endpoint webhooka i kolejny cykl aktualizacji.

To najczęstszy błąd techniczny, jaki widzimy, dokładanie pięciu albo sześciu modułów pojedynczych metod, aż etap płatności zwalnia i zaczynają się konflikty. Praktyczna zasada: trzymaj jednocześnie aktywne moduły płatności w granicach trzech lub czterech: agregator dla większości metod, PayPal dla zaufania kupujących i najwyżej jeden albo dwa dedykowane moduły lokalne tam, gdzie agregator nie obsługuje danej metody. Powyżej tego progu kupujesz sobie sesje debugowania, nie konwersje.

Jak wybrać: schemat decyzyjny

Idź od góry do dołu. Pierwsze pytanie, które daje jasną odpowiedź, zwykle rozstrzyga wybór.

1. Na ilu rynkach faktycznie sprzedajesz?

• Jeden kraj: zainstaluj dominującą lokalną metodę plus PayPal jako opcję zaufania i na tym poprzestań. Sklep holenderski zaczyna od iDEAL; polski od Przelewy24/BLIK; niemiecki od metod opartych na bankach. Dodawanie metod, których nikt na danym rynku nie używa, tylko zaśmieca płatność.
• Kilka krajów UE: zacznij od agregatora (Mollie obejmuje najszerszy zestaw europejskich metod lokalnych w jednym module), dodaj PayPal i dodaj jeden moduł BNPL tylko wtedy, gdy Twoja kategoria na tym korzysta. Taki zestaw trzech modułów pokrywa zdecydowaną większość europejskich preferencji płatniczych, a do rozliczeń zostawia dokładnie jeden panel agregatora.

Jeśli nie masz pewności, jakich lokalnych metod oczekuje dany rynek, to osobny temat do sprawdzenia, opisaliśmy czego europejscy klienci oczekują przy płatności oraz konkretne lokalne systemy w artykule o BLIK, iDEAL i Bancontact.

2. Jaka jest Twoja średnia wartość zamówienia?

Poniżej mniej więcej 80 EUR BNPL rzadko zarabia na swoją wyższą prowizję. Powyżej tej kwoty, szczególnie w modzie, meblach i kategoriach lifestyle, opcja „kup teraz, zapłać później” może zwiększyć odsetek klientów, którzy finalizują większy koszyk, dlatego Klarna pojawia się właśnie w takich sklepach. To, czy wzrost pokrywa prowizję, trzeba mierzyć w konkretnym sklepie; nie jest to gwarancja. Ten kompromis omawiamy w artykule o tym, co BNPL oznacza dla konwersji.

3. Sklep oparty głównie na kartach albo subskrypcjach?

Jeśli większość Twoich klientów płaci kartą i nie potrzebujesz nietypowych lokalnych systemów płatności, niższa prowizja Stripe dla kart z UE oraz wbudowana obsługa płatności cyklicznych czynią go efektywnym wyborem, po Stripe chętnie sięgają też agencje, bo integracja i dokumentacja są przejrzyste. Jeśli wąskim gardłem jest zaufanie do marki w momencie płatności (nowy sklep, kupujący po raz pierwszy, sprzedaż międzynarodowa), rozpoznawalność PayPal uzasadnia jego wyższą prowizję jako dodatkowego przycisku.

Szerszy argument za oferowaniem więcej niż jednej metody, i wyjaśnienie, dlaczego pojedyncza bramka zostawia pieniądze na stole, omawiamy osobno w artykule dlaczego metody płatności mają znaczenie i czemu więcej opcji oznacza większą sprzedaż.

Kontrole techniczne przed uruchomieniem modułu płatności

Porównanie prowizji to łatwa część. Poniżej są rzeczy, które po cichu psują moduły płatności na produkcji, a każdą z nich możesz sprawdzić z własnego serwera albo panelu administracyjnego.

Webhooki muszą naprawdę docierać

Każda nowoczesna bramka potwierdza status płatności przez webhook serwer-serwer, nie przez przekierowanie przeglądarki klienta. Co oznacza, że zamówienie może być opłacone po stronie bramki, a w Twoim sklepie nadal widnieć jako nieopłacone, jeśli webhook nigdy nie dotrze. Przed startem potwierdź trzy rzeczy: certyfikat SSL jest ważny (bramki odmawiają wysyłki na błędny certyfikat), serwer odpowiada na URL webhooka w limicie czasu bramki (często ~30 sekund), a zapora albo CDN nie blokuje zakresów IP dostawcy płatności. W PrestaShop webhook trafia do własnego front controllera modułu (handler controllers/front/ modułu, osiągany przez index.php?fc=module&module=...&controller=...); sprawdź, czy jest publicznie dostępny, zanim mu zaufasz.

Jeden szczegół szczególnie często wykłada integracje Stripe: Stripe podpisuje każdy webhook sekretem, a moduł weryfikuje względem niego nagłówek Stripe-Signature. Jeśli wygenerujesz nowy sekret podpisywania w panelu Stripe, ale nie wkleisz nowej wartości do konfiguracji modułu, każdy webhook dotrze i zostanie odrzucony jako niepodpisany, bramka pokaże płatność jako pobraną, a PrestaShop nigdy nie zmieni zamówienia na opłacone. Gdy zamówienie Stripe wisi jako „oczekujące”, ale panel pokazuje obciążenie, najpierw sprawdź zgodność sekretu podpisywania webhooków.

Nigdy nie pozwól modułowi dotykać surowych numerów kart

Jeśli moduł płatności zbiera numery kart w formularzu serwowanym z Twojej własnej domeny, przejmujesz pełny zakres PCI DSS, czyli roczny koszt zgodności liczony w tysiącach. Wybieraj moduły korzystające z pól hostowanych przez bramkę albo iframe (PayPal Checkout, Stripe Elements, Mollie Components): może to ograniczyć Twój zakres PCI DSS, ale możliwość korzystania z SAQ A zależy od tego, czy Twoja integracja spełnia obowiązujące wymagania. To warunek nienegocjowalny i całkowicie uczciwy powód, by odrzucić nawet tańszy moduł.

Przetestuj powierzchnię konfliktów w środowisku stagingowym

Ponieważ każdy moduł płatności rejestruje się w tym samym hooku paymentOptions, dwa moduły mogą walczyć o renderowanie procesu płatności, kolejność metod albo zasoby. Zainstaluj i przećwicz nowy moduł płatności najpierw na kopii stagingowej, złóż prawdziwe zamówienie testowe każdą metodą, zanim zobaczy go klient na produkcji. Moduł płatności, który rzuca błąd 500 na etapie płatności, nie traci jednej sprzedaży; traci każdą sprzedaż, dopóki tego nie zauważysz.

Nasza rekomendacja

Dla większości europejskich sklepów PrestaShop efektywnym punktem startu jest jeden agregator (Mollie, jeśli Twoje rynki opierają się na europejskich metodach lokalnych; Stripe, jeśli dominują płatności kartą albo potrzebujesz subskrypcji) plus PayPal jako opcja budująca zaufanie, dwa moduły, pokrycie większości popytu i jeden panel do rozliczeń. Dodaj Klarna tylko tam, gdzie średnia wartość zamówienia i kategoria uzasadniają koszt BNPL, a dedykowany moduł lokalny tylko wtedy, gdy agregator nie obsługuje metody, której faktycznie używa Twój rynek. Potem zostaw ten zestaw w spokoju: każdy dodatkowy moduł płatności to stałe utrzymanie, a lekki, dobrze utrzymany zestaw płatności konwertuje lepiej niż przeładowany.

Niezależnie od tego, na których modułach skończysz, zasada dotycząca ich powierzchni pozostaje ta sama: etap płatności to najcenniejszy ekran w Twoim sklepie, a zadaniem każdego modułu jest pobrać płatność poprawnie, szybko i bez zaskakiwania klienta. Wszystkie powyższe moduły rejestrują się w tym samym etapie płatności, więc układ tego etapu ma równie duże znaczenie jak to, które moduły się w nim znajdują, utrzymanie metod, sumy zamówienia i przycisku potwierdzenia w jednym widoku to miejsce, w którym nasza jednostronicowa kasa Checkout Revolution pokazuje swoją wartość, bo daje czysty etap płatności dla Stripe (karty, Apple Pay, Google Pay, Link), PayPal i lokalnych systemów bez wybijania klienta z rytmu. Wybierz pod swoje rynki, utrzymaj mały zestaw, zweryfikuj webhooki, i podejmiesz decyzję biznesową, nie tylko techniczną. A właśnie tym jest wybór modułów płatności.

Najczęściej zadawane pytania

Ile modułów płatności powinien jednocześnie uruchamiać sklep PrestaShop?

Dla większości sklepów praktyczny limit to trzy albo cztery: jeden agregator (Mollie lub Stripe) dla większości metod, PayPal jako opcja zaufania i najwyżej jeden albo dwa dedykowane moduły lokalne tam, gdzie agregator nie obsługuje metody potrzebnej na Twoim rynku. Każdy dodatkowy moduł to kolejny webhook do utrzymania i kolejny cykl aktualizacji, a ponieważ wszystkie dzielą ten sam hook paymentOptions, zbyt duży stos modułów prowadzi do konfliktów w procesie płatności i wolniejszego kroku płatności.

Czy Mollie, czy Stripe jest lepszym agregatorem dla sklepu PrestaShop?

To zależy od tego, gdzie są Twoi klienci. Mollie oferuje najszerszy zestaw europejskich metod lokalnych (iDEAL, Bancontact, BLIK, Przelewy24, Klarna i inne) w jednym module z cennikiem zależnym od metody, co pasuje sklepom działającym na wielu rynkach Beneluksu/DACH. Stripe ma niższą prowizję dla kart z UE, wbudowane płatności cykliczne i dobrą obsługę portfeli (Apple Pay, Google Pay, Link), co pasuje sklepom opartym głównie na kartach albo subskrypcjach. Dużo kart i zasięg globalny → Stripe; szerokie pokrycie lokalnych metod w Europie → Mollie.

Czy potrzebuję certyfikacji PCI, żeby przyjmować płatności kartą przez te moduły?

Nie w ciężkim znaczeniu, o ile moduł korzysta z pól hostowanych przez bramkę albo iframe (Stripe Elements, Mollie Components, PayPal Checkout). W takim modelu utrzymywanie surowych danych kart poza Twoim serwerem może ograniczyć Twój zakres PCI DSS; możliwość korzystania z SAQ A nadal zależy od spełnienia obowiązujących wymagań. Pułapką jest każdy moduł, który renderuje formularz numeru karty serwowany z Twojej własnej domeny, to przenosi pełny zakres PCI DSS na Twój sklep wraz z kosztami audytu.

Zamówienie jest opłacone w bramce, ale nieopłacone w PrestaShop. Co jest nie tak?

Niemal zawsze chodzi o webhook, który nie dotarł albo nie został zaakceptowany. Potwierdź, że certyfikat SSL jest ważny, front controller modułu jest publicznie dostępny, a żaden CDN ani zapora nie blokuje zakresów IP bramki. W przypadku Stripe sprawdź konkretnie, czy sekret podpisywania webhooków w module odpowiada temu w panelu Stripe, niezgodny sekret sprawia, że sklep po cichu odrzuca każdy poza tym poprawny webhook.

Czy prowizje w tabeli porównawczej są stałe?

Nie. To publicznie podawane europejskie stawki bazowe z momentu pisania, a one się zmieniają. Dostawcy aktualizują cenniki, a większość stawek można negocjować po przekroczeniu określonego miesięcznego wolumenu. Traktuj tabelę jako kształt porównania, nie ofertę, i przed decyzją potwierdź aktualne stawki na stronie cennika każdego dostawcy.