W checkoutach płatności czasem nie dostajesz „pomyślnie” albo „nie udało się”. Czasem pojawia się sygnał, że płatność wymaga dodatkowej akcji, bo uruchamia się mechanizm SCA/3D Secure. W Stripe najczęściej widać to jako status requires_action — i właśnie tu UX copy robi największą różnicę.
Jeśli napiszesz „Coś poszło nie tak”, użytkownik będzie szukał przyczyny i najpewniej wróci do działań, które nie rozwiążą problemu. Jeśli natomiast nazwiesz to weryfikacją oraz pokażesz „co dalej” wprost, komunikat staje się prowadzeniem przez proces płatności, a nie raportem awarii. W tym poradniku dostaniesz schemat i gotowe warianty microcopy do użycia w UI.
Z perspektywy zespołów marketingu, e-commerce i UX chodzi o jedno: spójność między tym, co obiecujesz zdaniem, a tym, co realnie zobaczy użytkownik po statusie requires_action.
Dlaczego `requires_action` to nie „błąd”, tylko kolejny krok (SCA/3DS)
Szybka różnica w języku: „weryfikacja” vs „nie udało się”
Status requires_action pojawia się wtedy, gdy płatność nie może domknąć się automatycznie bez dodatkowej akcji wynikającej z wymagań SCA/3D Secure. Stripe opisuje tę logikę wprost: w typowych scenariuszach status oznacza, że trzeba uruchomić kolejny krok po stronie integracji/UI, aby doprowadzić proces do końca.
UX copy ma to odzwierciedlać. Zamiast języka porażki użyj języka „weryfikacji”. To nie jest kosmetyka słów — to ustawienie oczekiwań. Krótki rdzeń, który warto trzymać w głowie:
- To wymagana weryfikacja, aby dokończyć płatność, a nie zwykły błąd płatności.
Gdy user widzi status wymagający SCA, to jego realnym kolejnym krokiem jest przejście przez ekran następnej akcji (np. weryfikacji). Niech komunikat przygotuje na ten etap, zamiast sugerować, że trzeba „naprawiać” płatność od nowa.
Język, który minimalizuje frustrację: obietnica procesu, nie rezultatu
W copywritingowym ujęciu najczęstsza pułapka to obietnica wyniku. W tym miejscu lepiej zrezygnować z deklaracji typu „płatność się powiedzie” i skupić się na procesie. Badania w UX czasem pokazują, że obietnice rezultatu bolą, gdy sytuacja jest zależna od weryfikacji — a tu mamy dokładnie taki mechanizm.
- Obiecuj kolejny etap (weryfikacja), nie obiecuj efektu.
- Używaj spokojnych konstrukcji: „przejdź do weryfikacji”, „dokończ weryfikację”, „to kolejny krok w płatności”.
Dzięki temu użytkownik ma mniej powodów do paniki. W praktyce: skoro status mówi o dodatkowej akcji, to rolą UI jest ją zainicjować lub pokazać instrukcję, a rolą copy jest sprawić, żeby ta akcja była zrozumiała.
Cel UX copy w statusie `requires_action`: informować, prowadzić, nie mieszać
Co musi znaleźć się w komunikacie (minimalny komplet)
Dobre UX copy dla requires_action odpowiada na dwa pytania użytkownika, zanim zdąży kliknąć w losowe miejsca:
- Co się stało? — weryfikacja jest wymagana, aby dokończyć płatność (SCA/3D Secure).
- Co mam zrobić teraz? — przejść do kolejnego kroku i potwierdzić weryfikację, gdy pojawi się ekran weryfikacji.
To wystarczy jako minimalny komplet. Reszta to dopowiedzenia pomagające w zrozumieniu, np. że to standardowa część płatności, a nie „awaria”. Warto też pamiętać o ograniczeniach: microcopy musi być krótkie, a jednocześnie precyzyjne.
Jeśli w UI masz miejsce na jedno zdanie, trzymaj je w tej logice: nazwa „weryfikacja” + wskazanie „co dalej”. Jeśli masz więcej przestrzeni, dodaj jedno zdanie uspokajające: to kolejny etap płatności, a nie osobna, niezależna próba.
Czego nie dorzucać w treści (żeby nie tworzyć „fałszywego błędu”)
W tym scenariuszu nie chcesz dopisywać interpretacji, która przeczy temu, co się dzieje. Stripe wskazuje, że status oznacza potrzebę dodatkowej akcji związanej z uwierzytelnianiem. Dlatego copy powinno unikać komunikatów, które wyglądają jak zwykły błąd lub jak prośba o ponawianie płatności ręcznie.
- Nie dopisuj „spróbuj ponownie”, jeśli celem jest przejście przez weryfikację.
- Nie sugeruj działań „na ślepo” (np. „kliknij coś i będzie dobrze”).
- Nie wprowadzaj sprzeczności: jeśli mówisz „weryfikacja”, następny krok nie może wyglądać jak „błąd”.
W copywritingowym języku: unikaj fałszywego dopasowania narracji. Status requires_action to sygnał procesu, a nie pomyłki użytkownika.
Gotowy schemat zdania po zdaniu: „co się dzieje” + „co zrobić dalej”
Wzór komunikatu do przepisania w UI
Najwygodniej jest pisać kompozycją dwóch krótkich zdań. Schemat możesz traktować jak wzór redakcyjny, który później dostosujesz długością do miejsca w checkout.
- Zdanie 1 (co się dzieje): płatność wymaga dodatkowej weryfikacji, aby ją dokończyć.
- Zdanie 2 (co zrobić dalej): przejdź do kolejnego kroku i potwierdź weryfikację.
Jeśli potrzebujesz wariantu jeszcze krótszego, skróć całość do jednego zdania i dopisz etykietę przy przycisku (albo podpowiedź pod nim), np. „Przejdź do weryfikacji”. Dodatkowa korzyść: łatwo utrzymać spójność języka między alertem, przyciskiem i kolejnym ekranem.
Dla zespołów, które wdrażają flow: pamiętaj, że copy ma prowadzić w ramach tego samego procesu. To powinno być czytelne już w samym tekście: to nie jest „nowa próba płatności”, tylko „kolejny etap płatności”.
Jak dobrać długość tekstu do miejsca w checkout
Nie każde miejsce w checkout nadaje się do tego samego komunikatu. Zamiast pisać uniwersalny „długi paragraf”, dostosuj wersję do komponentu:
- Alert/blok informacyjny: możesz pozwolić sobie na 2–3 krótkie zdania (co się dzieje + co zrobić + jedno zdanie normalizujące).
- Miejsce przy przycisku: jeden komunikat prowadzący (np. „Aby dokończyć płatność, przejdź do weryfikacji”).
- Opis pod CTA: jedno dopowiedzenie „co zobaczysz dalej” bez obiecywania wyniku.
W praktyce to oszczędza czas redakcji: tworzysz rdzeń tekstu i sklejasz go w różne długości, zamiast za każdym razem pisać od zera. Najważniejsze: niezależnie od długości, instrukcja „co dalej” ma być jasna.
Łączenie komunikatu z ekranem weryfikacji (UI states i przejścia)
Zasada spójności: treść → następny ekran
W scenariuszu requires_action integracja/UI ma zwykle uruchomić kolejny krok (np. weryfikację). To oznacza, że komunikat w checkout powinien przygotować użytkownika na to, co zobaczy w kolejnym ekraniu.
- Jeśli w komunikacie mówisz „weryfikacja”, kolejny ekran nie powinien wyglądać jak typowy błąd.
- Jeśli zapowiadasz „przejdź do weryfikacji”, CTA powinno rzeczywiście prowadzić do następnego kroku, a nie zamykać dialog i zostawiać użytkownika bez kierunku.
- Jeśli przepływ może przejść przez automatyczny element lub dodatkowe przełączenie, unikaj kategorycznego języka o przebiegu „zawsze tak samo”.
To także miejsce, gdzie UX writing spotyka się z praktyką: copy powinno być zsynchronizowane z tym, jak front-end obsługuje status. Jeśli komunikat ma normalizować sytuację, to musi robić to konsekwentnie w całej ścieżce.
Dzięki temu użytkownik nie interpretuje kolejnego kroku jako „kolejnego błędu”, tylko jako oczekiwany etap płatności.
Warianty mikrocopy: on-session vs off-session (kiedy klient jest obecny)
Jak napisać „prowadzenie”, a nie „zgadywanie”
W badanym kontekście Stripe rozróżnia sytuacje on session i off session. Z punktu widzenia copy oznacza to, że w jednej sytuacji użytkownik jest aktywnie w checkout (i może przejść weryfikację od razu), a w drugiej płatność jest inicjowana poza widocznym kontekstem użytkownika. Różnica wpływa na to, jak dużo trzeba wytłumaczyć.
W obu przypadkach kluczowe jest prowadzenie, a nie zgadywanie:
- Weryfikacja jest wymagana, aby dokończyć płatność.
- Użytkownik ma przejść do kolejnego kroku, gdy pojawi się ekran weryfikacji.
- Nie proś o ponowienie płatności jako ręcznej akcji, jeśli mechanika jest oparta o dalszy etap procesu.
Gdy komunikat jest zbyt ogólny („coś wymaga potwierdzenia”), użytkownik zacznie szukać przyczyny. Gdy jest zbyt instrukcyjny („kliknij tutaj, potem tam”), a przepływ może się różnić, też rośnie frustracja. Dlatego najlepiej trzymać się neutralnego języka „kolejnego kroku” i zapowiedzi tego, co ma się pokazać.
Przykładowe różnice w tonie w zależności od kontekstu
To, jak brzmi zdanie, można dopasować do tego, czy użytkownik jest „w środku” procesu.
- On session: ton może być bardziej zwięzły. Użytkownik widzi checkout, więc wystarczy krótka zapowiedź weryfikacji i proste „przejdź dalej”.
- Off session: ton powinien zawierać krótkie dopowiedzenie „dlaczego teraz” — bo użytkownik nie był w trakcie płatności. Nadal rdzeń pozostaje ten sam: wymagana jest dodatkowa akcja, aby dokończyć płatność.
Jeśli masz w zespole dwie osoby piszące teksty do różnych miejsc, te warianty tonów pomagają zachować spójność, mimo różnic w kontekście ekranów.
Checklist: najczęstsze błędy w UX copy dla `requires_action`
Szybki test tekstu: czy użytkownik wie, co ma zrobić teraz?
Zrób szybki test przed wdrożeniem. Przeczytaj komunikat tak, jakbyś widział go po raz pierwszy, bez znajomości mechaniki płatności:
- Czy komunikat nazywa sytuację „weryfikacją”, a nie „błędem”?
- Czy jasno mówi, że istnieje kolejny krok w ramach płatności?
- Czy instrukcja „co dalej” prowadzi do procesu, a nie do ponawiania płatności jako nowej próby?
- Czy obietnica jest o procesie, a nie o wyniku?
Jeśli choć na jedno pytanie odpowiedź brzmi „nie do końca”, zwykle wystarczy doprecyzować jedno zdanie: co się dzieje i gdzie użytkownik ma przejść dalej.
Szybki test spójności: czy słowa pasują do następnego ekranu?
Teraz test spójności — szczególnie ważny, gdy komunikat i ekran weryfikacji „obsługują się” przez integrację. Tu chodzi o zgodność między treścią a zachowaniem UI.
- Czy to, co zapowiadasz, zgadza się z tym, co użytkownik zobaczy w kolejnym kroku?
- Czy nie dublujesz informacji tak, że użytkownik ma wrażenie, że widzi „to samo ponownie”?
- Czy komunikat nie sugeruje awarii, jeśli status oznacza wymaganie dodatkowej akcji?
- Czy nie używasz technicznych detalów z integracji, które użytkownikowi w ogóle nie pomagają przejść dalej?
Spójność języka i kolejności kroków ogranicza frustrację nawet wtedy, gdy proces ma dodatkowy etap.
Przykłady gotowych komunikatów (do przepisania)
Komunikat w checkout (dłuższy wariant)
Możesz użyć wersji, która ma pełny sens i prowadzi krok po kroku:
Płatność wymaga dodatkowej weryfikacji, aby ją dokończyć. Przejdź do kolejnego kroku i potwierdź weryfikację. To standardowa część procesu płatności — nie musisz uruchamiać płatności ponownie ręcznie.
Ten wariant dobrze działa w alertach i blokach informacyjnych. Daje odpowiedź na „co się dzieje” (weryfikacja) i „co zrobić teraz” (przejść do kolejnego kroku i potwierdzić).
Komunikat krótszy (dla ograniczonego miejsca)
Gdy masz mało przestrzeni, postaw na krótkie prowadzenie bez dodatków:
Aby dokończyć płatność, przejdź do weryfikacji.
Jeśli jest miejsce na dopowiedzenie przy CTA, możesz dodać drugą warstwę w jednym zdaniu:
Potwierdź weryfikację w kolejnym kroku, który pojawi się po kliknięciu.
Komunikat dla płatności poza aktywnym kontekstem (off-session)
Gdy użytkownik nie jest „w środku” checkoutu, komunikat powinien łatwo odpowiedzieć na pytanie „dlaczego widzę to teraz”. Zachowaj rdzeń i doprecyzuj sens:
Twoja płatność wymaga dodatkowej akcji, aby ją dokończyć. Przejdź do weryfikacji w kolejnym kroku i potwierdź ją, gdy zobaczysz ekran weryfikacji.
To zdanie ogranicza poczucie chaosu: nie nazywa sytuacji błędem, tylko wskazuje, że potrzebny jest proces weryfikacji.
Podsumowując: requires_action oznacza konieczność dodatkowego kroku wynikającego z wymagań SCA/3D Secure, a nie klasyczną porażkę płatności. W UX copy najważniejsze jest znormalizowanie sytuacji („weryfikacja”), jasne wskazanie „co dalej” oraz przygotowanie użytkownika na ekran kolejnej akcji. Dobrze, gdy słowa w checkout dokładnie pasują do tego, co realnie pojawia się w następnym kroku, a obietnice dotyczą procesu, nie wyniku. Na koniec warto przejrzeć wszystkie komunikaty wokół statusu i upewnić się, że nigdzie nie pojawia się język błędu ani instrukcje „ponów płatność od zera”. Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
