> 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-et/makseviisid/kaardid/emv-r-3-d-secure-emv-3ds.md). # EMV® 3-D Secure (EMV 3DS) Kaardiomaniku autentimine veebimaksete jaoks – makselüüsi hallatav, õigusaktidega nõutud ja loodud pettuse tõkestamiseks ilma müüki pidurdamata. EMV® 3-D Secure (EMV 3DS), mida tavaliselt nimetatakse 3DS2-ks, on EMVCo poolt välja töötatud ülemaailmne autentimisprotokoll veebipõhiste kaardimaksete jaoks. See võimaldab kaardi väljastajal enne veebimakse autoriseerimist kaardiomaniku identiteeti kontrollida, vahetades turvaliselt autentimis- ja tehinguandmeid kaupmehe, kaardiskeemi ja väljastaja vahel. Kliendid võivad protsessi ära tunda kaardiskeemide kaubamärkide Visa Secure ja Mastercard Identity Check järgi. Euroopa kaupmeeste jaoks on EMV 3DS enamat kui pettusetõrje vahend: see on standardne mehhanism PSD2 kohase Tugeva Kliendi Autentimise (SCA) nõuete täitmiseks veebipõhiste kaardimaksete puhul. SEB Ecommerce Payment Gateway käsitleb EMV 3DS-i kaardimaksete töötlemise lahutamatu osana – lüüs käivitab autentimisvoo alati, kui see makse jaoks vajalik on, nii et teil ei ole vaja ise otsustada, millal 3DS rakendub. ### Peamised eelised * Vähendab veebimaksete pettust * Suurendab maksete autoriseerimise määra, vähendades ekslikke keeldumisi * Toetab PSD2 alusel tugeva kliendi autentimise (SCA) nõudeid * Parandab kliendi kassakogemust hõõrdevaba autentimise kaudu * Optimeeritud veebis, mobiilis ja rakendusesiseste maksete jaoks ### Võimaluste kokkuvõte
VõimalusToetus
ProtokollEMV® 3-D Secure 2.x – versioon 2.2.0; versioon 2.3.1 toetatud vastavalt kaardiskeemide nõuetele
Kaardiskeemi programmidVisa Secure, Mastercard Identity Check
AutentimisvoodSujuv ja väljakutsega autentimine
AlgatamineLüüsi poolt, alati kui autentimine on makse jaoks vajalik
SCA erandidToetatud vastavalt PSD2-le ja kaardiskeemide reeglitele
Kaupmehe algatatud tehingud3DS taotleja algatatud (3RI) autentimine, kui see on kohaldatav
AutentimiskogemusÜmbersuunamisel põhinev voog; väljakutse esitab kliendi kaardi väljastaja
Vastutuse üleminekVastavalt kaardiskeemide reeglitele (vt Vastutuse üleminek)
Integreerimise vaevPuudub Hosted Checkouti puhul; ümbersuunamise käsitlemine Merchant API integratsioonide korral
Sandboxi testimineToetatud – 3DS autentimisvooge saab Sandbox-keskkonnas testida
Üksikute võimaluste saadavus sõltub teie kaupmehe lepingust, lubatud teenustest ja omandamiskonfiguratsioonist. ### Kuidas EMV 3DS töötab Kui kaardimakse vajab autentimist, toimub järgmine – suurel määral teie jaoks ja enamasti ka kliendi jaoks nähtamatult: 1. Lüüs käivitab autentimise. Makse töötlemise käigus tuvastab lüüs, et autentimine on vajalik – näiteks seetõttu, et tehingule rakendub SCA – ning käivitab EMV 3DS voo. 2. Andmeid jagatakse väljastajaga. Rikkalikud tehingu- ja seadmeandmed vahetatakse väljastajaga kaardiskeemi 3-D Secure infrastruktuuri kaudu. Võrreldes pärand-3DS 1 protokolliga edastab EMV 3DS oluliselt rohkem andmepunkte, võimaldades väljastajal riski täpselt hinnata kliendi kogemust häirimata. 3. Väljastaja hindab riski. Riskihinnangu põhjal otsustab väljastaja, kas autentida klient vaikselt (sujuv voog) või nõuda täiendavat kontrollisammu (väljakutsega voog). 4. Klient autentib end, kui see on vajalik. Kui väljakutse on nõutud, teeb klient selle otse oma väljastajaga – tavaliselt kinnituse mobiilipanga rakenduses, ühekordse parooli või biomeetrilise kontrolli kaudu. Lüüs haldab ümbersuunamisel põhinevat autentimisvoogu. 5. Makse liigub autoriseerimise juurde. Autentimistulemus lisatakse autoriseerimistaotlusele ning lõpliku autoriseerimisotsuse teeb väljastaja. #### Sujuv ja väljakutsega autentimise vood
Sujuv voogVäljakutsega voog
Mis juhtubVäljastaja autentib tehingu vahetatud andmete põhjal – kliendipoolne sekkumine puudubKlient täidab oma väljastajaga täiendava kontrollisammu
KliendikogemusMidagi nähtavat ei toimu – kassaprotsess jätkub katkestustetaKinnitamine pangarakenduses, ühekordne parool (OTP) või biomeetriline kontroll
Millal see kehtibMadalama riskiga tehingud, kohaldatavad SCA erandid, väljastaja riskipõhine otsusKõrgema riskiga tehingud, regulatiivsed nõuded või väljastaja poliitika
Valdkonna hinnangute kohaselt toimub valdav enamus EMV 3DS autentimistest sujuva voo kaudu – klient ei märka kunagi, et autentimine toimus. Otsus kahe voo vahel kuulub alati väljastajale. ### SCA ja erandid PSD2 kohaselt on Euroopa klientide algatatud veebipõhiste kaardimaksete puhul nõutav Tugev Kliendi Autentimine. Praktikas tähendab see, et esialgne või ühe klõpsuga kaardimakse võib enne väljastaja kinnitust vajada EMV 3DS autentimist. Lüüs rakendab autentimist kooskõlas regulatiivsete nõuete ja kaardiskeemide reeglitega – sh toetatakse kohaldatavaid SCA erandeid, nagu väikese väärtusega tehingud või tehinguriski analüüs (TRA), kui teie acquiringu konfiguratsioon seda lubab. Kuidas see praktikas toimib, on oluline meeles pidada kahte asja: * Väljastajal on viimane sõna. Isegi kui erandit rakendatakse, võib väljastaja siiski nõuda autentimist ja keelduda esmasest autoriseerimiskatsest (nn pehme keeldumine). Sellisel juhul liigub makse läbi 3DS voo – lüüs haldab seda; teiepoolset tegevust ei ole vaja. * Kaupmehe algatatud tehinguid (MIT) käsitletakse teisiti. Kaupmehe algatatud tehingud töödeldakse ilma kliendi kohalolekuta; kui see on kohaldatav, võib kasutada 3DS taotleja algatatud (3RI) autentimist. Esialgse kliendi algatatud makse käigus teostatud SCA katab salvestatud maksetunnuse seadistuse. Vt Kaupmehe algatatud tehingud (MIT). ### Vastutuse üleminek Edukas EMV 3DS autentimine võib kooskõlas kaardiskeemide reeglitega nihutada pettusega seotud chargeback’ide vastutuse kaupmehelt väljastajale. See on üks 3DS kõige käegakatsutavamaid ärilisi eeliseid: kui autentitud tehing osutub hiljem pettuseks, kannab vaidluse üldjuhul väljastaja, mitte teie. Pidage meeles, et vastutuse ülemineku reeglid määravad ja haldavad kaardiskeemid ja väljastajad – see sõltub autentimise tulemusest, tehingu tüübist ja kohaldatavatest skeemi reeglitest ning ei kehti kõigi vaidlusaluste põhjuste puhul (näiteks kaupade või teenustega seotud vaidlused ei muutu). Autentimine vähendab pettuseriski vastutust; see ei asenda head tellimuse täitmise ja tarnimise praktikat. ### EMV 3DS ja muud makseviisid * Digirahakotid. Apple Pay, Google Pay ja Click to Pay teostavad tavaliselt tugeva kliendi autentimise rahakoti voo sees, mis tähendab, et eraldi 3DS sammu ei pruugi vaja minna. Kui 3DS töötlemine rakendub – näiteks Google Pay maksete puhul, kus kaart on salvestatud – käsitleb lüüs seda automaatselt. * Maksa pangaga. Pay by Bank ei kasuta 3DS-i üldse: Tugeva Kliendi Autentimise teostab kliendi pank omaenda autentimisvoos. * Salvestatud maksetunnused. Ühe klõpsuga kaardimaksed on kliendi algatatud ja võivad sõltuvalt eranditest ning väljastaja otsusest vajada 3DS-i; korduvmaksud on kaupmehe algatatud ja kasutavad vajaduse korral 3RI-d. ### Mida vajate EMV 3DS on osa kaardimaksete töötlemisest – selle jaoks ei ole eraldi aktiveerimist. #### Kui kasutate Hosted Checkouti Mitte midagi. Lüüs käivitab vajaduse korral autentimise ja esitab väljakutsega voo Hosted Checkouti kaudu. #### Kui loote oma kassalahenduse ise (Merchant API) Tugev Kliendi Autentimine teostatakse vajaduse korral ümbersuunamisel põhineva voona: teie integratsioon haldab kliendi suunamist autentimissammule ja tema tagasitulekut teie kassasse, nagu on kirjeldatud integratsioonijuhendis. Te ei pea ise 3DS loogikat rakendama – lüüs otsustab, millal autentimine on vajalik, ning haldab sõnumivahetust kaardiskeemi infrastruktuuriga. {% hint style="warning" %} Ärge püüdke oma integratsioonis autentimist tuvastada, vahele jätta ega alla suruda. Kui lüüs käivitab 3DS-i, on põhjuseks regulatsioon, kaardiskeemi reeglid või väljastaja nõue – sellest möödahiilimine toob kaasa maksete tagasilükkamise. {% endhint %} ### Kaupmehe parimad tavad * Käsitlege autentimist tavapärase maksevoolu osana – hoidke tellimusi ootel kuni lõpliku makseoleku kinnitamiseni, sh maksete puhul, kus klient täidab väljakutset. * Käsitlege pooleli jäänud autentimist sujuvalt: kui klient ei lõpeta väljakutset, laske tal proovida uuesti või valida mõni muu makseviis. * Esitage maksetaotlustes täpsed tellimuse- ja kliendiandmed – rikkalikumad ja täpsemad andmed toetavad väljastaja riskihinnangut ning suurendavad sujuvate autentimiste osakaalu. * Ärge täitke tellimusi pelgalt selle põhjal, et klient naasis teie veebisaidile – lähtuge kinnitatud makse olekust ja callback-teavitustest. * Teavitage kliente, et nende pank võib paluda neil makse kinnitada – näiteks mobiilipanga rakenduses –, et väljakutseline samm ei tuleks üllatusena. ### Testimine Sandbox-keskkond toetab 3DS autentimisvoogude testimist. Enne Production aktiveerimise taotlemist kontrollige järgmist: * Edukad maksed sujuva autentimisega. * Edukad maksed väljakutsega vooga, sh kliendi ümbersuunamine ja tagasitulek. * Ebaõnnestunud ja pooleli jäänud autentimise stsenaariumid – klient peab saama proovida uuesti või valida mõne muu makseviisi ning ühtegi tellimust ei tohi täita. * Õige tellimuse oleku käsitlemine kõigi autentimistulemuste korral callback-teavituste põhjal. ### Korduma kippuvad küsimused #### Kas iga kaardimakse läbib 3DS-i? Ei. Lüüs käivitab autentimise siis, kui see on vajalik – kuna rakendub SCA, kaardiskeemi reeglid seda nõuavad või väljastaja seda palub. Erandid ja kohaldamisalast väljas olevad juhud (näiteks kaupmehe algatatud tehingud) tähendavad, et paljud maksed töödeldakse ilma 3DS sammuta ning enamik autentitud makseid lõpeb sujuvalt. #### Kas ma pean 3DS-i ise rakendama? Ei. Hosted Checkouti puhul toimub autentimine täielikult Hosted Checkouti lehel. Merchant API puhul haldab teie integratsioon ümbersuunamisel põhinevat autentimisvoogu – väljaminevat suunamist ja kliendi tagasitulekut – kuid otsustusprotsessi ja 3DS sõnumivahetust haldab lüüs. #### Miks paluti minu kliendil oma pangarakenduses makse kinnitada? Väljastaja otsustas, et väljakutse on vajalik – lähtudes oma riskihinnangust, regulatiivsetest nõuetest või oma poliitikast. See on tavapärane ning kaitseb nii klienti kui ka teid. Väljakutse meetodi valik (pangarakendus, OTP, biomeetria) kuulub väljastajale. #### Kas 3DS tagab, et ma ei saa chargeback’e? Ei. Edukas autentimine võib kooskõlas kaardiskeemi reeglitega nihutada pettusega seotud chargeback’ide vastutuse väljastajale, kuid muudel põhjustel – näiteks kauba mittesaamine – tekkinud vaidlused sellest ei muutu. Vastutuse ülemineku otsuse teevad kaardiskeemid ja väljastajad. #### Millist 3DS versiooni lüüs toetab? EMV® 3-D Secure 2.x – hetkel versioon 2.2.0, ning versioon 2.3.1 on toetatud niipea, kui see muutub kaardiskeemide poolt nõutavaks. Versiooniuuendused hallatakse lüüsi poolel ega nõua muudatusi teie integratsioonis. #### Kas ma saan taotleda, et konkreetne makse jätaks 3DS-i vahele või sunniks selle rakendamist? Autentimist rakendatakse kooskõlas regulatsiooni, kaardiskeemi reeglite ja väljastaja nõuetega. Kui SCA erandid on kohaldatavad, käsitletakse neid lüüsi ja teie acquiringu konfiguratsiooni kaudu – arutage võimalusi oma SEB esindajaga. ### Seotud dokumentatsioon Jätkake järgmiste teemadega: * [Kaardid](/seb-docs-draft/seb-docs-public-et/makseviisid/kaardid.md) * [Tugev kliendi autentimine (SCA)](/seb-docs-draft/seb-docs-public-et/vastavus/tugev-kliendi-autentimine-sca.md) * [PSD2 (teine makseteenuste direktiiv)](/seb-docs-draft/seb-docs-public-et/vastavus/psd2-teine-makseteenuste-direktiiv.md) * [Salvestatud makseandmed](/seb-docs-draft/seb-docs-public-et/makseviisid/kaardid/salvestatud-makseandmed.md) * [Kliendi algatatud tehingud (CIT)](/seb-docs-draft/seb-docs-public-et/makseviisid/kaardid/salvestatud-makseandmed/kliendi-algatatud-tehingud-cit.md) * [Kaupmehe algatatud tehingud (MIT)](/seb-docs-draft/seb-docs-public-et/makseviisid/kaardid/salvestatud-makseandmed/kaupmehe-algatatud-tehingud-mit.md) * [Testimine](/seb-docs-draft/seb-docs-public-et/makseviisid/kaardid/testimine.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-et/makseviisid/kaardid/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.