---
title: "Jak wybrać bramkę płatniczą dla Magento 2"
description: "Ramy decyzyjne dla bramek płatniczych na Magento 2, Adobe Commerce i Mage-OS: utrzymanie modułu, zachowanie przy aktualizacjach, wsparcie Hyvä i headless oraz lokalne metody płatności, które na każdym rynku przesądzają o krótkiej liście."
author: "Luboš Zápotočný"
published: "2026-08-02"
language: "pl"
canonical: "https://zapolu.com/pl/blog/bramka-platnicza-dla-magento/"
---

# 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](https://developer.adobe.com/commerce/php/development/payments-integrations/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](https://gitlab.hyva.io/hyva-public/module-tracker)
dla motywu oraz osobny
[tracker integracji](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker)
dla Hyvä Checkout, a jego dokumentacja
[wymienia główne śledzone integracje płatności](https://docs.hyva.io/hyva-checkout/integrations/available-payment-methods.html).
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`](https://developer.adobe.com/commerce/webapi/graphql/schema/cart/mutations/set-payment-method)
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](https://listings.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf)
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](https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/how-does-an-e-commerce-merchant-meet-the-saq-a-eligibility-criteria-for-scripts/)
(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](https://docs.adyen.com/account/supported-currencies)
dla sprzedawców z UE, w tym CZK i PLN,
[Mollie wymienia 13 walut wypłat](https://help.mollie.com/hc/en-us/articles/5546871220370-What-are-multi-currency-payouts),
[PayU rozlicza się 1:1 w 11 walutach](https://developers.payu.com/europe/docs/get-started/integration-overview/references/),
a
[GoPay dokumentuje waluty wypłat w podziale na banki](https://help.gopay.com/cs/tema/mam-platebni-branu/chci-pouzivat-gopay-obchodni-ucet/chci-prijimat-platby-v-dalsich-menach/v-jakych-menach-mohu-prijimat-platby-u-ceskych-a-slovenskych-bank).
[Comgate publikuje warunki wypłat dla poszczególnych walut](https://help.comgate.cz/docs/vyplaceni-penez-na-ucet),
a
[Braintree publikuje listę walut schematu](https://developer.paypal.com/braintree/docs/reference/general/currencies),
przy czym zestaw walut dla każdego sprzedawcy ustala się przy
onboardingu i rozszerza poprzez
[wnioskowanie o dodatkowe konta handlowe](https://developer.paypal.com/braintree/articles/get-started/currencies).
[Klarna wypłaca w walucie transakcji](https://docs.klarna.com/acquirer/klarna/web-payments/additional-resources/use-cases/consumer-fx/).
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](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-4)).
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](https://github.com/magento/magento2/issues/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](https://github.com/magento/magento2/issues/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.](http://web.archive.org/web/20250520080628/https://commercemarketplace.adobe.com/klarna-m2-klarna.html),
a poprawioną linię pokazują po raz pierwszy
[13 czerwca](http://web.archive.org/web/20250613064417/https://commercemarketplace.adobe.com/klarna-m2-klarna.html),
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](https://mage-os.org/releases/2026-03-18-mage-os-2-2-1-release/)
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](https://mage-os.org/faq/) 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ä](/pl/blog/hyva-vs-luma/) 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](https://docs.hyva.io/hyva-themes/building-your-theme/luma-theme-fallback.html),
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](https://docs.hyva.io/hyva-checkout/devdocs/payments/payment-in-hyva-checkout.html)
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](https://github.com/adyen-examples/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](https://github.com/adyen-examples/adyen-magento2-hyva/issues/140)).
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](https://github.com/Adyen/adyen-magento2)
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](https://docs.adyen.com/plugins/adobe-commerce)
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](https://github.com/Adyen/adyen-magento2/releases/tag/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](https://docs.adyen.com/plugins/adobe-commerce/headless-integration/),
a pokrycie metod płatności w UE
[obejmuje iDEAL, polecenie zapłaty SEPA, BLIK, Twint i Bancontact](https://docs.adyen.com/plugins/adobe-commerce/supported-payment-methods/),
przy czym karty renderowane są jako komponenty osadzone wewnątrz
checkoutu. Cennik jest
[publikowany w modelu interchange++](https://www.adyen.com/pricing)
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ł](https://github.com/stripe/stripe-magento2-releases)
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](https://docs.stripe.com/use-stripe-apps/adobe-commerce/payments/install)),
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](https://docs.stripe.com/use-stripe-apps/adobe-commerce/payments/custom-storefront).
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](https://github.com/stripe/stripe-magento2-releases/blob/master/CHANGELOG.md):
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](https://docs.stripe.com/connectors/adobe-commerce/payments),
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](https://stripe.com/en-cz/pricing).

**Mollie** to najsilniejsze połączenie otwartości i zgodności z
Hyvä. [Moduł](https://github.com/mollie/magento2) 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ä](https://github.com/mollie/magento2-hyva-compatibility)
oraz moduły zgodności z
[Hyvä Checkout](https://github.com/mollie/magento2-hyva-checkout),
ogłosiła
[strategiczne partnerstwo](https://www.hyva.io/blog/news/hyva-commerce-mollie-partnership.html)
z Hyvä w październiku 2024 r. i wspiera finansowo Mage-OS na
[Open Collective](https://opencollective.com/mage-os), choć nie
deklaruje żadnego technicznego wsparcia Mage-OS.
[Wydanie v3.0.0](https://github.com/mollie/magento2/releases/tag/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](https://www.mollie.com/pricing) 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](https://github.com/genecommerce/module-braintree-magento2)
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](https://github.com/magento/magento2/issues/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](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-9)),
podczas gdy
[strona Braintree w dokumentacji Adobe](https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/braintree)
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](https://developer.adobe.com/commerce/webapi/graphql/payment-methods/braintree-vault).
PayPal publikuje cennik Braintree dla poszczególnych krajów:
[niemiecka strona z opłatami](https://www.paypal.com/de/enterprise/paypal-braintree-fees)
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](https://www.paypal.com/cz/enterprise/paypal-braintree-fees)
i [polska](https://www.paypal.com/pl/enterprise/paypal-braintree-fees),
choć bez stawki dla metody fakturowej Ratepay. Starsze metody
Payflow w module rdzeniowym są
[oznaczone przez PayPal jako przestarzałe](https://developer.paypal.com/api/nvp-soap/)
i dostępne wyłącznie w Stanach Zjednoczonych, Kanadzie, Australii i
Nowej Zelandii, zgodnie ze
[stroną Payflow Pro w dokumentacji Adobe](https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/paypal/paypal-payflow-pro),
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](https://docs.klarna.com/klarna-payments/in-depth-knowledge/puchase-countries-currencies-locales/)
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](https://commercemarketplace.adobe.com/klarna-m2-klarna.html)
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](https://docs.klarna.com/platform/adobe-commerce/payments/klarna-payments-module/)
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](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/12)
oznacza ją jako utrzymywaną przez społeczność. Tempo wydań w 2026 r.
było szybkie: od 4.1.1 w styczniu
([zarchiwizowany listing](http://web.archive.org/web/20260215102634/https://commercemarketplace.adobe.com/klarna-m2-klarna.html))
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](https://docs.unzer.com/payment-methods/)
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](https://github.com/unzerdev/magento2) 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](https://docs.unzer.com/plugins/magento-2/magento2-install-plugin/),
2.4.6 do 2.4.8 na
[stronie przeglądu wtyczki](https://docs.unzer.com/plugins/magento-2/)).
Jego trzy repozytoria Hyvä
([magento2-hyva-checkout](https://github.com/unzerdev/magento2-hyva-checkout)
i pokrewne) nie mają żadnych tagów ani wydań i ostatni push miały w
grudniu 2025 r., choć
[dokumentacja](https://docs.unzer.com/plugins/magento-2-hyva-checkout/)
podaje wydanie wtyczki Hyvä Checkout 1.0.0 w lutym 2026 r. Unzer
[publikuje stawki podstawowe](https://www.unzer.com/en/pricing-information/)
(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](https://www.gopay.com/cs/platebni-brana/) jedna z
największych bramek czeskich i słowackich, sam nie utrzymuje modułu
do Magento. Jej
[strona integracji](https://www.gopay.com/en/integration/) wymienia
własne moduły dla Shoptet, WooCommerce, Shopify, OpenCart i
PrestaShop. Dla Magento
[centrum pomocy](https://help.gopay.com/en/knowledge-base/integration-of-payment-gateway/essential-guide-to-integration)
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](https://maghos.com/gopay-payment-for-magento-2.html) 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](https://web.archive.org/web/20211203/https://connect20.aveo-trade.cz/details=1/extension=atconnect/magento-two-gopay)
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](https://www.gopay.com/en/payment-methods/))
przy [publikowanym cenniku](https://www.gopay.com/en/pricing/),
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](https://help.comgate.cz/docs/open-source-reseni),
dostępne moduły są płatne i zamknięte, jedynym publicznym
repozytorium jest [nieoficjalne](https://github.com/ppexxi/comgate_magento2),
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](https://www.comgate.eu/cs/platebni-brana) 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](https://www.comgate.eu/cs/cenik-platebni-brany) 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](https://github.com/PayU-EMEA/plugin_magento_24),
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](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/work_items/553),
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](https://developers.payu.com/europe/docs/payment-solutions/blik/)
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](https://poland.payu.com/en/pricing/).

**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](https://commercemarketplace.adobe.com/przelewy24-magento2-przelewy24.html)
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](https://www.przelewy24.pl/en/download).
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](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/549),
[PayPo](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/550)),
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](https://www.przelewy24.pl/bramka-platnicza).

## 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](https://www.ehi.org/presse/paypal-festigt-spitzenposition/)).
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](https://www.blik.com/media/2025_03_12_EY_BLIK_payments_and_economy_report.pdf);
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](https://www.ceska-ecommerce.cz/),
[wersja zarchiwizowana](http://web.archive.org/web/20250401235543/https://www.ceska-ecommerce.cz/),
ponieważ aktualna strona jest co roku nadpisywana; udziały pokrywają
się z [własną serią danych APEK z 2024 r.](https://data.apek.cz/)).
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.](https://www.teraz.sk/ekonomika/dobierky-predstavuju-pre-e-shopy-najna/973629-clanok.html).
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](/pl/services/magento/), a podłączeniem bramki do
ERP lub do przepływu subskrypcyjnego zajmuje się nasza
[usługa integracji](/pl/services/integrations/).