Moduł PayPal w PrestaShop instaluje się w kilkanaście minut, ale źle zaplanowane wdrożenie potrafi kosztować tygodnie ręcznego porządkowania zamówień. Największe problemy nie leżą w samym module, a w decyzjach wokół niego: mapowaniu statusów, walutach, webhookach, fakturach i testach przed live. Poniżej zbieramy część organizacyjną: typowe błędy, checklistę wdrożenia i pytania, które najczęściej dostajemy od klientów. Samą instalację i konfigurację API opisujemy osobno w artykule PayPal w PrestaShop: szybka konfiguracja krok po kroku. Jeśli dopiero wybierasz platformę, porównaj też PrestaShop i WooCommerce.
Moduł płatności w PrestaShop to wtyczka leżąca w katalogu /modules/, której główna klasa dziedziczy po PaymentModule. Sam przycisk „Zapłać” to tylko wierzchołek — moduł rejestruje się na hookach. W PrestaShop 1.7 i 8 najważniejszy jest paymentOptions (zwraca listę metod na stronie zamówienia), obok niego displayPaymentReturn, actionOrderStatusUpdate oraz hooki koszyka. Właśnie tam rozstrzyga się, czy po powrocie klienta z PayPala zamówienie dostanie właściwy status, czy zostanie w „Oczekiwaniu na płatność”, mimo że pieniądze są już na koncie. Mechanikę hooków opisuje dokumentacja dla deweloperów PrestaShop.
Trzy warianty, które najczęściej się rozważa:
Kiedy PayPal ma sens: sprzedaż B2C, klienci zagraniczni (Niemcy, Francja, Włochy, Hiszpania, USA), osoby bez karty płatniczej lub niechętne podawaniu jej mało znanemu sklepowi, zakupy mobilne i pierwsze zamówienie u nowego sprzedawcy — PayPal daje kupującemu ochronę, co realnie podnosi konwersję. Kiedy sensu nie ma: B2B z odroczonym terminem płatności, zamówienia na fakturę pro forma, sklep wyłącznie krajowy, gdzie 80% klientów i tak płaci BLIK-iem.
Wymagania wstępne: konto PayPal Business (Personal nie da dostępu do REST API, Client ID/Secret ani webhooków), certyfikat SSL na całym sklepie, włączone waluty w „Międzynarodowe > Waluty” i poprawnie ustawione strefy oraz kraje. Bez tego klient zagraniczny wróci z błędu, mimo że moduł będzie „zainstalowany”. Samą instalację i konfigurację API opisujemy osobno w PayPal w PrestaShop: szybka konfiguracja krok po kroku.
Zacznij od pięciu kryteriów: koszt samego modułu (jednorazowy czy abonament), prowizje transakcyjne, tempo aktualizacji, wsparcie po polsku i zgodność z PHP 8. W PrestaShop 8 sklepy najczęściej stoją na PHP 8.0/8.1, a moduły pisane pod PHP 5.6–7.0 potrafią wywalać błędy typu fatal w momencie składania zamówienia. To nie jest scenariusz teoretyczny — trafia do nas kilka takich sklepów w roku.
Drugi zestaw kryteriów dotyczy funkcji: obsługa kart obok PayPala, subskrypcje i płatności cykliczne, 3DS/SCA wymuszane przez PSD2 dla kart w UE, webhooks oraz zwroty i zwroty częściowe (refundy robisz w panelu PrestaShop czy w panelu operatora?).
Dwie pułapki, które kosztują najwięcej:
Rekomendacja dla MŚP w Polsce: jeśli potrzebujesz PayPala i kart w jednym module, wybierz PrestaShop Checkout. Jeśli PayPal ma być uzupełnieniem, a klienci krajowi płacą BLIK-iem i przelewem, dodaj Przelewy24 lub tpay i nie dubluj kosztów. Stripe rozważ, gdy sprzedajesz szeroko poza UE i chcesz kart w wielu walutach. Braintree — gdy planujesz subskrypcje. Moduły z listy PrestaShop marketplace sprawdzaj pod kątem daty ostatniej aktualizacji i wspieranych wersji PHP.
| Rozwiązanie | Metody | Subskrypcje i autoryzacja | 3DS/SCA | Wsparcie po polsku | Ryzyko porzucenia |
|---|---|---|---|---|---|
| PrestaShop Checkout (oficjalny) | PayPal i karty, zakres zależny od kraju konta | zależnie od konfiguracji konta | obsługiwane w module | przez PrestaShop i partnerów | niskie – rozwijany razem z PrestaShop |
| Oficjalny moduł PayPal (REST API) | tylko PayPal | autoryzacja i capture w ustawieniach modułu | obsługiwane | ograniczone, materiały głównie EN | średnie – tempo aktualizacji zależy od wydania |
| PayPal Braintree | karty i PayPal | tak, płatności cykliczne | obsługiwane | ograniczone | średnie |
| Stripe | karty, portfele, metody lokalne | tak | obsługiwane | częściowo, przez partnerów | niskie |
| Przelewy24 | przelewy, BLIK, karty | nie | obsługiwane | tak | niskie |
| tpay | przelewy, BLIK, karty | nie | obsługiwane | tak | niskie |
Krok 1: backup. Zanim cokolwiek wgrasz, zrób eksport bazy (mysqldump albo eksport w phpMyAdmin) i kopię katalogu sklepu przez FTP/SFTP. Backup, który powstał po instalacji, jest bezwartościowy.
Krok 2: instalacja. Zaplecze > Menedżer modułów > szukaj „PayPal” albo „Wyślij moduł” z plikiem ZIP. Jeśli ZIP się nie wgrywa, sprawdź limity upload_max_filesize i max_execution_time w PHP — alternatywnie wrzuć katalog modułu przez FTP do /modules/ i zainstaluj z panelu. Instalację rób w oknie serwisowym, nie w środku dnia handlowego.
Krok 3: API. W panelu deweloperskim PayPal utwórz aplikację REST i skopiuj Client ID oraz Secret. Najpierw tryb sandbox, produkcyjne klucze wgrywasz dopiero po testach. Nie mieszaj kluczy sandbox z live — to najczęstsza przyczyna „moduł działa, ale płatności nie księgują się”.
Krok 4: ustawienia zaawansowane. Wybierz model płatności: capture (pobranie środków od razu) albo authorize (blokada środków i ręczne pobranie później — autoryzacja ma ograniczony czas ważności, sprawdź aktualne warunki na swoim koncie). 3DS/SCA zostaw włączone, tego wymaga PSD2 przy kartach w UE. Upewnij się, że waluty włączone w sklepie pokrywają się z walutami konta, a webhook ma zarejestrowany poprawny adres.
Krok 5: test. Utwórz konto testowe Business i Personal w sandboxie, złóż zamówienie, sprawdź status, e-mail do klienta, fakturę i zdjęcie stanu magazynowego. Potem przetestuj zwrot i anulowanie.
Pułapka: zamówienia zostające w „Oczekiwaniu na płatność” prawie zawsze oznaczają niedostarczony webhook. Nie zmieniaj statusów ręcznie, zanim nie sprawdzisz logów modułu i historii transakcji w PayPal — inaczej rozjedzie się księgowość. Jeśli wdrożenie obejmuje też inne integracje, zobacz, jak podchodzimy do tego w ramach organizacji wdrożenia sklepu PrestaShop.
Sandbox to nie formalność, którą można pominąć. W panelu deweloperskim PayPal utwórz dwa konta testowe: Business (rola sprzedawcy) i Personal (rola kupującego). Do konta Business dodaj aplikację REST i wygeneruj Client ID oraz Secret — te wartości wklejasz potem do modułu zamiast danych produkcyjnych. Sandbox nie obsługuje adresów lokalnych: PayPal musi móc odpytać Twój sklep, więc testuj na kopii na subdomenie z HTTPS (np. test.twojsklep.pl), zamkniętej hasłem i z wyłączoną indeksacją.
Drugi krok to powiadomienia zwrotne. W aplikacji REST wskaż adres webhooka — dokładną ścieżkę znajdziesz w plikach swojego modułu, nie zgaduj jej — i przetestuj wysyłką zdarzenia testowego z panelu. Sprawdź, czy wpis pojawia się w logu modułu i czy podpis zdarzenia jest weryfikowany. Starsze integracje korzystają z IPN: jeśli moduł go używa, włącz IPN w ustawieniach konta, ustaw URL zwrotny i pamiętaj, że IPN działa niezależnie od tego, czy klient wróci do sklepu.
Zasada organizacyjna numer jeden: status zamówienia zmienia wyłącznie zweryfikowany webhook lub IPN, a nie powrót klienta na stronę sklepu. Jeśli moduł opiera się na return URL, zamówienia będą wisieć w „Oczekiwanie na płatność”, gdy ktoś zamknie kartę przeglądarki przed przekierowaniem.
Częściowe zwroty to najczęstsza luka. Większość modułów obsługuje pełny refund, a zwrot częściowy wykonany w panelu PayPal nie zmieni statusu w sklepie — pozostaje korekta faktury i ręczne oznaczenie zamówienia. Ustal z księgowością, kto to robi i na jakim dokumencie.
Osobno przelicz waluty i kwoty. Jeśli sklep działa w PLN, ustaw w konfiguracji płatności walutę sklepu, żeby uniknąć różnic kursowych przy księgowaniu. Dopuszczenie płatności w walucie kupującego wymaga włączonej waluty w PrestaShop i sprawdzenia, czy moduł nie wymusza PLN w koszyku. Samą instalację i konfigurację API PayPal w PrestaShop krok po kroku opisujemy w osobnym materiale.
| Status w PayPal | Co oznacza | Status w PrestaShop i działanie |
|---|---|---|
| pending | Płatność zainicjowana, np. eCheque albo weryfikacja po stronie banku | Oczekiwanie na płatność — nie wystawiaj faktury, nie wysyłaj towaru |
| completed | Środki zaksięgowane na koncie | Płatność zaakceptowana — dopiero tu faktura i zmiana stanu magazynowego |
| refunded | Pełny zwrot środków | Zwrot — korekta faktury, informacja do magazynu |
| reversed | PayPal cofnął transakcję (chargeback, reklamacja) | Zwrot — blokada realizacji, komplet dokumentów dla księgowości |
| denied / expired / canceled | Płatność nie doszła do skutku | Anulowane — zwolnij rezerwację magazynu, nie wysyłaj ponagleń |
Kody błędów z API wracają w logach modułu, ale ich znaczenie bywa mylące. 10001 to nieprawidłowe żądanie — najczęściej błąd w polach adresowych, niezgodna waluta albo wygasłe dane aplikacji; sprawdź, czy sklep nie wysyła waluty, której nie ma na koncie PayPal. 10486 oznacza, że bank odrzucił płatność (brak środków, blokada, nieudane uwierzytelnienie) — nie ponawiaj takiej transakcji automatycznie. 10413 to niezgodność kwoty koszyka z kwotą przekazaną do PayPal: typowy powód to rabat, zmiana kosztu dostawy albo podatek doliczony po utworzeniu sesji płatności. 10417 mówi, że kupujący nie może zapłacić wybraną metodą — zwykle ma saldo zero i nie dodał karty.
Brak przycisku PayPal w koszyku diagnozuj w tej kolejności: moduł wyłączony lub bez Client ID i Secret; moduł przypisany do strefy, której klient nie spełnia; waluta zamówienia nieobsługiwana przez moduł (klasyka przy sklepie w PLN, gdy zostawiono tylko EUR); brak podpięcia do hooków displayPayment i displayPaymentReturn w motywie; cache — wyczyść cache PrestaShop, cache szablonów i CDN. Listę hooków i ich działanie opisuje dokumentacja deweloperska PrestaShop.
Duplikaty zamówień biorą się z dwóch webhooków dla tej samej transakcji albo z braku sprawdzenia transaction_id przed zmianą statusu. Minimum to weryfikacja kwoty, waluty i identyfikatora transakcji, zanim moduł cokolwiek zapisze.
Logi czytaj w dwóch miejscach: w PrestaShop w Zaawansowane → Logi (tabela ps_log) i w plikach w katalogu var/logs, a po stronie PayPal w historii aktywności konta. Tryb debug w module włączaj tylko na kopii sklepu, z aktualną kopią bazy i na koncie sandbox. Po testach wyłącz debug, usuń pliki logów i sprawdź, czy nie zawierają danych osobowych klientów. Większość tych błędów to skutek pośpiechu w planowaniu, nie wada platformy — jeśli dopiero porównujesz systemy, zobacz PrestaShop czy WooCommerce – przewodnik dla początkujących.
| Kod | Znaczenie | Co zrobić w sklepie |
|---|---|---|
| 10001 | Nieprawidłowe żądanie: błędne dane, waluta lub parametry aplikacji | Sprawdź Client ID, walutę zamówienia i kompletność pól adresowych w logu |
| 10486 | Bank odrzucił płatność lub nie udało się uwierzytelnienie | Poproś klienta o inną metodę; nie ponawiaj transakcji automatycznie |
| 10413 | Kwota koszyka nie zgadza się z kwotą transakcji | Porównaj sumę produktów, dostawy i rabatów po obu stronach |
| 10417 | Kupujący nie może zapłacić tą metodą | Pokaż alternatywne metody płatności, nie blokuj koszyka |
PayPal jest odrębnym administratorem danych swoich użytkowników, ale dane, które do niego trafiają z Twojego sklepu, przetwarzasz również Ty. W praktyce: podpisz umowę powierzenia przetwarzania danych (DPA) — PayPal udostępnia standardowy dokument do akceptacji w panelu konta. W polityce prywatności wskaż PayPal jako odbiorcę danych, wymień zakres (imię i nazwisko, adres, e-mail, IP, kwota i identyfikator transakcji) oraz informację o transferze poza EOG i podstawie prawnej, czyli standardowych klauzulach umownych.
PCI DSS: gdy płatność idzie przez przekierowanie lub ramkę do PayPal, dane karty nigdy nie przechodzą przez serwer sklepu — to zakres SAQ A, najkrótszy z kwestionariuszy. Warunek: nie logujesz i nie przechowujesz numerów kart, a integracja faktycznie działa w modelu hostowanym. Jeśli dane karty przechodzą przez formularz na Twojej domenie, wchodzisz w znacznie cięższy zakres i realny audyt.
PSD2 i silne uwierzytelnianie klienta (SCA) to warunek po stronie PayPal, nie ustawienie w PrestaShop. Wyjątki są liczone w EUR, nie w PLN: transakcje poniżej progu niższego, seria kolejnych płatności do progu sumarycznego oraz odbiorcy z listy zaufanych, których klient sam dodaje w swoim koncie PayPal. W polskim sklepie większość typowych koszyków i tak trafi na dodatkowy krok 3DS, co zwiększa porzucenia — testuj to na sandboxie i licz konwersję osobno dla PayPal.
Faktury VAT wystawiaj po statusie completed i na dane z formularza sklepu, nie z PayPal — przy płatności firmowej dane bywają inne, a NIP zwykle nie wraca w transakcji. Płatność w walucie obcej przeliczaj kursem z dnia poprzedzającego, a prowizję PayPal księguj jako koszt. Przy chargebacku pamiętaj, że spór można otworzyć przez 180 dni od transakcji, a opłatę za jego rozpatrzenie znajdziesz w cenniku swojego konta. Dowody to potwierdzenie dostawy, logi IP i korespondencja z klientem.
Checklista ma sens tylko wtedy, gdy przechodzisz ją na środowisku testowym, a nie po pierwszym prawdziwym zamówieniu.
Testy robisz w dwóch wymiarach: metody i urządzenia. Sandbox: płatność z konta PayPal, karta bez konta, anulowanie, powrót do sklepu, płatność oczekująca. Potem produkcja na kwocie 1 zł. Mobile to nie formalność — iOS Safari i Android Chrome inaczej obsługują powrót z zewnętrznej bramki, a klient, który nie wróci do sklepu, zostawia zamówienie bez statusu.
Po wdrożeniu włącz monitoring: logi modułu, alert mailowy przy błędach webhooków, przegląd transakcji w panelu PayPal raz w tygodniu i lista zamówień „Oczekiwanie na płatność” starszych niż 24 h. Jeśli liczysz konwersje, dopilnuj, żeby zdarzenie zakupu nie dublowało się po powrocie z bramki — opisujemy to przy okazji wdrożenia GA4 w PrestaShop.
Aktualizacje planuj jak wdrożenie: kopia bazy, staging, changelog modułu, zgodność wersji PHP, okno poza szczytem sprzedaży, a po aktualizacji test płatności na 1 zł i sprawdzenie statusów.
| Zdarzenie | Status w PrestaShop | Akcja automatyczna |
|---|---|---|
| Płatność zaakceptowana | Płatność zaakceptowana | Mail potwierdzający, faktura, zdjęcie stanu |
| Płatność oczekująca (eCheck) | Oczekiwanie na płatność | Mail z informacją, brak faktury, brak wysyłki |
| Anulowanie przez klienta | Anulowane | Zwolnienie rezerwacji stanu |
| Zwrot środków w PayPal | Zwrócone | Korekta faktury, korekta stanu |
| Chargeback | Chargeback | Alert do obsługi, wstrzymanie wysyłki |
Realny budżet to głównie czas, nie koszt modułu. Sam moduł PayPal jest darmowy, ale wdrożenie to praca: API, statusy, maile, testy i dokumentacja dla zespołu.
Koszt modułów: od 0 zł (oficjalny moduł PayPal) do około 1500 zł rocznie za rozwiązania rozszerzające — dodatkowe bramki, raty, integracje rozliczane jako licencja lub abonament. Jeśli doliczasz do tego wsparcie producenta, sprawdź, czy abonament obejmuje aktualizacje zgodne z nowymi wersjami PrestaShop.
Prowizje PayPal zależą od obrotu, kraju, metody płatności i indywidualnych negocjacji. Jedyne wiarygodne źródło to aktualny cennik w Twoim panelu PayPal — nie licz na liczby z bloga sprzed trzech lat.
Kiedy deweloper, a kiedy opieka techniczna: deweloper jest potrzebny, gdy zmieniasz logikę (statusy, faktury, integracje, multi-store, nietypowe waluty). Zwykła opieka techniczna wystarcza do aktualizacji modułu, przeglądu logów, reakcji na błędy i kontaktu z PayPal.
SLA i wsparcie: ustal na piśmie czas reakcji (przykładowo 1 dzień roboczy) i czas naprawy awarii blokującej płatności (przykładowo 4–8 h). Awaria bramki w piątek po 16:00 to nie „drobiazg”, a konkretna strata — bez zapisu w umowie reagujesz wtedy, kiedy ktoś odbierze telefon.
| Zakres prac | Szacowany czas | Typowy scenariusz |
|---|---|---|
| Podstawowa konfiguracja | 4–12 h | Jeden sklep, jedna waluta, standardowe statusy i maile |
| Konfiguracja pośrednia | 12–20 h | Dwie waluty, faktury po statusie, dodatkowe szablony maili |
| Zaawansowana | 20–40 h | Multi-store, ERP/magazyn, webhooki, raty, kilka języków |
Dla większości małych i średnich sklepów rekomendacja jest prosta: oficjalny, darmowy moduł PayPal plus uporządkowane mapowanie statusów i przetestowane ścieżki powrotu. To wystarcza, gdy masz jeden sklep, jedną lub dwie waluty, standardowy koszyk i nie podłączasz systemu magazynowego.
Oficjalny moduł wybierz, gdy: sprzedajesz na jednym rynku, nie modyfikujesz koszyka, akceptujesz domyślne statusy i chcesz mieć wsparcie po stronie PayPal. Alternatywę (moduł płatny lub rozwiązanie agencyjne) wybierz, gdy: potrzebujesz wielu walut albo sklepów, dodatkowych bramek obok PayPal w jednym miejscu, nietypowej logiki statusów, integracji z ERP, rat lub indywidualnego SLA. Płać za funkcje, których naprawdę użyjesz — nie za listę metod płatności, których klienci nie klikają.
Kolejny krok jest techniczny i krótki: przejdź konfigurację API punkt po punkcie zgodnie z instrukcją konfiguracji PayPal w PrestaShop, a checklistę wdrożeniową z tego artykułu potraktuj jako warunek uruchomienia produkcji. Jeśli dopiero porównujesz platformy, zobacz PrestaShop czy WooCommerce — przewodnik dla początkujących.
Prowadzisz sklep i nie chcesz przechodzić tego samodzielnie? Napisz do nas, co masz teraz: wersję PrestaShop i PHP, liczbę walut i sklepów, miesięczną liczbę zamówień oraz to, czy działa integracja z magazynem. Wrócimy z zakresem prac, szacunkiem godzinowym i propozycją opieki technicznej po wdrożeniu. Nie zaczynamy od prezentacji, tylko od Twoich logów i ustawień.
Wdrożenie modułu od razu na sklepie produkcyjnym, bez środowiska testowego i kont sandbox.
Jak wykryć: W historii wdrożenia nie ma etapu z kontem sandbox, a pierwsza transakcja testowa to jednocześnie pierwsza transakcja klienta.
Jak naprawić: Założ konto sandbox w panelu deweloperskim PayPal, skopiuj sklep na subdomenę testową i przepnij moduł w tryb sandbox. Na produkcję wchodzisz dopiero po przejściu pełnej ścieżki: koszyk, płatność, status, faktura, zwrot.
Brak mapowania statusów PayPal (pending, completed, refunded, reversed) na statusy zamówień w PrestaShop.
Jak wykryć: Zamówienia zostają na statusie "Oczekiwanie na płatność PayPal" mimo że pieniądze wpłynęły, a obsługa klienta dopytała PayPal ręcznie.
Jak naprawić: Ustal w module, który status PayPal ma nadawać jaki status w PrestaShop, i przetestuj każdy z osobna. Osobno obsłuż płatności oczekujące (eCheck) i osobno zwroty oraz reklamacje.
Poleganie wyłącznie na powrocie klienta do sklepu (return URL) bez działających webhooków lub IPN.
Jak wykryć: Zamówienia nieaktualizują się, gdy klient zamknie kartę przeglądarki lub straci internet przed powrotem do sklepu.
Jak naprawić: Skonfiguruj webhooki w panelu PayPal i wskaż w module poprawny, publicznie dostępny adres URL. Sprawdź ręcznie w historii webhooków, że zdarzenia dochodzą i mają status 200.
Instalacja modułu z niepewnego źródła, tzw. nulled, albo modułu porzuconego przez autora.
Jak wykryć: Moduł nie ma aktualnej daty wydania, brak changeloga, brak kompatybilności z PHP 8 albo pochodzi z forum lub serwisu z "darmowymi" wersjami premium.
Jak naprawić: Korzystaj z oficjalnego marketplace PrestaShop lub bezpośrednio od producenta. Przed zakupem sprawdź datę ostatniej aktualizacji i to, czy autor deklaruje wsparcie dla Twojej wersji PrestaShop i PHP.
Brak backupu plików i bazy przed instalacją lub aktualizacją modułu płatności.
Jak wykryć: Przy pierwszym błędzie nie ma z czego przywrócić sklepu, a poprawki testowane są bezpośrednio na działającej bazie.
Jak naprawić: Zrób kopię plików i zrzut bazy (np. przez phpMyAdmin lub panel hostingu) przed każdą zmianą w module płatności. Trzymaj kopię poza serwerem produkcyjnym i sprawdź, że da się ją odtworzyć na środowisku testowym.
Niespójne waluty i strefy: sklep sprzedaje w PLN, a konto PayPal lub moduł działa tylko w EUR.
Jak wykryć: Przycisk PayPal nie pojawia się w koszyku dla części klientów albo pojawia się, ale kończy komunikatem o niedostępnej walucie.
Jak naprawić: Ustal, w jakich walutach chcesz przyjmować płatności, dodaj je w PrestaShop i w koncie PayPal, i przypisz metodę płatności do właściwych stref geograficznych. Przetestuj zakup dla każdej obsługiwanej waluty i dla Polski oraz dla zagranicy.
Pominięcie księgowości i obsługi faktur przy płatnościach w obcej walucie.
Jak wykryć: Po pierwszym miesiącu pojawiają się pytania o kurs, datę księgowania i kwotę prowizji, a nikt nie ma na to ustalonej odpowiedzi.
Jak naprawić: Przed live ustal z księgowością, jakim kursem przeliczacie transakcje, w którym momencie powstaje obowiązek podatkowy i jak dokumentujecie prowizję PayPal. Ustal też, kto obsługuje chargeback i w jakim terminie.
Moduł PayPal w PrestaShop jest technicznie prosty, ale jego wartość zależy od decyzji podjętych przed instalacją: sposobu mapowania statusów, działania webhooków, obsługiwanych walut i ustaleń z księgowością. Dwa najczęstsze źródła problemów to brak testów w sandboxie i brak backupu — oba są do wyeliminowania w kilkanaście minut. Przejdź checklistę punkt po punkcie przed pierwszym live, a nie po pierwszej reklamacji. Jeśli nie masz pewności co do którejś pozycji, lepiej zatrzymać wdrożenie na etapie testów niż naprawiać rozliczenia po fakcie.
Oficjalne rozwiązanie PayPal dla PrestaShop jest udostępniane bez opłaty za sam moduł. Płacisz natomiast prowizję od transakcji, zgodnie z cennikiem przypisanym do Twojego konta i kraju. Ceny i warunki zmieniają się, więc aktualne stawki sprawdź bezpośrednio w panelu PayPal, zanim wpiszesz je do kalkulacji marży.
Do przyjmowania płatności w sklepie potrzebujesz konta firmowego (Business). Konto prywatne ma inne limity i nie daje dostępu do wszystkich ustawień, których wymaga moduł. Przy zakładaniu konta przygotuj dane firmy i dane do wypłat — weryfikacja może zająć kilka dni, więc nie zostawiaj tego na dzień uruchomienia sklepu.
Sandbox to środowisko testowe: używasz osobnych kluczy API i kont testowych, a prawdziwe pieniądze nie biorą udziału w transakcji. Tryb live to realne płatności Twoich klientów. Przełączenie polega na podmianie kluczy i adresów, ale po przełączeniu trzeba powtórzyć test zakupu, zwrotu i webhooków, bo w sandboxie niektóre zdarzenia zachowują się inaczej.
Najczęstsze przyczyny to brak przypisania metody płatności do stref geograficznych, waluta koszyka nieobsługiwana przez konfigurację, wyłączony hook płatności w szablonie albo cache, który trzyma starą wersję strony. Sprawdź konfigurację ograniczeń modułu, wyczyść cache sklepu i cache przeglądarki, a potem przetestuj w trybie incognito. Jeśli problem zostaje, zajrzyj do logów PrestaShop.
Najczęściej winne jest jednoczesne działanie powrotu klienta do sklepu i webhooka przy braku poprawnego mapowania statusów lub błędzie w adresie powrotu. Moduł tworzy nowe zamówienie, bo nie rozpoznaje wcześniejszego jako opłacone. Sprawdź logi transakcji i logi sklepu, porównaj czasy zdarzeń, a poprawkę przetestuj na kopii sklepu, nie na produkcji.
Nie. PayPal to odrębna metoda płatności i nie obsługuje BLIK-a ani polskich przelewów online. W polskim sklepie B2C zwykle potrzebujesz obu: szybkiej płatności dla klientów zagranicznych i kart oraz lokalnych metod, których oczekuje polski kupujący. Oba kanały warto rozliczać według tego samego schematu statusów i faktur, żeby księgowość nie pracowała na dwóch różnych logikach.
Sama instalacja i wpisanie kluczy to kilkanaście minut. Sensowne wdrożenie z testami, webhookami, mapowaniem statusów i ustaleniami z księgowością to zwykle od jednego do kilku dni roboczych, w zależności od liczby walut i tego, jak bardzo sklep jest przystosowany do zmian. Największą część czasu pochłaniają testy, nie konfiguracja.
Jeśli wolisz, żeby ktoś przeszedł tę konfigurację z Tobą i zweryfikował ją na kopii sklepu, napisz do nas — zajmujemy się wdrożeniami PrestaShop i integracjami płatności. Zanim zadzwonisz, przygotuj listę walut i metod płatności, które chcesz obsługiwać, oraz dane kontaktowe do swojej księgowości.