Wybór i obsługa metod płatności w PrestaShop

Jak byśmy do tego podeszli

Zachowalibyśmy działającą integrację płatności, chyba że nie spełnia wymagania, którego naprawdę potrzebujesz: metody, o którą proszą klienci, rynku, którego konektor nie obsłuży, lub błędu, który da się odtworzyć. Wymiana konektora zmienia tworzenie zamówień, powiadomienia, zwroty i uzgadnianie, a nie tylko przycisk w procesie zakupowym. Najpierw sprawdź, czy obecna integracja już to potrafi: jeden moduł może zwracać kilka metod, a brakująca opcja może wynikać z ustawień konta, warunków kwalifikacji, waluty lub ograniczeń.

Gdy zmiana jest uzasadniona, wprowadź ją na kopii testowej sklepu produkcyjnego: z tym samym motywem, modułami, przewoźnikami i własnym kodem, odizolowanej od prawdziwych płatności, e-maili do klientów i eksportów do realizacji zamówień oraz podłączonej do konta testowego operatora. Ćwicz testy zakupu, przerwania i zwrotu, aż przejdą, a następnie przełącz sklep produkcyjny w uzgodnionym oknie, z poprzednią konfiguracją gotową do przywrócenia i jedną wskazaną osobą uzgadniającą płatności i zamówienia.

Które rozwiązanie pasuje do problemu?

Natywny proces zakupowy PrestaShop pokazuje to, co zwracają zainstalowane moduły bramek płatności. Express Checkout korzysta ze Stripe i łączy adres, dostawę, płatność i potwierdzenie w jednym oknie na stronach produktów, listach lub w koszyku. Jego opis produktu obejmuje wymagane pola adresu, dostępność płatności według grupy odbiorców, kraju i waluty, bieżące ceny dostawy, odrzucanie wykluczonych kombinacji płatności i przewoźnika, tworzenie zamówienia po ukończonej płatności nawet przy zamkniętej przeglądarce oraz pełne lub częściowe zwroty z ekranu zamówienia. Checkout Revolution umieszcza dane kontaktowe, adres, dostawę, płatność, kupony i podsumowanie zamówienia na jednej stronie z Twoimi dotychczasowymi przewoźnikami i metodami płatności, a także oferuje okno szybkiego zakupu. Express Checkout również ma opcjonalną finalizację zakupów na jednej stronie, więc porównaj, w czym się pokrywają, zanim kupisz oba; żaden z opisów nie potwierdza, że te dwa moduły powinny działać razem w Twoim sklepie.

Jeśli wybierasz spośród kandydatów, PrestaShop Module Selection & Fit Assessment testuje ścieżki pod kątem Twojego wymagania na kontrolowanej kopii sklepu. Jeśli moduł jest już wybrany, PrestaShop Module Installation & Configuration Service instaluje jeden istniejący moduł, konfiguruje uzgodnione ustawienia i sprawdza odpowiednią ścieżkę; licencje, dodatkowe moduły i prace programistyczne są osobno.

Wybierz metody dla obsługiwanych rynków

Przygotuj krótką listę na podstawie krajów, walut i urządzeń klientów, zgłoszeń do obsługi oraz udanych i nieudanych prób zakupu. Brak preferowanej metody może być powodem rezygnacji, ale ani ta obserwacja, ani stereotyp o danym kraju nie dowodzą, jakiej metody potrzebuje Twój sklep.

To lista kontrolna do analizy, a nie ranking ani obowiązkowy zestaw. Nie zakładaj, że w całym kraju karty są rzadkie, zagraniczne lub bezużyteczne ani że jeden operator BNPL dominuje na wszystkich rynkach nordyckich.

Cartes Bancaires to francuska krajowa sieć kartowa. Wiele kart nosi również markę sieci międzynarodowej. Sprawdź wymagania dotyczące wyboru sieci przez posiadacza karty w danej integracji, zamiast wymuszać preferowaną trasę i obiecywać mniej odmów.

Przy pobraniu sprawdź odbiór gotówki przez przewoźnika, opłaty, rozliczenie oraz obsługę odmów i zwrotów. Sama opcja płatności nie zapewnia odbioru gotówki.

Poznaj moduły, metody i wbudowane ograniczenia

Moduł płatności może zwracać kilka obiektów PaymentOption przez paymentOptions. PrestaShop 1.7.8 i 9.1 zbierają opcje płatności według modułu. Jedna integracja operatora może więc udostępniać karty, portfele i metody lokalne bez osobnego modułu dla każdej metody.

Płatności > Preferencje ogranicza moduły płatności według waluty, kraju, grupy klientów i przewoźnika. Ograniczenia dotyczą modułu, a nie każdej metody zwracanej przez agregator. Wyłączenie Mollie lub Stripe dla kraju ukrywa w nim także opcje kartowe dostarczane przez ten moduł.

1. Sprawdź, czy moduł jest aktywny w docelowym sklepie.
2. Sprawdź wbudowane ograniczenia modułu dla rzeczywistego kontekstu koszyka.
3. Sprawdź metody włączone na koncie operatora, uprawnienia sprzedawcy i obsługiwane waluty.
4. Sprawdź ustawienia poszczególnych metod dostępne w tej wersji modułu, w tym limity kwotowe i kolejność.
5. Przetestuj wynikową listę dla reprezentatywnych krajów, walut, grup i przewoźników.

Wbudowane pozycje hooków w Wygląd > Pozycje określają kolejność modułów w paymentOptions; metody wewnątrz agregatora wymagają własnych ustawień kolejności w integracji. Wbudowana tabela ograniczeń nie zawiera ogólnej reguły kwoty zamówienia. Nie zakładaj, że każdy agregator oferuje takie same ustawienia kraju rozliczeniowego, waluty czy kwoty.

Checkout Revolution zapewnia dodatkowe ustawienia prezentacji opcji płatności, z płatnością osadzoną tam, gdzie jest obsługiwana, i przekierowaniami tam, gdzie są wymagane; konfigurację opisuje jego pomoc modułu.

Oceń, czy kolejna metoda pokryje swój koszt

Zacznij od metod, na które jest popyt i które możesz obsługiwać operacyjnie. Dodanie opcji może obsłużyć nowy segment, przenieść obecnych kupujących między operatorami lub zwiększyć nakład utrzymania bez dodatkowych zamówień. Nie ma jednej właściwej liczby metod ani modułów.

Rozważ przykładowy proces zakupowy. Jest 1 000 prób, początkowo 800 sfinalizowanych zamówień i średnia wartość zamówienia 60 EUR. Odzyskanie 8% z 200 utraconych prób daje 16 dodatkowych zamówień, czyli 816 sfinalizowanych zamówień.

To wpływy po jednej założonej opłacie, a nie zysk ani prognoza konwersji. Odejmij koszty produktów, realizacji, wysyłki, zwrotów, oszustw, obsługi i integracji. Uwzględnij wpływ obecnych kupujących wybierających droższą metodę. Odzyskane zamówienie nie jest automatycznie czystą korzyścią.

Pokazuj wyłącznie metody rzeczywiście dostępne w procesie zakupowym. Umieszczaj przydatne logotypy i jasne nazwy tam, gdzie klienci ich potrzebują, i wyjaśniaj przekierowania. Zarówno osadzone pola, jak i przekierowania do banku lub aplikacji wymagają testów; żadne z tych rozwiązań nie zapewnia lepszej konwersji w każdej sytuacji.

Poznaj BLIK, iDEAL | Wero i Bancontact

BLIK, iDEAL i Bancontact mają różne ścieżki klienta i procesy techniczne. Nie steruje nimi wspólny przełącznik „3-D Secure”. 3-D Secure jest protokołem uwierzytelniania kart; metoda bankowa lub aplikacyjna korzysta z własnego procesu uwierzytelniania.

• BLIK: klient może pobrać sześciocyfrowy kod z aplikacji bankowej i zatwierdzić w niej płatność. Dokumentacja API BLIK w Stripe wymaga płatności w PLN. Waluta wypłaty dla sprzedawcy to osobna kwestia konta i rozliczeń.
• iDEAL | Wero: korzystaj z aktualnego procesu wyboru banku hostowanego przez operatora. Sprzedawcom nakazano usunięcie własnych list wyboru banku do 31 marca 2025 r..
• Bancontact: oceń proces kartowy lub aplikacyjny obsługiwany przez operatora dla belgijskich klientów. Samo istnienie systemu nie dowodzi powszechności kart obsługujących wyłącznie Bancontact.

Etap wspólnego brandingu iDEAL | Wero rozpoczął się w 2026 r. Migracja techniczna przebiega etapami i jest niezależna od zmiany logo. Nie opisuj iDEAL jako już wycofanego. Stosuj instrukcje dotyczące brandingu i integracji właściwe dla Twojej bramki.

Sprawdź konkretną wersję wtyczki. Upewnij się, że wersja konektora PrestaShop obsługuje BLIK, nawet jeśli API operatora go obsługuje. Aktualna lista metod Mollie wymienia BLIK i Przelewy24 osobno. Nie publikuj nieprzetestowanej macierzy obsługi ani nie określaj obsługi iDEAL/Bancontact w P24 jako „ograniczonej” bez wskazania konkretnej integracji.

Jeśli brakuje metody lokalnej, sprawdź jej aktywację u sprzedawcy, dostępność dla kraju i waluty, kwotę koszyka, wbudowane ograniczenia modułu, obsługę w integracji i błędy na stronie sklepu.

Porównuj integracje, a nie marki operatorów

Porównaj dokładne nazwy i wersje modułów, deklarowaną obsługę PrestaShop/PHP, częstotliwość wydań, poprawki bezpieczeństwa, licencje i warunki wsparcia. Przetestuj swój motyw i proces zakupowy. Określenia „oficjalny”, „płatny” i „osobne moduły” nie dowodzą zgodności ani pełnej funkcjonalności.

Spisz obsługę hostowanego i osadzonego procesu płatności, metod lokalnych, portfeli, autoryzacji i pobrania środków, częściowych zwrotów, zapisanych danych płatniczych, subskrypcji, sporów i multistore. Możliwości platformy operatora mogą wykraczać poza możliwości konektora. Zapisane dane i portfele nie muszą być funkcjami wyłącznie premium.

Potwierdź obsługiwane kraje sprzedawców, branżę, wymagania identyfikacyjne, warunki dotyczące banku i wypłat oraz zatwierdzenie każdej metody. Rozróżniaj walutę obciążenia, walutę rozliczenia i przewalutowanie. Jedna integracja nie gwarantuje jednego salda, jednej waluty wypłat ani jednego rachunku rozliczeniowego.

Porównaj Stripe i PayPal dla swojego konta

Stripe może korzystać z osadzonego formularza płatności lub hostowanego Checkout, zależnie od integracji. Metody lokalne i uwierzytelnianie mogą wymagać przekierowania. Integracje PayPal także mogą oferować różne procesy z przyciskami, portfelami i kartami. Przetestuj rzeczywistą konfigurację, zamiast zakładać, że dany operator zawsze zatrzymuje klienta w Twojej domenie.

W procesie PayPal zatwierdzenie przez kupującego, autoryzacja i pobranie środków to odrębne etapy. Moduł PrestaShop decyduje, kiedy powstaje lokalne zamówienie. Zatwierdzenie przez kupującego nie dowodzi pobrania środków; jeśli przeglądarka nie wróci do sklepu, pobierz status transakcji.

Porównaj akceptację płatności, popyt klientów, skuteczność, dostępność ochrony sprzedawcy, obsługę zwrotów i łączny koszt. Nie wybieraj na podstawie niepopartego dowodami twierdzenia, że jeden operator sprzyja kupującym lub że nowy sklep zawsze potrzebuje konkretnego logo.

Jeśli prowadzisz niezależne konta Stripe i PayPal, osobno uzgadniaj ich salda, opłaty, zwroty i rozliczenia. Zbiorczy raport finansowy nie zapewnia automatycznego dopasowania wypłat bankowych ani przypisywania rentowności według płatności, kraju i urządzenia.

Odróżniaj roszczenia w Centrum rozstrzygania PayPal od obciążeń zwrotnych u wydawcy karty. Posiadacz karty może zgłosić spór przez wydawcę; Centrum rozstrzygania nie jest obowiązkowym pierwszym etapem każdego sporu kartowego.

Korzystaj z opłat opatrzonych datą dla danego rynku i pełnych kalkulacji kosztów

Poniższe przykłady opublikowanych opłat pochodzą z 27 października 2026 r. Dotyczą różnych rynków sprzedawców i produktów i nie mogą służyć jako równoważne oferty dla jednego sprzedawcy.

Uzyskaj rzeczywistą ofertę dla swojego kraju i produktu. Uwzględnij opłaty stałe, strukturę kart, opłaty transgraniczne, przewalutowanie, podatki, opłaty za wypłaty i aktywację, zwroty, spory oraz abonament modułu lub koszt integracji. Metody lokalne nie zawsze mają stałą opłatę ani nie zawsze są tańsze.

W przykładzie standardowych kart Stripe w Irlandii transakcje na 20 EUR, 50 EUR i 150 EUR generują opłaty za przetwarzanie odpowiednio 0,55 EUR, 1,00 EUR i 2,50 EUR przed innymi należnymi opłatami. Przelicz każdego operatora przy tych samych założeniach dotyczących sprzedawcy, zamiast porównywać niepowiązane stawki bazowe z różnych krajów Europy.

Cennik Stripe w Irlandii podaje także 20 EUR za otrzymany spór i osobne 20 EUR za ręczne zakwestionowanie roszczenia, ze zwrotem tej drugiej opłaty po wygranej. PayPal również publikuje opłaty za spory i obciążenia zwrotne z regionalnymi zasadami i wyjątkami. Nie zakładaj, że spór jest bezpłatny lub że po wygranej odzyskasz każdą opłatę.

Zapisz konfigurację i przygotuj odwracalną zmianę

Zmiana płatności dotyczy nie tylko operatora: także procesu zakupowego, przewoźników, stanów zamówień, e-maili, stanów magazynowych i wszystkiego, co odczytuje opłacone zamówienia. Zapisz konfigurację przed zmianą, aby przetestować tę samą kombinację na środowisku testowym i przywrócić ją, jeśli uruchomienie się nie powiedzie.

• Zapisz dokładne wersje PrestaShop, PHP, motywu i konektora i poproś dostawcę konektora o potwierdzenie tej kombinacji. Deklarowany zakres wersji nie jest testem Twojego sklepu.
• Wypisz pozostałe moduły procesu zakupowego i płatności, integracje przewoźników, wymagania multistore i własny kod, który zmienia koszyk, sumy lub tworzenie zamówień. Uwzględnij każdy system ERP, księgowy lub do realizacji zamówień, który pobiera opłacone zamówienia.
• Bezpiecznie zapisz obecne ustawienia konektora, konto, tryb i konfigurację powiadomień, bez kopiowania tajnych danych dostępowych do zgłoszeń lub zrzutów ekranu.
• Wykonaj odtwarzalną kopię zapasową bazy danych, plików i konfiguracji oraz przygotuj kopię testową sklepu produkcyjnego. Odizoluj środowisko testowe od prawdziwych płatności, wiadomości do klientów i eksportów do realizacji zamówień.
• Uzgodnij okno uruchomienia, kroki wycofania zmian i osobę, która uzgodni płatności i zamówienia, jeśli wrócisz do poprzedniego stanu. Rekordy operatora nie cofają się, gdy odtwarzasz bazę danych sklepu, więc odtworzenie musi chronić zamówienia i płatności otrzymane od wykonania kopii.

Połącz środowisko testowe w trybie testowym i udowodnij uzgadnianie

1. Połącz środowisko testowe z zamierzonym kontem testowym obsługiwaną przez moduł metodą połączenia. Trzymaj testowe i produkcyjne dane dostępowe osobno.
2. Skonfiguruj wymagany punkt końcowy powiadomień i jego uwierzytelnianie zgodnie z instrukcjami zainstalowanego wydania. Jeśli środowisko testowe jest za logowaniem, daj operatorowi kontrolowany dostęp tylko do tego punktu końcowego, jak opisano w sekcji o śledzeniu poniżej.
3. Wykonaj udokumentowany zakup testowy, a następnie porównaj dowody dostarczenia u operatora z przetwarzaniem w konektorze i powstałym zamówieniem.
4. Powtórz test z przerwanym powrotem przeglądarki. Zachowaj razem identyfikator koszyka, identyfikator płatności i oczekiwany wynik zamówienia dla wsparcia.

Przy każdym teście porównaj numer referencyjny płatności, kwotę i walutę z koszykiem i powstałym zamówieniem. Potwierdź oczekiwany stan zamówienia, e-maile, ruch magazynowy i eksport do kolejnych systemów, w tym ich czas. Jedna udana płatność kartą nie dowodzi działania całej ścieżki.

Sprawdź metody Mollie, zgodność i mapowanie statusów

Tabela zgodności Mollie rozróżnia generacje modułu: Mollie 6 dla PrestaShop 1.7.6 i nowszych, Mollie 5 dla wcześniejszych wydań 1.7 oraz starsze gałęzie dla dawnych sklepów. Sprawdź deklarowaną obsługę PrestaShop 9/PHP dla konkretnego wydania, zamiast traktować wszystkie wersje jako jeden przetestowany pakiet.

Korzystaj z oficjalnej dokumentacji integracji przy instalacji modułu i łączeniu konta.

Sprawdź zatwierdzenie konta i profilu, rozdzielenie trybów testowego i produkcyjnego, włączone metody oraz listę rzeczywiście dostępnych opcji w procesie zakupowym. Aktualna dokumentacja wymienia karty, metody bankowe, portfele i płatności odroczone, w tym BLIK i Przelewy24 jako osobne metody. Obecność na liście operatora nie oznacza, że każdy starszy zainstalowany moduł je udostępnia.

Potwierdź rzeczywisty URL powiadomień wygenerowany dla integracji. Nie zgaduj go na podstawie przykładu z innej wersji. Punkt końcowy może zachowywać się inaczej dla przeglądarkowego GET i wysyłanego przez operatora POST. Przekroczenie czasu w przeglądarce może dotyczyć innej trasy lub ścieżki sieciowej i nie dowodzi, że Mollie nie może dotrzeć do punktu końcowego.

Mapuj statusy zgodnie z definicjami Mollie: open/pending nie oznacza opłacenia; authorized nie oznacza pobrania środków. Zbadaj konkretną płatność, zanim ustalisz przyczynę oczekiwania lokalnego zamówienia na płatność. Następnie sprawdź dostarczenie powiadomienia, weryfikację i lokalne przetwarzanie.

W multistore sprawdź zakres danych dostępowych i profilu oraz kierowanie powiadomień dla każdego sklepu. Przetestuj każdą walutę, w tym sytuację, w której metoda związana z konkretną walutą jest niedostępna. Niedostępna metoda lokalna nie może pozostawić klienta bez użytecznej alternatywy.

Sprawdź konto Przelewy24, dane dostępowe i weryfikację

Do konfiguracji własnego modułu P24 używaj oficjalnego pakietu i instrukcji. Strona pobierania oddziela starsze pakiety 1.5/1.6 i 1.7.0-1.7.5.2 od aktualnego pakietu 1.7.6/8/9. Moduł początkowo obsługujący 1.7 nie staje się automatycznie niezgodny z nowszymi wersjami głównymi.

Potwierdź bezpośrednio z P24 wymagania rejestracji i dokumentów dla swojej formy prawnej i kraju. Bez umowy nie obiecuj akceptacji zagranicznego sprzedawcy, czasu weryfikacji ani określonych warunków przewalutowania i wypłat.

Rozróżniaj identyfikatory sprzedawcy/POS lub sklepu, dane dostępowe API i dane CRC/do podpisywania zgodnie z wybranym pakietem. W całej konfiguracji zachowaj zgodność trybu testowego i produkcyjnego. Przy błędzie podpisu sprawdź konkretne dane dostępowe, pola podpisu, serializację i dane transakcji, zamiast zakładać, że przyczyną zawsze jest końcowa spacja.

Oficjalna historia zmian obejmuje obsługę płatności w walutach innych niż PLN. Ograniczaj metodę zgodnie z jej warunkami, kontem sprzedawcy i modułem; nie ukrywaj globalnie P24 dla EUR. Zachowaj zgodność koszyka, przekazanej kwoty płatności i waluty.

Poprawne powiadomienie P24 wymaga udokumentowanych kontroli podpisu i transakcji oraz weryfikacji transakcji po stronie serwera przez API P24. Przetestuj płatność, po której klient nie wraca do sklepu. Samo oznaczenie zamówienia jako opłaconego na stronie podsumowania nie dowodzi wywołania callbacku, ponieważ integracja może też sprawdzać status podczas powrotu.

Udostępniaj obsługiwany język i metody użyteczne dla Twoich odbiorców. Dobieraj płatności kartowe i bankowe do potrzeb klientów. Osobno potwierdź obsługę zapisanego BLIK i funkcji ratalnych w module oraz na koncie.

Sprawdź integrację Stripe, portfele i wymagania płatności cyklicznych

Konfigurację i obsługiwane metody tego konektora sprawdzaj w dokumentacji modułu PrestaShop w Stripe.

Sprawdź zatwierdzenie konta, tożsamość kont testowego i produkcyjnego, klucze oraz własność obiektów. Błąd „No such payment intent” może wynikać z pomieszania środowisk lub kont albo użycia nieaktualnego obiektu płatności; sprawdź konkretny obiekt i wybrany tryb przed ponowieniem zakupu.

• Klucz publiczny: przy ręcznym użyciu kluczy jest to wartość przeznaczona dla interfejsu płatności w sklepie.
• Tajne dane dostępowe: uprawnienie po stronie serwera do wywoływania konta płatności. Trzymaj je poza motywem, kodem przeglądarki, zrzutami ekranu i wiadomościami do pomocy technicznej.
• Sekret podpisywania powiadomień: tam, gdzie jest wymagany, wartość służąca do walidacji przychodzących powiadomień. Nie jest zamienna z tajnym kluczem API.

To role, a nie reguła, że każdy konektor prosi o wszystkie trzy wartości na jednym ekranie. Express Checkout konfiguruje się na przykład za pomocą dwóch kluczy z konta płatności. Dopasuj konto, środowisko i ustawienia powiadomień do instrukcji zainstalowanego modułu.

Rejestracja webhooka może być automatyczna lub ręczna, zależnie od modułu. Używaj rzeczywistego punktu końcowego integracji, sekretu podpisu, listy zdarzeń i zakresu obsługi. Ogólna lista zdarzeń płatności, zwrotów i sporów nie jest uniwersalną instrukcją subskrybowania zdarzeń dla każdego modułu. Lista musi odpowiadać zaimplementowanej obsłudze i uzgadnianiu rozliczeń.

Strona pomocy konektora Stripe podaje, że obsługuje on płatności jednorazowe, a nie Stripe Billing. Możliwości subskrypcyjne operatora, zapisane dane i kompletna integracja odnowień w PrestaShop to osobne funkcje.

Przy płatnościach poza sesją uzyskaj odpowiednią zgodę i skonfiguruj metodę do takiego użycia. Zapewnij ścieżkę odzyskania płatności, która w razie potrzeby sprowadzi klienta z powrotem do uwierzytelnienia. Odnowienia z zapisanej karty nie gwarantują uniknięcia przyszłych dodatkowych weryfikacji.

Zarejestruj wszystkie właściwe domeny i subdomeny dla obsługiwanych portfeli zgodnie z wymaganiami Stripe dotyczącymi domen metod płatności. Google Pay także może wymagać rejestracji domeny. Rozróżniaj rejestrację domeny i weryfikację pliku Apple. Testuj kwalifikujące się urządzenia, przeglądarki i skonfigurowane konta portfeli; samo włączenie przycisku nie sprawi, że pojawi się wszędzie.

Jeśli brakuje przycisku portfela, najpierw odtwórz problem na urządzeniu i koncie, które według dostawcy konektora spełniają warunki. Następnie sprawdź wybrany kraj, walutę i ustawienia kwalifikacji w module, a dopiero potem konfigurację domeny i portfela. Opis produktu wymieniający portfele nie mówi, które z nich obsługuje zainstalowane wydanie: potwierdź Apple Pay, Google Pay lub dowolną metodę lokalną dla danego wydania, konta, kraju, waluty i urządzenia. Odróżniaj niedostępną metodę od niedziałającego procesu zakupowego; kupujący, który nie spełnia warunków, nadal potrzebuje użytecznej alternatywy.

Weryfikuj status i przetwarzaj każdą płatność tylko raz

Oddziel utworzenie płatności u operatora, zatwierdzenie i powrót przeglądarki, obsługę powiadomień, utworzenie lokalnego zamówienia i późniejsze zmiany statusu. Zależnie od integracji serwer może sprawdzać status przy powrocie przeglądarki, przez webhook lub zadanie uzgadniające. Potwierdzaj płatność przez uwierzytelniony mechanizm statusu lub powiadomień operatora.

1. Uwierzytelnij powiadomienie za pomocą udokumentowanego podpisu lub mechanizmu weryfikacji operatora. W razie potrzeby pobierz wiążący status.
2. Zweryfikuj konto sprzedawcy, tryb testowy lub produkcyjny, identyfikator płatności operatora, powiązanie z koszykiem lub zamówieniem, oczekiwaną kwotę i walutę. Stosuj konwencje jednostek walutowych operatora.
3. Rozróżniaj stany oczekiwania, autoryzacji, pobrania środków/opłacenia, niepowodzenia, anulowania, wygaśnięcia, częściowego zwrotu i pełnego zwrotu.
4. Trwale oznacz zdarzenie lub transakcję jako przejęte do obsługi, aby równoległe procesy i późniejsze ponowienia nie zastosowały go dwukrotnie. Sama deduplikacja zdarzeń nie wystarcza, gdy kilka typów zdarzeń opisuje tę samą płatność.
5. Twórz zamówienie tylko wtedy, gdy wymaga tego zweryfikowany proces i koszyk nie ma jeszcze zamówienia. Aktualizuj istniejące oczekujące zamówienie przez odpowiedni proces płatności i historii.
6. Zapisz wynik i błędy pozwalające na ponowienie. Potwierdzaj odbiór dopiero po przetworzeniu lub bezpiecznym, trwałym zapisaniu w kolejce zgodnie z projektem integracji.

Metoda rdzenia PaymentModule::validateOrder() odrzuca koszyk, który ma już zamówienie. Nie używaj jej jako uniwersalnej funkcji „przenieś oczekujące zamówienie do następnego etapu”.

Powroty, powiadomienia i zaplanowane uzgadnianie muszą korzystać z tych samych zweryfikowanych reguł zmiany stanów. Zduplikowane zdarzenia lub zdarzenia w niewłaściwej kolejności nie mogą tworzyć dodatkowych zamówień, płatności, zmian stanów magazynowych ani e-maili. Zmiany statusu istniejących zamówień wymagają odpowiednich API historii i płatności, a nie bezpośredniego SQL zmieniającego wyświetlany stan.

Utworzenie zamówienia może wpłynąć na stan magazynowy przed potwierdzeniem płatności, zależnie od integracji i stanu zamówienia. Nie wywodź rezerwacji ani zmniejszenia zapasu wyłącznie z etykiety statusu płatności.

Prześledź opłaconą transakcję z oczekującym lub brakującym zamówieniem

1. Zapisz numer referencyjny płatności, konto, tryb testowy lub produkcyjny, kwotę, walutę i czas. Sprawdź rzeczywisty stan transakcji w panelu lub API operatora. Potwierdź pobranie środków, a nie samo zatwierdzenie czy autoryzację, i sprawdź konto oraz tryb. Porównaj ten stan z uzgodnionym stanem pozwalającym na realizację.
2. Dopasuj transakcję do sklepu, koszyka lub zamówienia, kwoty i waluty. Szukaj koszyków, zamówień i logów konektora według numeru referencyjnego płatności, a nie tylko nazwiska klienta. Sprawdź możliwe podzielone zamówienia lub inną próbę płatności.
3. Sprawdź logi dostarczania powiadomień: adres docelowy, metodę, odpowiedź, ponowienia i znaczniki czasu.
4. Przejrzyj logi reverse proxy, WAF, certyfikatów i aplikacji dla tego punktu końcowego. Strony logowania, uwierzytelnianie podstawowe, tryb konserwacji i wyzwania przeglądarkowe mogą blokować żądanie operatora.
5. Sprawdź weryfikację podpisu, wyjątki w obsłudze, brakujące mapowania, blokady i zapisy do bazy danych po dostarczeniu. Własny kod zamówień lub integracja z ERP działająca podczas walidacji zamówienia może zawieść już po dotarciu poprawnego powiadomienia.
6. Poproś opiekuna modułu o zestawienie rekordu operatora z błędem serwera i logami modułu. Przed udostępnieniem dowodów usuń dane dostępowe i zbędne dane klientów.
7. Ponów obsługę lub uzgodnij stan przez obsługiwany proces idempotentny. Pobierz aktualny stan, zanim cokolwiek utworzysz lub oznaczysz zamówienie jako opłacone.

Wstrzymaj realizację, dopóki stan jest nierozstrzygnięty. Nie proś klienta o ponowną płatność ani nie oznaczaj zamówienia jako opłaconego, aby oczyścić kolejkę zgłoszeń, dopóki pierwotna płatność nie zostanie uzgodniona: kolejna próba może obciążyć klienta dwukrotnie.

Stosuj wąsko zakreślone, udokumentowane reguły punktów końcowych, zachowując uwierzytelnianie powiadomień. Udany GET, HTTP 200 z niepowiązanej strony lub powrót przeglądarki nie dowodzą poprawnego przetworzenia webhooka. Dostępny punkt końcowy nadal może odrzucić podpis lub zakończyć się błędem po przyjęciu żądania.

Przy pracy lokalnej lub na prywatnej kopii testowej użyj autoryzowanego mechanizmu przekierowania lub testów, jeśli operator wymaga publicznej osiągalności, albo daj operatorowi kontrolowany dostęp tylko do punktu końcowego powiadomień, bez udostępniania całej kopii i osłabiania kontroli podpisów. Nie zakładaj, że operator może wywołać prywatny adres localhost. Sprawdź zachowanie ponowień każdego operatora, zamiast kopiować uniwersalny limit czasu 30 sekund.

Prześledź opłacone zamówienie bez powrotu przeglądarki

Klient kupuje personalizowany kubek, kończy płatność i zamyka przeglądarkę w telefonie przed stroną potwierdzenia. Pracownicy widzą płatność u operatora, ale nie mogą znaleźć oczekiwanego zamówienia. Testem odbioru jest to, czy integracja odtworzy uzgodnioną zawartość zamówienia i zapisze płatność bez proszenia klienta o ponowną zapłatę.

Przećwicz ten przypadek na środowisku testowym. Przed rozpoczęciem zachowaj wybraną personalizację, adres dostawy, przewoźnika, końcową sumę i walutę. Następnie dopasuj numer referencyjny płatności do koszyka i wszystkich powstałych zamówień oraz sprawdź personalizację i instrukcje dostawy, a także kwotę. Płatność przypisana do niewłaściwego koszyka to nadal nieudana ścieżka zakupu.

Jeśli powiadomienie dotrze później, potwierdź, że zamówienie osiąga uzgodniony stan realizacji dokładnie raz. Zapytaj dostawcę, jak jego obsługiwana procedura uzgadniania obsługuje ten przypadek. Ręczne utworzenie zamówienia, gdy odzyskiwanie nadal trwa, może wygenerować drugie zamówienie, a ręczna naprawa powinna przebiegać udokumentowaną ścieżką odzyskiwania konektora, przećwiczoną na środowisku testowym, a nie przez bezpośrednią edycję bazy danych.

Uzgadniaj zwroty, anulowania i rozliczenia

Oddziel anulowanie autoryzacji, zwrot płatności, wystawienie korekty, wydanie kuponu, zwrot towaru do magazynu i zmianę stanu zamówienia. Zmiana etykiety w PrestaShop na „zwrócono” nie dowodzi, że bramka zwróciła pieniądze.

1. Potwierdź pierwotną płatność oraz kwotę pobraną i możliwą do zwrotu.
2. Zainicjuj pełny lub częściowy zwrot przez obsługiwany proces integracji lub operatora.
3. Zapisz jego numer referencyjny u operatora i obserwuj wynik: oczekujący, udany lub nieudany.
4. Zaktualizuj lokalny zapis płatności lub księgowy i stan magazynowy wyłącznie zgodnie z rzeczywistym zwrotem i polityką zwrotów.
5. Uzgodnij salda i wypłaty operatora ze sprzedażą, opłatami, zwrotami i sporami.

Unikaj zwrotu raz w module i drugi raz w panelu operatora. Zapisz, czy pracownicy rozpoczynają zwroty w PrestaShop, czy w panelu operatora, i kto uzgadnia zwrot rozpoczęty w innym miejscu. Sprawdź dla każdej metody obsługiwany okres zwrotu, możliwość częściowego zwrotu, niezwracane opłaty za przetwarzanie i terminy rozliczeń. Operator może wypłacać środki w innej walucie lub według innego harmonogramu niż obciążenie klienta.

Przetestuj częściowy zwrot dla zamierzonych pozycji zamówienia i opłaty za dostawę, a następnie potwierdź kwotę u operatora, rekord zamówienia i każdy wymagany dokument księgowy. O przyjęciu towaru na stan decyduj osobno: odesłanie pieniędzy nie dowodzi, że towar dotarł do magazynu.

Przechowuj odpowiednie faktury, dane śledzenia i potwierdzenia doręczenia, komunikację z klientem i oryginalne wiadomości zgodnie z właściwą polityką retencji. Historia zamówień w rdzeniu zapisuje historię stanów; nie archiwizuje automatycznie każdego dokumentu potrzebnego w sporze. Zapewnij dostęp do tych dowodów wskazanemu pracownikowi, sprawdzaj instrukcje odpowiedzi i termin każdej sprawy na koncie operatora i nie zakładaj, że ustawienia zwrotów w module zapewniają też proces obsługi sporów.

Oceń warunki, prezentację i rentowność BNPL

Klarna, Clearpay/Afterpay, PayPal Pay Later, Riverty i inne produkty różnią się rynkiem, warunkami dla sprzedawcy, planem płatności i integracją. Sprawdź rzeczywistą ofertę, zamiast zakładać, że każdy klient otrzymuje taką samą umowę na trzy lub cztery raty.

Zweryfikuj autoryzację, pobranie środków, raportowanie wysyłki, częściowe pobranie, anulowanie, zwroty i terminy wypłat. Niektóre integracje pobierają środki przy wysyłce. Nie wysyłaj wyłącznie na podstawie zatwierdzenia ani nie zakładaj, że standardowy proces realizacji pozostaje bez zmian.

Kredytodawca może przejąć określone ryzyko kredytowe, ale sprzedawca zachowuje obowiązki umowne i narażenie na spory dotyczące dostawy lub inne roszczenia regresowe. Przeczytaj rzeczywiste warunki ochrony. Obsługa cykliczna zależy od produktu operatora i integracji obsługującej odnowienia; nie jest zawsze niemożliwa ani automatycznie dostępna.

Porównaj opłaty umowne, opłaty stałe, przewalutowanie, podatki i zasady opłat przy zwrotach. Nie zakładaj, że BNPL zawsze ma konkretną dopłatę względem kart ani że jego cena nie przekracza 6%. Aktualna strona PayPal UK publikuje własną cenę Pay Later, więc stare ogólne stwierdzenie „bez dopłaty” nie może zastępować tej oferty.

Dla przykładowej kategorii o miesięcznej sprzedaży 10 000 EUR hipotetyczna dopłata trzech punktów procentowych kosztuje 300 EUR, jeśli cała ta sprzedaż przejdzie z pierwotnej metody, jeszcze przed dodatkowymi zamówieniami. Aby ocenić opłacalność zmiany, potrzebujesz rzeczywistego przeniesionego wolumenu, nowych zamówień i marży pokrycia.

Wyświetlaj zatwierdzone przez operatora komunikaty ratalne przy odpowiednich cenach produktów i w procesie zakupowym, gdy warunki na to pozwalają. Na przykład 99,99 EUR można przedstawić jako trzy płatności po 33,33 EUR tylko wtedy, gdy obowiązuje dokładnie taki plan i wymagane informacje. Aktualizuj komunikaty przy zmianie ceny, waluty lub wybranego produktu.

Jeśli komunikaty znikają, sprawdź warunki dostępności, konfigurację operatora i klienta, skrypty, kontenery i rzeczywisty hook motywu. Brak hooka to jedna z możliwych przyczyn. Nie zakładaj, że określona wartość koszyka lub przedział wiekowy wyznaczają rentowną grupę odbiorców.

Stosuj przepisy kraju klienta. Artykuł 48 dyrektywy (UE) 2023/2225 przewiduje stosowanie środków od 20 listopada 2026 r., z uwzględnieniem wdrożenia krajowego. FCA objęła odpowiednie brytyjskie kredyty Deferred Payment Credit regulacją 15 lipca 2026 r.. Ocena kredytowa pożyczkodawcy nie usuwa obowiązków sprzedawcy dotyczących prezentacji i umowy.

Gdy to możliwe, porównuj losowo dobrane grupy spełniające warunki. Wyższe koszyki użytkowników BNPL mogą wynikać z doboru klientów, a nie ze związku przyczynowego. Uwzględnij zastępowanie innych metod, zwroty i opłaty oraz unikaj sztywnych reguł „60 dni i 200 zamówień”.

Prawidłowo obsługuj uwierzytelnianie i zakres PCI

SCA dotyczy objętych nim płatności elektronicznych zgodnie z właściwymi przepisami, z wyłączeniami i zwolnieniami. Przepisy EOG i Wielkiej Brytanii mają własne podstawy prawne. PSP może zażądać uwierzytelnienia lub zwolnienia, a o wyniku decyduje wydawca. Uwierzytelnianie może korzystać z aplikacji, kodu lub innego obsługiwanego mechanizmu.

Korzystaj z utrzymywanej obsługi EMV 3DS. Możliwy jest zarówno wynik bez dodatkowej interakcji, jak i wyzwanie; 3DS1 nie jest aktualną alternatywą zalecaną w Europie. Przedłużony przez FCA termin wdrożenia dla e-commerce upłynął 14 marca 2022 r..

3DS może przenieść odpowiedzialność za kwalifikujące się spory dotyczące oszukańczych płatności, z zastrzeżeniem warunków i wyjątków systemu oraz operatora. Nie chroni przed każdym sporem, problemem z dostawą ani transakcją objętą zwolnieniem. Sprawdź wynik uwierzytelniania i odpowiedzialność dla konkretnej płatności.

Domena strony otaczającej formularz nie wyznacza zakresu. Ustal, kto dostarcza pola i którędy przechodzą dane karty. Potwierdź właściwy SAQ i obowiązki walidacji z agentem rozliczeniowym lub podmiotem akceptującym zgodność.

PCI SSC FAQ 1604 potwierdza obowiązek skanowania ASV odpowiednich stron e-commerce objętych SAQ A, w tym przekierowań i osadzonych iframe. Nie opisuj SAQ A jako błahej corocznej formalności ani skanowania jako obowiązku wyłącznie SAQ D; uwzględnij wymagane skany kwartalne.

Dla osadzonych formularzy płatności aktualny SAQ A zawiera także warunek kwalifikacji dotyczący ataków skryptowych opisany w PCI SSC FAQ 1588. Przetwarzanie hostowane ogranicza bezpośredni kontakt z danymi kart, ale przejęta strona sprzedawcy nadal może przekierowywać kupujących lub wstrzyknąć fałszywy formularz zbierający dane.

Korzystaj z sygnałów oszustw i miej procedurę reagowania na incydenty

Kontrole AVS i CVV to ograniczone sygnały. Poprawny CVV nie dowodzi fizycznego posiadania karty ani uczciwości kupującego. Kontrole mogą być niedostępne, a prawidłowe adresy mogą się nie zgadzać. Przeanalizuj zachowanie wydawców i krajów oraz wyniki weryfikacji operatora.

Oceniaj częstotliwość prób płatności, powtarzające się błędy, nietypowe zmiany wysyłki i odpowiednie sygnały konta lub urządzenia, stosując proporcjonalne zabezpieczenia. Dane zamówień i koszyków PrestaShop mogą pomóc w analizie, ale nie zapewniają uniwersalnego mechanizmu identyfikacji urządzeń ani wykrywania oszustw między kontami. Testuj reguły ryzyka bramki pod kątem fałszywych alarmów.

Dobierz ręczną weryfikację lub dodatkowe kontrole do wartości zamówienia, ryzyka odsprzedaży produktu, częstotliwości ataków i narażenia na spory. Nie ma uniwersalnego progu liczby zamówień, poniżej którego zabezpieczenia przed oszustwami są zbędne.

Nie zapisuj numerów kart ani wrażliwych danych uwierzytelniających w logach aplikacji, narzędziach debugowania ani zgłoszeniach do pomocy. Tokeny i numery referencyjne transakcji nadal wymagają kontroli dostępu; treść webhooków też może zawierać dane osobowe. Loguj wyłącznie oczyszczone pola potrzebne do diagnozy.

1. Odizoluj dotkniętą trasę lub przejęty komponent i wstrzymaj niebezpieczną realizację zamówień.
2. Zabezpiecz odpowiednie logi i dowody bez zbierania dodatkowych danych kart.
3. Skontaktuj się z PSP/agentem rozliczeniowym i odpowiednimi specjalistami od incydentów, wymień przejęte dane dostępowe i ustal zakres zdarzenia.
4. Oceń obowiązki powiadomienia o naruszeniu danych osobowych i przekazuj rzetelne informacje.
5. Napraw i zweryfikuj integrację przed wznowieniem normalnego przetwarzania.

Jeśli obowiązuje GDPR i jesteś administratorem danych, art. 33 wymaga zgłoszenia właściwemu organowi bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia naruszenia, chyba że ryzyko dla osób jest mało prawdopodobne. Osobno oceń obowiązek zawiadomienia osób zgodnie z art. 34.

Przetestuj cały cykl i zmierz wynik

Używaj środowisk testowych, testowych danych dostępowych i wartości obsługiwanych przez operatora. Przy odrębnej walidacji produkcyjnej przestrzegaj jego zasad. Nigdy nie wpisuj prawdziwych danych karty do środowiska testowego tylko dlatego, że prosi o to poradnik.

Dokumentacja testowa Stripe podaje następujące przykłady dla trybu testowego:

Wykonaj każdy scenariusz na środowisku testowym i zachowaj dowody, aby móc powtórzyć kontrolę po zmianie motywu, konektora lub integracji.

W każdym scenariuszu sprawdź lokalne rekordy płatności, zachowanie stanów magazynowych, historię zamówienia, e-maile i ostateczne rozliczenie u operatora. Powtórz z portfelami mobilnymi, metodami lokalnymi, każdą obsługiwaną walutą, multistore i swoim rzeczywistym motywem oraz procesem zakupowym. Udany test kartą testową nie dowodzi, że działają portfele lub zwroty, więc zachowaj dowody z właściwego urządzenia i powstałego zamówienia PrestaShop.

Zapisuj próby zakupu, porzucenia na etapie płatności, powodzenia i błędy u operatora, użycie metod, zwroty, zgłoszenia do obsługi, szybkość procesu zakupowego i marżę. Dziel dane według krajów i urządzeń tylko wtedy, gdy Twoje raportowanie rzeczywiście je dostarcza. Lista Koszyki zakupowe w PrestaShop 9.1 zawiera statusy zamówione, niezamówione i porzucone, bez natywnego filtra kraju. Wybierz zamierzony status i do podziału według krajów użyj eksportu o ograniczonym zakresie lub odpowiedniej analityki.

Zapis koszyka nie mówi, dlaczego klient odszedł. Gdy to możliwe, porównuj kontrolowane zmiany, uwzględniaj sezonowość i strukturę klientów oraz obserwuj ruch spełniający kryteria w ilości wystarczającej do wykrycia szukanego efektu. Nie obiecuj wzrostu konwersji ani nie wybieraj operatora na podstawie ogólnej średniej branżowej.

Uruchom zmianę i przekaż ją dalej

Gdy środowisko testowe przejdzie testy, postępuj zgodnie z instrukcjami konektora dotyczącymi trybu produkcyjnego i zasadami operatora dla uzgodnionej weryfikacji na produkcji. Zachowaj poprzednią konfigurację i kroki wycofania zmian. Po uruchomieniu obserwuj rzeczywiste zamówienia, płatności i przekazania do realizacji, a po zmianach motywu, konektora lub integracji powtarzaj odpowiednie testy.

O co zapytać programistę przed przekazaniem

• Które wydanie modułu i konfigurację sklepu przetestowano i gdzie są wyniki?
• Co tworzy lub odzyskuje zamówienie, gdy przeglądarka nigdy nie wraca, i jak obsługiwane są powtarzane powiadomienia?
• Które stany płatności pozwalają na realizację i jak zwroty, spory oraz metody z opóźnionym rozliczeniem trafiają do pracowników?
• Jak kupujący wraca do zakupu po nieudanym lub anulowanym uwierzytelnieniu i które kombinacje płatności i przewoźnika są wykluczone?
• Gdzie pracownicy znajdą zanonimizowane logi, identyfikator płatności, instrukcje odzyskiwania i osobę odpowiedzialną za niewyjaśnioną płatność?