3D Secure fizetési átjáró: hogyan védi a 3DS2 a kereskedőket a csalástól
A 3D Secure a kártyasémák által kidolgozott hitelesítési protokoll, amely egy plusz azonosítási réteget ad az online kártyatranzakciókhoz. Amikor egy ügyfél egy 3D Secure-kompatibilis átjárón keresztül fizet, a kibocsátó bankja a tranzakciót még az engedélyezés elott elenőrzi, akár súrlódásmentes háttér-elenőrzéssel, akár az ügyfél banki applikáción keresztüli hitelesítési promptolásával. A kereskedők számára a 3D Secure két kritikus elonyt biztosít: szignifikánsan csökkenti a csalási veszteségeket az online tranzakciókon, és átruházza a visszaterhelési felelősséget a csalási vitákra a kereskedőről a kibocsátó bankra. Ez az útmutató elmagyarázza, hogyan muködik a 3D Secure, miben különbözik a 2-es verzió az 1-estől és hogyan implementálható a 3DS2 az RoxPay-en keresztül.
Mi a 3D Secure és hogyan muködik
A 3D Secure (3DS) egy XML-alapú hitelesítési protokoll a kártya nem jelen létu tranzakciókhoz. A névben szereplő három domain a kereskedoi doménre, az acquirer doménre és az interoperabilitási doménre (a kártyaséma hálózat és a kibocsátó bank) utal.
Tranzakciós folyamat 3DS-sel:
Az ügyfél megadja a kártyaadatokat a pénztárnál és beküldi a fizetést. A kereskedő átjárója 3DS hitelesítési kéréssel nyújtja be a tranzakciót. A kártyaséma a kérést a kártyakibocsátó Access Control Serveréhez irányítja. Ha a kockázatértékelés alacsony kockázatot jelez, a tranzakció ügyfélinterakció nélkül kerül hitelesítésre. Ha a kockázat meghaladja a súrlódásmentes küszöbértéket, az ügyfelet hitelesítésre kérik fel.
A felelősség-átruházás: Amikor egy tranzakció sikeresen kerül hitelesítésre 3DS-en keresztül, és a kártyabirtokos késobb vitatja azt csalásként, a visszaterhelési felelősség a kereskedőről a kibocsátó bankra száll át. Ez a felelősség-átruházás a 3DS elsodleges kereskedelmi elonye a kereskedők számára.
A magas kockázatú fizetési átjárót üzemeltető kereskedők számára a 3DS2 megvalósítása különösen fontos, mert a magas kockázatú kategóriák általában magasabb csalási és barátságos csalási aránnyal rendelkeznek.
3DS1 vs 3DS2: mi változott és miért fontos
Az eredeti 3D Secure specifikáció (3DS1) a 2000-es évek elején jelent meg. Bár felelősség-átruházási mechanizmust biztosított, komoly használhatósági és konverziós problémái voltak. A 3DS2-t (EMV 3DS) ezek a problémák orvoslására fejlesztették ki.
3DS1 problémák:
A 3DS1 a kibocsátó hitelesítési oldalára való átirányítást igényelt, amely sokszor gyenge minoségu és az ügyfelek számára zavaros volt. Mobileszközökön az átirányítás és felugró ablak alapú folyamat különösen problémás volt.
3DS2 fejlesztések:
A 3DS2 gazdag adatmegosztási modellt vezet be. A kereskedő átjárója akár 150 adatpontot küld a hitelesítési kéréssel, beleértve az eszköz ujjlenyomatot, böngészo jellemzőket és viselkedési jelzéseket. Alacsony kockázatú tranzakciók esetén a kibocsátó súrlódásmentes hitelesítést adhat, ami azt jelenti, hogy az ügyfélnek semmit sem kell tennie.
PSD2 és Eros Ügyfél Hitelesítés: Az EU felülvizsgált fizetési szolgáltatások irányelve (PSD2) kötelezové teszi a Eros Ügyfél Hitelesítést (SCA) a legtöbb európai kártya nem jelen létu tranzakcióhoz. A 3DS2 az SCA-megfelelés elsodleges mechanizmusa. Azok a kereskedők, akik nem támogatják a 3DS2-t, azt tapasztalják, hogy a tranzakciókat a kibocsátók soft-el utasítják.
Hogyan csökkenti a 3D Secure a kereskedők visszaterhelési felelősségét
A 3D Secure hitelesítés által biztosított felelősség-átruházás az a mechanizmus, amelyen keresztül a kereskedők csökkentik visszaterhelési veszteségeiket a csalási vitákon.
Hogyan muködik a felelősség-átruházás a gyakorlatban: Az ügyfél befejez egy vásárlást és hitelesít 3DS2-n keresztül. A tranzakció feldolgozásra kerül. Egy hónappal késobb az ügyfél azt állítja, hogy a tranzakció engedély nélküli volt. A kereskedő átjárója benyújtja a cáfolatot a 3DS2 hitelesítési rekorddal: az Authentication Transaction ID-val (ATID), a hitelesítési státusszal (hitelesített) és az ECI értékkel. A gyakorlatban ez az esetek túlnyomó többségében a visszaterhelés megfordítását eredményezi.
Tranzakciók, amelyek nem részesülnek felelősség-átruházásban: Nem minden 3DS2 kimenetel biztosít felelősség-átruházást. A felelősség-átruházás legeroteljesebben a sikeres hitelesítési eredményű és ECI 05 értékű (Visa) vagy 02 (Mastercard) tranzakciókra vonatkozik.
Mentességek és felelősség: Bizonyos 3DS2 mentességek (30 euro alatti alacsony értéku tranzakciók, megbízható kedvezményezetői listák, ismétlodo tranzakciók) lehetővé teszik a tranzakciók SCA nélküli feldolgozását. A mentesség-alapú tranzakciók felelősségi pozíciója mentességtípusonként változik.
Mikor kötelező és mikor opcionális a 3D Secure
A PSD2 Eros Ügyfél Hitelesítési mandátuma értelmében a 3D Secure a legtöbb európai kártya nem jelen létu tranzakcióhoz kötelező, de mentességek és hatályon kívüli forgatókönyvek sora határozza meg, mikor nem vonatkozik az SCA.
Mikor szükséges a 3DS (SCA alkalmazandó):
Az ügyfél által kezdeményezett (CIT) standard kártya nem jelen létu fizetések az alacsony értéku küszöbérték feletti összegekre SCA-ra kötelezők. Az alapértelmezett pozíció az, hogy az SCA szükséges; a mentességek a kivételek.
Mentességek, amelyek lehetővé teszik a tranzakciókat 3DS nélkül:
Alacsony értéku tranzakciók: A 30 euro alatti tranzakciók alacsony értéku mentességre jogosultak. Ismétlodo tranzakciók: Az ismétlodo sorozat kezdeti kifizetése SCA-t igényel; a következő kereskedő által kezdeményezett tranzakciók (MIT-k) SCA nélkül folytatódhatnak. Megbízható kedvezményezett: A kártyabirtokosok kereskedőket adhatnak hozzá egy fehérlistára a kibocsátójuknál.
Az SCA hatályán kívül: A kereskedő által ügyfélinterakció nélkül kezdeményezett tranzakciók (MIT), az EGT-n kívül az egyik félnél lévő tranzakciók és a vállalati kártyatranzakciók meghatározott körülmények között a PSD2 SCA hatályán kívül esnek.
3DS2 megvalósítása RoxPay-jel
Az RoxPay fizetési átjárója natívan támogatja a 3DS2-t. A megvalósítás a meglévő integrációs architektúrán belül kerül kezelésre, nincs szükség külön 3DS szolgáltatóra.
Drop-in UI megközelítés: Az RoxPay drop-in UI (JavaScript-alapú kártya beviteli) használata esetén a 3DS2 automatikusan kerül kezelésre. Ez a 3DS2 megfelelés legegyszerubb útja.
API integrációs megközelítés: A közvetlen API integrációt használó kereskedők számára a 3DS2 hitelesítési adatokat a payment intent paramétereken keresztül adják tovább. A teljes dokumentáció elérheto a app.roxpay.eu/api/v4/docs oldalon.
Súrlódásmentes arány optimalizálás: Az RoxPay maximálisan elérheto adatokat küld a 3DS2 hitelesítési kéréssel a magas súrlódásmentes arányok támogatása érdekében.
Sandbox tesztelés: Az RoxPay sandbox minden 3DS2 kimenetetre tesztelési forgatókönyveket biztosít. Tesztelj minden forgatókönyvet az élesítés elott.
Az RoxPay regisztrációhoz és a sandbox 3DS2 tesztelés megkezdéséhez a regisztráció tíz percnél kevesebbet vesz igénybe, a sandbox hitelesítők azonnal kiadásra kerülnek. Az RoxPay PCI DSS Level 1 tanúsítvánnyal (QS83A47X629) és ISO 27001 tanúsítvánnyal rendelkezik.
Gyakran ismételt kérdések
Csökkenti-e a 3D Secure a konverziós arányokat?
A megfelelően megvalósított 3DS2 minimális konverziós hatással rendelkezik a 3DS1-hez képest. A súrlódásmentes hitelesítési folyamat, ahol a kibocsátó a háttérben hitelesíti a tranzakciót ügyfélintézkedés nélkül, a jól konfigurált kereskedők hitelesített tranzakcióinak 80-90%-át teszi ki. A kihívást igénylő maradék tranzakciók magasabb lemorzsolódást mutatnak, de ez szignifikánsan alacsonyabb a 3DS1 átirányítási és statikus jelszó modelljével tapasztalt lemorzsolódásnál.
Mi az ECI érték a 3DS hitelesítésben?
Az Electronic Commerce Indicator (ECI) érték egy 3DS hitelesítési válaszban jelzi az elért hitelesítési szintet. ECI 05 (Visa) vagy 02 (Mastercard) azt jelenti, hogy teljes hitelesítés ment végbe és teljes felelősség-átruházást biztosít. ECI 06 vagy 01 azt jelenti, hogy a kártya hitelesítést kísérelt meg, de a kibocsátó nem támogatta, korlátozott felelősség-átruházást biztosítva. ECI 07 azt jelenti, hogy hitelesítés nem történt; felelősség-átruházás nem vonatkozik.
Mi történik, ha az ügyfél nem sikerül 3D Secure hitelesítést végezni?
Ha az ügyfél nem tudja befejezni a 3DS2 kihívást (megszakítja a banki app push értesítést, rossz OTP-t ír be, vagy lejár a munkamenet), a hitelesítés meghiúsul és a fizetés nem kerül feldolgozásra. Az átjáród világos hibaüzenetet kell megjelenítenie és lehetővé kell tennie az ügyfélnek az újrapróbálkozást vagy más fizetési mód használatát. A sikertelen hitelesítés nem visszaterhelés; a tranzakció egyszeruen nem kerül engedélyezésre.
Ezt is érdemes megnézni
Magas kockázatú fizetési gateway
Biztonságos fizetésfeldolgozás magas kockázatú iparágak számára, többszörös acquirer routinggal és chargeback védelemmel.
Kisvállalkozások fizetési megoldásai
Átlátható IC++ árazás, ingyenes Smart POS terminál és 24 órás aktiválás kisvállalkozások számára.
E-kereskedelmi fizetési integrációk
Egykattintásos bővítmények Shopify-hoz, WooCommerce-hez, Magento-hoz és PrestaShop-hoz teljes API-hozzáféréssel.
Optimalizálja fizetéseit még ma
Az RoxPay natív 3DS2-t támogat súrlódásmentes arány optimalizálással, felelősség-átruházással a hitelesített tranzakciókra és teljes sandbox teszteléssel. PCI DSS Level 1 tanúsított, IC++ árazás 0,45%-tól.
✓ Nincsenek fix havi költségek · ✓ Aktiválás 24 órán belül · ✓ Dedikált technikai támogatás
