WooCommerce: zamówienie failed, a klient zapłacił. Fałszywi dłużnicy

Mieliśmy włączyć automat, który przypomina klientom sklepu o zaległych ratach. Zanim ruszył na żywo, przepuściliśmy go w trybie testowym po bazie sklepu klientki. Na liście dłużników wylądowały osoby, które zapłaciły co do grosza. Dwanaście przypadków w jednym sklepie. Jeśli też widzisz w WooCommerce zamówienie failed, a klient zapłacił – ten tekst jest o tym, skąd to się bierze i jak nie wysłać monitu komuś, kto nic nie jest winien.

Kontekst: sklep na WooCommerce Subscriptions z ratami

Klientka sprzedaje kursy online w ratach. Technicznie każda sprzedaż ratalna to subskrypcja WooCommerce Subscriptions – system sam co miesiąc tworzy zamówienie odnowieniowe i próbuje pobrać płatność. Kilkaset aktywnych subskrypcji, kilka metod płatności, w tym szybkie płatności online i BLIK.

Nasza wtyczka miała przejąć to, co wcześniej robił człowiek: wyłapać nieopłacone raty i wysłać monit. Stawka była oczywista. Mail windykacyjny do osoby, która zapłaciła godzinę wcześniej, to nie jest drobna wpadka w automacie. To wiadomość, którą klientka sklepu dostaje od marki, której właśnie zaufała i przelała pieniądze. Po czymś takim pisze do obsługi, a czasem po prostu rezygnuje z kolejnych zakupów.

Dlatego każdy automat, który pisze do klientów, uruchamiamy najpierw „na sucho” – liczy wszystko, ale niczego nie wysyła. I właśnie ten suchy przebieg pokazał problem.

Diagnoza: dlaczego lista dłużników kłamała

Hipoteza 1: złe zapytanie o statusy. Nie to

Pierwsze podejrzenie padło na zbyt szeroki filtr statusów. Sprawdziliśmy: wtyczka brała pending, failed i on-hold, czyli dokładnie te statusy, które w WooCommerce oznaczają brak zaksięgowanej płatności. Zapytanie było poprawne.

Hipoteza 2: opóźnienie księgowania w bramce. Też nie

Następna myśl: płatność doszła, ale status nie zdążył się zaktualizować, bo bramka spóźniła się z powiadomieniem. Tyle że te rekordy miały po kilka tygodni. Nic nie księguje się tak długo.

Moment, w którym coś przestało się zgadzać

Wyciągnęliśmy wszystkie zamówienia jednej subskrypcji, posortowane po dacie utworzenia. I wtedy zobaczyliśmy ten sam wzór w kółko:

#34273  failed      07:36   1444,00 zł
#34274  completed   07:37   1444,00 zł

Ta sama subskrypcja. Ta sama kwota. Różnica jednej minuty. Drugie zamówienie opłacone, pierwsze wisi jako nieudane.

Przyczyna źródłowa: porzucona próba płatności wygląda jak dług

Scenariusz jest banalny. Klientka klika w link do płatności, wybiera jedną metodę, płatność nie dochodzi do skutku – zamknęła okno, bank odrzucił, skończył się czas. Zamówienie zostaje ze statusem failed. Minutę później wraca i płaci BLIKiem. WooCommerce nie odświeża tamtego zamówienia – tworzy nowe, opłacone. Rata jest uregulowana, a nieudana próba wisi w bazie do końca świata i wygląda dokładnie jak zaległość.

To nie jest błąd WooCommerce Subscriptions ani bramki płatności. To normalne zachowanie sklepu, w którym klient ma prawo powtórzyć płatność inną metodą. Problem powstaje dopiero wtedy, gdy nad taką bazą stawiasz automat, który pyta „czy jest tu nieopłacone zamówienie?” zamiast „czy ta rata została zapłacona?”.

Nasza wtyczka brała najnowsze zamówienie subskrypcji ze statusem pending, failed lub on-hold – i myliła się za każdym razem, gdy ktoś płacił za drugim podejściem. U jednej osoby były pod rząd trzy nieudane próby i jedna udana. Automat widział trzy długi.

Jeśli w Twoim sklepie przypomnienia o płatnościach albo windykację robi skrypt, warto zadać sobie to samo pytanie. Takie mechanizmy budujemy w ramach automatyzacji procesów firmy – i zawsze zaczynamy od tego, co naprawdę jest w danych, a nie od tego, co powinno w nich być.

Rozwiązanie: szukaj opłaconego bliźniaka, nie kasuj zamówień

Zamiast patrzeć na pojedyncze zamówienie, wtyczka sprawdza teraz, czy istnieje jego opłacony bliźniak. Warunki dopasowania:

1. ta sama subskrypcja,
2. inne ID zamówienia,
3. ta sama kwota z tolerancją groszową (0,01),
4. status processing albo completed,
5. data utworzenia w oknie 7 dni od nieudanej próby.

W uproszczeniu logika wygląda tak:

dla każdego zamówienia ze statusem pending / failed / on-hold:
    szukaj w tej samej subskrypcji zamówienia, które:
        - ma inne ID
        - ma tę samą kwotę (różnica <= 0,01)
        - ma status processing albo completed
        - powstało w ciągu 7 dni od tej próby
    znalezione  -> NIE dłużnik, trafia do „Do sprawdzenia ręcznie”
    brak        -> realna zaległość, można wysłać przypomnienie

Jest bliźniak – zamówienie nie liczy się jako zaległość i żaden monit nie wychodzi. Trafia natomiast do osobnej sekcji „Do sprawdzenia ręcznie”, żeby człowiek widział, że w bazie leży śmieć do uporządkowania. Nie chowamy go po cichu – wątpliwy przypadek ma być widoczny.

Czego NIE robić

Nie blokuj tworzenia nowego zamówienia, gdy poprzednie jest nieopłacone. Brzmi jak porządek w danych, a odcina klientowi możliwość zapłaty inną metodą po nieudanej próbie. To drugie zamówienie jest tym, na którym zarabiasz.

Druga zasada, która u nas obowiązuje na sztywno: automat niczego nie kasuje i nie zmienia statusów zamówień. Porządek w zamówieniach robi człowiek, świadomie. Skrypt, który sam sprząta zamówienia sklepu, prędzej czy później skasuje coś, czego nie zrozumiał – a zamówienie to także ślad księgowy.

Efekt

Przed poprawką lista zaległości w jednym sklepie zawierała 12 osób, które nie miały żadnego długu. Po zmianie zniknęły z windykacji i wylądowały w sekcji do ręcznego przejrzenia. Żaden mail nie wyszedł – bo wtyczka była puszczona w trybie testowym, zanim ktokolwiek włączył wysyłkę. Na liście zostały wyłącznie realne zaległości, a klientka sklepu dostała przy okazji listę starych, porzuconych prób do posprzątania.

Podobne podejście – najpierw sprawdzić, kto naprawdę zapłacił, a dopiero potem cokolwiek wysyłać – opisaliśmy przy okazji faktur we wpisie o automatycznym sprawdzaniu płatności.

Jak sprawdzić u siebie

1. Wyświetl zamówienia ze statusem failed z ostatniego roku i porównaj kwoty w obrębie tej samej subskrypcji albo tego samego klienta.
2. Sprawdź, czy do każdego nieudanego zamówienia nie ma bliźniaka completed albo processing na tę samą kwotę w ciągu kilku dni.
3. Zanim włączysz jakikolwiek automat mailowy – odpal go w trybie testowym i przeczytaj listę odbiorców nazwisko po nazwisku.
4. Sprawdź, czy Twój system windykacyjny pyta o ratę, czy o zamówienie. To nie jest to samo pytanie.
5. Upewnij się, że automat ma sekcję „do sprawdzenia ręcznie” zamiast po cichu pomijać wątpliwe przypadki.

Czego nauczyła nas ta historia

Kod działał dokładnie tak, jak był napisany. Problem był w założeniu, że jedno nieopłacone zamówienie oznacza jedną nieopłaconą ratę. Dane w żywym sklepie zawsze zawierają przypadki, których nikt nie przewidział przy projektowaniu – nieudana próba płatności jest jednym z nich, a będzie ich więcej. Dlatego suchy przebieg i przeczytanie listy odbiorców to u nas obowiązkowy krok przed każdym automatem, który pisze do klientów.

Jeśli prowadzisz sprzedaż kursów w ratach, więcej o tym, jak poukładać płatności i dostęp do treści, znajdziesz na platformykursowe.pl.

FAQ

Czy zamówienie ze statusem failed można po prostu usunąć?

Odradzamy. To ślad księgowy i diagnostyczny – pokazuje, że klient próbował zapłacić i mu nie wyszło. Jeśli chcesz uporządkować listę, przenieś takie zamówienia do kosza ręcznie, po sprawdzeniu, a nie skryptem masowym.

Dlaczego WooCommerce nie oznacza starego zamówienia jako opłacone?

Bo płatność została wykonana w ramach innej transakcji, powiązanej z nowym zamówieniem. Bramka nie ma jak połączyć jej z poprzednią, porzuconą próbą. Każde zamówienie ma własny identyfikator płatności.

Jak odróżnić porzuconą próbę od realnej zaległości?

Po istnieniu opłaconego zamówienia na tę samą kwotę, w tej samej subskrypcji, w bliskim oknie czasowym. Brak takiego bliźniaka po kilku dniach to już realna zaległość.

Czy dotyczy to tylko rat i subskrypcji?

Najboleśniej właśnie tam, bo subskrypcje generują zamówienia cyklicznie i skala rośnie z miesiąca na miesiąc. Ten sam mechanizm działa jednak w każdym sklepie, w którym klient może ponowić płatność inną metodą.

Ile takich przypadków to dużo?

W sklepie, o którym piszemy, było 12 przy kilkuset aktywnych subskrypcjach. To wystarczy, żeby pierwsze uruchomienie windykacji zepsuło relację z kilkunastoma płacącymi klientami naraz.

Masz ten sam problem? Napisz do nas

Masz w sklepie subskrypcje albo raty i chcesz automatycznych przypomnień o płatnościach, które nie piszą do osób, które już zapłaciły? Robimy takie systemy pod konkretny sklep: wykrywanie zaległości, monity mailowe, panel do ręcznej weryfikacji. Zaczynamy od przejrzenia Twoich danych, nie od włączenia wysyłki. Zobacz też, jak budujemy sklepy internetowe na WooCommerce.

Napisz do nas – opowiedz, jak wygląda Twój sklep