W checkout często dzieje się więcej niż „zwykłe” wypełnienie formularza i kliknięcie zapłać. W pewnym momencie użytkownik trafia na dodatkowy etap uwierzytelniania 3D Secure, który jest realizowany w osobnym flow (z ekranem/promptem od wystawcy). Jeśli Twoje komunikaty wyglądają jak błąd całego checkoutu, rośnie chaos: użytkownik nie wie, czy problem jest w płatności jako całości, czy tylko w tej konkretnej warstwie uwierzytelniania.
UX writing w 3D Secure powinien więc mówić językiem procesu: co teraz się dzieje (processing), co oznacza nieudane uwierzytelnienie (z perspektywy flow), i jaki ma sens „co dalej” — bez zgadywania przyczyny. W praktyce wystarczy dobrze rozdzielić stan „trwa przetwarzanie 3D Secure” od komunikatu po nieudanym wyniku, a całość będzie bardziej przewidywalna.
Dlaczego komunikaty w 3D Secure są osobnym „mikro-journey” w checkout
3D Secure to dodatkowy krok uwierzytelniania, który ma ograniczać ryzyko fraudu. Dla użytkownika oznacza to zwykle osobny ekran lub prompt w obrębie checkoutu: nie tyle „kolejny błąd formularza”, co wyraźnie wydzielony etap weryfikacji po stronie wystawcy (issuer). Dlatego komunikat nie może brzmieć jak ogólna awaria zakupów — ma sygnalizować, że to dzieje się konkretnie w 3D Secure.
W tym mikro-journey kluczowe jest również dopasowanie do tego, co użytkownik widzi. Podczas wymiany komunikatów w 3D Secure w wytycznych dla UX pojawia się ekran przetwarzania (processing), który ma informować, że trwa „3-D Secure processing”. To ważna wskazówka dla copy: gdy użytkownik czeka, tekst ma utrzymywać sens działania procesu, a nie sugerować, że checkout „już odrzucił” płatność.
Z perspektywy redakcyjnej pomaga jedna zasada: komunikat na Twojej stronie powinien współgrać z flow 3DS. Nie mieszaj pojęć (np. „błąd płatności” w momencie, gdy użytkownik jest w trakcie przetwarzania uwierzytelniania), bo to zaburza mapowanie: użytkownik interpretuje komunikat jako informację o całym checkout, a nie o osobnym kroku.
Język dla stanu „processing / czekanie na uwierzytelnienie”
Gdy użytkownik widzi, że uwierzytelnianie jest w toku, ton komunikatu powinien być procesowy i uspokajający. W tym momencie nie testujesz hipotez, nie rozstrzygasz „dlaczego”, nie diagnozujesz zachowania kart czy sieci. Wystarczy przekazać jedną rzecz: trwa przetwarzanie 3D Secure (w praktyce zgodnie z oczekiwanym „processing screen” podczas wymiany komunikatów).
Jak to przełożyć na copy? Używaj sformułowań, które brzmią jak obserwacja stanu systemu, a nie obietnica rezultatu. Unikaj komunikatów w stylu „już za chwilę” albo „zaraz przejdziemy dalej”. Jeśli użytkownik czeka, dla niego liczy się jasność: to jest etap oczekiwania w 3D Secure, a nie nowy, losowy błąd w checkout.
Warto też pamiętać o języku po drugiej stronie flow. Wytyczne i dokumentacja wskazują, że język samego przepływu 3D Secure może zależeć od ustawień (np. preferred_locales). Twoje teksty w checkout powinny być jednoznaczne również wtedy, gdy część doświadczenia w 3DS będzie po innej stronie komunikacyjnej. Dlatego terminologia musi być konsekwentna: „3D Secure” jako nazwa etapu oraz „przetwarzanie” jako opis stanu.
Elementy, które powinien „nosić” tekst w processing
Dobry komunikat w stanie processing ma spełniać trzy rolę: nazwać etap, nazwać stan i nie mieszać znaczeń z innymi błędami. Pomocne jest utrzymanie krótkiej struktury, którą możesz powtarzać w kolejnych wariantach:
- Etap: użyj nazwy „3D Secure” oraz prostego określenia „krok uwierzytelniania”.
- Stan: wprost powiedz, że „trwa przetwarzanie” lub że „3D Secure jest w toku” (bez ocen).
- Brak diagnozy: nie opisuj, co poszło nie tak — w tym stanie nie ma jeszcze zakończenia próby, więc to będzie zgadywanie.
Jeśli chcesz być jeszcze bardziej praktyczny, możesz dopisać jedno zdanie o tym, że użytkownik pozostaje w procesie oczekiwania na wynik uwierzytelniania. To pomaga dopasować ton do sytuacji „czekania”: użytkownik ma poczuć, że system działa, a nie że checkout się zawiesił.
Błąd uwierzytelniania 3D Secure: jak pisać „co dalej” bez zgadywania przyczyny
Komunikat po nieudanym uwierzytelnieniu 3D Secure powinien odpowiadać na jedno kluczowe pytanie użytkownika: „co to znaczy i co mam zrobić teraz?”. W danych z dokumentacji dotyczących 3D Secure podkreślane jest, że po nieudanym uwierzytelnieniu autoryzacja może zostać automatycznie odrzucona. To ważna informacja dla UX writing, ale nie oznacza, że masz przerobić komunikat na długą instrukcję techniczną.
Najbezpieczniejsze podejście to rozdzielenie komunikatu na dwa kroki: najpierw neutralna informacja o zakończeniu próby uwierzytelniania w 3D Secure, a potem kierunek „co dalej” jako działanie w obrębie checkout. Unikaj dopisywania przyczyn, jeśli nie masz ich wprost w logice statusów flow. Badania użytkowników czy domysły zespołu nie są tu potrzebne — liczy się spójność z tym, co wiadomo na poziomie procesu.
Jeżeli planujesz obsłużyć ponowną próbę w checkout, pamiętaj o ostrożności. Dokumentacja wskazuje mechanizm czasowego wyłączania 3D Secure po kilku nieudanych próbach w krótkim czasie. Copy nie powinno więc obiecywać, że ponowienie „na pewno” zadziała. Zamiast tego możesz opisać, że użytkownik może wrócić do kroku i spróbować ponownie w ramach checkout, bez gwarancji.
W praktyce dobrze działa też taka kolejność myślenia: najpierw komunikat o wyniku próby w 3D Secure, potem dopiero neutralna instrukcja kontynuacji. Dzięki temu użytkownik rozumie, że to zamknięcie etapu, a nie przypadkowy błąd całego procesu zakupowego.
Kopie komunikatów pod scenariusze przerwania i bezczynności (inactivity)
Nieudane uwierzytelnianie może wynikać także z przerwania procesu lub bezczynności. Wytyczne wskazują, że porzucone uwierzytelnianie może być skutkiem inactivity timeout. Dla copy oznacza to, że w scenariuszu „zbyt długo trwało” nie wolno pisać jak o winie użytkownika. To ma być neutralne opisanie sytuacji jako „nieukończona próba” — bez straszenia i bez moralizowania.
Jak pisać „co dalej” w takich przypadkach? Zadbaj, by instrukcja była spójna z tym, że próba nie została dokończona w ramach procesu uwierzytelniania. Najczęściej sensownie brzmią komunikaty o ponowieniu kroku uwierzytelniania w checkout lub powrocie do wcześniejszego miejsca w ścieżce (np. do etapu wyboru metody płatności, jeśli to jest część Twojego flow). Unikaj stwierdzeń, które sugerują, że użytkownik „powinien był” coś zrobić inaczej.
Warto też przewidzieć, jak te teksty zachowują się przy kolejnych próbach. Skoro 3D Secure może być czasowo wyłączane po kilku nieudanych próbach, komunikat „spróbuj ponownie” powinien brzmieć jak zaproszenie do kontynuacji procesu, a nie jak obietnica natychmiastowego sukcesu.
Najważniejsze jest bezpieczeństwo interpretacji: nie zakładaj, czy to była przerwana sesja, zbyt długa przerwa czy anulowanie — Twoje „co dalej” ma kierować do działania w checkout, bez diagnozy przyczyn po stronie użytkownika.
Język i dopasowanie w praktyce: gdy część flow może być po innej stronie
W 3D Secure użytkownik może przemieszczać się między ekranami, które są częścią checkoutu, a ekranami hostowanymi po stronie wystawcy. Dlatego copy w Twojej witrynie powinno być napisane tak, by nadal było zrozumiałe, nawet jeśli użytkownik widzi komunikaty o innej stylistyce lub w innym języku (ponieważ język flow 3DS zależy od ustawień po stronie implementacji).
W praktyce oznacza to minimalizm treści i konsekwencję terminologiczną. Gdy użytkownik jest w processing, tekst powinien trzymać się opisu „trwa przetwarzanie 3D Secure”. Gdy próba się kończy niepowodzeniem, tekst powinien przejść na język „próba zakończona” i neutralne „co dalej”. Nie próbuj jednocześnie tłumaczyć całego checkoutu i etapów po drugiej stronie flow — to prowadzi do chaosu.
Dobry UX writing daje użytkownikowi mapę sytuacji: „jestem w 3D Secure” i „teraz dzieje się X”. Reszta szczegółów nie musi być komunikowana wprost, bo nie jesteś w stanie przewidzieć, co użytkownik dokładnie widzi w 3DS po swojej stronie. Twoja rola redakcyjna to spójne prowadzenie w tych dwóch stanach: oczekiwanie oraz zakończenie próby.
Szybka zasada: terminologia musi prowadzić, a nie mieszać
Ustal prostą regułę, którą stosujesz we wszystkich wariantach komunikatów 3D Secure:
- Na etapie 3D Secure używaj nazw „3D Secure” oraz „krok/uwierzytelnianie 3D Secure”, zamiast ogólników typu „błąd płatności”.
- Dobieraj czasownik do stanu: „trwa przetwarzanie” w processing i „próba zakończona” w komunikacie po nieudanym wyniku.
- Dołącz tylko te działania, które mieszczą się w checkout jako „co dalej” — bez zgadywania przyczyny po stronie użytkownika.
To ogranicza ryzyko, że użytkownik pomyśli, że całe zamówienie ma awarię, kiedy tak naprawdę „zawiesił się” tylko etap uwierzytelniania. A tam, gdzie różne elementy flow mogą być po innej stronie, terminologia robi największą robotę.
Checklist copywritera: audyt komunikatów 3D Secure w checkout
Zanim wdrożysz teksty do produkcji, potraktuj je jak element krytyczny procesu. Poniższa checklist pomaga sprawdzić, czy komunikaty prowadzą użytkownika przez mikro-journey i czy nie wprowadzają interpretacji, które nie wynikają z logiki flow.
- Czy komunikat jasno sygnalizuje, że to etap 3D Secure, a nie ogólny błąd całego checkout?
- Czy masz wyraźnie oddzielony stan processing / czekanie od komunikatu po nieudanym uwierzytelnieniu?
- Czy w stanie oczekiwania tekst jest procesowy (bez ocen, bez obietnic wyniku, bez „diagnoz”)?
- Czy „co dalej” po nieudanym uwierzytelnieniu opisuje bezpieczny next step w ramach checkout, zamiast zgadywać przyczynę (np. sieć, kod, sesja)?
- Czy unikasz obietnic typu „na pewno zadziała po ponowieniu” i uwzględniasz ostrożność wobec kolejnych nieudanych prób (z perspektywy działania procesu)?
- Czy scenariusze przerwania/inactivity są neutralne i nie przypisują winy użytkownikowi, tylko kierują do kontynuacji procesu?
- Czy komunikaty nie proszą o dane lub działania, które omijałyby krok uwierzytelniania?
Gdy przejdziesz tę listę, znacznie łatwiej będzie utrzymać spójność języka między ekranami i statusami. A spójność w UX writingu jest jak warstwa ochronna: zmniejsza liczbę nieporozumień, nawet gdy użytkownik trafia w „trudniejszy” moment checkoutu.
Mini-wzór procesu: co ma być w każdej wersji komunikatu
Żeby komunikaty były konsekwentne w wielu stanach, trzymaj się jednego schematu. To proste, ale działa, bo zawsze prowadzi użytkownika od tego, co dzieje się teraz, do tego, co może zrobić dalej.
- Wersja processing: „Jesteś w kroku 3D Secure. Trwa przetwarzanie / czekanie na uwierzytelnienie.” (bez wchodzenia w przyczyny).
- Wersja po nieudanym uwierzytelnieniu: „Próba uwierzytelniania 3D Secure zakończyła się niepowodzeniem.” + „Możesz wrócić do kroku w checkout i spróbować ponownie” (bez gwarancji).
- Wersja przerwana / inactivity: „Proces uwierzytelniania został przerwany / nie został dokończony.” + „Wróć do checkout i ponów krok, aby kontynuować płatność.”
Jeśli w każdej wersji trzymasz ten układ, użytkownik zawsze wie, gdzie jest w całym doświadczeniu. A Ty utrzymujesz copy, które jest zgodne z logiką procesu i nie wybiega poza to, co da się bezpiecznie powiedzieć.
Najlepsze copy w 3D Secure prowadzi użytkownika przez osobny mikro-journey w checkout: jasno sygnalizuje etap i utrzymuje sens „processing” wtedy, gdy trwa wymiana komunikatów. Po nieudanym uwierzytelnieniu komunikat ma być neutralny i skoncentrowany na tym, co dalej w ramach flow — bez zgadywania przyczyny. W scenariuszach przerwania lub bezczynności zadbaj o język opisujący nieukończoną próbę, a nie winę użytkownika. Dzięki spójnej terminologii i strukturze komunikatu ograniczasz chaos, nawet gdy język po stronie 3DS może się różnić.
Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
