> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/emv-r-3-d-secure-emv-3ds.md). # EMV® 3-D Secure (EMV 3DS) Kortelės turėtojo autentifikavimas internetiniams mokėjimams – atliekamas vartų sistemos, privalomas pagal reglamentavimą, sukurtas padėti stabdyti sukčiavimą nesustabdant pardavimų. EMV® 3-D Secure (EMV 3DS), paprastai vadinamas 3DS2, yra pasaulinis internetinių mokėjimų kortele autentifikavimo protokolas, sukurtas EMVCo. Jis leidžia kortelės išdavėjui patikrinti kortelės turėtojo tapatybę prieš autorizuojant internetinį mokėjimą, saugiai keičiantis autentifikavimo ir operacijos duomenimis tarp prekybininko, kortelių schemos ir išdavėjo. Klientai šį procesą gali atpažinti pagal kortelių schemų prekės ženklus Visa Secure ir Mastercard Identity Check. Europos prekybininkams EMV 3DS yra daugiau nei sukčiavimo prevencijos priemonė: tai standartinis mechanizmas, padedantis įvykdyti stipraus klientų autentifikavimo (SCA) reikalavimus pagal PSD2 internetiniams mokėjimams kortele. SEB Ecommerce Payment Gateway EMV 3DS apdoroja kaip neatskiriamą kortelių mokėjimų apdorojimo dalį – mokėjimų vartai inicijuoja autentifikavimo eigą kiekvieną kartą, kai tai būtina mokėjimui, todėl jums nereikia spręsti, kada taikomas 3DS. ### Pagrindiniai privalumai * Sumažina internetinių mokėjimų sukčiavimą * Didina mokėjimų autorizavimo rodiklius, sumažindamas klaidingus atmetimus * Padeda įgyvendinti stipraus kliento autentifikavimo (SCA) reikalavimus pagal PSD2 * Pagerina kliento atsiskaitymo patirtį, nes autentifikavimas vyksta sklandžiai * Optimizuota žiniatinklio, mobiliesiems įrenginiams ir programėlėse atliekamiems mokėjimams ### Galimybių santrauka
GalimybėPalaikymas
ProtokolasEMV® 3-D Secure 2.x – 2.2.0 versija; 2.3.1 versija palaikoma, kai to reikalauja kortelių schemos
Schemos programosVisa Secure, Mastercard Identity Check
Autentifikavimo eigosSklandžioji ir su papildomu patvirtinimu
InicijavimasMokėjimų vartų pagalba, kai tik mokėjimui būtinas autentifikavimas
SCA išimtysPalaikoma pagal PSD2 ir kortelių schemų taisykles
Prekybininko inicijuojamos operacijos3DS užsakovo inicijuotas (3RI) autentifikavimas, kai taikoma
Autentifikavimo patirtisPeradresavimo pagrindu veikianti eiga; papildomą patvirtinimą pateikia kliento išdavėjas
Atsakomybės perkėlimasPagal kortelių schemų taisykles (žr. Atsakomybės perkėlimas)
Integravimo pastangosNereikia, jei naudojate Hosted Checkout; Merchant API integracijoms reikia tvarkyti peradresavimą
Testavimas Sandbox aplinkojePalaikoma – 3DS autentifikavimo eigas galima testuoti Sandbox aplinkoje
Atskirų galimybių prieinamumas priklauso nuo jūsų prekybininko sutarties, įgalintų paslaugų ir įsigyjančiojo banko konfigūracijos. ### Kaip veikia EMV 3DS Kai mokėjimui kortele reikia autentifikavimo, vyksta toliau nurodyti veiksmai – jums ir, daugeliu atvejų, klientui jie beveik nematomi: 1. Mokėjimų vartai inicijuoja autentifikavimą. Mokėjimo apdorojimo metu vartai nustato, kad autentifikavimas būtinas – pavyzdžiui, nes operacijai taikomas SCA – ir inicijuoja EMV 3DS eigą. 2. Duomenys dalijami su išdavėju. Per kortelių schemos 3-D Secure infrastruktūrą su išdavėju apsikeičiama išsamiais operacijos ir įrenginio duomenimis. Palyginti su senesniu 3DS 1 protokolu, EMV 3DS perduoda gerokai daugiau duomenų taškų, todėl išdavėjas gali tiksliau įvertinti riziką netrikdydamas kliento. 3. Išdavėjas įvertina riziką. Remdamasis rizikos vertinimu, išdavėjas nusprendžia, ar autentifikuoti klientą tyliai (sklandžioji eiga), ar reikalauti papildomo patvirtinimo žingsnio (papildomo patvirtinimo eiga). 4. Jei reikia, klientas autentifikuojasi. Jei reikalingas papildomas patvirtinimas, klientas jį užbaigia tiesiogiai su savo išdavėju – paprastai tai patvirtinimas mobiliosios bankininkystės programėlėje, vienkartinis slaptažodis arba biometrinis patvirtinimas. Mokėjimų vartai valdo peradresavimo pagrindu veikiančią autentifikavimo eigą. 5. Mokėjimas pereina į autorizavimą. Autentifikavimo rezultatas pridedamas prie autorizavimo užklausos, o galutinį autorizavimo sprendimą priima išdavėjas. #### Sklandžioji ir papildomo patvirtinimo eigos
Sklandžioji eigaPapildomo patvirtinimo eiga
Kas vykstaIšdavėjas autentifikuoja operaciją remdamasis apsikeistais duomenimis – jokio kliento įsitraukimoKlientas savo išdavėjui atlieka papildomą patvirtinimo žingsnį
Kliento patirtisNieko nematoma – atsiskaitymas tęsiasi be pertraukųPatvirtinimas bankininkystės programėlėje, vienkartinis slaptažodis (OTP) arba biometrinis patvirtinimas
Kada taikomaMažesnės rizikos operacijos, taikomos SCA išimtys, išdavėjo rizika pagrįstas sprendimasDidesnės rizikos operacijos, reguliavimo reikalavimai arba išdavėjo politika
Pramonės vertinimais, didžioji dauguma EMV 3DS autentifikacijų užbaigiamos sklandžiąja eiga – klientas net nepastebi, kad autentifikavimas vyko. Sprendimas, kurią iš dviejų eigų taikyti, visada priklauso išdavėjui. ### SCA ir išimtys Pagal PSD2 stiprus klientų autentifikavimas reikalaujamas Europoje klientų inicijuotiems internetiniams mokėjimams kortele. Praktikoje tai reiškia, kad pradinį arba vieno paspaudimo mokėjimą kortele gali reikėti autentifikuoti EMV 3DS prieš išdavėjui jį patvirtinant. Mokėjimų vartai autentifikavimą taiko pagal reguliavimo reikalavimus ir kortelių schemų taisykles – įskaitant palaikymą taikomoms SCA išimtims, tokioms kaip mažos vertės operacijos arba operacijos rizikos analizė (TRA), kai tai leidžia jūsų priėmimo konfigūracija. Du svarbūs dalykai apie tai, kaip tai veikia praktikoje: * Paskutinį žodį taria išdavėjas. Net jei taikoma išimtis, išdavėjas vis tiek gali reikalauti autentifikavimo ir atmesti pradinį autorizavimo bandymą („minkštasis atmetimas“). Tokiu atveju mokėjimas pereina per 3DS eigą – tai valdo mokėjimų vartai; iš jūsų jokių veiksmų nereikia. * MIT tvarkomi kitaip. Prekybininko inicijuojamos operacijos apdorojamos klientui nedalyvaujant; kai taikoma, joms gali būti naudojamas 3DS užsakovo inicijuotas (3RI) autentifikavimas. Pradinis kliento inicijuotas mokėjimas, kurio metu atliekamas SCA, apima saugomo kredencialo nustatymą. Žr. Prekybininko inicijuojamos operacijos (MIT). ### Atsakomybės perkėlimas Sėkmingas EMV 3DS autentifikavimas pagal kortelių schemų taisykles gali perkelti su sukčiavimu susijusių grąžinamųjų mokėjimų atsakomybę iš prekybininko išdavėjui. Tai vienas apčiuopiamiausių 3DS komercinių privalumų: jei autentifikuota operacija vėliau pasirodo esanti apgaulinga, ginčą paprastai padengia išdavėjas, o ne jūs. Turėkite omenyje, kad atsakomybės perkėlimą reglamentuoja ir nustato kortelių schemos bei išdavėjai – jis priklauso nuo autentifikavimo rezultato, operacijos tipo ir taikomų schemos taisyklių, ir jis netaikomas visiems ginčo pagrindams (pavyzdžiui, ginčai dėl prekių ar paslaugų nėra paveikiami). Autentifikavimas sumažina sukčiavimo atsakomybę; jis nepakeičia geros užsakymų ir pristatymo praktikos. ### EMV 3DS ir kiti mokėjimo būdai * Skaitmeninės piniginės. Apple Pay, Google Pay ir Click to Pay paprastai atlieka stiprų klientų autentifikavimą pačios piniginės eigoje, todėl atskiras 3DS žingsnis gali būti nereikalingas. Kai 3DS apdorojimas taikomas – pavyzdžiui, mokėjimams Google Pay su kortele, saugoma sistemoje – mokėjimų vartai tai tvarko automatiškai. * Mokėjimai per banką. Mokėjimai per banką 3DS visai nenaudoja: stiprų klientų autentifikavimą atlieka paties kliento bankas savo autentifikavimo eigoje. * Saugomi kredencialai. Vieno paspaudimo mokėjimai kortele yra kliento inicijuojami ir, priklausomai nuo išimčių bei išdavėjo sprendimo, jiems gali reikėti 3DS; pasikartojantys nurašymai yra prekybininko inicijuojami ir, kai taikoma, naudoja 3RI. ### Ko jums reikia EMV 3DS yra kortelių mokėjimų apdorojimo dalis – jam nereikia atskiro aktyvavimo. #### Jei naudojate priglobtą atsiskaitymą Nereikia. Mokėjimų vartai inicijuoja autentifikavimą, kai to reikia, ir pateikia papildomo patvirtinimo eigą per Hosted Checkout. #### Jei kuriate savo atsiskaitymo aplinką (Merchant API) Kai to reikalaujama, stiprus klientų autentifikavimas atliekamas per peradresavimo pagrindu veikiančią eigą: jūsų integracija valdo kliento peradresavimą į autentifikavimo žingsnį ir jo grįžimą į jūsų atsiskaitymo puslapį, kaip aprašyta integravimo vadove. Jūs patys neįgyvendinate jokios 3DS logikos – mokėjimų vartai nustato, kada autentifikavimas būtinas, ir valdo pranešimų mainus su kortelių schemos infrastruktūra. {% hint style="warning" %} Nemėginkite savo integracijoje aptikti, praleisti ar slopinti autentifikavimo. Kai mokėjimų vartai inicijuoja 3DS, taip yra todėl, kad to reikalauja reglamentai, schemos taisyklės arba išdavėjas – apeinant tai mokėjimai atmetami. {% endhint %} ### Geriausia prekybininkų praktika * Autentifikavimą laikykite įprasto mokėjimo srauto dalimi – laikykite užsakymus laukiančiais, kol bus patvirtintas galutinis mokėjimo statusas, įskaitant mokėjimus, kai klientas užbaigia papildomą patvirtinimą. * Tvarkykite nebaigtą autentifikavimą sklandžiai: jei klientas neužbaigia papildomo patvirtinimo, leiskite jam bandyti dar kartą arba pasirinkti kitą mokėjimo būdą. * Savo mokėjimo užklausose pateikite tikslius užsakymo ir kliento duomenis – išsamesni ir tikslesni duomenys padeda išdavėjo rizikos vertinimui ir didina sklandžiųjų autentifikacijų dalį. * Nevykdykite užsakymų remdamiesi tuo, kad klientas grįžo į jūsų svetainę – remkitės patvirtintu mokėjimo statusu ir grįžtamaisiais pranešimais. * Informuokite klientus, kad jų bankas gali paprašyti jų patvirtinti mokėjimą – pavyzdžiui, mobiliosios bankininkystės programėlėje – kad papildomo patvirtinimo žingsnis jų nenustebintų. ### Testavimas Sandbox aplinka palaiko 3DS autentifikavimo eigų testavimą. Prieš prašydami aktyvavimo Production aplinkoje, patikrinkite: * Sėkmingus mokėjimus su sklandžiąja autentifikacija. * Sėkmingus mokėjimus su papildomo patvirtinimo eiga, įskaitant kliento peradresavimą ir grįžimą. * Nepavykusius ir nebaigtus autentifikavimo scenarijus – klientas turi galėti bandyti dar kartą arba pasirinkti kitą mokėjimo būdą, o joks užsakymas negali būti įvykdytas. * Teisingą užsakymo būsenos tvarkymą pagal grįžtamuosius pranešimus visiems autentifikavimo rezultatams. ### Dažniausiai užduodami klausimai #### Ar kiekvienas mokėjimas kortele pereina per 3DS? Ne. Mokėjimų vartai inicijuoja autentifikavimą tada, kai to reikia – nes taikomas SCA, to reikalauja schemos taisyklės arba to paprašo išdavėjas. Išimtys ir neapimti atvejai (tokie kaip prekybininko inicijuojamos operacijos) reiškia, kad daugelis mokėjimų apdorojami be 3DS žingsnio, o dauguma autentifikuotų mokėjimų užbaigiami sklandžiai. #### Ar man pačiam reikia įgyvendinti 3DS? Ne. Su Hosted Checkout autentifikavimas visiškai atliekamas Hosted Checkout puslapyje. Su Merchant API jūsų integracija valdo peradresavimo pagrindu veikiančią autentifikavimo eigą – peradresavimą į išorę ir kliento grįžimą – tačiau sprendimų priėmimą ir 3DS pranešimų mainus valdo mokėjimų vartai. #### Kodėl mano klientas buvo paprašytas patvirtinti mokėjimą savo bankininkystės programėlėje? Išdavėjas nusprendė, kad reikalingas papildomas patvirtinimas – remiantis rizikos vertinimu, reguliavimo reikalavimais arba savo politika. Tai yra įprasta ir apsaugo tiek klientą, tiek jus. Papildomo patvirtinimo metodą (bankininkystės programėlė, OTP, biometrika) parenka išdavėjas. #### Ar 3DS garantuoja, kad negausiu grąžinamųjų mokėjimų ginčų? Ne. Sėkmingas autentifikavimas pagal kortelių schemų taisykles gali perkelti su sukčiavimu susijusių grąžinamųjų mokėjimų atsakomybę išdavėjui, tačiau ginčams dėl kitų priežasčių – pavyzdžiui, negautos prekės – tai netaikoma. Sprendimą dėl atsakomybės perkėlimo priima kortelių schemos ir išdavėjai. #### Kurią 3DS versiją palaiko mokėjimų vartai? EMV® 3-D Secure 2.x – šiuo metu 2.2.0 versiją, o 2.3.1 versija palaikoma, kai ją ima reikalauti kortelių schemos. Versijų atnaujinimai atliekami mokėjimų vartų pusėje ir nereikalauja jūsų integracijos pakeitimų. #### Ar galiu paprašyti, kad konkretus mokėjimas praleistų 3DS arba būtų priverstinai per jį nukreiptas? Autentifikavimas taikomas pagal reglamentavimą, kortelių schemų taisykles ir išdavėjo reikalavimus. Kai taikomos SCA išimtys, jos apdorojamos per mokėjimų vartus ir jūsų priėmimo konfigūraciją – aptarkite galimybes su savo SEB atstovu. ### Susijusi dokumentacija Tęskite su šiomis temomis: * [Kortelės](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles.md) * [Stiprus kliento autentifikavimas (SCA)](/seb-docs-draft/seb-docs-public-lt/atitiktis/stiprus-kliento-autentifikavimas-sca.md) * [PSD2 (Antroji mokėjimo paslaugų direktyva)](/seb-docs-draft/seb-docs-public-lt/atitiktis/psd2-antroji-mokejimo-paslaugu-direktyva.md) * [Išsaugoti kredencialai](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys.md) * [Kliento inicijuoti sandoriai (CIT)](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys/kliento-inicijuotos-transakcijos-cit.md) * [Prekybininko inicijuojamos operacijos (MIT)](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/issaugoti-duomenys/prekybininko-inicijuotos-transakcijos-mit.md) * [Testavimas](/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/testavimas.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/seb-docs-draft/seb-docs-public-lt/mokejimo-metodai/korteles/emv-r-3-d-secure-emv-3ds.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.