> 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-lv/maksajumu-metodes/kartes/emv-r-3-d-secure-emv-3ds.md). # EMV® 3-D Secure (EMV 3DS) Kartes turētāja autentifikācija tiešsaistes maksājumiem — vārteja to apstrādā, to pieprasa regulējums, un tā ir izstrādāta, lai apturētu krāpniecību, neapturot pārdošanu. EMV® 3-D Secure (EMV 3DS), ko parasti dēvē par 3DS2, ir globālais tiešsaistes karšu maksājumu autentifikācijas protokols, ko izstrādājis EMVCo. Tas ļauj kartes izdevējam pirms tiešsaistes maksājuma apstiprināšanas pārbaudīt kartes turētāja identitāti, droši apmainoties ar autentifikācijas un darījuma datiem starp tirgotāju, karšu shēmu un izdevēju. Klienti šo procesu var atpazīt ar karšu shēmu zīmoliem Visa Secure un Mastercard Identity Check. Tirgotājiem Eiropā EMV 3DS ir vairāk nekā krāpšanas novēršanas rīks: tas ir standarta mehānisms, lai tiešsaistes karšu maksājumos izpildītu Stingrās klienta autentifikācijas (SCA) prasības saskaņā ar PSD2. SEB Ecommerce Payment Gateway apstrādā EMV 3DS kā neatņemamu karšu maksājumu apstrādes daļu – vārteja uzsāk autentifikācijas plūsmu ikreiz, kad tā ir nepieciešama maksājumam, tāpēc jums nav jālemj, kad 3DS tiek piemērots. ### Galvenie ieguvumi * Samazina tiešsaistes maksājumu krāpniecību * Palielina maksājumu autorizācijas rādītājus, samazinot nepamatotus atteikumus * Atbalsta Stingrās klienta autentifikācijas (SCA) prasības saskaņā ar PSD2 * Uzlabota klienta norēķinu pieredze, izmantojot autentifikāciju bez papildu darbībām * Optimizēts tīmekļa, mobilajiem un lietotnē veiktajiem maksājumiem ### Funkcionalitātes kopsavilkums
FunkcionalitāteAtbalsts
ProtokolsEMV® 3-D Secure 2.x – versija 2.2.0; versija 2.3.1 tiek atbalstīta, ja to pieprasa karšu shēmas
Shēmu programmasVisa Secure, Mastercard Identity Check
Autentifikācijas plūsmasBez papildu darbībām un ar papildu verifikāciju
IniciēšanaAr vārteju, ikreiz, kad autentifikācija ir nepieciešama maksājumam
SCA atbrīvojumiAtbalstīti saskaņā ar PSD2 un karšu shēmu noteikumiem
Tirgotāja iniciēti darījumi3DS pieprasījuma iniciēta (3RI) autentifikācija, ja piemērojams
Autentifikācijas pieredzePlūsma ar novirzīšanu; papildu verifikāciju prezentē klienta izdevējs
Atbildības pārejaSaskaņā ar karšu shēmu noteikumiem (skatīt Atbildības pāreju)
Integrācijas darbsNav nepieciešams Hosted Checkout; novirzīšanas apstrāde Merchant API integrācijām
Sandbox testēšanaAtbalstīta – 3DS autentifikācijas plūsmas var testēt Sandbox vidē
Atsevišķu funkcionalitāšu pieejamība ir atkarīga no jūsu tirgotāja līguma, iespējotajiem pakalpojumiem un apstrādes konfigurācijas. ### Kā darbojas EMV 3DS Kad karšu maksājumam ir nepieciešama autentifikācija, notiek tālāk norādītais – lielākoties jums un vairumā gadījumu arī klientam tas notiek nemanāmi: 1. Vārteja uzsāk autentifikāciju. Maksājuma apstrādes laikā vārteja nosaka, ka autentifikācija ir nepieciešama – piemēram, tāpēc, ka darījumam ir piemērojama SCA – un uzsāk EMV 3DS plūsmu. 2. Dati tiek kopīgoti ar izdevēju. Bagātīgi darījuma un ierīces dati tiek apmainīti ar izdevēju, izmantojot karšu shēmas 3-D Secure infrastruktūru. Salīdzinājumā ar mantoto 3DS 1 protokolu EMV 3DS nodod ievērojami vairāk datu punktu, ļaujot izdevējam precīzi novērtēt risku, netraucējot klientu. 3. Izdevējs novērtē risku. Pamatojoties uz riska novērtējumu, izdevējs lemj, vai klientu autentificēt nemanāmi (plūsma bez papildu darbībām) vai prasīt papildu verifikācijas soli (plūsma ar papildu verifikāciju). 4. Klients autentificējas, ja tas ir nepieciešams. Ja ir vajadzīga papildu verifikācija, klients to pabeidz tieši pie sava izdevēja – parasti apstiprinot to savas mobilās bankas lietotnē, izmantojot vienreizēju paroli vai biometrisko verifikāciju. Vārteja pārvalda uz novirzīšanu balstīto autentifikācijas plūsmu. 5. Maksājums pāriet autorizācijā. Autentifikācijas rezultāts tiek pievienots autorizācijas pieprasījumam, un gala autorizācijas lēmumu pieņem izdevējs. #### Plūsmas bez papildu darbībām un ar papildu verifikāciju
Plūsma bez papildu darbībāmPlūsma ar papildu verifikāciju
Kas notiekIzdevējs autentificē darījumu, pamatojoties uz apmainītajiem datiem – bez klienta mijiedarbībasKlients pabeidz papildu verifikācijas soli pie sava izdevēja
Klienta pieredzeNekas nav redzams – norēķins turpinās bez pārtraukumaApstiprinājums bankas lietotnē, vienreizēja parole (OTP) vai biometriskā verifikācija
Kad tas tiek piemērotsZema riska darījumi, piemērojamie SCA atbrīvojumi, izdevēja uz risku balstīts lēmumsAugstāka riska darījumi, normatīvās prasības vai izdevēja politika
Nozares aplēses liecina, ka lielākā daļa EMV 3DS autentifikāciju tiek pabeigta, izmantojot plūsmu bez papildu darbībām – klients pat nepamana, ka autentifikācija ir notikusi. Lēmums starp abām plūsmām vienmēr pieder izdevējam. ### SCA un atbrīvojumi Saskaņā ar PSD2 Stingrā klienta autentifikācija ir obligāta klienta iniciētiem tiešsaistes karšu maksājumiem Eiropā. Praktiski tas nozīmē, ka sākotnējam vai ar vienu klikšķi veiktam kartes maksājumam pirms izdevēja apstiprinājuma var būt nepieciešama autentifikācija ar EMV 3DS. Vārteja piemēro autentifikāciju atbilstoši normatīvajām prasībām un karšu shēmu noteikumiem – tostarp atbalstot piemērojamos SCA atbrīvojumus, piemēram, mazvērtīgiem darījumiem vai darījuma riska analīzei (TRA), ja to atļauj jūsu apstrādes konfigurācija. Divi svarīgi punkti par to, kā tas darbojas praksē: * Izdevējam ir pēdējais vārds. Pat tad, ja tiek piemērots atbrīvojums, izdevējs joprojām var pieprasīt autentifikāciju un noraidīt sākotnējo autorizācijas mēģinājumu (“soft decline”). Tādā gadījumā maksājums turpinās 3DS plūsmā – to pārvalda vārteja; no jums nekādas darbības nav nepieciešamas. * MIT tiek apstrādāti citādi. Tirgotāja iniciētie darījumi tiek apstrādāti, klientam neesot klāt; ja piemērojams, tie var izmantot 3DS pieprasījuma iniciētu (3RI) autentifikāciju. SCA, kas veikta sākotnējā klienta iniciētajā maksājumā, attiecas uz saglabātā maksājuma līdzekļa iestatīšanu. Skatīt Tirgotāja iniciētie darījumi (MIT). ### Atbildības pāreja Veiksmīga EMV 3DS autentifikācija saskaņā ar karšu shēmu noteikumiem var pārcelt ar krāpniecību saistītu atgriezenisko maksājumu atbildību no tirgotāja uz izdevēju. Tas ir viens no taustāmākajiem 3DS komerciālajiem ieguvumiem: autentificēta darījuma gadījumā, kas vēlāk izrādās krāpniecisks, strīdu parasti sedz izdevējs, nevis jūs. Ņemiet vērā, ka atbildības pāreju regulē un nosaka karšu shēmas un izdevēji – tā ir atkarīga no autentifikācijas rezultāta, darījuma veida un piemērojamajiem shēmu noteikumiem, un tā neattiecas uz visiem strīdu iemesliem (piemēram, strīdi par precēm vai pakalpojumiem netiek ietekmēti). Autentifikācija samazina krāpšanas risku; tā neaizstāj labu pasūtījumu un piegādes praksi. ### EMV 3DS un citi maksājumu veidi * Digitālie maki. Apple Pay, Google Pay un Click to Pay parasti veic Stingro klienta autentifikāciju maka plūsmā, tāpēc atsevišķs 3DS solis var nebūt nepieciešams. Ja tiek piemērota 3DS apstrāde – piemēram, Google Pay maksājumiem ar saglabātu karti – vārteja to apstrādā automātiski. * Pay by Bank. Pay by Bank vispār neizmanto 3DS: Stingrā klienta autentifikācija tiek veikta klienta bankā tās pašu autentifikācijas plūsmā. * Saglabātie maksājuma dati. Ar vienu klikšķi veiktie kartes maksājumi ir klienta iniciēti un atkarībā no atbrīvojumiem un izdevēja lēmuma var prasīt 3DS; atkārtotie maksājumi ir tirgotāja iniciēti un, ja piemērojams, izmanto 3RI. ### Kas jums nepieciešams EMV 3DS ir daļa no karšu maksājumu apstrādes – tam nav nepieciešama atsevišķa aktivizēšana. #### Ja izmantojat Hosted Checkout Nekas. Vārteja uzsāk autentifikāciju, kad tas ir nepieciešams, un Hosted Checkout parāda papildu verifikācijas plūsmu. #### Ja veidojat savu norēķinu lapu (Merchant API) Stingrā klienta autentifikācija, ja nepieciešams, tiek veikta, izmantojot uz novirzīšanu balstītu plūsmu: jūsu integrācija apstrādā klienta novirzīšanu uz autentifikācijas soli un atpakaļ uz jūsu norēķinu lapu, kā aprakstīts integrācijas rokasgrāmatā. Jums pašiem nav jāievieš 3DS loģika – vārteja nosaka, kad autentifikācija ir nepieciešama, un pārvalda ziņojumu apmaiņu ar karšu shēmas infrastruktūru. {% hint style="warning" %} Nemēģiniet savā integrācijā noteikt, izlaist vai slāpēt autentifikāciju. Kad vārteja uzsāk 3DS, tas notiek tāpēc, ka to pieprasa regulējums, shēmu noteikumi vai izdevējs – apiešana noved pie atteiktiem maksājumiem. {% endhint %} ### Tirgotāja labākā prakse * Uzskatiet autentifikāciju par normālas maksājuma plūsmas daļu – saglabājiet pasūtījumus kā gaidošus, līdz tiek apstiprināts galīgais maksājuma statuss, tostarp maksājumiem, kuros klients pabeidz papildu verifikāciju. * Rīkojieties saudzīgi ar pamestu autentifikāciju: ja klients nepabeidz papildu verifikāciju, ļaujiet viņam mēģināt vēlreiz vai izvēlēties citu maksājuma metodi. * Maksājuma pieprasījumos norādiet precīzus pasūtījuma un klienta datus – bagātāki un precīzāki dati atbalsta izdevēja riska novērtējumu un palielina autentifikāciju bez papildu darbībām īpatsvaru. * Neizpildiet pasūtījumus, balstoties uz klienta atgriešanos jūsu vietnē – paļaujieties uz apstiprināto maksājuma statusu un atzvanīšanas paziņojumiem. * Informējiet klientus, ka viņu banka var lūgt apstiprināt maksājumu – piemēram, mobilās bankas lietotnē –, lai papildu verifikācijas solis nebūtu pārsteigums. ### Testēšana Sandbox vide atbalsta 3DS autentifikācijas plūsmu testēšanu. Pirms pieprasāt Production aktivizēšanu, pārbaudiet: * Veiksmīgus maksājumus ar autentifikāciju bez papildu darbībām. * Veiksmīgus maksājumus ar papildu verifikācijas plūsmu, tostarp klienta novirzīšanu un atgriešanos. * Neizdevušos un pamestus autentifikācijas scenārijus – klientam jāspēj mēģināt vēlreiz vai izvēlēties citu maksājuma metodi, un pasūtījumu nedrīkst izpildīt. * Pareizu pasūtījuma statusa apstrādi, pamatojoties uz atzvanīšanas paziņojumiem, visiem autentifikācijas rezultātiem. ### Biežāk uzdotie jautājumi #### Vai katrs kartes maksājums iziet caur 3DS? Nē. Vārteja uzsāk autentifikāciju tad, kad tas ir nepieciešams – jo piemērojama SCA, to pieprasa shēmu noteikumi vai to lūdz izdevējs. Atbrīvojumi un gadījumi ārpus darbības jomas (piemēram, tirgotāja iniciēti darījumi) nozīmē, ka daudzi maksājumi tiek apstrādāti bez 3DS soļa, un lielākā daļa autentificēto maksājumu noslēdzas bez papildu darbībām. #### Vai man pašam jāievieš 3DS? Nē. Ar Hosted Checkout autentifikācija pilnībā tiek pārvaldīta Hosted Checkout lapā. Ar Merchant API jūsu integrācija apstrādā uz novirzīšanu balstīto autentifikācijas plūsmu – novirzīšanu uz ārpusi un klienta atgriešanos –, bet lēmumu pieņemšanu un 3DS ziņojumu apmaiņu pārvalda vārteja. #### Kāpēc mans klients tika aicināts apstiprināt maksājumu savas bankas lietotnē? Izdevējs nolēma, ka ir nepieciešama papildu verifikācija – balstoties uz riska novērtējumu, normatīvajām prasībām vai savu politiku. Tas ir normāli un aizsargā gan klientu, gan jūs. Papildu verifikācijas metodes izvēle (bankas lietotne, OTP, biometrika) pieder izdevējam. #### Vai 3DS garantē, ka es nesaņemšu atgriezeniskos maksājumus? Nē. Veiksmīga autentifikācija saskaņā ar karšu shēmu noteikumiem var pārcelt ar krāpniecību saistītu atgriezenisko maksājumu atbildību uz izdevēju, taču strīdi citu iemeslu dēļ – piemēram, preces nav saņemtas – netiek ietekmēti. Lēmumu par atbildības pāreju nosaka karšu shēmas un izdevēji. #### Kuru 3DS versiju atbalsta vārteja? EMV® 3-D Secure 2.x – pašlaik versija 2.2.0, un versija 2.3.1 tiek atbalstīta, tiklīdz to pieprasa karšu shēmas. Versiju atjauninājumi tiek veikti vārtejas pusē, un tiem nav nepieciešamas izmaiņas jūsu integrācijā. #### Vai es varu pieprasīt, lai konkrēts maksājums izlaistu vai piespiestu 3DS? Autentifikācija tiek piemērota saskaņā ar regulējumu, karšu shēmu noteikumiem un izdevēja prasībām. Ja ir piemērojami SCA atbrīvojumi, tos apstrādā vārteja un jūsu apstrādes konfigurācija – pārrunājiet iespējas ar savu SEB pārstāvi. ### Saistītā dokumentācija Turpiniet ar šādām tēmām: * [Kartes](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes.md) * [Stingrā klienta autentifikācija (SCA)](/seb-docs-draft/seb-docs-public-lv/atbilstiba/speciga-klienta-autentifikacija-sca.md) * [PSD2 (Otrā maksājumu pakalpojumu direktīva)](/seb-docs-draft/seb-docs-public-lv/atbilstiba/psd2-otra-maksajumu-pakalpojumu-direktiva.md) * [Saglabātie maksājuma dati](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati.md) * [Klienta iniciēti darījumi (CIT)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/klienta-inicieti-darijumi-cit.md) * [Tirgotāja iniciēti darījumi (MIT)](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/saglabatie-maksajumu-akreditacijas-dati/tirgotaja-inicieti-darijumi-mit.md) * [Testēšana](/seb-docs-draft/seb-docs-public-lv/maksajumu-metodes/kartes/testesana.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-lv/maksajumu-metodes/kartes/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.