Płatności kartą w sklepie: konfiguracja WooCommerce

Zapisz nazwę i wersję rozszerzenia, wersję WooCommerce oraz rodzaj checkoutu. Kilka wtyczek może łączyć sklep z tym samym operatorem, lecz ich ustawienia i obsługiwane funkcje nie muszą być identyczne. Nie przenoś instrukcji między nimi wyłącznie na podstawie nazwy Stripe.

Karta kredytowa i debetowa różnią się sposobem finansowania płatności. Logo sieci nie wskazuje automatycznie rodzaju karty. Zakres akceptacji potwierdź dla operatora, konta, kraju i waluty, zamiast deklarować obsługę każdej marki we wszystkich sytuacjach. Jeśli dopiero oceniasz potrzebę tej metody, zacznij od decyzji o kartach w sklepie.

Wymień wymagane scenariusze: jednorazowy zakup, zapisanie metody, subskrypcja lub późniejsze pobranie środków. Każdy potrzebuje osobnego potwierdzenia. Podstawowa płatność nie dowodzi obsługi całego procesu cyklicznego.

Sprawdź także istniejące integracje. Zapisz, czy inny moduł już obsługuje karty lub odbiera zdarzenia operatora. Nie uruchamiaj drugiego mechanizmu bez określenia roli pierwszego. Przy migracji potrzebny jest plan przełączenia oraz zachowania obsługi wcześniejszych transakcji, nie tylko nowy formularz.

Przed konfiguracją wykonaj inwentaryzację środowiska i zaplanuj możliwość odtworzenia. Przygotuj kopię do prób oraz listę zależności: motyw, dodatkowe pola, waluty, podatki i reguły dostawy. Jeśli formularz zamówienia został zmodyfikowany, uwzględnij te zmiany w odbiorze.

Sprawdź konto sprzedawcy, jego status i zakres udostępnionych funkcji. Połączenie techniczne nie usuwa ewentualnych ograniczeń konta. Ustal osobę mającą odpowiednie uprawnienia do operatora oraz osobę odpowiedzialną za konfigurację sklepu. Nie przekazuj sekretów przez treść zgłoszenia ani dokumentację projektu.

Sklep i zasoby checkoutu powinny korzystać z prawidłowo skonfigurowanego HTTPS. Przewodnik bezpieczeństwa Stripe opisuje wspólną odpowiedzialność za PCI DSS. Komponent przekazujący dane karty bezpośrednio operatorowi może ograniczyć zakres obowiązków, ale nie znosi ich całkowicie.

Nie projektuj przechowywania pełnych danych kart w bazie sklepu. Sprawdź także logi, narzędzia nagrywania sesji i zgłoszenia błędów. Do diagnozy potrzebujesz identyfikatora operacji oraz informacji o stanie, a nie numeru karty i kodu CVV.

Uzgodnij z osobą utrzymującą witrynę zakres dostępu skryptów i komunikacji. Ochrona strony nie powinna być wyłączana globalnie tylko po to, aby formularz zaczął się wyświetlać.

W opisanym rozszerzeniu przejdź do WooCommerce > Ustawienia > Płatności > Stripe. Przewodnik ustawień wskazuje osobne zakładki Live i Test w konfiguracji połączenia. Poprawny stan jednej nie potwierdza gotowości drugiej.

Na kopii przygotuj wyłącznie połączenie testowe. Zweryfikuj, że integracje zewnętrzne, wiadomości, CRM i pomiar nie trafią do usług produkcyjnych. Sama kopia bazy albo dopisek test w adresie nie zapewniają izolacji. Sprawdź także zadania uruchamiane w tle.

Dokumentacja testowania rozszerzenia Stripe opisuje połączenie testowe i tryb testowy. Używaj scenariuszy oraz danych testowych operatora, nigdy rzeczywistej karty do sprawdzania przypadków odmowy lub zwrotu. Jeżeli potrzebna jest tylko walidacja logiki sklepu, zastosuj testowe odpowiedzi zamiast wywoływania operacji finansowej.

Przed późniejszym przełączeniem przygotuj listę różnic środowisk: konto, domena, ustawienia metody i adres odbioru zdarzeń. Odbiór testów nie oznacza, że wolno bez sprawdzenia skopiować wszystkie dane połączenia na produkcję.

Zapisz wersję konfiguracji, datę i osobę zatwierdzającą zakres. Taki ślad pozwala ustalić, czy przyszły problem pojawił się po aktualizacji, zmianie konta czy modyfikacji checkoutu.

Lista Payment Methods służy do wyboru metod, a Enable Stripe steruje ich prezentacją w checkout. To różne ustawienia. Zaznaczenie karty na liście nie zastąpi poprawnego połączenia i spełnienia wymagań. Dostępność metody w panelu Stripe nie oznacza też, że każda z nich jest obsługiwana przez rozszerzenie.

Po zapisaniu ustawień na kopii sprawdź widok dla reprezentatywnego koszyka. Użyj właściwej waluty, adresu i rodzaju produktu. Jeśli formularz się nie pojawia, ustal, czy problem dotyczy całego checkoutu, tylko tej metody czy wybranego scenariusza. Nie zaczynaj od przypadkowego przełączania wszystkich opcji.

Zobacz, jak klient rozpoznaje metodę i jej komunikaty. Nazwa powinna odpowiadać faktycznej usłudze, a błędy nie mogą znikać poza widocznym obszarem. Sprawdź telefon, obsługę klawiaturą i powrót po przerwaniu procesu.

Portfele ekspresowe oceniaj oddzielnie. Widoczny przycisk portfela nie jest dowodem poprawnego działania klasycznego formularza kart i odwrotnie. Konfigurację tego wariantu opisuje poradnik Google Pay w WooCommerce.

Gdy porównujesz różne metody, zachowaj pozostałe warunki koszyka. Zmiana produktu lub kraju pomiędzy próbami może dać inny wynik bez jakiejkolwiek awarii integracji.

Ustal, czy sklep używa klasycznego formularza, czy Checkout Block. Rozszerzenie płatnicze, dodatkowe pola i motyw muszą współpracować z używanym wariantem. Nie wystarczy sprawdzić samego edytora strony: obejrzyj wynik renderowania oraz walidację danych.

Przygotuj koszyk z produktem fizycznym, a jeśli sprzedajesz także wirtualne, sprawdź je osobno. Uwzględnij zmianę adresu, podatku, dostawy i rabatu. Kwota kierowana do płatności musi odpowiadać ostatecznie zaakceptowanemu podsumowaniu, a waluta nie może wynikać z przypadkowej wartości domyślnej.

Nie usuwaj wymaganych pól, aby wymusić przejście formularza. Najpierw ustal, dlaczego walidacja i integracja się rozmijają. Dodatkowe pole może być potrzebne do realizacji, rozliczenia lub określonego modelu sprzedaży. Rozwiązanie powinno zachować jego rolę.

Sprawdź komunikaty dla brakującej informacji i możliwość poprawy bez utraty całego koszyka. Potwierdź również dostępność warunków zakupu przed zatwierdzeniem. Przy ekspresowej ścieżce nie zakładaj, że wszystkie informacje z pełnego checkoutu zostaną pokazane automatycznie.

Wynik odbioru zapisz jako scenariusz, oczekiwanie i zaobserwowany rezultat. Ogólne stwierdzenie formularz działa nie pokazuje, dla jakiego koszyka i wariantu strony zostało to potwierdzone.

3-D Secure służy uwierzytelnieniu płatnika. Autoryzacja, pobranie środków i wypłata dla sprzedawcy to kolejne, odrębne pojęcia. Ich pomylenie może prowadzić do realizacji zamówienia, którego płatność nie osiągnęła oczekiwanego stanu.

Opcja Issue an authorization on checkout, and capture later rezerwuje środki zamiast automatycznie je pobierać. Przed jej użyciem ustal proces późniejszego capture i osobę odpowiedzialną. Nie włączaj tego ustawienia tylko dlatego, że brzmi jak dodatkowe zabezpieczenie.

Nie naprawiaj niezgodności przez ręczne ustawienie zamówienia jako opłacone. Taka zmiana nie wykonuje płatności. Najpierw porównaj stan operatora, zdarzenia i historię zamówienia, a następnie zastosuj procedurę właściwą dla potwierdzonego problemu.

Webhook przekazuje do sklepu informację o zdarzeniu po stronie operatora. Powrót przeglądarki na stronę podziękowania nie powinien być jedynym dowodem oceny całego procesu. Klient może przerwać nawigację, a odpowiedź usługi dotrzeć później.

Dokumentacja webhooków rozszerzenia podaje, że od wersji 8.6.1 tworzy je połączenie ze Stripe. Sprawdź status osobno w Live i Test oraz informację o przetwarzaniu. Nie dodawaj kolejnego endpointu bez ustalenia, co już istnieje.

Ponowna konfiguracja webhooków jest zmianą połączenia, nie neutralnym odczytem. Dokumentacja opisuje odtwarzanie właściwych wpisów i usuwanie starych kierujących do witryny. Przed taką operacją potrzebujesz rozpoznania i kontrolowanego planu, zwłaszcza gdy konto obsługuje więcej integracji.

W diagnostyce porównaj identyfikator zdarzenia, operacji i zamówienia. Sprawdź opóźnioną odpowiedź oraz ponowienie tego samego komunikatu w izolowanych testach. Powtórzenie nie powinno tworzyć kolejnego zamówienia ani drugiego skutku tej samej operacji.

Przy rozbieżnościach skorzystaj z poradnika duplikatów zamówień i płatności. Nie wysyłaj ponownie realnego żądania finansowego tylko po to, aby zobaczyć, czy status się poprawi.

Przed udostępnieniem metody przejdź przez przypadki pozytywne i negatywne. Sprawdź kwotę, walutę, zmianę koszyka, odmowę, przerwanie uwierzytelnienia oraz opóźniony webhook. Wszystkie próby powinny pozostawać w uzgodnionym środowisku testowym, odizolowanym od rzeczywistej obsługi klienta.

Odbierz także to, czego nie powinno być: danych karty w logach, podwójnego zamówienia, wiadomości do realnego klienta i zdarzeń w produkcyjnej analityce. Samo udane przejście do podziękowania nie zamyka tych kontroli.

Ustal, kto reaguje na błąd i gdzie szuka informacji. Dokumentacja powinna zawierać wersje komponentów, zakres obsługiwanych scenariuszy i znane ograniczenia. Aktualizacja motywu, checkoutu lub rozszerzenia wymaga kontroli odpowiednich zależności, a nie automatycznego założenia zgodności.

Wycena wdrożenia zależy od obecnej konfiguracji, dodatkowych pól i potrzebnej integracji. Nie utożsamiaj kosztu operatora z kosztem pracy technicznej. Przy planowaniu sklepu internetowego uwzględnij konfigurację, odbiór i późniejszą obsługę. Przez kontakt możesz przekazać nazwę platformy, rozszerzenia i opis wymaganego procesu bez danych kart oraz sekretów konta.