Klient wraca z płatności na telefonie. Czy sklep pokazuje mu właściwe zamówienie?
Trzy próby mobilnego zakupu: płatność udana, przerwana i oczekująca. Porównaj ekran klienta z zamówieniem, zanim uznasz koszyk za sprawdzony.
Na komputerze wszystko wygląda dobrze. Na telefonie kupujący przechodzi do płatności, wraca do sklepu i znów widzi koszyk. Czy ma zapłacić jeszcze raz? Sprawdź osobno udaną płatność, jej przerwanie oraz oczekiwanie na potwierdzenie. W każdej próbie porównaj komunikat na telefonie z tym, co rzeczywiście zapisano przy zamówieniu. Sam widok przycisku „Kupuję” nie wystarcza do oceny całej drogi.
Telefon to codzienne narzędzie, ale procent użytkowników nie jest udziałem zamówień
W informacji GUS opublikowanej 5 grudnia 2025 roku z telefonu do łączenia się z internetem korzystało 87,3% osób w Polsce w wieku 16–74 lata. To pomiar korzystania z sieci, nie odsetek zakupów opłaconych na smartfonie. Nie wolno na jego podstawie przyjąć, że taki sam udział ma telefon w obrotach Twojego sklepu.
Dane dają jednak rozsądny powód, by telefon uwzględnić w kontroli zakupu. To nasz wniosek praktyczny, a nie wynik badania skuteczności konkretnego koszyka. Zacznij od urządzeń i przeglądarek używanych przez Twoich kupujących, jeśli dysponujesz takim zbiorczym zestawieniem. Nie potrzebujesz do tego nazwisk ani historii pojedynczych osób.
Przygotuj jeden koszyk, którego wynik potrafisz rozpoznać
Użyj demonstracyjnej kopii sklepu oraz testowej płatności, która nie pobiera pieniędzy i nie kieruje paczki do wysyłki. Przed próbą ustal z osobą utrzymującą sklep, jak rozpoznasz testowe zamówienie oraz jak zasymulujesz wynik płatności. Jeżeli nie ma takiej możliwości, sprawdź dostępne kroki przed zapłatą, a powrót z płatności pozostaw wyraźnie jako niesprawdzony.
Wymyślony koszyk DEMO może zawierać notes za 24 zł i dostawę za 12 zł. Zapisz oczekiwane 36 zł, wariant produktu i sposób odbioru. Dla każdej z poniższych prób utwórz odrębne testowe zamówienie. Dzięki temu nie pomylisz wyniku jednej próby z kolejną.
| Próba | Co robisz na telefonie | Co porównujesz po powrocie |
|---|---|---|
| Płatność udana | Kończysz testową płatność i wracasz do sklepu. | Telefon pokazuje właściwe zamówienie, jego kwotę i potwierdzony stan płatności; panel opisuje ten sam wynik. |
| Płatność przerwana | W testowym przebiegu rezygnujesz z płacenia i wracasz. | Komunikat nie twierdzi, że zapłacono. Wiadomo, jak wznowić płatność do istniejącego zamówienia. |
| Potwierdzenie opóźnione | W kontrolowanej próbie odkładasz przekazanie potwierdzenia płatności. | Sklep odróżnia oczekiwanie od odmowy; po nadejściu potwierdzenia właściwie aktualizuje to samo zamówienie. |
Ta tabela jest propozycją kontroli, nie opisem działania każdej bramki płatniczej. Sposób wywołania poszczególnych wyników ustal zgodnie z dokumentacją używanego rozwiązania. Nie próbuj uzyskać opóźnienia przez przypadkowe przerywanie prawdziwych płatności klientów.
Przełącz aplikację i wróć do tego samego miejsca
Odtwórz zwykłe zachowanie kupującego: opuszczenie przeglądarki w trakcie płatności i powrót do niej. Sprawdź, czy widoczna kwota nadal odpowiada koszykowi i czy sklep nie prosi o ponowne złożenie już przyjętego zamówienia. Obejrzyj też ekran po odświeżeniu. Samo odświeżenie nie powinno być dla klienta instrukcją ponownej zapłaty.
Gdy test wykaże rozbieżność, zanotuj kolejność działań i dwa widoki stanu: „co zobaczył kupujący” oraz „co zapisano w sklepie”. W przykładzie DEMO można zapisać: „po powrocie koszyk nadal otwarty, w panelu zamówienie istnieje i ma opłacone 36 zł”. To daje wykonawcy konkretny scenariusz do poprawy. Ogólne „płatności nie działają na telefonie” nie mówi, na którym przejściu ginie informacja.
Sprawdź, czy podpowiedź nie prowadzi do podwójnego działania
Po nieudanej lub niepewnej próbie przeczytaj komunikat dosłownie, jak osoba robiąca zakupy pierwszy raz. Czy zachęca do utworzenia nowego koszyka, choć stare zamówienie już istnieje? Czy „spróbuj ponownie” wyjaśnia, czego dotyczy ponowienie? Osobno potwierdź w kontrolowanej próbie, czy powtórne wejście na ekran zakończenia nie tworzy drugiego zamówienia.
Na koniec przejrzyj testową wiadomość wysyłaną po zakupie. Jej opis płatności powinien odpowiadać znanemu stanowi, a nie samemu powrotowi kupującego do sklepu. Zamknij poprawkę dopiero po ponowieniu tej samej próby na tym samym urządzeniu. Wynik oznacza sprawdzenie opisanej drogi; nie jest obietnicą wzrostu sprzedaży ani potwierdzeniem wszystkich metod płatności.