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

{
„@context”: „https://schema.org”,
„@type”: „Article”,
„articleSection”: „Case Study”,
„name”: „WooCommerce Payment Gateway – naprawa odrzuconych transakcji”,
„description”: „Naprawa bramki płatności WooCommerce odrzucającej 30% transakcji po konflikcie wersji PHP.”,
„publisher”: {
„@type”: „Organization”,
„name”: „HelpGuru.eu”,
„url”: „https://helpguru.eu”
},
„author”: {
„@type”: „Person”,
„name”: „Adrian Szewalski”,
„url”: „https://helpguru.eu/news/author/aszewalski/”
},
„about”: {
„@type”: „Thing”,
„name”: „WooCommerce + Przelewy24”
},
„mainEntity”: {
„@type”: „ItemList”,
„name”: „Wyniki Case Study”,
„itemListElement”: [
{
„@type”: „ListItem”,
„position”: 1,
„name”: „Przed”,
„description”: „30% transakcji odrzuconych, błąd HTTP 500 w API”
},
{
„@type”: „ListItem”,
„position”: 2,
„name”: „Po”,
„description”: „100% transakcji realizowanych, PHP 8.1, monitoring wdrożony”
},
{
„@type”: „ListItem”,
„position”: 3,
„name”: „Czas realizacji”,
„description”: „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.