opóźnione dane o płatnościach

Opóźnione dane o płatnościach prowadzą do wysyłania przypomnień klientom, którzy już uregulowali należność.

Skąd biorą się opóźnione dane o płatnościach

Opóźnione dane o płatnościach pojawiają się wtedy, gdy informacja o zaksięgowaniu przelewu lub płatności kartą nie trafia od razu do systemu wystawiającego faktury, panelu klienta albo modułu odpowiedzialnego za wysyłanie przypomnień. W typowym środowisku dane przechodzą przez kilka elementów: bramkę płatniczą, system bankowy, moduł księgowy, bazę danych oraz usługę wysyłającą wiadomości e-mail. Każdy z tych elementów może przekazywać informacje z innym opóźnieniem.

Przyczyną bywa praca cykliczna zamiast ciągłej synchronizacji. Program może sprawdzać status transakcji co kilka minut, pobierać pliki z banku raz dziennie albo oczekiwać na komunikat zwrotny z zewnętrznego operatora. Opóźnienie może też powstać podczas awarii połączenia sieciowego, przeciążenia serwera, błędu uwierzytelniania API, zatrzymania zadania harmonogramu lub nieprawidłowego przetworzenia pliku importu. Sam fakt, że klient zapłacił, nie oznacza więc automatycznie, że wszystkie powiązane aplikacje mają już aktualny status należności.

Jak system rozpoznaje zapłaconą należność

Automatyczne przypomnienie powinno być wysyłane na podstawie jednoznacznego powiązania płatności z konkretną fakturą, zamówieniem albo kontem klienta. Do identyfikacji mogą służyć między innymi numer faktury, identyfikator transakcji, kwota, waluta oraz data operacji. Jeżeli import płatności nie zawiera właściwego numeru referencyjnego albo numer został zapisany w innym formacie, system może nie przypisać przelewu do należności, mimo że środki faktycznie wpłynęły.

Znaczenie ma również kolejność przetwarzania danych. Najpierw system powinien pobrać płatność, następnie zweryfikować jej status, przypisać ją do dokumentu, zaktualizować saldo i dopiero potem sprawdzić, czy należy wysłać przypomnienie. Jeżeli moduł powiadomień korzysta ze starszego odczytu bazy danych, może zobaczyć należność jako niezapłaconą. Podobny efekt wystąpi, gdy aktualizacja salda zakończy się błędem, ale zadanie wysyłające wiadomości nadal będzie działać na podstawie poprzedniego stanu.

W poprawnie zaprojektowanym przepływie warto rejestrować czas otrzymania płatności, czas jej zaksięgowania, czas aktualizacji dokumentu oraz moment uruchomienia powiadomienia. Takie znaczniki pozwalają ustalić, czy opóźnienie powstało po stronie banku, integracji, bazy danych czy aplikacji użytkowej. Istotne jest także rozróżnienie statusów „oczekująca”, „zainicjowana”, „zaakceptowana”, „rozliczona” i „odrzucona”, ponieważ sama obecność identyfikatora transakcji nie musi oznaczać ostatecznego rozliczenia.

Objawy nieaktualnego statusu w aplikacji

Najbardziej widocznym objawem jest wysłanie ponaglenia po uregulowaniu należności. W panelu użytkownika może wtedy nadal widnieć saldo do zapłaty, faktura może mieć status „nieopłacona”, a historia operacji może nie zawierać przelewu. Czasami aplikacja pokazuje sprzeczne informacje: ekran szczegółów transakcji wskazuje płatność przyjętą, natomiast lista faktur nadal oznacza dokument jako zaległy. Taka rozbieżność zwykle wskazuje na różne źródła danych albo różne momenty ich odświeżenia.

Podczas sprawdzania problemu należy porównać logi aplikacji z historią operacji w systemie płatniczym i rekordami w bazie danych. W logach warto szukać identyfikatora płatności, numeru dokumentu, kodu odpowiedzi usługi oraz informacji o czasie rozpoczęcia i zakończenia synchronizacji. Należy też sprawdzić, czy zadanie harmonogramu uruchomiło się prawidłowo, czy nie zakończyło się wyjątkiem oraz czy po błędzie zostało ponowione. Brak ponowienia może pozostawić dane w stanie przejściowym przez wiele godzin.

Ważnym testem jest porównanie zegarów urządzeń i serwerów. Nieprawidłowy czas systemowy albo różne strefy czasowe mogą spowodować, że płatność zostanie uznana za nowszą lub starszą, niż jest w rzeczywistości. Trzeba również zweryfikować filtrowanie po dacie, zaokrąglenia kwot oraz obsługę płatności częściowych i zwrotów. Błąd w którymkolwiek z tych miejsc może spowodować, że system nie zamknie należności albo ponownie zakwalifikuje ją do wysyłki przypomnienia.

Ograniczanie liczby błędnych przypomnień

Podstawowym zabezpieczeniem jest ponowne sprawdzenie statusu płatności bezpośrednio przed wysłaniem wiadomości. Aplikacja nie powinna traktować braku danych w lokalnym widoku jako dowodu braku zapłaty. Bezpieczniejsza logika uwzględnia czas ostatniej synchronizacji i w przypadku świeżej, niepełnej lub niejednoznacznej informacji wstrzymuje automatyczne przypomnienie. Wiadomość może zostać wysłana dopiero po przekroczeniu ustalonego okresu oczekiwania oraz po potwierdzeniu, że dokument nadal ma saldo większe od zera.

Integracja powinna być odporna na powtórne przetwarzanie tego samego komunikatu. Służy temu identyfikator transakcji zapisywany jako unikalny klucz albo inny mechanizm idempotencji, który nie pozwala wielokrotnie zaksięgować jednej płatności. Zadania synchronizacyjne powinny mieć kontrolę błędów, limit ponowień i czytelne logowanie. Dobrą praktyką jest także oddzielenie kolejki importu płatności od kolejki powiadomień, aby chwilowy błąd wysyłki wiadomości nie zmieniał stanu rozliczenia.

Na komputerze użytkownika można sprawdzić, czy problem nie wynika wyłącznie z nieodświeżonego interfejsu. Pomaga ponowne załadowanie strony, wylogowanie i zalogowanie oraz porównanie widoku w innej przeglądarce. Jeżeli status jest nieaktualny na kilku urządzeniach, przyczyny należy szukać po stronie systemu lub integracji, a nie w pamięci podręcznej jednego laptopa. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w przypadku problemów z aplikacją może również pomóc odróżnić awarię lokalnego komputera od błędu występującego w systemie rozliczeniowym.