Wdrożenie Przelewy24 w PrestaShop to w praktyce mniej praca programisty, a więcej uporządkowanie danych, statusów i testów. Jeśli konto sprzedawcy, klucze i regulamin są przygotowane wcześniej, konfiguracja modułu zajmuje godziny, a nie dni. Jeśli nie — proces zatrzymuje się na etapie, którego nie da się obejść kodem. Poniżej organizacja całego wdrożenia: wybór modułu, lista rzeczy do przygotowania, mapowanie statusów zamówień i testy akceptacyjne przed uruchomieniem. Działanie bramki i słownik pojęć opisujemy w części technicznej artykułu.
W PrestaShop obsługa Przelewy24 sprowadza się do jednego z trzech modeli i od tego wyboru zależy, co dzieje się ze statusem zamówienia.
Powrót klienta do sklepu to sygnał dla przeglądarki, nie dowód zapłaty. Status „Płatność zaakceptowana” wolno ustawić dopiero po notyfikacji (webhooku) z serwerów Przelewy24, zweryfikowanej podpisem. Pieniądze na rachunek bankowy trafiają w cyklu wypłat wynikającym z umowy z operatorem, nie w momencie kliknięcia „Wróć do sklepu” — harmonogram wypłat znajdziesz w panelu sprzedawcy.
Słownik, który wystarczy do dalszej lektury:
Kolejność „zamówienie → płatność” wynika z tego, że PrestaShop nadaje zamówieniu ID, rezerwuje stany magazynowe i zapisuje koszyk przed przekierowaniem. Dzięki temu notyfikacja ma do czego się odwołać. Przy odwrotnej kolejności po tygodniu masz płatności bez zamówień i zamówienia bez płatności, a nikt nie wie, który status był prawdziwy. Cykl życia zamówienia opisujemy szerzej w materiale o tym, [jak w PrestaShop powstaje zamówienie i koszyk](https://dropdigital.pl/prestashop-co-to).
| Model | Gdzie płaci klient | Kiedy się nadaje | Główne ryzyko |
|---|---|---|---|
| Przekierowanie | na stronie Przelewy24 | typowy sklep B2C | status zależy wyłącznie od notyfikacji |
| Pay-by-link | z linku w mailu lub SMS | zamówienia telefoniczne, dopłaty, B2B | link trzeba zabezpieczyć i wygasić po czasie |
| API bezpośrednie | w sklepie | mobile i wysoka konwersja | więcej pracy i odpowiedzialność za zgodność |
Decyzję o module podejmij na pięciu kryteriach, nie na liczbie gwiazdek w katalogu:
Gotowy moduł wystarczy w typowym sklepie B2C: jedna waluta, jedna metoda, standardowe statusy. Konfiguracja to zwykle 4–8 roboczogodzin. Własna integracja zaczyna się opłacać przy nietypowej logice: dopłatach do zamówienia, płatnościach częściowych, rozdzieleniu statusów między markami albo integracji z ERP. Wtedy licz 40–80 godzin na start i stały koszt utrzymania przy każdej aktualizacji PrestaShop.
Największe ryzyko to moduły porzucone. Poza błędami po aktualizacji zdarza się problem poważniejszy: moduł ustawia status „opłacone” po samym powrocie klienta, bez weryfikacji podpisu notyfikacji. To realna droga do darmowych zamówień. Zanim wdrożysz, sprawdź w kodzie trzy rzeczy: czy weryfikuje sumę kontrolną, czy loguje notyfikacje i czy da się go wyłączyć bez rozwalenia koszyka.
Zadbaj też o wsparcie po wdrożeniu i jasne SLA: czas reakcji, kto kontaktuje się z operatorem i co się dzieje, gdy operator zmieni API. To element [wdrożeń PrestaShop](https://dropdigital.pl/prestashop), który ustala się przed podpisaniem umowy, a nie po pierwszej awarii. Kryteria wyboru rozpisujemy w tekście o tym, [jak wybrać i wdrożyć moduły PrestaShop](https://dropdigital.pl/prestashop-moduly), a techniczne podstawy interfejsu modułów znajdziesz w [dokumentacji dla deweloperów PrestaShop](https://devdocs.prestashop-project.org/).
| Kryterium | Moduł gotowy | Własna integracja |
|---|---|---|
| Koszt startowy | licencja + 4–8 h konfiguracji | 40–80 h pracy |
| Czas wdrożenia | 1–2 dni | 1–3 tygodnie |
| Nietypowe scenariusze | często wymaga obejść | pełna kontrola |
| Utrzymanie | zależne od autora modułu | po Twojej stronie |
Zanim ktokolwiek dotknie plików sklepu, przygotuj trzy zestawy rzeczy: dane z panelu, dokumenty i dostęp techniczny.
Dane z panelu Przelewy24:
Sandbox kontra produkcja. Tryby rozpoznasz po ID sprzedawcy: panel testowy ma własny identyfikator i własny klucz. Nie mieszaj ich — podpis nie przejdzie i dostaniesz błąd autoryzacji, który łatwo pomylić z błędem modułu. Testuj przelewem testowym, nie własnym kontem: zwroty i korekty zaśmiecą rozliczenia na miesiące. Pamiętaj, że testy tworzą prawdziwe zamówienia w PrestaShop — rób je na kopii i po testach wyczyść bazę.
Wymagania formalne. Regulamin sklepu musi wskazywać operatora płatności, a informacja o tym, kto realizuje płatność, powinna pojawić się w koszyku i przy wyborze metody płatności. Dane firmy w panelu muszą zgadzać się z CEIDG/KRS, bo na tej podstawie wystawiane są dokumenty rozliczeniowe. Jeśli dane klientów trafiają do operatora, potrzebujesz podstawy do powierzenia przetwarzania.
Dostęp techniczny. Potrzebujesz konta z prawem zapisu do katalogu modułów, kopii plików i bazy sprzed instalacji oraz środowiska stagingowego z tą samą wersją PrestaShop i PHP co produkcja. Testowanie na innej wersji PHP niż produkcyjna to strata czasu. Na czas testów wyłącz cache Smarty i cache strony, a po ich włączeniu przetestuj powrót klienta jeszcze raz — najczęstsza wpadka to „działało przed czyszczeniem cache”.
| Element | Gdzie | Na co uważać |
|---|---|---|
| ID sprzedawcy | panel Przelewy24 | inne dla testów, inne dla produkcji |
| Klucz do sumy kontrolnej | panel Przelewy24 | nie kopiuj go do repozytorium ani maila |
| Adresy powrotu i notyfikacji | panel Przelewy24 | muszą zgadzać się z URL-em sklepu, z https i www |
| Regulamin i informacja o operatorze | koszyk i strona płatności | wymóg formalny, nie ozdoba |
| Kopia plików i bazy | hosting | zrób snapshot, nie tylko eksport bazy |
| Staging | serwer testowy | ta sama wersja PrestaShop i PHP co produkcja |
Zacznij od instalacji: Moduły > Menedżer modułów > Wgraj moduł (ZIP) albo instalacja z Addons. Zaraz po instalacji wejdź w Zaawansowane > Wydajność i wyczyść cache. Jeśli moduł dokłada szablony do koszyka lub checkoutu, usuń też katalogi var/cache/dev i var/cache/prod przez FTP. Bez tego najczęstszym objawem jest brak przycisku płatności albo stary koszyk — to fałszywy alarm, nie błąd modułu.
Drugi krok to hooki. Moduł musi być zarejestrowany na displayPayment (lista metod na kroku płatności) i displayPaymentReturn (strona potwierdzenia). W PrestaShop 8 i 9 część modułów korzysta już z nowego API płatności i hooka paymentOptions — sprawdź w Moduły > Pozycje, gdzie moduł faktycznie wisi, zamiast zakładać, że instalacja zrobiła to poprawnie. Nadpisany szablon checkoutu w motywie to typowe miejsce, w którym hook wypada z listy.
Kolejność włączania metod dla sklepu MŚP: najpierw szybki przelew i BLIK, potem karta, na końcu pay-by-link. BLIK i przelewy obsługują większość koszyka i zwykle nie wymagają nowej umowy, jeśli już przyjmujesz płatności. Karta to osobne rozliczenia i prowizja — włączaj, gdy widzisz realny popyt, nie „na wszelki wypadek”. Pay-by-link ma sens głównie przy zamówieniach telefonicznych i mailowych, gdzie nie ma kasy w przeglądarce.
Ustaw kwoty minimalne i maksymalne zgodnie z tym, co obsługuje dana metoda, a walutę ogranicz do PLN. Kraje ustaw tak, jak realnie wysyłasz — jeśli nie obsługujesz dostaw do Niemiec, zablokuj je również na poziomie metody płatności, bo klient z zagranicy zapłaci, a potem zaczyna się zwrot i korespondencja.
Loguj wszystko. Włącz Zaawansowane > Logi, sprawdź, czy moduł zapisuje własny plik logu, i zapamiętaj, gdzie trafiają odpowiedzi bramki: status płatności trafia do tabeli zamówienia (Zamówienia > Płatności), a identyfikator transakcji do tabeli modułu. Zawsze notuj ID transakcji — po nim znajdziesz zamówienie w panelu operatora. Ogólne zasady budowy modułów opisujemy w tekście o tym, jak wybierać i wdrażać moduły PrestaShop, a strukturę hooków znajdziesz w dokumentacji dla deweloperów PrestaShop.
| Metoda | Kiedy włączyć | Na co uważać |
|---|---|---|
| Szybki przelew | od pierwszego dnia | status początkowy: oczekiwanie na płatność, nie zaakceptowana |
| BLIK | od pierwszego dnia | testuj na realnym telefonie z aplikacją banku |
| Karta | gdy jest popyt i podpisana umowa | osobne rozliczenia, prowizja, obsługa chargeback |
| Pay-by-link | zamówienia telefoniczne i mailowe | link trzeba wygenerować ręcznie z panelu |
Zanim cokolwiek przetestujesz, zapisz sobie ID statusów, których używasz. W standardowej instalacji PrestaShop „Płatność zaakceptowana” to ID 2, błąd płatności 8, anulowane 6, oczekiwanie na przelew 10 — ale po imporcie statusów numeracja bywa inna. Sprawdź to w Zamówienia > Statusy i dopiero wtedy mapuj w konfiguracji modułu. Mapowanie powinno wyglądać tak: notyfikacja „płatność przyjęta” ustawia status 2 i wysyła mail z potwierdzeniem, notyfikacja o nieudanej płatności ustawia 8, brak płatności po czasie — 6 z anulowaniem.
Kluczowa zasada: status zmienia notyfikacja serwerowa z bramki, a nie powrót klienta na stronę sklepu. displayPaymentReturn służy do pokazania komunikatu, nie do zmiany statusu. Jeśli oprzesz logikę na powrocie, będziesz mieć dwa rodzaje bałaganu: zamówienia bez płatności (klient nie wrócił) i płatności bez zamówień (notyfikacja dotarła, ale zamówienie nie zostało poprawnie zapisane).
Notyfikacje muszą być powtarzalne. Endpoint powinien zwracać HTTP 200, nie generować PDF-ów ani masowych maili i mieć zabezpieczenie przed ponownym przetworzeniem tej samej transakcji — po ID transakcji. Gdy webhook nie dotrze (błąd 500, blokada na firewallu, zmiana adresu sklepu), zamówienie zostaje w oczekiwaniu na płatność. Rozwiązanie: zadanie cron co 10–15 minut, które dopyta bramkę o status, plus przycisk ręcznego odświeżenia przy zamówieniu.
Kiedy ręczna weryfikacja jest tańsza niż automatyzacja? Policz uczciwie: 40 zamówień miesięcznie po 2 minuty sprawdzania w panelu operatora to około 80 minut pracy i realne ryzyko wysłania towaru bez wpłaty. Poniżej 20 zamówień miesięcznie i przy jednej metodzie płatności (przelew tradycyjny) półautomat ręczny wystarcza. Powyżej 50 zamówień miesięcznie automatyzacja zwraca się w pierwszym miesiącu — nie przez koszt godzin, ale przez błędy.
Dorzuć jedną regułę niezależnie od automatu: zamówienia powyżej ustalonej kwoty oraz pierwsze zamówienie od nowego klienta weryfikuj ręcznie. To najtańsze ubezpieczenie od chargebacku.
| Sytuacja | Status w PrestaShop | Co dostaje klient |
|---|---|---|
| Notyfikacja: płatność przyjęta | Płatność zaakceptowana (domyślnie ID 2) | mail z potwierdzeniem zamówienia |
| Notyfikacja: płatność odrzucona | Błąd płatności (domyślnie ID 8) | mail z informacją i linkiem do ponownej płatności |
| Brak notyfikacji po ustalonym czasie | Anulowane (domyślnie ID 6) | mail informacyjny, zwolniony magazyn |
| Metoda offline (przelew tradycyjny) | Oczekiwanie na przelew (domyślnie ID 10) | mail z danymi do przelewu |
Testy robisz w środowisku testowym operatora, z osobnymi kluczami — nie na produkcji i nie na prawdziwej karcie. Przed startem zrób zrzut bazy, żeby móc cofnąć stan po testach. Środowisko testowe Przelewy24 i sposób wygenerowania kluczy opisuje aktualna instrukcja operatora — te dane zmieniają się w czasie, więc nie zakładaj, że podejście z zeszłego roku jest nadal aktualne.
Zestaw testów jest krótki, ale musi przejść przez wszystkie cztery stany: płatność udana, odrzucona, brak powrotu klienta i podwójne kliknięcie. Całość realnie odklikasz w 30 minut, jeśli nie zgubisz się w danych testowych.
Osobno przetestuj kwoty. Wpisz kwotę minimalną dopuszczalną dla metody, maksymalną, a potem zamówienie z darmową dostawą i produktem za symboliczną kwotę. Bramki odrzucają kwoty poniżej progu albo równe zero — łatwo to przeoczyć, jeśli testujesz tylko koszyk za 200 zł.
Na koniec sprawdź, czy zamówienie się nie duplikuje. Po powrocie na stronę potwierdzenia odśwież ją trzy razy i policz rekordy w Zamówienia — nie może być dwóch o tym samym koszyku. To samo przy dwukrotnym kliknięciu „Zapłać”: sprawdź, czy przycisk blokuje się po pierwszym kliknięciu.
Mobile to nie emulator. BLIK przetestuj na realnym telefonie z aplikacją banku — emulator nie odzwierciedla zachowania aplikacji przy powrocie do przeglądarki. W DevTools włącz throttling Slow 3G i sprawdź, czy przy wolnym łączu nie wysyłasz formularza dwa razy. Jeśli testy wypadają, uzupełnij wiedzę o wdrożeniach PrestaShop i dokumentacji hooków w PrestaShop Developer Documentation.
| Scenariusz | Jak wymusić | Co sprawdzić |
|---|---|---|
| Płatność udana | poprawna transakcja w sandboxie | status 2, mail, stan magazynowy zmniejszony |
| Płatność odrzucona | transakcja odrzucona przez bramkę | status 8, mail z możliwością ponowienia, brak duplikatu |
| Brak powrotu klienta | zamknij stronę banku po płatności | status zmieniony przez notyfikację, nie przez powrót |
| Podwójne kliknięcie „Zapłać” | kliknij dwa razy szybko | jedno zamówienie, przycisk zablokowany po pierwszym kliku |
| Kwota minimalna i maksymalna | koszyk na granicy widełek | metoda widoczna lub ukryta zgodnie z konfiguracją |
| Produkt z darmową dostawą | kupon 100% na dostawę | poprawna kwota przekazywana do bramki |
| Odświeżenie strony potwierdzenia | F5 trzy razy pod rząd | jeden rekord zamówienia o danym koszyku |
| Mobile i słabe łącze | realny telefon, throttling Slow 3G | powrót do sklepu, brak podwójnego wysłania formularza |
Diagnostykę zaczynasz od jednego pytania: czy transakcja w ogóle dotarła do Przelewy24. Panel sprzedawcy pokazuje każdą próbę płatności z jej statusem i identyfikatorem sesji. Jeśli transakcji tam nie ma — problem leży po stronie sklepu: wysyłki żądania, kluczy albo połączeń wychodzących. Jeśli jest, a zamówienie zostało w koszyku — problem jest po stronie odbioru notyfikacji i mapowania statusów. Ta jedna informacja skraca diagnozę z godzin do minut.
Błędy konfiguracji serwera. Najczęstsze trzy: brak wychodzących połączeń HTTPS (firewall lub polityka hostingu), zablokowany webhook od bramki przez WAF, wyłączone rozszerzenie cURL. Sprawdź na serwerze: php -m | grep curl, curl -I na adres bramki z dokumentacji modułu, logi firewalla. Adres notyfikacji musi być publiczny — tryb serwisowy, hasło w .htaccess albo ochrona całego katalogu przed botami potrafią cicho zabijać powroty i notyfikacje.
Aktualizacje PHP i PrestaShop. Moduły pisane pod PHP 7 potrafią rzucać 500 po przejściu na 8.x. Włącz tryb debug i zajrzyj do var/logs/dev.log — brak klasy lub wywołanie usuniętej funkcji widać w pierwszej linii. Zanim wdrożysz cokolwiek na produkcję, postaw kopię sklepu na docelowej wersji PHP i przejdź pełną transakcję testową. Wersja PHP na stagingu musi być identyczna z produkcyjną — inaczej test nic nie wnosi.
Czytanie logów. Utrzymuj dwa źródła prawdy: log modułu i historię transakcji w panelu bramki. Notyfikacja bez zamówienia to problem sklepu. Zamówienie bez notyfikacji w panelu to problem wysyłki. Porównaj liczbę notyfikacji z liczbą zamówień — rozjazd oznacza brak obsługi powtórzeń.
| Objaw | Najczęstsza przyczyna | Gdzie sprawdzić w 5 minut |
|---|---|---|
| Brak przekierowania na bramkę po kliknięciu „Zapłać” | Brak wychodzących połączeń HTTPS lub blokada firewall/WAF | SSH: curl -I na adres bramki z dokumentacji modułu; php -m | grep curl; logi firewalla |
| Błąd sumy kontrolnej (sign) przy starcie transakcji | Niezgodny klucz CRC w konfiguracji modułu albo inne kodowanie znaków w opisie | Klucze w panelu P24 vs. konfiguracja modułu; log modułu w var/logs |
| Klient wraca do sklepu, ale zamówienie zostało w koszyku | Adres powrotu lub notyfikacji nieosiągalny: tryb serwisowy, hasło w .htaccess, zły URL | Wejście na URL notyfikacji z przeglądarki — musi zwrócić 200 bez logowania |
| Transakcja opłacona, zamówienie bez zmiany statusu | Brak mapowania statusu płatności zatwierdzonej | Konfiguracja modułu, zakładka statusów; ręczna zmiana statusu na zamówieniu testowym |
| Zdublowane zamówienia lub powtarzające się notyfikacje | Brak obsługi powtórzeń i weryfikacji identyfikatora sesji | Tabela zamówień vs. liczba notyfikacji w logu modułu |
| Biała strona lub 500 po aktualizacji PHP/PrestaShop | Moduł używa funkcji usuniętych w nowszej wersji PHP | Tryb debug, var/logs/dev.log; test na kopii na docelowej wersji PHP przed produkcją |
Checkout to najbardziej wrażliwy ekran sklepu. Najbardziej psują go: skrypty bramki ładowane globalnie (na stronie głównej i w kategoriach), ramki i widgety wstrzykiwane po załadowaniu layoutu, ikony płatności w PNG zamiast SVG oraz dodatkowe pola i walidacje blokujące wątek główny. Efekt widać w trzech metrykach z Core Web Vitals: LCP, INP i CLS. Największym problemem w koszyku jest zwykle INP — długie zadania JavaScriptu opóźniają reakcję przycisku.
Rozwiązanie jest proste do wdrożenia: skrypt bramki ładuje się wyłącznie na kroku płatności, z atrybutem defer, a domena bramki dostaje preconnect. Nie wczytuj jej na kartach produktu — klient, który nie doszedł do koszyka, nie potrzebuje tego kodu. To realna oszczędność kilkuset kilobajtów i kilku sekund na najdroższej w utrzymaniu grupie użytkowników.
Co mierzyć przed i po wdrożeniu:
Punktem wyjścia są Lighthouse i PageSpeed Insights dla koszyka oraz dane z pola, jeśli masz RUM. Samo wdrożenie bramki to też temat technicznego SEO sklepu na PrestaShop, a porządek całego procesu opisuje organizacja wdrożenia PrestaShop krok po kroku.
Nie podamy cennika z sufitu, bo ten sam zakres może kosztować 900 zł i 9000 zł — zależy od liczby sklepów i systemów, które trzeba spiąć. Podajemy natomiast realistyczne widełki czasowe, bo czas to jedyna uczciwa jednostka rozliczeniowa.
Na liczbę godzin najbardziej wpływają: wielosklepowość (każdy sklep w multistore to osobna konfiguracja i osobne klucze), integracja z ERP lub systemem księgowym, sposób wystawiania faktur, liczba niestandardowych statusów oraz historia zamówień, którą trzeba przenieść.
Rozliczamy się za godziny i zakres opisany w umowie, nie za „pakiety”. Pakiet zawsze jest albo przepłacony, albo niedoszacowany, a przy zmianach w module nikt nie wie, co jeszcze w nim jest. Po wdrożeniu dostajesz raport z faktycznie przepracowanym czasem.
Opieka po wdrożeniu to osobna pozycja: SLA z czasem reakcji liczonym w godzinach w dni robocze, monitoring notyfikacji i reakcja na zmiany po stronie bramki. Gdy dostawca płatności zmienia API, stary moduł przestaje działać bez ostrzeżenia — wtedy liczy się to, czy ktoś pilnuje wersjonowania i ma gotowy plan aktualizacji. Zapytaj o to przed podpisaniem umowy, nie po awarii. Wybór modułu i jego pułapki opisujemy w materiale o modułach PrestaShop.
Napisz, ile masz sklepów, skąd biorą się faktury i czy ERP musi wiedzieć o płatności. Na tej podstawie podamy zakres i liczbę godzin, a nie widełki „od–do”.
Włączenie wszystkich metod płatności bez ustawienia zakresów kwot, walut i krajów.
Jak wykryć: Zrób zamówienie testowe na kwotę minimalną i na maksymalny koszyk. Jeśli bramka odrzuca płatność, a metoda nadal jest widoczna w koszyku, zakresy są źle ustawione.
Jak naprawić: Ustaw kwoty minimalne i maksymalne dla każdej metody osobno i wyłącz waluty oraz kraje, w których nie sprzedajesz. Sprawdź, czy ustawienia są spójne z modułem wysyłki.
Brak mapowania statusów zamówień po instalacji modułu — sklep zostaje z domyślnym statusem oczekiwania.
Jak wykryć: Po udanej płatności testowej zamówienie ląduje w statusie oczekiwania na płatność zamiast w statusie płatności przyjętej.
Jak naprawić: W konfiguracji modułu przypisz statusy dla czterech zdarzeń: płatność przyjęta, oczekiwanie na płatność, płatność odrzucona, anulowane. Sprawdź, czy nie tworzysz duplikatów istniejących statusów.
Klucze ze środowiska testowego trafiają na produkcję (albo odwrotnie).
Jak wykryć: W sandboxie płatności przechodzą, a na produkcji bramka zwraca błąd autoryzacji lub błąd sumy kontrolnej w logach.
Jak naprawić: Trzymaj konfigurację osobno dla testów i produkcji. Po migracji wymień ID sprzedawcy, klucz i CRC, zapisz ustawienia i wyczyść cache sklepu.
Instalacja modułu bez kopii bazy i bez środowiska stagingowego.
Jak wykryć: Przed instalacją nie ma świeżej kopii plików i bazy, a błędu nie da się powtórzyć nigdzie poza produkcją.
Jak naprawić: Zrób kopię plików i bazy, zainstaluj moduł najpierw na stagingu, przejdź testy, a dopiero potem powtórz procedurę na produkcji.
Pominięcie informacji o operatorze płatności w koszyku i w regulaminie.
Jak wykryć: W koszyku nie ma nazwy operatora ani odesłania do regulaminu płatności. Sprawdź checkout także w trybie gościa i na telefonie.
Jak naprawić: Dodaj informację o operatorze płatności w koszyku oraz w regulaminie, a spójność treści sprawdź w e-mailach potwierdzających zamówienie.
Brak logowania zdarzeń i brak dostępu do odpowiedzi bramki.
Jak wykryć: Przy sporze nie da się ustalić, czy notyfikacja dotarła — logi modułu i serwera są puste albo nikt nie wie, gdzie leżą.
Jak naprawić: Włącz logowanie w module, ustal, gdzie zapisują się odpowiedzi bramki i kto je czyta. Ustal też, jak długo logi są przechowywane.
Sukces wdrożenia Przelewy24 w PrestaShop zależy mniej od samego modułu, a bardziej od przygotowania: poprawnie rozdzielonych kluczy, jasnego mapowania statusów i przemyślanych zakresów kwot oraz metod. Największym ryzykiem nie jest brak funkcji, tylko zamówienia bez płatności i płatności bez zamówień — oba wynikają z pominiętych notyfikacji i statusów. Przed uruchomieniem przejdź testy akceptacyjne na stagingu, a nie na produkcji. Jeśli nie masz pewności co do konfiguracji, zleć przegląd wdrożenia — zobacz naszą ofertę wdrożeń PrestaShop.
W większości sklepów MŚP gotowy moduł wystarcza. Własna integracja ma sens, gdy potrzebujesz niestandardowego przepływu (np. płatność częściowa), nietypowego mapowania statusów albo integracji z systemem ERP, którego gotowy moduł nie obsłuży. Kryteria wyboru i ryzyka modułów porzuconych przez autorów opisujemy szerzej w artykule o modułach PrestaShop.
Zamówienie zostaje w statusie oczekiwania, a status zmienia się dopiero po dotarciu notyfikacji z bramki. Dlatego kluczowe jest, żeby webhook był skonfigurowany i logowany — inaczej sklep zależy wyłącznie od powrotu klienta. Przy braku notyfikacji trzeba mieć procedurę ręcznej weryfikacji płatności.
Nie ustalaj tego po długości ani po wyglądzie identyfikatora. Oba zestawy są widoczne osobno w panelu Przelewy24 i to panel jest jedynym wiarygodnym źródłem. Przed uruchomieniem zapisz w dokumentacji wdrożenia, które wartości są produkcyjne, i dopiero je wpisz do modułu na produkcji.
Tak. Informacja o operatorze płatności powinna być widoczna w koszyku i w regulaminie, a spójna także w e-mailach potwierdzających zamówienie. To element formalny, który najłatwiej pominąć przy wdrożeniu, bo nie blokuje technicznie płatności — problem pojawia się dopiero przy reklamacji.
Najpierw sprawdź logi modułu i serwera, czy żądanie w ogóle dotarło i jaki zwróciło kod odpowiedzi. Jeśli notyfikacja nie przychodzi powtarzalnie, trzeba ustalić przyczynę po stronie hostingu lub konfiguracji adresu zwrotnego. Do czasu naprawy potrzebna jest procedura ręcznego potwierdzania płatności, żeby nie wysyłać towaru na podstawie samego zamówienia.
Przy bardzo małej liczbie zamówień dziennie ręczne sprawdzanie wyciągu bywa szybsze niż utrzymanie i debugowanie automatyzacji. Próg jest indywidualny i zależy od kosztu godziny pracy oraz liczby nieudanych dopasowań. Policz to na własnych danych: ile minut dziennie zajmuje weryfikacja i ile płatności wymaga ręcznej korekty.
W polskim e-commerce BLIK i szybki przelew to zwykle pierwsze metody do uruchomienia, bo klient jest do nich przyzwyczajony. Kartę można dołożyć po pierwszych udanych testach — każda dodatkowa metoda to kolejny scenariusz do sprawdzenia i kolejne miejsce, w którym może rozjechać się zakres kwot.
Jeśli chcesz, żeby ktoś przeszedł z Tobą przez konfigurację Przelewy24 i statusów zamówień w PrestaShop, napisz do nas — powiemy, co da się załatwić w godzinę, a co wymaga szerszej pracy nad sklepem.