W naszej pracy spotykamy się codziennie z wieloma problemami,z którymi muszą zmagać się właściciele jak również klienci sklepów internetowych. Czasem są one niewidoczne dla szarego kupującego, ale czasem uderzają w niego z tak dużą siłą, że nie pozostaje on obojętny.

Frustracja klienta narasta, a po osiągnięciu apogeum kupujący zazwyczaj obwinia za to sklep internetowy. Tak też było w tym przypadku, ale czy słusznie?

Na czym polega problem?

Kupując produkty w sklepie internetowym zwykle chcemy być informowani o ważnych etapach realizacji zamówienia. Na przykład o tym, że zamówienie zostało przyjęte, skompletowane, wysłane lub doręczone. Oczekujemy także, jeśli na którymś etapie pojawi się problem z realizacją sklep da nam o tym znać.

Co zatem się stanie, gdy w trakcie dokonywania zakupu z użyciem bramki Przelewy24 płatność się nie powiedzie? Otóż wtedy, bez względu na to czy właściciel sklepu internetowego tego chce czy nie, to kupujący będzie zasypywany takimi powiadomieniami mailowymi dokładnie co 15 minut i to w nieskończoność (dopóki nie podda się tym torturom i zapłaci).

Czy ten problem dotyczy też mojego sklepu?

Jeśli korzystasz z bramki płatności Przelewy24 i używasz oficjalnej wtyczki od P24 w wersji 1.0.8. (potencjalnie również w wersji 1.0.7.) to niestety TAK!

Dlaczego ten problem w ogóle występuje?

Przeprowadziliśmy szybkie dochodzenie zaczynając od frazy “nie zostało opłacone”. Wprost trafiliśmy do wtyczki Przelewy24 (ver 1.0.8.) do pliku notification_email.php, który (jako jedyny) taką frazę zawiera:

Pomijając piękny przykład kodu typu “spaghetti” oraz faktu, że nikt nawet nie próbuje stosować w tym kodzie ecape’owania (co, jeśli tłumaczenie frazy będzie zawierać kod HTML?) widzimy, że jest to szablon maila. Tutaj nastąpiło pierwsze zaskoczenie.

Dlaczego wtyczka bramki płatności w ogóle wysyła jakiekolwiek maile w imieniu sklepu?!

Po nitce do kłębka. Skoro mamy szablon wiadomości email to możemy sprawdzić gdzie i dlaczego taki szablon jest w ogóle wykorzystywany. Tak trafiamy na jego jedyne użycie w pliku Przelewy24Mailer.class.php w linii 25:

Funkcja triger(), w której znajduje się wywołanie wysyłki maila z użyciem szablonu sprawdza poprawność jedynie podstawowe parametry jak samo istnienie obiektu zamówienia oraz to czy zamówienie jest opłacone oraz czy zamówienie ma być opłacone poprzez Przelewy24. Następnie wysyła e-mail i dodaje notkę o jego wysłaniu.

Zatem kiedy funkcja trigger() jest wywoływana? To znajdziemy w linii 217 w pliku woocommerce-gateway-przelewy24.php, w funkcji woocommerce_p24_email_send_order_payment_reminder:

Tutaj mamy dołączoną wskazaną wcześniej klasę Mailera i wywołanie wysłania maila. Nie ma natomiast już żadnych sprawdzeń czegokolwiek.

A gdzie zatem wywoływana jest funkcja woocommerce_p24_email_send_order_payment_reminder? Otóż w pliku class-p24-payment-reminder.php w klasie P24_Payment_Reminder w metodzie try_send_email:

Mamy tutaj sprawdzenie czy zamówienie jest nieopłacone, czy potrzebuje zapłaty (w poprzednim kroku w funkcji trigger nie sprawdzano nawet, czy zamówienie zapłaty wymaga) i czy opłacone ma być metodą płatności Przelewy24 (znów ciekawostka, bo sprawdzenie wykonywane jest w inny sposób – wcześniej sprawdzamy wyłącznie równość z get_payment_method() == ‘przelewy24’, a tutaj robiony jest preg_match metody pobranej z zamówienia z wzorcem '/^przelewy24(\_extra\_\d+)?$/';).

Po czym wysyłany jest email (i dodawana notka). A po wysłaniu maila ustawiany jest event dla tego samego zamówienia.

Wymieniony event robi bardzo prostą rzecz, czyli ustawia event za 15 minut od teraz, żeby całą procedurę powtorzyć. Tak – dokładnie tak! Ten fragment kodu ustawia wysłanie kolejnego maila o tej samej treści 15 minut po pierwszym, a po jego wysłaniu zostanie ustawiony kolejny za 15 minut.

I tak oto co 15 minut klient będzie bombardowany mailami o tym, że nie opłacił zamówienia. Jedyną opcją przerwania tego błędnego koła jest poddanie się kupującego i finalne opłacenie zamówienie.

Czy nie można wyłączyć wysyłania takich wiadomości?

Otóż można. Autorzy wtyczki nawet przewidzieli taką opcję w konfiguracji metody płatności Przelewy24 w WooCommerce.

Tyle, że jak widzieliśmy w powyższych fragmentach kodu – opcje te nie są nawet sprawdzane. Nikt też nie zadbał o to, żeby może dla jednego zamówienia nie wysyłać tego samego powiadomienia wielokrotnie (albo przynajmniej zbyt często). Nikt nie przewidział też opcji anulowania wysyłki tych maili… Można jedynie skasować zamówienie lub oznaczyć je jako opłacone ręcznie…

Co zrobić, gdy problem dotyczy mojego sklepu?

Nie możemy was, drodzy właściciele sklepów, do niczego namawiać. Natomiast do czasu naprawy kodu przez jej autorów, jedynym rozwiązaniem problemu wysyłania maili do klientów w nieskończoność co 15 minut jest dezaktywacja wtyczki Przelewy24 i wymiana jej na inną, obsługującą płatności poprawnie i nie spamującą użytkowników wiadomościami wprost ze sklepu.

My, z naszej strony, zrobiliśmy, co mogliśmy – błąd został przeanalizowany i namierzony, a odpowiednie zgłoszenie zostało wysłane do Przelewy24 (podobnie, jak w w przypadku niedawnych problemów wtyczki iMoje). Pytanie, jak szybko Przelewy24 błąd poprawią i wydadzą nową wersję wtyczki.

Warto też przypomnieć, że nie jest to pierwsza tak duża wpadka Przelewy24. Nie tak dawno bramka ta w pewnym sensie przeprowadzała atak DDoS na sklepy jej klientów, zasypując te sklepy powiadomieniami i zużywając zasoby serwerowe do tego stopnia, że spora liczba sklepów nie była w stanie tego sztucznego ruchu wytrzymać i była blokowana przez hostingi.