Nieudana płatność w aplikacji: jak pokazać stan i pomóc klientowi wrócić do zadania

Klient kończy zamówienie, zatwierdza płatność i wraca do sklepu. Zamiast potwierdzenia widzi komunikat o błędzie połączenia. W banku zauważa operację, ale sklep nie pokazuje jeszcze jej wyniku. Kliknąć ponownie czy poczekać? Właśnie w takiej chwili aplikacja powinna powiedzieć, co rzeczywiście wie, a nie zgadywać za klienta.

Nieudana płatność, płatność oczekująca na potwierdzenie i brak odpowiedzi operatora to różne sytuacje. Dobrze zaprojektowany proces łączy je z konkretnym zamówieniem, pokazuje dostępny następny krok i pozwala obsłudze wyjaśnić rozbieżność. Szczegóły zależą od metody płatności oraz integracji z wybranym operatorem.

Jeśli projektujesz zakup w aplikacji, wyślij brief z opisem przebiegu zamówienia, używanych kanałów i problemu, który chcesz rozwiązać. Wystarczy fikcyjny scenariusz. Nie przesyłaj danych kart, haseł ani danych klientów.

Oddziel zamówienie od próby płatności

Wyobraźmy sobie sklep, w którym klient zamawia produkt i wybiera płatność online. Powstaje zamówienie, a następnie próba opłacenia go przez operatora. To przykład projektowy, nie opis konkretnego sklepu. Jedno zamówienie może wymagać ponowienia próby, ale każda operacja musi pozostać rozpoznawalna dla systemu i obsługi.

Zapiszcie, co oznacza każdy stan w waszym procesie. Zamówienie może być złożone, lecz oczekiwać na wynik płatności. Próba może wymagać dodatkowego działania klienta, zakończyć się odmową albo pozostać w trakcie przetwarzania. Etykiety powinny odpowiadać rzeczywistej integracji. Nie przenoście nazw technicznych jednego operatora na wszystkie dostępne metody.

Dokumentacja Stripe opisuje cykl PaymentIntent, w którym występują między innymi stany wymagające działania, przetwarzania i powodzenia. To przykład konkretnego API. Zespół powinien sprawdzić dokumentację oraz zachowanie operatora rzeczywiście używanego w danej aplikacji.

Płatność może być jednym z warunków udostępnienia usługi, lecz nie zawsze kończy cały proces. W artykule o płatności i dostępie do kursu opisujemy różnicę między otrzymaniem potwierdzenia a udostępnieniem materiałów. Podobne rozróżnienie przydaje się przy rezerwacji, zamówieniu i aktywacji konta.

Przed rozpoczęciem prac narysujcie prostą mapę: zamówienie, jego kwota i waluta, próba płatności oraz wynik potwierdzony przez operatora. Przy każdej zmianie zapiszcie, który system jest jej źródłem. Jeżeli aplikacja dopuszcza kilka prób, obsługa powinna rozpoznać każdą z nich, a klient powinien widzieć jeden zrozumiały stan zamówienia. Zmiana adresu dostawy czy zawartości koszyka po rozpoczęciu płatności wymaga osobnej decyzji, ponieważ może zmienić warunki zakupu.

Pokaż to, co system potrafi potwierdzić

Komunikat po powrocie od operatora powinien odnosić się do aktualnego stanu znanego aplikacji. Jeśli potwierdzono niepowodzenie próby, można wyjaśnić, że zamówienie pozostaje nieopłacone i podać dostępne dalsze działania. Jeśli odpowiedź jeszcze nie dotarła, lepiej napisać „sprawdzamy status płatności” niż zapewnić o odmowie albo zachęcić do natychmiastowej ponownej wpłaty.

Przykładowy tekst dla stanu niepewnego: „Nie mamy jeszcze potwierdzenia płatności za to zamówienie. Sprawdź status za chwilę lub skontaktuj się z nami, podając numer zamówienia”. To propozycja do przetestowania w konkretnym procesie. Informacja o czasie i możliwości ponowienia musi wynikać z rzeczywistego działania operatora, a nie z gotowego szablonu.

Nie należy prosić klienta o numer karty, kod zabezpieczający czy dane logowania do banku w formularzu wsparcia. Zespół powinien korzystać z odpowiednich narzędzi operatora i ustalonego zakresu danych. Samo zdjęcie ekranu bankowego może zawierać inne wrażliwe informacje, dlatego przed prośbą o materiał trzeba ustalić bezpieczny sposób jego przekazania.

Jeśli klient otrzymał informację o odmowie od operatora, aplikacja nie musi przedstawiać szczegółowego powodu, którego nie zna. Może wskazać dostępne opcje, na przykład wybór innej metody, o ile rzeczywiście jest dostępna. Zrozumiały komunikat nie obiecuje, że kolejne podejście na pewno się powiedzie.

Komunikat powinien pozostać dostępny także po odświeżeniu strony lub powrocie z innego urządzenia, jeśli klient ma uprawnienie do otwarcia zamówienia. Nie opierajcie całej informacji na krótkim powiadomieniu, które znika po kilku sekundach. Numer zamówienia i następna czynność powinny być możliwe do znalezienia również w historii zakupów albo innym kanale przewidzianym w procesie.

Zaplanuj powrót do zadania

Klient powinien móc wrócić do właściwego zamówienia bez ponownego wypełniania całego formularza. Warto zachować numer sprawy, zawartość koszyka i uzgodnione dane w zakresie potrzebnym do kontynuacji. Jeśli rezerwacja produktu lub terminu ma ograniczony czas, aplikacja musi sprawdzić jej aktualny stan przed umożliwieniem dalszej pracy.

Po ponownym otwarciu strony nie wystarczy odtworzyć ostatniego widoku z przeglądarki. W międzyczasie operator mógł potwierdzić płatność, zamówienie mogło zostać anulowane albo zmieniła się dostępność towaru. Aplikacja powinna pobrać właściwy stan i pokazać go użytkownikowi. Jeśli danych nie da się pobrać, potrzebny jest komunikat o braku potwierdzenia zamiast starej informacji przedstawionej jako aktualna.

Zastanówcie się, gdzie prowadzi przycisk „Spróbuj ponownie”. Czy tworzy nową próbę dla tego samego zamówienia? Czy poprzednia operacja na pewno pozwala na taki krok? Odpowiedź musi wynikać z umowy, API operatora i zachowania aplikacji. Nie projektujcie przycisku, który tworzy kolejne zamówienie przy każdym kliknięciu tylko dlatego, że jest to najprostsza droga w interfejsie.

W artykule o bezpiecznym ponawianiu żądań opisujemy, jak rozpoznawać powtórzenia operacji. To zagadnienie techniczne wspiera doświadczenie klienta, ale nie zastępuje sprawdzenia stanu płatności i zasad konkretnego dostawcy.

Jeśli klient wybiera inną metodę, przed rozpoczęciem kolejnej operacji ustalcie, czy wcześniejsza próba może jeszcze zakończyć się powodzeniem. Takie zachowanie zależy od wybranej metody i dostawcy. Przy braku pewności aplikacja powinna skierować sprawę do wyjaśnienia zgodnie z przyjętą procedurą. Widoczna wygoda ponowienia nie może zastąpić rozpoznania tego, co wydarzyło się wcześniej.

Potwierdzenie może przyjść później

Klient może zamknąć kartę przeglądarki, stracić połączenie lub nie wrócić ze strony operatora. System nie powinien traktować samego powrotu do sklepu jako jedynego dowodu wyniku. Zależnie od integracji operator może przekazywać zdarzenia do aplikacji również później. Zespół musi sprawdzić, jakie potwierdzenia są dostępne dla wybranej metody i jak zweryfikować ich pochodzenie.

Webhook to wiadomość wysyłana między systemami po wystąpieniu zdarzenia. Dokumentacja Stripe dotycząca webhooków opisuje między innymi weryfikację podpisów i obsługę zdarzeń. Szczegóły implementacji oraz możliwe ponowienia należy sprawdzić dla konkretnego operatora i środowiska.

Przyjmijcie, że komunikat może dotrzeć ponownie albo po wyświetleniu klientowi wcześniejszego stanu. Obsługa zdarzenia powinna rozpoznać właściwe zamówienie oraz nie uruchamiać dwa razy tej samej czynności. Jeżeli po potwierdzeniu płatności system wysyła zamówienie do realizacji, także ten kolejny etap potrzebuje własnego stanu i możliwości wyjaśnienia błędu.

Po potwierdzeniu pokażcie klientowi, co stało się dalej: zamówienie zostało przyjęte do realizacji, dostęp oczekuje na aktywację albo potrzebny jest kontakt. Nie należy nazywać całego procesu zakończonym tylko dlatego, że operator zaakceptował jeden etap. Przy sprzedaży usług informacja o kolejnym kroku bywa równie ważna jak potwierdzenie samej płatności.

Daj obsłudze kontekst bez ujawniania zbędnych danych

Konsultant potrzebuje widzieć zamówienie, jego stan, powiązane próby oraz informacje, które operator udostępnia firmie. Przydatne są czas zdarzenia, identyfikator służący do wyszukania operacji i historia zmian. Nie oznacza to potrzeby kopiowania pełnych danych płatniczych do panelu obsługi lub wiadomości e-mail.

Uzgodnijcie, co konsultant może zrobić sam, a kiedy kieruje sprawę do osoby uprawnionej lub operatora. Przykładowo klient zgłasza, że widzi operację w banku, a sklep nadal oczekuje na potwierdzenie. Pracownik powinien sprawdzić stan w odpowiednich narzędziach i wiedzieć, jak poinformować klienta o kolejnym kroku. Sam widok pojedynczego komunikatu w sklepie może nie wystarczyć do rozstrzygnięcia sprawy.

Ważne jest także powiązanie wiadomości wysłanej klientowi z aktualnym stanem. Potwierdzenie otrzymania zgłoszenia nie oznacza potwierdzenia płatności. Jeśli później pojawi się wynik od operatora, zespół powinien wiedzieć, czy i jak przekazać aktualizację. Przy zwrotach oraz reklamacjach powstają kolejne etapy, opisane w artykule o obsłudze zwrotów w e-commerce.

Zdarza się, że klient kontaktuje się przez kilka kanałów. Połączenie rozmowy ze sprawą pomaga uniknąć sytuacji, w której dwie osoby niezależnie proponują sprzeczne działania. Dostęp do historii powinien jednak odpowiadać roli pracownika. W widoku wystarczą informacje potrzebne do wyjaśnienia problemu, bez kopiowania pełnej korespondencji do każdego systemu.

Dla spraw wymagających kontaktu z operatorem zapiszcie osobę odpowiedzialną i sposób przekazywania odpowiedzi do klienta. Jeśli operator potrzebuje więcej informacji, pracownik powinien wiedzieć, jakie dane wolno zebrać i w jakim kanale. Dobrze rozróżnić pytanie skierowane do operatora od potwierdzonego rozstrzygnięcia. Klient nie powinien otrzymywać informacji o zakończeniu sprawy wyłącznie dlatego, że wysłano zapytanie.

Przetestuj przerwany zakup i potwierdzenie

Przygotujcie próby w środowisku testowym operatora. Obejmijcie poprawną płatność, odmowę, wymagane dodatkowe działanie i zamknięcie okna przed powrotem do sklepu. Sprawdźcie także późniejsze potwierdzenie oraz ponowne dostarczenie zdarzenia, jeżeli narzędzia testowe pozwalają odtworzyć taką sytuację. Oczekiwany rezultat zapiszcie przed próbą.

Porównajcie trzy widoki: to, co widzi klient, stan zamówienia w aplikacji oraz dane dostępne operatorowi. Jeśli różnią się w czasie przetwarzania, ustalcie, jak długo i w jakich warunkach mogą pozostawać różne. Nie wpisujcie uniwersalnej liczby minut bez sprawdzenia danej metody płatności i warunków usługi.

W artykule o testowaniu integracji bez danych klientów opisujemy rozdzielenie prób od rzeczywistej pracy. Taki test nie dowodzi sam przez się działania produkcji. Po wdrożeniu zespół potrzebuje odpowiedniej obserwacji i procedury reagowania na faktyczne problemy.

Poproście osobę niezwiązaną z projektem o przejście przerwanego zakupu. Zapytajcie, czy rozumie, czy może bezpiecznie spróbować ponownie oraz gdzie znajdzie numer zamówienia. Jeśli musi dopytywać autora interfejsu, poprawcie komunikat. Scenariusze i odpowiedzialność za ich potwierdzenie można zapisać w kryteriach odbioru aplikacji.

W planie uwzględnijcie również niedostępność samego operatora. Kto aktualizuje komunikat na stronie, kto sprawdza kolejne potwierdzenia i jak obsługa odnajduje zamówienia wymagające wyjaśnienia? Pomocny przebieg działania opisujemy przy awarii integracji.

Po zakończeniu problemu sprawdźcie, czy wszystkie oczekujące zamówienia otrzymały właściwy stan i czy potrzebny jest kontakt z klientami. Lista wyjątków powinna wskazywać osobę odpowiedzialną za wyjaśnienie, nie jedynie liczbę błędów. W integracjach systemów czytelny stan płatności pomaga klientowi wrócić do zakupów, a zespołowi rozstrzygnąć sprawę na podstawie potwierdzonych danych.

Testujcie też zmianę urządzenia i powrót do zamówienia z wiadomości e-mail. Link powinien prowadzić do właściwej sprawy oraz respektować uzgodnione zasady dostępu. Jeżeli klient nie może się zalogować, aplikacja potrzebuje bezpiecznej drogi pomocy. Nie ujawniajcie szczegółów zamówienia osobie, która zna jedynie przypadkowy numer albo przechwyciła cudzy adres strony.