Bramka Platnosci 3D Secure: Jak 3DS2 Chroni Merchantow przed Oszustwem
3D Secure to protokol uwierzytelniania opracowany przez systemy kart, ktory dodaje warstwe weryfikacji tozsamosci do transakcji kartowych online. Gdy klient placij przez bramke z wlaczonym 3D Secure, jego bank wydajacy weryfikuje transakcje przed jej autoryzacja, albo przez bezfrkcyjne sprawdzenie w tle, albo przez podpowiedz klientowi o uwierzytelnienie w aplikacji bankowej. Dla merchantow 3D Secure zapewnia dwie kluczowe korzysci: znacznie zmniejsza straty z tytu lu oszustw na transakcjach online i przesuwa odpowiedzialnosc za chargeback z tytu lu sporow o oszustwo z merchant a na bank wydajacy. Ten przewodnik wyjasnia, jak dziala 3D Secure, czym rozni sie wersja 2 od wersji 1 i jak wdrozyc 3DS2 przez RoxPay.
Czym Jest 3D Secure i Jak Dziala
3D Secure (3DS) to protokol uwierzytelniania oparty na XML dla transakcji bez fizycznej karty. Trzy domeny w nazwie odnosi sie do domeny merchant a, domeny akwizytora i domeny interoperacyjnosci (siec systemu kart i bank wydajacy). Razem te trzy strony uczestnicza w weryfikacji, ze osoba inicjujaca transakcje jest uprawnionym posiadaczem karty.
Przeplyw transakcji z 3DS:
Klient wprowadza dane karty przy kasie i przesyla platnosc. Bramka merchant a przesyla transakcje z zadaniem uwierzytelniania 3DS. System kart kieruje zadanie do Serwera Kontroli Dostepu wydawcy karty. Wydawca przeprowadza ocene ryzyka transakcji. Jesli ocena ryzyka wskazuje na niskie ryzyko (przeplyw bezfrakcyjny), transakcja jest uwierzytelniana bez interakcji klienta. Jesli ryzyko przekracza prog bezfrakcyjny, klient jest proszony o uwierzytelnienie, zazwyczaj przez zatwierdzenie powiadomienia push w aplikacji bankowej, wprowadzenie jednorazowego hasla lub potwierdzenie biometryczne. Wynik uwierzytelniania (uwierzytelniony, probowany lub nieudany) jest zwracany do bramki merchant a, ktora dolacza go do zadania autoryzacji do akwizytora.
Przesuniecie odpowiedzialnosci: Gdy transakcja jest pomyslnie uwierzytelniana przez 3DS i posiadacz karty pozniej kwestionuje ja jako oszustwo, odpowiedzialnosc za chargeback przesuwa sie z merchant a na bank wydajacy. Bank wydajacy zatwierdzil uwierzytelniona transakcje; nie moze potem skutecznie kwestionowac jej jako nieuprawnionej. To przesuniecie odpowiedzialnosci jest glowna korzysc ia komercyjna 3DS dla merchantow.
Dla merchantow prowadzacych bramke platnosci wysokiego ryzyka, wdrozenie 3DS2 jest szczegolnie wazne, poniewaz kategorie wysokiego ryzyka zazwyczaj maja podwyzszone wspolczynniki oszustw i friendly fraud, co sprawia, ze ochrona odpowiedzialnosci ma znaczenie komercyjne.
3DS1 vs 3DS2: Co Sie Zmienilo i Dlaczego To Ma Znaczenie
Oryginalna specyfikacja 3D Secure (3DS1) zostala wprowadzona na poczatku lat 2000. Chociaz zapewniala mechanizm przesuniecia odpowiedzialnosci, miala powazne problemy z uzytecznoscia i konwersja, ktore merchantci odczuwali jako porzucanie koszyka na etapie uwierzytelniania. 3DS2 (EMV 3DS) zostal opracowany w celu rozwiazania tych problemow.
Problemy 3DS1:
3DS1 wymag al przekierowania na strone uwierzytelniania wydawcy, ktora czesto byla slabo zaprojektowana i mylaca dla klientow. Model statycznych hasel uzywany przez wielu wydawcow (Verified by Visa, MasterCard SecureCode) byl latwy do zapomnienia i tworzyl friction na kazdej transakcji. Na urzadzeniach mobilnych przeplyw oparty na przekierowaniach i wyskakujacych oknach byl szczegolnie problematyczny. Wielu merchantow wylaczalo 3DS1 wlasnie dlatego, ze etap uwierzytelniania powodoval wiecej porzucen transakcji niz straty z tytu lu oszustw, ktore probowal zapobiec.
Usprawnienia 3DS2:
3DS2 wprowadza bogaty model udostepniania danych. Bramka merchant a wysyla nawet 150 punktow danych z zadaniem uwierzytelniania, w tym odcisk palca urzadzenia, charakterystyki przegladarki, historie zamowien i sygnaly behawioralne. Wydawca uzywa tych danych do podjecia decyzji o ryzyku. Dla transakcji o niskim ryzyku wydawca moze przyznac uwierzytelnianie bezfrakcyjne, co oznacza, ze klient nie jest nigdy proszony o nic i transakcja przebiega bez zaklocen.
Metody uwierzytelniania w 3DS2: Gdy uwierzytelnianie jest wymagane, 3DS2 obsluguje nowoczesne metody: powiadomienia push do aplikacji bankowej z potwierdzeniem biometrycznym, jednorazowe kody przez SMS i uwierzytelnianie w aplikacji bez przekierowania. Sa one znacznie mniej zaklocajace niz przekierowanie 3DS1.
PSD2 i Silne Uwierzytelnianie Klienta: Zmieniona Dyrektywa UE w Sprawie Uslug Platniczych (PSD2) naklada obowiazek Silnego Uwierzytelniania Klienta (SCA) dla wiekszosci europejskich transakcji kartowych bez fizycznej karty. 3DS2 jest glownym mechanizmem zgodnosci z SCA. Wydawcy sa zobowiazani do stosowania SCA do transakcji, ktore nie kwalifikuja sie do zwolnienia. Merchantci, ktorzy nie obsluguja 3DS2, odkrywaja, ze transakcje sa miekko odrzucane przez wydawcow, ktorzy wymagaja SCA, ale nie moga jej zakonczyc, poniewaz bramka nie przekazuje danych uwierzytelniania 3DS2.
Jak 3D Secure Zmniejsza Odpowiedzialnosc za Chargeback dla Merchantow
Przesuniecie odpowiedzialnosci zapewnione przez uwierzytelnianie 3D Secure jest mechanizmem, przez ktory merchantci zmniejszaja straty z tytu lu sporow o oszustwa.
Jak przesuniecie odpowiedzialnosci dziala w praktyce: Klient finalizuje zakup i uwierzytelnia sie przez 3DS2 (na przyklad przez zatwierdzenie powiadomienia push w aplikacji bankowej). Transakcja jest przetwarzana i towary sa dostarczane. Miesiac pozniej klient kontaktuje sie ze swoim bankiem wydajacym, twierdzac ze transakcja byla nieuprawniona. Bank inicjuje chargeback pod kodem przyczyny oszustwa (Visa 10.4, Mastercard 4853).
Gdy bramka merchant a przesyla odpowiedz, dolacza rekord uwierzytelniania 3DS2: Identyfikator Transakcji Uwierzytelniania (ATID), status uwierzytelniania (uwierzytelniony) i wartosc ECI wskazujaca pelne uwierzytelnianie. Ten rekord demonstruje, ze sam bank wydajacy posiadacza karty uwierzytelnil transakcje. Zespol ds. sporow w banku widzi, ze ten sam bank, ktory teraz przetwarza spor, byl tym, ktory uwierzytelnil transakcje. W praktyce skutkuje to odwroceniem chargeback w zdecydowanej wiekszosci przypadkow.
Transakcje, ktore nie korzystaja z przesuniecia odpowiedzialnosci: Nie wszystkie wyniki 3DS2 zapewniaja przesuniecie odpowiedzialnosci. Transakcja, ktora przeszla przez proces uwierzytelniania, ale daje status uwierzytelniania "probowanego" (karta nie obsluguje pelnego uwierzytelniania), zapewnia ograniczona ochrone w porownaniu z w pelni uwierzytelnionym wynikiem. Przesuniecie odpowiedzialnosci stosuje sie najsilniej do transakcji z udanym wynikiem uwierzytelniania i wartoscia ECI 05 (Visa) lub 02 (Mastercard).
Zwolnienia i odpowiedzialnosc: Niektore zwolnienia 3DS2 (transakcje o niskiej wartosci ponizej 30 euro, listy zaufanych beneficjentow, transakcje powtarzajace sie) pozwalaja na przetwarzanie transakcji bez SCA. Pozycja odpowiedzialnosci dla transakcji opartych na zwolnieniach rozni sie w zaleznosci od typu zwolnienia. Transakcje o niskiej wartosci, gdzie wydawca stosuje zwolnienie, utrzymuja odpowiedzialnosc po stronie merchant a. Transakcje, w ktorych merchant wnioskuje o zwolnienie, ktore wydawca nastepnie zatwierdza, moga skutkowac pozostaniem odpowiedzialnosci po stronie merchant a.
Kiedy 3D Secure Jest Wymagany vs Opcjonalny
Zgodnie z mandatem Silnego Uwierzytelniania Klienta PSD2, 3D Secure jest wymagany dla wiekszosci europejskich transakcji kartowych bez fizycznej karty, ale szereg zwolnien i scenariuszy poza zakresem definiuje, kiedy SCA nie ma zastosowania.
Kiedy 3DS jest wymagany (SCA ma zastosowanie):
Wszystkie standardowe platnosci kartowe bez fizycznej karty inicjowane przez klienta (transakcje inicjowane przez klienta lub CITs) dla kwot powyzej progu niskiej wartosci podlegaja SCA. Domyslna pozycja jest taka, ze SCA jest wymagana; zwolnienia sa wyjatkami.
Zwolnienia pozwalajace na transakcje bez 3DS:
Transakcje o niskiej wartosci: Transakcje ponizej 30 euro moga kwalifikowac sie do zwolnienia z niskiej wartosci. Jednak wydawcy sledza skumulowane kwoty i liczby transakcji; gdy zastosowano piec kolejnych zwolnien niskiej wartosci lub skumulowana kwota przekracza 100 euro, SCA jest wymagana dla nastepnej transakcji.
Analiza ryzyka transakcji (TRA): Wydawcy i akwizytorzy moga stosowac zwolnienia TRA do transakcji, ktore oceniaja jako niskiego ryzyka na podstawie benchmarkow wspolczynnika oszustw. Aby zastosowac zwolnienie TRA na poziomie akwizytora, akwizytorzy musi spelnic konkretne progi wspolczynnika oszustw zdefiniowane przez PSD2.
Transakcje powtarzajace sie: Pierwsza platnosc w serii powtarzajacej sie wymaga SCA. Kolejne transakcje inicjowane przez merchant a (MITs) w tym samym mandacie cyklicznym moga byc przetwarzane bez SCA, pod warunkiem ze poczatkowa transakcja byla uwierzytelniona, a kolejne transakcje przestrzegaja zasad przechowywanych danych uwierzytelniajacych.
Zaufany beneficjent: Posiadacze kart moga dodac merchantow do bialej listy u swojego wydawcy, stosujac zwolnienie zaufanego beneficjenta do przyszlych transakcji z tym merchantem.
Poza zakresem SCA: Transakcje inicjowane przez merchant a bez interakcji klienta (MIT), transakcje, gdzie jedna strona jest poza EOG (transakcje z jedna noga poza), i transakcje karta firmowa sa poza zakresem PSD2 SCA w konkretnych okolicznosciach.
Wdrazanie 3DS2 z RoxPay
Bramka platnosci RoxPay natywnie obsluguje 3DS2. Implementacja jest realizowana w ramach istniejaccej architektury integracji, bez koniecznosci oddzielnego dostawcy 3DS lub dodatkowej umowy.
Podejscie Drop-in UI: Jesli korzystasz z drop-in UI RoxPay (wprowadzanie kart oparte na JavaScript), 3DS2 jest obsługiwany automatycznie. Gdy wydawca wymaga uwierzytelniania, biblioteka zarzadza przekierowaniem do srodowiska uwierzytelniania wydawcy, obsługuje odpowiedz i kontynuuje przeplyw platnosci bez dodatkowego kodu po stronie merchant a. Jest to najprostsza droga do zgodnosci z 3DS2.
Podejscie integracji API: Dla merchantow korzystajacych z bezposredniej integracji API, dane uwierzytelniania 3DS2 sa przekazywane przez parametry intencji platnosci. API zwraca wynik uwierzytelniania i wymagane dzialanie dla frontenduu merchant a do obslugi, zgodnie ze standardowym przeplywem wyzwania 3DS2. Pelna dokumentacja jest dostepna na app.roxpay.eu/api/v4/docs.
Optymalizacja wspolczynnika bezfrakcyjnego: RoxPay przekazuje maksymalne dostepne dane w zadaniu uwierzytelniania 3DS2, aby wspierac wysokie wspolczynniki bezfrakcyjne. Uwierzytelnianie bezfrakcyjne oznacza, ze klient nie jest nigdy proszony o potwierdzenie czegos; wydawca zatwierdza transakcje w tle. Im wyzszy wspolczynnik bezfrakcyjny, tym lepszy wplyw na konwersje 3DS2.
Testowanie w sandbox: Sandbox RoxPay zapewnia scenariusze testowe dla kazdego wyniku 3DS2: uwierzytelnianie bezfrakcyjne, uwierzytelnianie z wyzwaniem, blad uwierzytelniania i karta nie zarejestrowana. Przetestuj wszystkie scenariusze przed uruchomieniem na zywo, aby upewnic sie, ze Twoja kasa prawidlowo obsługuje kazdy wynik.
Aby rozpoczac wniosek RoxPay i zaczac testowac 3DS2 w sandboxie, rejestracja zajmuje mniej niz dziesiec minut, a dane dostepowe do sandbox sa wydawane natychmiast. RoxPay posiada certyfikat PCI DSS Level 1 (QS83A47X629) i certyfikat ISO 27001.
Często zadawane pytania
Czy 3D Secure zmniejsza wspolczynniki konwersji?
3DS2 z prawidlowa implementacja ma minimalny wplyw na konwersje w porownaniu z 3DS1. Przeplyw uwierzytelniania bezfrakcyjnego, gdzie wydawca uwierzytelnia transakcje w tle bez dzialania klienta, reprezentuje 80-90% uwierzytelnionych transakcji dla dobrze skonfigurowanych merchantow. Pozostale transakcje wymagajace wyzwania (zazwyczaj powiadomienie push aplikacji bankowej lub OTP) doswiadczaja pewnego spadku, ale jest on znacznie nizszy niz spadek doswiadczany z modelem przekierowania i statycznych hasel 3DS1.
Czym jest wartosc ECI w uwierzytelnianiu 3DS?
Wartosc Wskaznika Handlu Elektronicznego (ECI) w odpowiedzi uwierzytelniania 3DS wskazuje poziom osiagnietego uwierzytelniania. ECI 05 (Visa) lub 02 (Mastercard) oznacza, ze pelne uwierzytelnianie zostalo ukonczone i zapewnia pelne przesuniecie odpowiedzialnosci. ECI 06 lub 01 oznacza, ze karta probowala uwierzytelniania, ale wydawca go nie obslugiwal, zapewniajac ograniczone przesuniecie odpowiedzialnosci. ECI 07 oznacza, ze uwierzytelnianie nie bylo przeprowadzane; nie ma przesuniecia odpowiedzialnosci.
Co sie dzieje, gdy klient nie przejdzie uwierzytelniania 3D Secure?
Jesli klient nie ukoncz y wyzwania 3DS2 (anuluje push aplikacji bankowej, wprowadzi bledne OTP lub pozwoli na wygasniecie sesji), uwierzytelnianie nie powiodlo sie i platnosc nie jest przetwarzana. Twoja bramka powinna wyswietlic jasny komunikat o bledzie i umozliwic klientowi powtorzenie proby lub uzycie innej metody platnosci. Nieudane uwierzytelnianie nie jest chargebackiem; transakcja jest po prostu nieautoryzowana.
Może Cię zainteresować
Bramka Płatności Wysokiego Ryzyka
Bezpieczne przetwarzanie płatności dla branż wysokiego ryzyka z routingiem multi-acquirer i ochroną przed chargeback.
Rozwiązania Płatnicze dla Małych Firm
Przejrzyste ceny IC++, bezpłatny terminal Smart POS i aktywacja w ciągu 24 godzin dla małych firm.
Integracje Płatności E-commerce
Wtyczki jednym kliknięciem dla Shopify, WooCommerce, Magento i PrestaShop z pełnym dostępem do API.
Zoptymalizuj swoje płatności już dziś
RoxPay obsluguje natywne 3DS2 z optymalizacja wspolczynnika bezfrakcyjnego, przesuniecie odpowiedzialnosci za uwierzytelnione transakcje i pelne testowanie sandbox. Certyfikat PCI DSS Level 1, ceny IC++ od 0,45%.
✓ Brak stałych kosztów miesięcznych · ✓ Aktywacja w 24 godziny · ✓ Dedykowane wsparcie techniczne
