WooCommerce Case Study: Bramka płatności odrzuca 30% transakcji - naprawa w 3 godziny

Poniedziałek, godzina 9:03 - sklep traci pieniądze w czasie rzeczywistym

Właściciel sklepu z odzieżą napisał: „Od rana bramka nie działa. Klienci próbują płacić, ale transakcje są odrzucane. Liczymy straty.” W logach WooCommerce:

[WooCommerce] Payment gateway error: HTTP 500
P24 API Response: {"error":{"code":"ERR_INVALID_SIGN"}}

Diagnoza: trzy pytania, jedna odpowiedź

Co się zmieniło?

Historia aktualizacji WordPress pokazała: dzień wcześniej o 23:12 uruchomił się auto-update wtyczki Przelewy24 for WooCommerce z wersji 3.2.4 do 3.3.0. Wersja 3.3.0 wprowadzała nowy algorytm generowania podpisu (SHA-384 zamiast MD5).

Dlaczego nowy algorytm powodował błąd?

Nowa wtyczka wymagała PHP 8.0+ dla obsługi hash_hmac() z SHA-384. Serwer klienta działał na PHP 7.4. Funkcja zwracała false zamiast prawidłowego hasha - stąd błąd weryfikacji podpisu po stronie P24. Najgorsze: błąd nie rzucał wyjątku PHP. Transakcja po prostu “wypadała” z błędem 500 bez żadnego ostrzeżenia w panelu admina.

Dlaczego 30%, a nie 100% odrzuceń?

30% użytkowników korzystało z metod płatności (BLIK, przelew ręczny) które nie używały tej samej biblioteki podpisów. Stąd nie 100%, a “tylko” 30% strat.

Naprawa w 3 krokach

Krok 1: Rollback wtyczki (10 minut)

Natychmiastowe działanie przez FTP: zastąpiliśmy katalog wtyczki wersją 3.2.4 z backupu. Transakcje zaczęły przechodzić. Sklep odżył.

Krok 2: Upgrade PHP 7.4 → 8.1 (90 minut)

Analiza kompatybilności 23 aktywnych wtyczek z PHP 8.1. Dwie wymagały poprawek (create_function zastąpione anonimowymi funkcjami). Upgrade przez panel hostingu, testy na stagingu, wdrożenie na produkcję.

Krok 3: Update wtyczki + monitoring (60 minut)

Update P24 do 3.3.0 po weryfikacji kompatybilności. Test transakcji testowej przez API sandbox. Konfiguracja alertów email dla błędów płatności powyżej 2% w ciągu godziny. Uptime Robot z alertem SMS.

Wyniki

• ✅ Konwersja płatności: 70% → 100%
• ✅ PHP: 7.4 → 8.1
• ✅ Monitoring: alert przy błędach płatności > 1%
• ✅ Środowisko staging: wdrożone dla przyszłych aktualizacji

Czas przestoju: 9 godzin. Szacowane straty: ok. 8 000 zł. Koszt naprawy: 3 roboczogodziny.

Złota zasada: bramki płatności - nigdy auto-update

Auto-update jest wygodny, ale dla wtyczek odpowiedzialnych za płatności i integracje z zewnętrznymi API - zawsze aktualizuj ręcznie, po teście na stagingu. Jeden błąd wersji może kosztować tysiące złotych w jedną noc.

O autorze

Adrian Szewalski

PrestaShop Architect & Backend Developer

Inżynier i architekt systemów e-commerce, dla którego PrestaShop nie ma tajemnic. Odpowiedzialny za najbardziej wymagające technicznie projekty w HelpGuru. Specjalizuje się w optymalizacji wydajności (Core Web Vitals), bezpieczeństwie baz danych oraz integracjach z systemami ERP i magazynowymi. Autor dziesiątek modułów usprawniających pracę sklepów.