Ścieżki w panelu administracyjnym potwierdzone dla PrestaShop 1.6, 1.7, 8 i 9.x; opisana niżej siatka ograniczeń Payment → Preferences oraz działanie SCA są aktualne.
Klient w Amsterdamie wypełnia koszyk, przechodzi do etapu płatności i widzi Visa, Mastercard oraz PayPal. Wychodzi. Nie dlatego, że ceny były złe albo dostawa zbyt wolna. Tylko dlatego, że nie ma tam jedynej metody, której naprawdę ufa: iDEAL. Dla holenderskiego kupującego kasa bez iDEAL wygląda tak samo, jak dla Ciebie kasa bez możliwości płatności kartą: ten sklep nie jest tak naprawdę przygotowany dla mnie. Pomnóż to przez każdy rynek, na który wysyłasz zamówienia, a pytanie „jakie metody płatności oferujesz” przestaje być detalem z panelu administracyjnego i staje się jedną z najcichszych, a zarazem najdroższych decyzji konwersyjnych, jakie podejmujesz.
Ten poradnik dotyczy jednej konkretnej rzeczy: czego europejscy klienci oczekują w kasie, kraj po kraju, oraz jak przełożyć to w PrestaShop na właściwy zestaw metod pokazywanych właściwemu kupującemu, z użyciem ustawień w panelu, których większość sprzedawców nigdy świadomie nie konfiguruje. To mapa, a nie instrukcja obsługi pojedynczej bramki płatniczej. Gdy dana metoda lub operator zasługuje na osobne, głębsze omówienie, Stripe kontra PayPal, Mollie, BLIK i pokrewne rozwiązania, kup teraz, zapłać później. Znajdziesz link dokładnie tam, gdzie będzie potrzebny.
Dlaczego „właściwa” metoda jest inna w każdym kraju
Nie istnieje jeden europejski standard płatności. Istnieje mozaika, a każdy jej element ukształtowały lokalna historia bankowości, regulacje i przyzwyczajenia. Niemiecki kupujący dorastał z płatnością za fakturę po otrzymaniu towaru; holenderski kupujący, z potwierdzaniem płatności w aplikacji własnego banku; polski kupujący oczekuje sześciocyfrowego kodu BLIK. Żadna z tych osób nie robi niczego nietypowego. Korzysta z metody, która dla niej jest normalna i bezpieczna. Domyślny zestaw karta plus PayPal wydaje się normalny Tobie.
Koszt tej rozbieżności jest dobrze udokumentowany co do kierunku, nawet jeśli nie da się go zamknąć w jednej wiarygodnej wartości procentowej: istotna część kupujących porzuca zamówienie właśnie dlatego, że brakuje preferowanej metody płatności, a odsetek ten rośnie przy zamówieniach transgranicznych, gdzie niedopasowanie jest wyraźniejsze. Każdą pojedynczą liczbę, którą przeczytasz (także te poniżej), traktuj jako wskazówkę i mierz własne wyniki, na końcu tego wpisu pokazuję, jak to zrobić. Zasada pozostaje prawdziwa niezależnie od dokładnej wartości: na etapie płatności klient już zdecydował się kupić, więc każdy powód do zawahania jest najdroższym rodzajem tarcia, jaki możesz mu podsunąć.
Mapa oczekiwań: co poszczególne rynki chcą zobaczyć
Traktuj to jako brief do targetowania, nie listę zakupów. Nie potrzebujesz każdej metody wszędzie, potrzebujesz jednej lub dwóch lokalnie zaufanych metod na każdym rynku, na którym realnie sprzedajesz, oprócz kart. Tabela daje szybki przegląd; uwagi pod nią zawierają niuanse, które decydują, czy faktycznie spełniasz oczekiwanie, czy tylko odhaczasz pozycję na liście.
| Rynek | Niezbędna metoda lokalna | Również oczekiwane | Pułapka, jeśli ją pominiesz |
|---|---|---|---|
| Niemcy / Austria | Faktura (Kauf auf Rechnung), SEPA Lastschrift | PayPal, karty (drugorzędnie) | Płatność po dostawie to domyślny sygnał zaufania; sklep wyłącznie z kartami wygląda ryzykownie. |
| Holandia | iDEAL | Bancontact (transgranicznie z Belgii), karty (rzadko) | Brak iDEAL oznacza w praktyce „zamknięte” dla holenderskich kupujących. |
| Belgia | Bancontact | iDEAL, PayPal, karty | Kupujący krajowi najpierw sięgają po Bancontact; karty wydają się obce. |
| Francja | Carte Bancaire (CB) | PayPal, raty 3x/4x, Apple/Google Pay | Traktowanie CB jak zwykłej Visa/Mastercard może podnosić odsetek odrzuconych płatności. |
| Polska | BLIK | Przelewy24 / przelew bankowy PayU, płatność za pobraniem | Brak BLIK sygnalizuje: „to nie jest sklep gotowy na polskiego klienta”. |
| Włochy | Karty (Visa/Mastercard) | PayPal, PostePay, płatność za pobraniem, Satispay | Osoby kupujące pierwszy raz w nieznanym sklepie traktują pobranie jako zabezpieczenie. |
| Hiszpania | Karty | Bizum, PayPal, płatność za pobraniem (obszary wiejskie) | Bizum jest dziś standardowym oczekiwaniem w e-commerce, nie ciekawostką. |
| Wielka Brytania | Karty debetowe | PayPal, Apple/Google Pay, Klarna/Clearpay | Kupujący kartą kredytową cenią ochronę Section 75 przy większych zamówieniach. |
| Kraje nordyckie (SE/NO/DK/FI) | Klarna | Swish (SE), Vipps (NO), MobilePay (DK), karty | Klarna to regionalny standard, nie dodatkowa opcja BNPL. |
Ta tabela ukrywa trzy rzeczy, które w praktyce mają znaczenie. Po pierwsze, niemieckie oczekiwanie faktury dotyczy momentu płatności, nie technologii, klient chce zapłacić po otrzymaniu towaru, a Ty możesz to umożliwić bez brania na siebie ryzyka kredytowego, kierując płatność przez dostawcę (Klarna, Billie), który wypłaca Ci środki z góry. Po drugie, francuskie Carte Bancaire to sieć co-badged, a nie marka Visa; bramka, która przetwarza płatność jako CB zamiast wymuszać międzynarodowe ścieżki rozliczeniowe, zwykle notuje mniej odmów. Po trzecie, rynki metod lokalnych nie wybaczają braków, w Holandii i Polsce brak iDEAL albo BLIK nie jest drobną niedogodnością, którą kupujący jakoś obejdzie, tylko ścianą.
Każda z głównych metod lokalnych ma dość głębi, aby zasłużyć na osobne omówienie. Rodzinę przekierowań bankowych z BeNeLuxu i Polski, iDEAL, Bancontact, BLIK, oraz dokładne sytuacje, w których każda z nich otwiera dany rynek, opisujemy we wpisie o lokalnych metodach płatności, które otwierają lokalne rynki. Fala płatności odroczonych (Klarna, Clearpay i reszta) ma własną analizę konwersji w poradniku kup teraz, zapłać później i co to oznacza dla Twojej konwersji. A szersze uzasadnienie różnorodności, dlaczego większy wybór opcji zwykle zwiększa sprzedaż, znajdziesz we wpisie o tym, dlaczego oferowanie większej liczby opcji oznacza większą sprzedaż.
Od „czego oczekują” do „co widzą”: ustawienia PrestaShop
W tym miejscu większość poradników się kończy, a sprzedawcy korzystający z PrestaShop zostają z problemem. Wiedza, że holenderski kupujący chce iDEAL, jest bezużyteczna, jeśli iDEAL pokazuje się także klientowi z Hiszpanii, który nigdy z niego nie skorzysta, zaśmiecając kasę. Tym, co pozwala nad tym zapanować, są wbudowane w PrestaShop ograniczenia metod płatności, i prawie nikt nie konfiguruje ich świadomie.
W nowoczesnym PrestaShop (od 1.7 przez 8 i 9.x) ekran znajduje się w panelu administracyjnym pod ścieżką Payment → Preferences. Strona pokazuje siatkę, w której każdy zainstalowany moduł płatności można włączać lub wyłączać według czterech niezależnych wymiarów:
- Ograniczenia walut, pokazują metodę tylko dla wybranych walut (przydatne, gdy lokalna metoda rozlicza się tylko np. w PLN albo DKK).
- Ograniczenia krajów, to one wykonują tutaj najważniejszą pracę. Możesz ograniczyć iDEAL do Holandii, BLIK do Polski, Bancontact do Belgii, dzięki czemu kasa każdego klienta pokazuje metody, które faktycznie rozpoznaje, i nic, czego nie potrzebuje.
- Ograniczenia grup klientów, np. zaoferuj fakturę lub płatność odroczoną tylko grupie „zweryfikowani” albo B2B, bądź pokaż metodę wyłącznie hurtową resellerom.
- Ograniczenia przewoźników, powiąż metodę z konkretnymi przewoźnikami, aby np. płatność za pobraniem pojawiała się tylko przy kurierze, który faktycznie ją obsługuje.
Wewnętrznie każde zaznaczenie w tej siatce jest zapisywane jako wiersz w tabelach module_country, module_currency, module_group i module_carrier, a kasa w sklepie pyta każdy moduł płatności, przez hook paymentOptions (metoda hookPaymentOptions w klasie modułu, która zastąpiła starszy hook displayPayment z wersji 1.6), co chce zaoferować dla tego koszyka. Siatka ograniczeń jest bramą, która decyduje, czy moduł w ogóle zostanie zapytany. Gdy więc poprawnie ustawisz ograniczenia krajów, nie ukrywasz metod CSS-em ani nie liczysz, że bramka płatnicza sama to uporządkuje, PrestaShop naprawdę nie pokaże ich niewłaściwemu klientowi. Co Ci to daje? Holenderski klient dostaje czystą kasę z iDEAL na pierwszym planie, polski klient dostaje BLIK, a żaden z nich nie widzi nieistotnych opcji drugiego rynku. Dokładnie tak powstaje sygnał „ten sklep jest przygotowany dla mnie”, który przekłada się na konwersję.
Praktyczna kolejność, która pozwala zrobić to dobrze w Twoim sklepie:
- Zainstaluj moduł lub moduły bramki płatniczej, które obsługują docelowe metody (jeden dobry agregator zwykle pokrywa większość Europy, więcej o wyborze poniżej).
- Przejdź do Payment → Preferences i dla każdej metody lokalnej odznacz wszystkie kraje oprócz tego lub tych, do których dana metoda należy. Karty i PayPal zostaw dostępne wszędzie.
- Jeśli prowadzisz sprzedaż B2B, użyj kolumny grup, aby ograniczyć faktury lub płatności odroczone do tych grup klientów, którym faktycznie chcesz udzielać warunków płatności.
- Kolejność w kasie ma znaczenie, lokalnie właściwa metoda powinna być wysoko. Większość modułów bramek pozwala ustawić pozycję wyświetlania; przy kolejności opartej na hookach możesz przenieść albo uporządkować moduł w Design → Positions, choć wiele bramek ma też własne ustawienie pozycji lub kolejności w konfiguracji modułu.
Jeden moduł czy wiele? Jak dostarczyć właściwe metody
Ogólnie masz trzy sposoby uruchomienia tych metod, a każdy z nich inaczej równoważy zasięg i kontrolę:
| Podejście | Na czym polega | Najlepsze, gdy… | Uważaj na |
|---|---|---|---|
| Jedna bramka agregująca | Pojedynczy moduł (np. Mollie, Stripe, Adyen), który udostępnia wiele metod przez jedną integrację | Sprzedajesz w kilku krajach i chcesz mieć jeden zestaw opłat, jedno uzgadnianie płatności i jedną aktualizację do utrzymania. | Zakres metod różni się między agregatorami; upewnij się, że Twoje obowiązkowe metody są faktycznie dostępne. |
| Bezpośrednie moduły metod | Dedykowany moduł dla każdej metody lub dostawcy (PayPal, krajowy moduł BLIK/Przelewy24, Klarna) | Jeden rynek odpowiada za większość przychodów i chcesz dla niego najgłębszej, najkorzystniej wycenionej integracji. | Więcej modułów do instalowania, aktualizowania i utrzymywania w zgodności przy aktualizacjach PrestaShop. |
| Model mieszany | Agregator dla szerokiego pokrycia plus jeden lub dwa moduły bezpośrednie dla kluczowego rynku macierzystego | Masz silny rynek krajowy i rosnący eksport. | Dwie siatki pozycji płatności do utrzymania w porządku, aby metody nie dublowały się ani nie kolidowały w kasie. |
W większości europejskich sklepów na co dzień wygrywa ścieżka agregatora, bo alternatywą jest utrzymywanie kilku modułów bramek przy każdej aktualizacji PrestaShop i PHP. Moduł Mollie dla PrestaShop to podręcznikowy przykład, jedna integracja obsługująca iDEAL, Bancontact, SEPA, karty i Klarnę, i omawiamy ją w osobnym poradniku. Jeśli Twój priorytet przesuwa się w stronę kart i globalnego zasięgu, poradnik integracji Stripe prowadzi przez całą konfigurację od początku do końca, a porównanie, nad którym większość sprzedawców naprawdę się zastanawia, rozstrzygamy we wpisie Stripe kontra PayPal. Jeśli Twoim rynkiem jest Polska, bezpośrednią ścieżką jest dedykowany poradnik konfiguracji Przelewy24. A jeśli przed decyzją chcesz po prostu zobaczyć zestawienie opcji obok siebie, zacznij od naszego pełnego porównania najlepszych modułów płatności dla PrestaShop.
Warstwa zgodności, której nie możesz pominąć: SCA / 3-D Secure
Niezależnie od wybranych metod europejskie płatności kartą podlegają zasadom silnego uwierzytelniania klienta PSD2, w praktyce 3-D Secure, czyli etapowi, w którym kupujący potwierdza płatność w aplikacji bankowej. To nie jest opcjonalne i nie jest czymś, co doklejasz samodzielnie; przepływ uwierzytelniania obsługuje za Ciebie bramka płatnicza. Z perspektywy sprzedawcy, a nie programisty, warto zwrócić uwagę na dwie rzeczy:
- Korzystaj z bramki obsługującej 3-D Secure 2.x. Nowsza wersja uwierzytelnia wiele płatności niskiego ryzyka cicho w tle, zamiast przerzucać każdego klienta do topornego przekierowania, to wyraźnie mniejsze tarcie w kasie. Jeśli bramka nadal mocno opiera się na starym, pełnym przekierowań przepływie 3DS1, to dobry powód, aby rozejrzeć się za inną.
- Wyłączenia istnieją, ale to zadanie bramki. Transakcje o niskiej wartości, wybrane płatności cykliczne i przepływy niskiego ryzyka mogą ominąć dodatkowe potwierdzenie; nie kodujesz tego ręcznie, chcesz po prostu operatora, który inteligentnie stosuje wyłączenia, aby zaufani, powracający klienci nie byli niepotrzebnie zatrzymywani.
Wniosek dla tego wpisu jest prosty: SCA jest stałym elementem na każdym rynku, więc nie zmienia tego, jakie metody oferujesz, ale bramka, która obsługuje je płynnie, chroni wzrost konwersji uzyskany dzięki zaoferowaniu właściwych metod.
Jak prezentować metody, żeby klient wybrał właściwą
Spełnienie oczekiwania to połowa zadania; druga połowa to sprawić, aby oczekiwana metoda była oczywista. Holenderski kupujący, który musi przewinąć cztery nieistotne opcje, żeby znaleźć iDEAL, nadal płaci podatek od tarcia, który można było usunąć. Kilka decyzji konsekwentnie robi różnicę:
- Ustawiaj kolejność według lokalnej trafności, nie własnej wygody. Skoro PrestaShop pozwala już ograniczać metody według kraju, kupujący najlepiej powinien widzieć krótką, trafną listę, a w niej dominującą na swoim rynku metodę jako pierwszą.
- Pokazuj metody przed kasą. Logotypy płatności w stopce i na stronach produktów są sygnałem zaufania, który uspokaja kupującego na długo przed finalizacją; znajoma plakietka iDEAL albo Bancontact widoczna wcześnie zmniejsza wahanie typu „czy ten sklep zadziała dla mnie?”.
- Pokazuj płatność odroczoną razem z kwotą. „Zapłać w 3 ratach po €33.33” konwertuje lepiej niż sam logotyp Klarny, to liczba przekonuje. (Pełne uzasadnienie konwersyjne BNPL znajdziesz w poradniku kup teraz, zapłać później.)
- Utrzymaj płatność w tym samym przepływie. Osadzone pola płatności konwertują lepiej niż gwałtowne przekierowanie na zewnętrzną stronę. Dokładnie tutaj spotykają się układ kasy i prezentacja płatności, nasz moduł Checkout Revolution utrzymuje cały proces, włącznie z osadzoną płatnością, na jednej stronie, dzięki czemu powracający klient nie traci rozpędu między wyborem metody a potwierdzeniem.
Jak zmierzyć, czy konfiguracja działa
Nie zmieniaj zestawu płatności na wyczucie i nie oceniaj go po jednym długim weekendzie danych. Zanim dodasz lokalną metodę danego rynku, zapisz trzy liczby, w podziale na kraje, jeśli analityka na to pozwala: współczynnik porzuceń kasy (kupujący, którzy dochodzą do płatności, ale nie kończą zamówienia), konkretny odpływ na etapie płatności oraz współczynnik konwersji dla ruchu z tego kraju. Dodaj metodę, skonfiguruj jej ograniczenie krajowe w Payment → Preferences, aby pokazywała się tylko tam, gdzie powinna, a następnie porównaj te same liczby przez co najmniej 30 dni i kilka setek zamówień z danego rynku, to wystarczający wolumen, aby zobaczyć realny trend, a nie tygodniowy szum, który kusi sprzedawców do cofania zmiany, która w rzeczywistości działała.
Szukasz konkretnego wzorca: spadku porzuceń na rynku, w który celowałeś, przy stabilnych wynikach reszty sklepu. To podpis realnie spełnionego oczekiwania, a nie ogólnego wzrostu, który i tak by się wydarzył.
Etap płatności to najbardziej „zdecydowana” strona w Twoim sklepie, każdy kupujący, który do niej dociera, już wybrał zakup, a Twoim jedynym zadaniem jest nie dać mu powodu, by się zatrzymał. W Europie oznacza to akceptację faktu, że odpowiedź na pytanie „czego oczekują Twoi klienci” jest inna w Amsterdamie, Monachium, Warszawie i Madrycie, a następnie użycie własnych ograniczeń krajowych PrestaShop, aby każdemu z nich pokazać krótką, znajomą listę, której oczekiwał. Ułóż mapę poprawnie, skonfiguruj bramę, a szczegóły poszczególnych metod zostaw głębszym poradnikom.
Najczęściej zadawane pytania
Jak pokazać iDEAL tylko klientom z Holandii, a BLIK tylko klientom z Polski?
Użyj kolumny krajów w Payment → Preferences. Dla każdej metody lokalnej odznacz wszystkie kraje oprócz tego lub tych, do których metoda należy, iDEAL dla Holandii, BLIK dla Polski, Bancontact dla Belgii, a karty i PayPal zostaw zaznaczone wszędzie. PrestaShop naprawdę nie zaoferuje wtedy tej metody niewłaściwemu klientowi; to brama po stronie serwera, a nie ukrywanie CSS-em, więc klient z Hiszpanii nawet nie zobaczy iDEAL.
Czy dodanie lokalnej metody dla jednego kraju spowolni albo zaśmieci kasę wszystkim pozostałym?
Nie, jeśli ustawisz ograniczenie krajowe. Siatka ograniczeń sprawia, że etap płatności każdego klienta renderuje tylko metody, które przejdą bramę dla jego koszyka, więc dodanie BLIK dla Polski nie dokłada logotypu do kasy kupującego z Niemiec. Na tym polega sens tej siatki, oferujesz szeroki zakres metod na poziomie sklepu, a każdy pojedynczy klient widzi krótką, trafną listę.
Czy muszę samodzielnie obsługiwać SCA / 3-D Secure?
Nie. Silne uwierzytelnianie klienta w ramach PSD2 to zadanie bramki płatniczej, to ona uruchamia przepływ 3-D Secure, w którym kupujący potwierdza płatność w aplikacji bankowej. Nie kodujesz tego. Twoim zadaniem jest wybrać bramkę działającą na 3-D Secure 2.x, która uwierzytelnia płatności niskiego ryzyka cicho w tle zamiast przerzucać każdego klienta do topornego przekierowania, oraz stosuje dostępne wyłączenia, aby powracający klienci nie byli niepotrzebnie zatrzymywani.
Czy warto oferować płatność za pobraniem na rynkach takich jak Włochy?
Może warto, zwłaszcza dla osób kupujących po raz pierwszy w nieznanym sklepie, gdzie pobranie działa jak siatka bezpieczeństwa. Włochy są tu najczytelniejszym przykładem. PrestaShop dostarcza opcję płatności za pobraniem, którą możesz ograniczyć według kraju i przewoźnika, więc możesz oferować ją tylko tam, gdzie na siebie zarabia, i tylko z kurierami, którzy faktycznie ją obsługują, korzystając z kolumny przewoźników w Payment → Preferences.
Jak długo czekać, zanim ocenię, czy nowa metoda pomogła?
Co najmniej 30 dni i kilka setek zamówień z docelowego rynku, ocenianych na liczbach segmentowanych według kraju, porzuceniach kasy i współczynniku konwersji z tego kraju, a nie na średniej dla całego sklepu. Sygnał sukcesu jest konkretny: porzucenia spadają na rynku, w który celowałeś, a reszta sklepu pozostaje stabilna. Krótsze okna pokazują tylko szum z tygodnia na tydzień, który kusi sprzedawców do cofania zmiany, która w rzeczywistości działała.
