Duplikaty zamówień i podwójne płatności w WooCommerce: diagnoza i naprawa

Dwa wpisy zamówienia oznaczają dwa rekordy w sklepie. Nie mówią jeszcze, ile razy operator pobrał pieniądze. Osobno rozpoznaj autoryzację, czyli zarezerwowanie środków, oraz capture, czyli ich pobranie w przepływach rozdzielających te operacje. Widoczna blokada na rachunku może mieć inny status niż rozliczona płatność. Wyjaśnienie wymaga danych operatora, a czasem również banku klienta.

Webhook jest powiadomieniem o zdarzeniu. Powtórna dostawa informacji o tej samej płatności nie stanowi sama w sobie nowego obciążenia. Błąd integracji może natomiast ponownie wykonać skutek uboczny: wysłać dokument, zmienić magazyn albo utworzyć dodatkowe zamówienie. Jeśli kod po otrzymaniu powiadomienia sam zleca kolejne operacje finansowe, trzeba sprawdzić również te żądania.

Nie usuwaj od razu duplikatu z panelu. Najpierw zachowaj powiązania z płatnością, fakturą i przesyłką. Pochopne czyszczenie utrudnia wyjaśnienie sprawy i może uruchomić następną automatyzację.

Zapisz identyfikatory obu zamówień, kwoty, walutę, metodę płatności oraz identyfikatory operatora. Ustal, czy klient ponawiał zakup i jaki komunikat widział. Korzystaj z minimalnego zakresu danych; do analizy technicznej nie potrzebujesz numeru karty ani pełnej kopii danych osobowych. Logów z sekretami nie przesyłaj zwykłym formularzem kontaktowym.

W WooCommerce sprawdź notatki zamówienia i dostępne logi integracji w sekcji Status. Jeżeli logowanie nie było aktywne, jego włączenie nie odtworzy historii. Zabezpiecz istniejące pliki przed rotacją i ustal ograniczony czas dodatkowego logowania. Zestaw je z historią żądań operatora, błędami aplikacji oraz czasami odpowiedzi serwera.

Przelicz znaczniki czasu do jednej strefy. Odstęp kilku sekund może pasować do ponowienia formularza, ale nie dowodzi przyczyny. Kilka minut między wpisami również nie potwierdza retry webhooka. Szukaj ciągu: żądanie klienta, utworzenie zamówienia, żądanie API, odpowiedź operatora i odebrana zmiana statusu. Ten sam identyfikator płatności może prawidłowo występować w wielu wpisach logu.

Na końcu oznacz lukę w dowodach. Gdy brak identyfikatora wychodzącego żądania, uczciwy wynik brzmi: mechanizm niepotwierdzony. Audyt cyfrowy może wtedy objąć uzupełnienie obserwowalności i przygotowanie reprodukcji, zamiast wdrażania przypadkowej poprawki.

Ponowne wysłanie formularza jest jedną z hipotez. Sprawdź obsługę przycisku, błędy JavaScript, klawisz Enter, odświeżenie i powrót z operatora. Blokada przycisku oraz informacja o przetwarzaniu pomagają użytkownikowi, lecz nie zastępują kontroli po stronie serwera. Dwa równoległe żądania mogą dotrzeć także bez dwóch świadomych kliknięć.

Ponowione powiadomienie jest normalnym scenariuszem integracji. Dokumentacja webhooków Stripe zaleca przygotowanie obsługi na duplikaty i brak gwarantowanej kolejności zdarzeń. Pytanie diagnostyczne brzmi więc: czy ponowienie spowodowało drugi efekt, a nie: czy powiadomienie pojawiło się ponownie?

Cache strony kasy może zaburzać dane zależne od sesji. WooCommerce opisuje wykluczenie koszyka i checkoutu z cache stron. Sprawdź wszystkie warstwy: wtyczkę, serwer i CDN. Sam fakt włączenia cache w sklepie nie dowodzi jednak źródła duplikatu. Statyczne obrazy mogą być buforowane niezależnie od dynamicznej odpowiedzi kasy.

Nakładające się integracje wymagają mapy odpowiedzialności. Ustal, która wtyczka inicjuje płatność, która odbiera status, a która przekazuje zamówienie dalej. Kilka endpointów może być zamierzonych. Nie usuwaj ich wyłącznie dlatego, że jest ich więcej niż jeden; sprawdź przeznaczenie każdego adresu i obsługiwane zdarzenia.

Przy problemie z formularzem popraw informację zwrotną i blokadę wielokrotnej wysyłki, a następnie sprawdź serwerową obsługę ponowienia. Rozwiązanie powinno zwracać wynik istniejącej operacji tam, gdzie użytkownik ponawia tę samą próbę. Jednocześnie musi pozwalać na świadome nowe zamówienie. Sama zgodność kwoty i adresu e-mail nie jest bezpiecznym kluczem deduplikacji.

Przy webhookach zweryfikuj podpis zgodnie z dokumentacją konkretnego operatora. Dopiero poprawne zdarzenie wiąż z właściwym zamówieniem. Kontrola przetworzenia musi być atomowa: dwa równoległe procesy nie mogą jednocześnie odczytać stanu nieprzetworzone i oba wykonać operacji. W zależności od architektury stosuje się ograniczenie unikalności, transakcję lub odpowiednio zaprojektowaną blokadę oraz rejestr stanów.

Szybka odpowiedź nie powinna oznaczać utraty zdarzenia. Przed potwierdzeniem odbioru zweryfikuj je i zapewnij trwały zapis lub przekazanie do trwałej kolejki. Następnie cięższa obsługa może działać asynchronicznie. Jeśli zapis się nie udał, nie potwierdzaj sukcesu tylko po to, aby panel operatora pokazywał zielony status. Potrzebny jest również mechanizm ponawiania pracy zakończonej błędem.

Konflikty dodatków, aktualizacje i zmiany cache sprawdzaj na stagingu z kopią oraz planem wycofania. Zmieniaj jeden podejrzany element, odtwarzaj scenariusz i zapisuj rezultat. W produkcji wdrażaj sprawdzony zakres. Ogólną konfigurację opisuje instrukcja checkoutu WooCommerce.

Stripe opisuje klucze idempotency dla żądań API. Przy ponowieniu tej samej operacji POST z właściwym kluczem operator może zwrócić zapisany wynik zamiast wykonywać operację od nowa. Klucz musi reprezentować konkretną operację, a nie każde zamówienie na zawsze. Nowy klucz przy każdym retry niweczy oczekiwane zabezpieczenie.

Stripe wskazuje możliwość usunięcia kluczy po co najmniej 24 godzinach. Nie jest to obietnica identycznego, dokładnie dobowego okna dla całej integracji. Nie przenoś tej reguły na innych operatorów. Klucze wychodzących żądań API nie deduplikują automatycznie powiadomień przychodzących do sklepu. To dwa oddzielne miejsca kontroli.

Przy webhookach Stripe sprawdzaj identyfikator zdarzenia; dokumentacja opisuje również sytuacje wymagające uwzględnienia identyfikatora obiektu i typu zdarzenia. Nie odrzucaj wszystkich kolejnych zdarzeń o tej samej transakcji, bo mogą przekazywać uzasadnioną zmianę statusu. Cykl płatności PayU także rozdziela status transakcji od samego dostarczenia powiadomienia.

Dla Przelewy24 lub innej bramki użyj dokumentacji wdrożonej wersji integracji. Nie kopiuj nazw statusów, zasad podpisu ani kodu Stripe do innego operatora. Odbiór powinien obejmować rzeczywistą konfigurację sklepu, a nie tylko zgodność przykładowego fragmentu kodu z poradnikiem.

Przygotuj odizolowane środowisko z trybem testowym operatora. Zablokuj prawdziwe wysyłki, dokumenty księgowe, powiadomienia do klientów i produkcyjny pomiar konwersji. Sama testowa karta nie chroni przed utworzeniem prawdziwej przesyłki przez inną integrację. Ustal, które systemy są atrapami, a które korzystają z osobnego konta testowego.

Scenariusze odbioru powinny obejmować zwykły zakup, ponowienie żądania, równoczesne dostarczenie zdarzenia, opóźniony webhook oraz błąd podczas przetwarzania po zapisaniu go w kolejce. Sprawdź także powrót klienta do sklepu po zamknięciu okna płatności. Oczekiwany rezultat opisuj osobno dla zamówienia, obciążenia, stanu magazynu i komunikacji.

Jeżeli potwierdzono drugi pobór pieniędzy, zwrot przeprowadź według procedury operatora i zasad obsługi reklamacji. Najpierw sprawdź, czy ktoś już go nie wykonał oraz czy operacja nie została automatycznie cofnięta. Zapisz identyfikator zwrotu i powiąż go ze sprawą. Nie naprawiaj finansów samą zmianą statusu w WooCommerce.

Alert na podobne zamówienia jest wskazówką do sprawdzenia, a nie automatycznym poleceniem anulowania. Klient może prawidłowo kupić dwa razy ten sam produkt. Lepsze sygnały techniczne obejmują błędy webhooków, zaległe zdarzenia kolejki i niespójność identyfikatorów płatności. Progi dobierz do normalnego działania własnego sklepu.

Prowadź rejestr wdrożeń i sprawdzaj scenariusz zakupu po zmianie bramki, motywu lub cache. Optymalizacja checkoutu powinna uwzględniać niezawodność obok wygody. Poprawnie zakończony test techniczny nie dowodzi jeszcze wzrostu konwersji; do tego potrzebna jest osobna obserwacja sprzedaży.

W KC Mobile możemy objąć diagnozą sklep internetowy, przygotować poprawkę i plan odbioru. Po wdrożeniu zakres wsparcia można ustalić w małym pakiecie godzinowym, z uzgodnioną odpowiedzialnością i zasadami reakcji. Opisz problem w kontakcie, podając operatora, wersję integracji i objaw bez danych klientów. Dostęp do chronionych logów uzgodnimy osobno.