Jak wybrać bramkę płatniczą dla Magento 2

Wybór dostawcy płatności dla sklepu na Magento zwykle przedstawia się jako porównanie opłat. W Magento opłaty są mniejszą częścią decyzji, ponieważ niemal każdy wybór dostawcy pociąga za sobą drugą decyzję: którego modułu Magento użyjesz. Moduł znajduje się w Twoim kodzie i jest renderowany wewnątrz checkoutu, a aktualizacja platformy albo go uwzględnia, albo napotyka na nim przeszkodę. Moduł płatności to kod zewnętrznego dostawcy najściślej powiązany z przepływem pieniędzy w każdym zamówieniu.

Ten wpis zawiera listę kontrolną do wyboru bramki, a następnie stosuje ją do sześciu międzynarodowych dostawców (Adyen, Stripe, Mollie, PayPal z Braintree, Klarna, Unzer) oraz czterech bramek specyficznych dla rynku czeskiego, słowackiego i polskiego (GoPay, Comgate, PayU, Przelewy24). Każdy fakt dotyczący dostawcy zweryfikowano względem podanego źródła 2 sierpnia 2026 r.; tam, gdzie czegoś nie dało się zweryfikować, piszemy o tym wprost.

Co sprawdzić przed podpisaniem umowy

Kto utrzymuje moduł i czy można przeczytać kod? Adyen, Mollie, Unzer i PayU utrzymują swoje moduły Magento w publicznych repozytoriach. Stripe publikuje wyłącznie archiwa wydań, z wyłączonym trackerem zgłoszeń. Klarna i Przelewy24 nie publikują żadnego repozytorium źródłowego, mimo oznaczeń licencji open source na swoich pakietach. GoPay i Comgate nie mają własnego modułu. Dostępne moduły pochodzą od zewnętrznych dostawców i są płatne oraz zamknięte. Bieżąca linia dołączonego rozszerzenia Braintree również nie ma publicznego kodu źródłowego; repozytorium Gene kończy się na starszych wydaniach 4.0.x. Publiczne repozytorium nie gwarantuje jakości, ale pozwala przeczytać diff przed aktualizacją, zamiast polegać na dzienniku zmian.

Jak moduł zachowywał się przy dotychczasowych aktualizacjach platformy. Kolejna sekcja omawia trzy wzorce awarii, których warto szukać. Tam, gdzie dostawca nie ma publicznego trackera, a jest tak w przypadku siedmiu z dziesięciu opisanych tu bramek, poszukaj nazwy modułu we własnym trackerze Magento: oba opisane niżej incydenty odnotowano właśnie tam, a nie w trackerze żadnego z dostawców.

Przepływy operacyjne stojące za checkoutem. Moduł przekierowania zależy od swojego asynchronicznego potwierdzenia: punktu końcowego webhooka, sprawdzania podpisu i ponawiania prób oraz tego, co dzieje się z zamówieniem, którego klient nigdy nie wrócił ze strony płatności. Kolejnym punktem do sprawdzenia są zwroty. Część modułów wystawia je z poziomu noty kredytowej Magento, inne wyłącznie w zapleczu bramki, a ten sam podział widać również w przechwytywaniu płatności przy wysyłce oraz zamówienia utworzone w panelu administracyjnym. Tokenom płatności warto poświęcić osobne pytanie, ponieważ rozszerzenia subskrypcyjne po stronie Magento oczekują mechanizmu Vault, podczas gdy lokalne bramki opisane niżej zwykle dokumentują własne, tokenizowane płatności cykliczne po stronie serwera. Ustal, który z tych dwóch mechanizmów udostępnia dany moduł. W Czechach, na Słowacji i w Polsce płatność zarejestrowana przed wysyłką może powodować obowiązek rozliczenia VAT z faktury zaliczkowej, co jest jednym z powodów, dla których sprzedawcy konfigurują tam przechwytywanie płatności dopiero przy wysyłce. Ten sposób postępowania warto skonsultować z księgowym. Poniższe profile nie zawierają tych informacji. Większość dostawców publikuje je wyłącznie w dokumentacji modułu, a zamknięte moduły nie publikują ich wcale. Ten punkt warto sprawdzić dla modułów, które trafią na Twoją krótką listę.

Wsparcie dla Hyvä, zgodnie z zapisami w publicznych trackerach. Hyvä utrzymuje publiczny tracker modułów zgodności dla motywu oraz osobny tracker integracji dla Hyvä Checkout, a jego dokumentacja wymienia główne śledzone integracje płatności. Każde zgłoszenie w trackerze integracji checkoutu jest oznaczone etykietą Vendor lub Community, która wskazuje, kto odpowiada za wdrożenie i pierwszą linię wsparcia. To, kto nim jest, ma równie duże znaczenie jak sam fakt istnienia integracji, ponieważ decyduje o tym, kto naprawi ją w momencie, gdy bramka wyda wersję łamiącą zgodność wsteczną.

Pokrycie headless. Mutacja Magento setPaymentMethodOnCart przekazuje kod metody wraz z obiektem wejściowym specyficznym dla danej metody, którego dokumentacja referencyjna wymaga dla każdej metody płatności online. Moduł bez własnej warstwy GraphQL nie może odebrać stokenizowanych danych płatności ani obsłużyć przekierowania przez GraphQL. Wdrożenie headless musi wtedy pokryć tę różnicę pracą niestandardową, zwykle przez REST.

Zakres PCI DSS. Zgodnie z wytycznymi SAQ Rady ds. Standardów Bezpieczeństwa PCI (materiał z ery wersji 3; obecne kwestionariusze w wersji 4 zachowują to samo rozróżnienie między przekierowaniem a iframe’em), pełne przekierowanie lub iframe hostowany przez dostawcę mogą pozwolić sprzedawcy pozostać przy krótszym kwestionariuszu SAQ A; formularze płatności lub JavaScript płatności serwowane z własnej strony oznaczają SAQ A-EP. Zgodnie z kryteriami kwalifikowalności w wersji 4.0.1, wyjaśnionymi w FAQ 1588 (luty 2025), nawet integracja przez iframe wymaga, aby strona sprzedawcy była zabezpieczona przed atakami skryptowymi, albo potwierdzenia dostawcy, że jego rozwiązanie ją chroni; zwykłe przekierowanie pozostaje najmniejszym możliwym zakresem.

Metody płatności faktycznie używane na Twoim rynku. Każda z opisanych tu bramek obsługuje karty. Decydujące metody to zakup na fakturę w Niemczech, głębokość obsługi BLIK-a w Polsce oraz, w Czechach, kwestia, czy udział przelewów i płatności za pobraniem w ogóle uzasadnia lokalną bramkę. Sekcja o rynkach poniżej zawiera liczby i ich źródła.

Publikowane cenniki, w walutach, w których się rozliczasz. Adyen, Stripe, Mollie, PayPal, GoPay, Comgate, PayU i Przelewy24 publikują cenniki. Unzer publikuje stawki podstawowe i negocjuje ceny wolumenowe indywidualnie. Klarna nie publikuje europejskiego cennika, a jej całkowitego kosztu nie da się wyliczyć z publicznie dostępnych informacji. Sprawdź też, czy bramka rozlicza się w każdej walucie, w której sprzedajesz, czy przelicza po własnym kursie; przewalutowanie pozostaje poza opłatą główną. Wiele z tych informacji jest publicznych: Adyen wymienia 26 walut rozliczeniowych dla sprzedawców z UE, w tym CZK i PLN, Mollie wymienia 13 walut wypłat, PayU rozlicza się 1:1 w 11 walutach, a GoPay dokumentuje waluty wypłat w podziale na banki. Comgate publikuje warunki wypłat dla poszczególnych walut, a Braintree publikuje listę walut schematu, przy czym zestaw walut dla każdego sprzedawcy ustala się przy onboardingu i rozszerza poprzez wnioskowanie o dodatkowe konta handlowe. Klarna wypłaca w walucie transakcji. Pozostali publikują mniej: Stripe renderuje swoją tabelę rozliczeniową po stronie klienta, Przelewy24 podają wypłaty w PLN lub EUR, a Unzer nie publikuje żadnej listy.

Jak aktualizacje wpływają na moduły płatności

Trzy wzorce awarii są udokumentowane w publicznych trackerach i informacjach o wydaniach, i wszystkie trzy warto sprawdzić w odniesieniu do dowolnego modułu na Twojej krótkiej liście.

Pierwszy to rozdzielenie od rdzenia (unbundling). Informacje o wydaniu Magento 2.4.4 stwierdzają: „Z wyjątkiem Braintree, wszystkie rozszerzenia dołączane przez dostawców zostały usunięte z bazy kodu Magento Open Source 2.4.4” (informacje o wydaniu). Od tego momentu moduły płatności są wersjonowane niezależnie od platformy, a aktualizacja rdzenia nie oznacza już zgodnego modułu płatności.

Drugi to rozbieżność wersji zależności. Zgłoszenie #39989 w repozytorium Magento dokumentuje, jak łatka bezpieczeństwa 2.4.8-p1 obniżyła wersję sześciu pakietów paypal/module-braintree z 4.7.0 do 4.6.1-p5 na dotkniętych instalacjach, poprzez ograniczenie metapakietu, które pozostawiało composerowi swobodę wyboru dowolnej z tych wersji. W drugą stronę, zgłoszenie #39803 odnotowuje, że moduł Klarny wprost blokował aktualizację do 2.4.8 przez konflikt wersji monolog. Adobe zamknęło zgłoszenie w ciągu jedenastu dni, wskazując sklepom Klarnę jako właściciela rozszerzenia. Poprawka trafiła do wydania modułu 3.3.1: zarchiwizowane zrzuty listingu na Marketplace nadal pokazują wersję sprzed poprawki, 3.3.0, 20 maja 2025 r., a poprawioną linię pokazują po raz pierwszy 13 czerwca, więc sklepy korzystające z tego modułu były zablokowane przez sześć do dziewięciu tygodni po ogólnej dostępności z 8 kwietnia.

Trzeci to sprzężenie z frontendem. Informacje o wydaniu Mage-OS 2.2.1 wycofują optymalizację opóźnionego ładowania reCAPTCHA z wersji 2.2.0, ponieważ powodowała ona błędy reCAPTCHA na stronach checkoutu korzystających z hostowanych i osadzonych w iframe formularzy płatności. Moduły płatności zależą od kolejności ładowania checkoutu i od czasowania skryptów, więc niezwiązana z nimi zmiana we frontendzie może zepsuć krok płatności w checkoucie. To dokładnie to samo sprzężenie, które sprawia, że zgodność z Hyvä stanowi osobne zadanie.

Konkretnie w przypadku Mage-OS: jego dystrybucja zawiera rdzeniowy moduł PayPal, ale nie Braintree (zweryfikowane względem metapakietu mage-os/product-community-edition), a żaden z dziesięciu opisanych niżej dostawców nigdzie nie deklaruje wsparcia dla Mage-OS. Sam Mage-OS twierdzi, że jest w pełni zgodny z rozszerzeniami Magento Open Source, więc oczekuje się, że moduł działający na Open Source zadziała również tam. Oczekiwanie to opiera się wyłącznie na deklaracji Mage-OS, bez żadnego zobowiązania ze strony dostawcy płatności. Dotyczy to jednakowo wszystkich dziesięciu bramek i wpisuje się w decyzję o platformie, a nie w wybór bramki.

Hyvä zmienia krótką listę

Storefront oparty na Hyvä zmienia kwestię płatności pod jednym względem. Z samym motywem Hyvä checkout może pozostać na standardowym checkoucie Luma dzięki udokumentowanemu mechanizmowi rezerwowemu motywu, przy którym istniejące moduły płatności nadal działają. Mechanizm ten konfiguruje się dla poszczególnych tras i oznacza on konieczność utrzymywania checkoutu opartego na motywie Luma obok Hyvä. A ponieważ dotyczy on wyłącznie skonfigurowanych tras, przyciski płatności ekspresowych (Apple Pay, Google Pay, PayPal), które moduły renderują na stronach produktu, koszyka i mini-koszyka, pozostają w motywie Hyvä i nadal wymagają zgodności z Hyvä po stronie modułu. Hyvä Checkout działa inaczej: składanie zamówienia przenosi się z metody płatności do centralnej usługi, więc frontend Luma modułu płatności w ogóle się tam nie uruchamia. Zgodnie z dokumentacją Hyvä backend modułu zwykle da się wykorzystać ponownie, natomiast warstwę zwróconą do checkoutu trzeba zbudować od nowa. Każdy dostawca wymaga dedykowanej integracji. Jeśli taka integracja nie powstanie, udokumentowanym obejściem jej braku jest mechanizm rezerwowy Luma.

Ustalenia dotyczące utrzymania tych integracji nie są jednolite, a przykład Adyen pokazuje, dlaczego ma to znaczenie. Adyen napisał własny moduł Hyvä Checkout, a następnie zakończył jego utrzymanie. Jego README zaczyna się teraz od informacji, że integracja nie jest już oficjalnie wspierana i nie otrzyma nowych aktualizacji (adyen-magento2-hyva). Zespół Hyvä przejął integrację i wydał przepisany pakiet, hyva-themes/magento2-hyva-checkout-adyen-payment-v2, działający z wtyczką Adyen w wersji v10, w marcu 2026 r. (zgłoszenie o przekazaniu). Sprzedawcy, którzy wybrali Adyen częściowo ze względu na jego pierwszorzędne wsparcie dla Hyvä, zależą teraz od pakietu utrzymywanego przez Hyvä, opartego na głównej wersji wtyczki, która wymaga Magento 2.4.8 lub nowszego.

Sześciu międzynarodowych dostawców

Adyen utrzymuje swoją wtyczkę do Magento w otwartym repozytorium na licencji MIT i w ciągu ostatnich dwunastu miesięcy wydał ją czterdzieści razy w równoległych liniach v9 i v10, licząc od strony wydań repozytorium. Kosztem tego tempa jest ścisły harmonogram wsparcia: własna tabela Adyen przewiduje dla każdej głównej wersji wtyczki stałe okno wsparcia (dwa lata dla v10), a sklepy na wersjach od 2.4.4 do 2.4.7 pozostają przy linii v9, w trybie wyłącznie aktualizacji bezpieczeństwa od maja 2026 r., kończącym się w grudniu 2026 r. Linia v10 dodała wsparcie dla Magento 2.4.9 i PHP 8.5 w wersji v10.10.0 (31 marca 2026 r.), choć w chwili sprawdzania tabela wsparcia i README nadal wskazywały wyłącznie 2.4.8; to informacje o wydaniu są aktualnie wiążące. Obsługę headless zapewnia udokumentowane wsparcie GraphQL, a pokrycie metod płatności w UE obejmuje iDEAL, polecenie zapłaty SEPA, BLIK, Twint i Bancontact, przy czym karty renderowane są jako komponenty osadzone wewnątrz checkoutu. Cennik jest publikowany w modelu interchange++ z opłatami za poszczególne metody. Migrację wtyczki warto zaplanować co jeden do dwóch lat; dokładnie to zaleca README Adyen.

Stripe dostarcza sprawny moduł w ramach zamkniętego procesu. Oficjalny moduł jest dystrybuowany jako archiwa wydań na własnej, zastrzeżonej licencji Stripe, z wyłączonymi zgłoszeniami na GitHubie: nie ma publicznego trackera błędów, który można by sprawdzić przed aktualizacją. Wydania pojawiają się mniej więcej co miesiąc, wsparcie obejmuje Magento od 2.3.7 do 2.4.x, a poprawki są udostępniane wyłącznie od wersji modułu 4.5.x wzwyż (tabela cyklu życia), a oba przepływy checkoutu, osadzony Payment Element i przekierowanie, są w dokumentacji Stripe opisane jako kwalifikujące się do SAQ A; dokumentacja ta obejmuje też REST i GraphQL dla niestandardowych storefrontów. Rozpakowaliśmy archiwum wydania 4.6.4: schemat GraphQL wraz z jego resolwerami znajduje się w kodzie źródłowym, a plik composer.json wymaga jedynie PHP 7.4 lub nowszego. Przed każdą aktualizacją warto przeczytać dziennik zmian: wersja 4.6.0 wprowadziła zmiany łamiące zgodność dla buildów headless, a notatki do wersji 4.6.2 stwierdzają, że zaostrzone wymagania uwierzytelniania wprowadzone w 4.6 „powodowały spadek konwersji w checkoucie”, zanim zostały złagodzone. Integracja Hyvä Checkout jest publikowana we własnej przestrzeni nazw Hyvä. Dziennik zmian Stripe wspomniał o Hyvä raz. Metody europejskie obejmują polecenie zapłaty SEPA, iDEAL, Przelewy24 i Klarnę. BLIK nie pojawia się na udokumentowanej liście metod modułu, choć jest obecny w kodzie źródłowym, który mapuje tę metodę i dostarcza jej ikonę; metody renderowane są przez Stripe Payment Element i włączane z poziomu Stripe Dashboard, więc warto to zweryfikować w polskim trybie testowym. Cennik publikowany jest osobno dla poszczególnych krajów, w tym cennik czeski.

Mollie to najsilniejsze połączenie otwartości i zgodności z Hyvä. Moduł jest publiczny, utrzymywany przez dostawcę i wydawany mniej więcej co miesiąc. Wsparcie GraphQL znajduje się w kodzie źródłowym i obejmuje pełny przepływ headless: rozszerza własne mutacje płatności Magento i zwraca adres URL przekierowania Mollie. Mollie utrzymuje własny motyw Hyvä oraz moduły zgodności z Hyvä Checkout, ogłosiła strategiczne partnerstwo z Hyvä w październiku 2024 r. i wspiera finansowo Mage-OS na Open Collective, choć nie deklaruje żadnego technicznego wsparcia Mage-OS. Wydanie v3.0.0 z czerwca 2026 r. było aktualizacją łamiącą zgodność (minimalne wymagania: Magento 2.4.5 i PHP 8.1, usunięto Orders API). Sklepy na starszych platformach pozostają przy linii 2.x bez podanej daty zakończenia wsparcia. Pokrycie metod obejmuje Europę Zachodnią i Środkową (iDEAL, SEPA, BLIK, Przelewy24, EPS, Twint), głównie w formie przekierowań na hostowaną stronę Mollie. Na jej liście nie znaleźliśmy żadnej czeskiej ani słowackiej metody z przyciskiem bankowym. Cennik jest publikowany per metoda, per transakcja, bez opłat minimalnych.

PayPal i Braintree to dwa różne produkty dostarczane razem. Rdzeniowy moduł PayPal jest częścią platformy w każdej dystrybucji, włącznie z Mage-OS, a jego kod źródłowy jest publiczny w samym Magento. Braintree to jedyne rozszerzenie wciąż dołączane do Magento, rozwijane przez Gene Commerce na zlecenie PayPal. Obecnie dołączana linia 4.x nie ma publicznego kodu źródłowego ani trackera zgłoszeń (publiczne repozytorium Gene kończy się na starszej linii 4.0.x), więc błędy zgłaszane są w repozytorium samego Magento. Platforma rozstrzyga wersję Braintree przez metapakiet rozszerzeń, którego luźne ograniczenie doprowadziło do obniżenia wersji opisanego w zgłoszeniu #39989. Nowsze wersje trafiają do repozytorium composer Adobe pomiędzy wydaniami platformy i można je wymusić jawnie. Magento 2.4.9 rozszerzyło rozszerzenie o BLIK oraz o zakup na fakturę dla Niemiec za pośrednictwem Ratepay (informacje o wydaniu 2.4.9), podczas gdy strona Braintree w dokumentacji Adobe wymienia polecenie zapłaty SEPA/ELV jako jeszcze nieobsługiwane. Wsparcie GraphQL dostarczane jest jako osobny pakiet paypal/module-braintree-graph-ql, widoczny w danych wyjściowych composera w tym samym zgłoszeniu, a Adobe dokumentuje przepływy GraphQL. PayPal publikuje cennik Braintree dla poszczególnych krajów: niemiecka strona z opłatami podaje 1,9% plus 0,30 EUR za karty i portfele firm trzecich, przy standardowych stawkach dla sprzedawców, taką samą stawkę podają strony czeska i polska, choć bez stawki dla metody fakturowej Ratepay. Starsze metody Payflow w module rdzeniowym są oznaczone przez PayPal jako przestarzałe i dostępne wyłącznie w Stanach Zjednoczonych, Kanadzie, Australii i Nowej Zelandii, zgodnie ze stroną Payflow Pro w dokumentacji Adobe, która wskazuje też, że Payflow Pro wymaga wtyczki firmy trzeciej dla PSD2; w Europie traktuj je jako niedostępne. Integracje Hyvä Checkout zarówno dla PayPal, jak i dla Braintree, to pakiety w przestrzeni nazw Hyvä.

Klarna sprzedaje własne metody (fakturę, raty, płatność od razu), a nie pełny stos acquiringowy, co w regionie DACH sprawia, że trudno ją pominąć. Jej lista krajów zakupu obejmuje Niemcy, Austrię, Czechy, Słowację i Polskę. Historia modułu jest niejednoznaczna. Dystrybucja odbywa się wyłącznie przez Marketplace, z etykietą licencji Apache 2.0, ale bez publicznego źródła czy trackera zgłoszeń, a wpis na listingu przeczy własnym informacjom o wydaniu: opis wciąż reklamuje Klarna Checkout i wsparcie dla Magento 2.4.4, podczas gdy informacje o wydaniu odnotowują usunięcie Klarna Checkout w wersji 4.0.0 oraz zakończenie wsparcia dla 2.4.4 i 2.4.5 w linii 4.x. Wspomniany wcześniej konflikt z monolog blokował aktualizację modułu przez sześć do dziewięciu tygodni. Własna dokumentacja Klarny deklaruje wsparcie GraphQL i headless. Nie ma europejskiego cennika. Wpis na Marketplace informuje o dodatkowych opłatach i kieruje link kontaktowy na stronę rejestracji, a nie na opublikowane stawki. Integracja Hyvä Checkout to kolejny pakiet w przestrzeni nazw hyva-themes, a jej zgłoszenie w trackerze oznacza ją jako utrzymywaną przez społeczność. Tempo wydań w 2026 r. było szybkie: od 4.1.1 w styczniu (zarchiwizowany listing) do 4.11.1 w lipcu, zgodnie z aktywnym listingiem powyżej.

Unzer, dawniej heidelpay, obsługuje zestaw metod DACH w ramach jednej umowy acquiringowej: własny zabezpieczony zakup na fakturę i raty dla Niemiec, Austrii i Szwajcarii, a także EPS, Twint i polecenie zapłaty SEPA. Karty renderowane są jako komponenty osadzone hostowane przez Unzer, kilka metod działa jako przekierowania. Od strony inżynierskiej moduł wypada słabiej. Repozytorium jest publiczne na licencji Apache 2.0, ale ma wyłączone zgłoszenia. Moduł nie ma w ogóle wsparcia GraphQL (sprawdziliśmy całe drzewo plików), a dokumentacja dostawcy jest wewnętrznie sprzeczna co do obsługiwanych wersji Magento (2.4.5 i nowsze na stronie instalacji, 2.4.6 do 2.4.8 na stronie przeglądu wtyczki). Jego trzy repozytoria Hyvä (magento2-hyva-checkout i pokrewne) nie mają żadnych tagów ani wydań i ostatni push miały w grudniu 2025 r., choć dokumentacja podaje wydanie wtyczki Hyvä Checkout 1.0.0 w lutym 2026 r. Unzer publikuje stawki podstawowe (od 1,50% plus 0,20 EUR za transakcję, opłata miesięczna od 19 EUR oraz 149 EUR za konfigurację) i negocjuje ceny wolumenowe indywidualnie.

Bramki lokalne: CZ, SK, PL

GoPay, według własnych danych jedna z największych bramek czeskich i słowackich, sam nie utrzymuje modułu do Magento. Jej strona integracji wymienia własne moduły dla Shoptet, WooCommerce, Shopify, OpenCart i PrestaShop. Dla Magento centrum pomocy wskazuje na pięciu zewnętrznych dostawców. Spośród stron dostawców, do których udało nam się dotrzeć, każdy moduł jest płatny i zamknięty, bez publicznego repozytorium i bez wzmianki o Hyvä. Jeden wspiera Magento tylko do wersji 2.4.6, a inny (Artio, dostępny z listy dostawców powyżej) deklaruje zgodność wyłącznie z Magento 2.2.x na PHP 7.0. Sklep piątego dostawcy był niedostępny w chwili sprawdzania, a ostatnia zarchiwizowana wersja jego modułu pochodzi z lutego 2019 r. Żaden z trackerów Hyvä nie ma wpisu dla GoPay, żadna z dostępnych stron dostawców nie wspomina o GraphQL, a wyszukiwanie na Adobe Commerce Marketplace nie zwraca obecnie żadnego rozszerzenia GoPay. Sama bramka pokrywa to, czego wymaga czeski checkout (przyciski bankowe, płatności QR, portfele, płatność odroczona) przy publikowanym cenniku, poprzez przekierowanie lub osadzoną nakładkę, zależnie od modułu dostawcy. Integrację warto zaplanować budżetowo jako pracę niestandardową z zewnętrznym dostawcą i przejrzeć moduł przed jego wdrożeniem, zaczynając od obsługi webhooków.

Comgate działa według tego samego schematu: własna dokumentacja oddaje moduł do Magento w ręce Platiti.cz, dostępne moduły są płatne i zamknięte, jedynym publicznym repozytorium jest nieoficjalne, nieaktywne od 2021 r., żaden z trackerów Hyvä nie ma wpisu dla Comgate, a żadna strona dostawcy nie wspomina o GraphQL ani o wsparciu headless. Standardowy przepływ bramki, czyli przekierowanie na hostowaną stronę Comgate, utrzymuje sklep w najmniejszym możliwym zakresie PCI. Comgate oferuje też tryby osadzone i przynajmniej jeden z zamkniętych modułów je reklamuje, więc warto sprawdzić, z którego przepływu faktycznie korzysta kupowany moduł. Lista metod jest jak na ten region szeroka: karty, portfele, BLIK, płatność odroczona przez Twisto i Skip Pay oraz to, co strona Comgate opisuje jako pełny zakres banków w Czechach, na Słowacji i w Polsce. Jeśli chodzi o przelewy i płatności QR, wartość, jaką bramka daje ponad samodzielnie generowany kod QR, który wiele czeskich sklepów już drukuje na fakturach, to natychmiastowe potwierdzenie i automatyczne dopasowanie zamówienia. Cennik jest publikowany aż po opłatę za chargeback.

PayU to jedyna bramka z regionu CEE, która utrzymuje swój moduł do Magento w taki sam sposób jak dostawcy międzynarodowi: publiczne repozytorium, licencja Apache 2.0, utrzymanie przez dostawcę, wyłącznie Magento 2.4. Tempo wydań jest nierówne, z dziewięciomiesięczną przerwą między wydaniami w latach 2025 i 2026, po której nastąpiły cztery wydania w 2026 r. Wsparcie dla Hyvä Checkout istnieje, ale zapewnia je firma trzecia (Snowdog) i jest ono oznaczone jako niekompletne w oficjalnym trackerze, a ostatnia otagowana wersja (2.0.0) pochodzi z kwietnia 2024 r. Moduł nie ma wsparcia GraphQL. Jego lista funkcji nie zawiera metody dedykowanej BLIK-owi, więc BLIK działa w ramach ogólnego przekierowania, które dokumentacja PayU opisuje jako ograniczone do standardowego pay-by-link; wprowadzanie kodu w checkoucie i warianty jednoklikowe należą do jego bezpośredniego API. Płatność kartą odbywa się przez formularz na stronie; pozostałe metody przekierowują. Polski cennik jest publikowany.

Przelewy24 samodzielnie utrzymują swój moduł, co odróżnia je od bramek czeskich, choć bez publicznego repozytorium tego utrzymania nie da się śledzić. Aktualny moduł dla Magento 2.4.4 i nowszych jest dystrybuowany przez Marketplace na licencji GPL-3.0, bez publicznego repozytorium czy trackera zgłoszeń i bez dat wydania poszczególnych wersji. Starsze buildy, osobny wariant GraphQL/PWA/VUE oraz własny moduł dostawcy do Hyvä Checkout (wersja 1.0.0, którą strona datuje na 24 marca 2026 r.) są dostępne do pobrania z własnej strony dostawcy. Rozpakowaliśmy oba te dodatkowe pakiety. Moduł Hyvä zawiera komponenty checkoutu w Magewire dla BLIK-a, kart, Google Pay i Apple Pay, zbudowane na hyva-themes/magento2-hyva-checkout. Wariant GraphQL (jego manifest composera wskazuje wersję 1.3.0; strona datuje go na 9 lutego 2026 r.) to moduł GraphQL po stronie serwera, podpięty pod mutację płatności Magento, bez żadnego kodu frontendu PWA czy Vue, mimo etykiety. Oba dodatki są nieobecne w trackerach Hyvä, więc widoczność w trackerze i pierwsza linia wsparcia spoczywają wyłącznie po stronie dostawcy. Polscy konkurenci Przelewy24, TPay i PayPo, mają wpisy w trackerze Hyvä Checkout (TPay, PayPo), przy czym moduł PayPo utrzymuje Snowdog, a moduł TPay sam dostawca. Domyślny przepływ to przekierowanie, z opcjonalnym wprowadzaniem karty i kodu BLIK w checkoucie. Udokumentowane wsparcie dla BLIK-a jest tu najpełniejsze spośród opisanych modułów: przekierowanie, wprowadzanie kodu w checkoucie i BLIK jednoklikowy, wszystko zgodnie z listingiem dostawcy na Marketplace i informacjami o wydaniach. Standardowy cennik jest publikowany.

Zestawienie

Bramka	Kto utrzymuje moduł	Publiczne źródło	Hyvä Checkout	GraphQL	Publiczny cennik
Adyen	Dostawca	Tak	Przestrzeń nazw Hyvä	Udokumentowane	Tak
Stripe	Dostawca	Tylko archiwa	Przestrzeń nazw Hyvä	W kodzie źródłowym	Tak
Mollie	Dostawca	Tak	Dostawca	W kodzie źródłowym	Tak
Braintree (dołączony)	Gene dla PayPal	Nie	Przestrzeń nazw Hyvä	Pakiet platformy	Tak
Klarna	Dostawca	Nie	Przestrzeń nazw Hyvä	Udokumentowane	Nie
Unzer	Dostawca	Tak	Dostawca, bez wersjonowania	Nie	Stawki podstawowe
GoPay	Firmy trzecie	Nie	Brak	Nie zadeklarowano	Tak
Comgate	Firmy trzecie	Nie	Brak	Nie zadeklarowano	Tak
PayU	Dostawca	Tak	Firma trzecia, częściowo	Nie	Tak
Przelewy24	Dostawca	Brak repozytorium	Dostawca, poza trackerem	Osobny build	Tak

„Przestrzeń nazw Hyvä” oznacza, że pakiet integracyjny jest publikowany w przestrzeni hyva-themes, przy czym pierwsza linia odpowiedzialności wynika z etykiet Vendor i Community w trackerze checkoutu. W kolumnie GraphQL „Udokumentowane” oznacza, że dostawca deklaruje wsparcie, a my nie czytaliśmy kodu; „W kodzie źródłowym” oznacza, że przeczytaliśmy go w publicznym kodzie; „Pakiet platformy” oznacza, że jest on dostarczany jako osobny pakiet composera obok platformy, z przepływami udokumentowanymi przez Adobe. Wsparcie GraphQL w Przelewy24 dostarczane jest jako osobny moduł do pobrania; rozpakowaliśmy go i znaleźliśmy serwerowe API GraphQL bez kodu frontendowego, mimo etykiety PWA. Wiersz Braintree dotyczy dołączonego rozszerzenia; kod źródłowy rdzeniowego modułu PayPal jest publiczny w samym Magento. Zawartość komórek wynika ze źródeł podlinkowanych powyżej; „Nie zadeklarowano” i „Brak” odnotowują nasze własne wyszukiwania. Wszystko według stanu na 2 sierpnia 2026 r.

Zacznij od rynku, potem odrzucaj

W Niemczech badanie płatności EHI Retail Institute wskazuje udział PayPal na poziomie 28,5 procent przychodów sprzedaży internetowej w 2024 r., zakupu na fakturę na 25,8 procent, polecenia zapłaty na 17,3 procent, a kart na 12,3 procent (EHI). Niemiecki checkout potrzebuje więc PayPal, produktu fakturowego i polecenia zapłaty SEPA, zanim zajdzie potrzeba czegokolwiek innego. Braintree pokrywa PayPal oraz, na Magento 2.4.9, zakup na fakturę przez Ratepay. Produkt fakturowy sprzedają zarówno Klarna, jak i Unzer. Dla polecenia zapłaty dostępne tu opcje to Unzer, Mollie, Adyen lub Stripe, ponieważ dokumentacja Braintree od Adobe wymienia polecenie zapłaty SEPA jako jeszcze nieobsługiwane. Ścieżka Ratepay wymaga Magento 2.4.9, które wtyczka Adyen obsługuje od wersji v10.10.0; to połączenie działa więc na aktualnej platformie, a na wersjach 2.4.8 i niższych opcje fakturowe to Klarna i Unzer. Żaden z trzech dostawców nie publikuje stawki za sam produkt fakturowy: niemiecka strona z opłatami Braintree podaje ceny kart i portfeli, bez wiersza dla Ratepay, Klarna nie publikuje żadnego cennika, a stawki podstawowe Unzer to ogólne wartości „od”. Dla drugiej co do wielkości metody na tym rynku porównanie opłat trzeba więc oprzeć na wycenach indywidualnych. Karty odpowiadały za około jedną ósmą tych przychodów. Checkout oparty wyłącznie na kartach traci więc konwersję na rzecz konkurencji, która oferuje preferowane metody, nawet tam, gdzie kupujący mogliby zapłacić kartą.

W Polsce operator BLIK-a zlecił firmie EY raport, który szacuje udział BLIK-a na około połowę wartości polskiej sprzedaży internetowej w 2023 r., licząc łącznie BLIK, karty i przelewy (raport EY dla BLIK-a; dane pochodzą od samego operatora i opierają się na danych banku centralnego). Polski checkout bez BLIK-a rezygnuje z wiodącej na rynku metody płatności online. PayU, Przelewy24 i Comgate obsługują go natywnie. Spośród dostawców międzynarodowych Adyen i Mollie wymieniają BLIK, Braintree dodał go w Magento 2.4.9, a dokumentacja modułu Stripe go pomija. Większość dostawców obsługuje BLIK w jakiejś formie. To, co odróżnia opcje w Polsce, to głębokość obsługi BLIK-a (przekierowanie, wprowadzanie kodu w checkoucie czy wariant jednoklikowy) oraz jakość modułu. Przelewy24 dokumentują najpełniejszą implementację, z zastrzeżeniem wynikającym z ich profilu: moduł Hyvä Checkout jest dostarczany z własnej strony dostawcy i nie pojawia się w żadnym z trackerów Hyvä, więc pierwsza linia wsparcia spoczywa wyłącznie po stronie dostawcy.

W Czechach fala badania konsumenckiego APEK z 2024 r., opublikowana w raporcie Shoptetu Stav české e-commerce, pokazuje karty jako metodę, z której kupujący korzystają najczęściej, na poziomie 42 procent, przy Google i Apple Pay na 23 procentach, płatności za pobraniem na 13 procentach i przelewie bankowym na 12 procentach (strona aktualna, wersja zarchiwizowana, ponieważ aktualna strona jest co roku nadpisywana; udziały pokrywają się z własną serią danych APEK z 2024 r.). Każda bramka międzynarodowa pokrywa karty i portfele. Przyciski bankowe i płatności QR, stojące za częścią udziału przelewów, obsługują GoPay i Comgate, których moduły do Magento są najsłabsze spośród wszystkich dziesięciu. Pytanie w Czechach brzmi więc, czy udział przelewów i płatności za pobraniem w ogóle uzasadnia drugą bramkę: dostawca międzynarodowy do kart plus lokalna bramka do przelewów oznacza drugi moduł przy każdej aktualizacji, drugą rekoncyliację i harmonogram opłat oraz deduplikację metod w checkoucie, ponieważ obie strony oferują karty i portfele. Takie połączenie ma sens tylko wtedy, gdy oszczędności na opłatach za karty przewyższają ten narzut. (Czeskie i słowackie bramki po stronie acquirera, GP webpay, ČSOB, TrustPay, wykraczają poza to zestawienie; pokrycie przycisków bankowych zapewniają GoPay i Comgate). Na Słowacji płatność za pobraniem wciąż stanowi od 25 do 30 procent zamówień, według analizy Upgates, operatora platformy e-commerce, o której poinformowała agencja prasowa TASR w czerwcu 2026 r.. To głównie decyzja dotycząca realizacji dostaw, ale i tak dotyka konfiguracji płatności poprzez rekoncyliację z przewoźnikiem oraz metodę płatności offline, a produkty płatności odroczonej opisane powyżej są odpowiedzią bramek na tę potrzebę. Słowacja rozlicza się w euro, co eliminuje tam argument walutowy za lokalną bramką.

Procedura wygląda więc tak: wypisz metody wymagane przez Twój rynek, zachowaj bramki, lub ich minimalne kombinacje, które łącznie obsługują te metody, odrzuć te niespełniające opisanych wyżej kryteriów modułowych i operacyjnych, i dopiero wtedy porównaj opłaty, łącznie z walutą rozliczeniową, wśród tych, które zostały.

Jeśli wybierasz bramkę w ramach szerszego projektu albo dziedziczysz taką, która blokuje aktualizację, ta ocena wchodzi w zakres naszych usług Magento, a podłączeniem bramki do ERP lub do przepływu subskrypcyjnego zajmuje się nasza usługa integracji.