Az erős ügyfélhitelesítés kapcsán sok hír és tévhit kering az elektronikus kereskedelem világában. A legtöbben már hallottak róla, de nagyon kevesen látják, hogy konkrétan milyen feladatokkal fog járni, milyen fejlesztéseket kell elvégezni, hogy az új szabályozás hatályba lépésekor kereskedőként biztonságban tudhassuk magunkat, a tranzakcióinkat, és megőrizzük a jó ügyfélélményt a megváltozott körülmények között.
Ez a cikk ebben igyekszik segítséget nyújtani a kereskedőknek, ezért összegyűjtöttük a webáruházak számára a tudni- és tennivalókat az SCA (Strong Customer Authentication) megfeleléshez.
Arról talán sokan hallottak már, hogy az Európai Unió PSD2 (Payment Service Directive) irányelve tartalmaz egy igen markáns elemet, amely az elektronikus fizetési (kártya, átutalás, tárca, stb.) és egyéb, pénzmozgással járó tranzakciókat (pl. online bankolás) hivatott biztonságosabbá tenni. Ez a direktíva elem 2019. szeptember 14-én lép hatályba.
A kereskedők számára ez a változás pozitív hozadékkal is jár, hiszen a hatályba lépéstől kezdve, megfelelő felkészültség esetén a kereskedő kvázi mentesülhet a lopott kártyákkal végzett rosszindulatú tranzakciókból eredő károk alól, és nem kaphat több „Nem én végeztem a tranzakciót” típusú chargeback eljárást.
A negatívum viszont, hogy rövid távon romlik az ügyfélélmény, és sok esetben az üzleti modell, a checkout, a vásárlási folyamat módosítására, illetve az ennek során végbemenő ügyfél-kommunikáció megváltoztatására is szükség lehet. Ha a kereskedő nem végzi el az alábbiakban leírt módosításokat, a pénzügyi szolgáltatók szélsőséges esetben akár el is utasíthatják a tőle érkező tranzakciókat.
Az eddig megszokott 3D Secure azonosításánál is komplexebb beazonosítással fognak találkozni az ügyfelek, hiszen a direktíva alapelve a kétfaktoros azonosítás, ami ugyan eddig is jelen volt, ám eddig a kártyaadatok teljes körű ismerete (kártyaszám+lejárat+CVC) betudható volt egy faktornak. Mostantól a kártyaadat kikerül ebből a körből, megjelennek viszont a biometrikus (ujjlenyomat, arcfelismerés stb.) és egyéb módszerek.
Az látszik, hogy elektronikus fizetési tranzakciók végzéséhez az esetek nagy részében okostelefonra lesz szükség. A fentiek az egyszeri és a tárolt kártyával végzett ún. egykattintásos (one-click) tranzakciókra is érvényesek lesznek. Minden olyan tranzakció indításkor el kell végezni az erős ügyfélhitelesítést, ahol az ügyfél indítja a tranzakciót (tehát tárolt kártya esetén is). Mentesülni ez alól egyedül a kereskedő által tárolt kártyára indított, ún. ismétlődő (recurring) tranzakciók fognak, ebben az esetben csak a kártya tárolásakor kell elvégezni az erős ügyfélhitelesítést. A már eltárolt kártyák jogilag erősen hitelesítettnek minősülnek, tehát a kártyák lejáratáig nem kell újra tokenizáltatni a meglévő, adott szolgáltatónál már korábban mentett kártyákat.
Az erős ügyfélhitelesítés ügyfelenként és tranzakciónként is működhet különböző módon, annak megfelelően, hogy a pénzügyi közvetítői rendszer (fizetési szolgáltató, kártyatársaság, kártyakibocsátó bank) mennyire érzékeli/értékeli az adott tranzakciót kockázatosnak. Az elektronikus fizetések hátterében felépül egy automatikus bírálati (scoring) rendszer, amely az egyes tranzakciókat kockázatossági kategóriákba sorolja, és eszerint követel meg különböző erősségű hitelesítést az ügyfél részéről, vagy engedi el akár teljesen a kiegészítő hitelesítési folyamatot. Ez a rendszer a kereskedők által az online fizetési tranzakciókkal együtt átadott adatok alapján működik (ld. alább).
Lehetőség lesz arra is, hogy a fizetési szolgáltatók, illetve a kártyakibocsátó, számlavezető bankok ún. fehér listát hozzanak létre, amelyet az egyes ügyfelek kezelhetnek, felvehetnek rá megbízhatónak minősített kereskedőket, szolgáltatókat. Az ezekkel a partnerekkel folytatott tranzakciók esetében a bankrendszer eltekint majd az erős hitelesítés alkalmazásától.
Az erős ügyfélhitelesítéssel kapcsolatban a vásárló mellett a kereskedőnek is dolga, fejlesztési feladatai lesznek saját webáruházában: egyrészt hogy a követelményeknek egyáltalán megfeleljen, ezáltal elkerülve lopott kártyás vásárlásokból eredő veszteség kockázatát, illetve biztosítva fizetési folyamatainak folytonosságát, másrészt, hogy a fent bemutatott, erős ügyfélhitelesítéssel lerontott ügyfél élményt „visszajavítsa” a megfelelő adatátadással.
Mit kell ehhez konkrétan tenni, milyen fejlesztési feladatokkal fog járni az SCA-megfelelés biztosítása?
A legfontosabb, minden kereskedőt érintő változás, hogy az SCA értelmében ahhoz, hogy mentesülhessünk a lopott kártyás fizetés kockázatai alól, kiegészítő adatokat kell átadnunk a fizetési szolgáltatónkon keresztül a pénzügyi közvetítői rendszernek, és végső soron a kártyaelfogadó banknak minden egyes elektronikus fizetési tranzakció esetében.
Ez 40-60 adatmezőt jelent, amelyeket össze kell gyűjteni és az eddigiek mellett (összeg, devizanem, rendelésazonosító, vásárlóazonosító) át kell adni a fizetési szolgáltató számára.
A legtöbb fizetési szolgáltató most dolgozik rendszerének módosításán, hogy egyáltalán képes legyen ezeket a jogszabályban előírt adatokat fogadni, mert eddig a fizetési szolgáltatók rendszerei sem voltak erre felkészítve, vagy ha igen, akkor korlátozottan, csak az adatok lényegesen szűkebb körét kezelték.
Milyen adatokat kell majd átadnunk?
A tételes lista körülbelül 60 elemet tartalmaz, ebből néhány mező opcionális, átadása esetén a fenti kockázatbírálati folyamatot segítjük, hogy vásárlóinknak jobb ügyfélélményt biztosítsunk a kevésbé rigorózus hitelesítéssel, több mint 2/3-a viszont kötelező.
Kötelező
Kötelező átadni a törvényi megfelelőséghez, illetve a lopott kártyás vásárlások kockázata alól történő mentesüléshez:
- A tranzakció normál adatait, amelyeket eddig is továbbítottunk (összeg, devizanem, rendelésazonosító, felhasználó azonosító, stb.)
- Vásárlói adatokat: név, e-mail cím, telefonszám, szállítási cím, számlázási cím – tételesen mezőkre bontva
- A vásárló böngészőjének adatait, amit az áruházunk érzékel (IP-cím, nyelv, színmélység, felbontás, időzóna, Java engédelyezve van-e, stb.) – ezekből az adatokból a vásárló böngészőjére vonatkozóan jön létre egy „technikai ujjlenyomat”
- Ezen túl van még néhány adatmező, amely a kereskedőre vonatkozik, illetve csak egykattintásos (one click), ismétlődő (recurring), vagy részletfizetéses (installment) tranzakciók esetében kell átadnunk, ha ilyet indítunk.
Opcionális
Opcionálisak, amelyek a kockázatelemző rendszerek további kiegészítő adatokkal való ellátásához, a jó ügyfélélmény biztosításához szükségesek:
- A vásárló ügyféltörténetére vonatkozó adatok: mikor regisztrált a webáruházban, mikor vásárolt utoljára, hányszor vásárolt az adott évben/héten/napon, mikor változtatott jelszót utoljára, mióta használja az adott szállítási címet, hányszor szállítottunk már oda sikeresen, stb.
- A rendelésre vonatkozó kiegészítő adatok: használtak-e ajándékkártyát, hűségpontokat is kiegyenlítéshez, előrendelés volt-e a termékre, mennyi idő a rendelés teljes átfutása, kereskedő tapasztal-e bármilyen gyanús dolgot, ha van erre vonatkozó rendszere, stb.
Ha úgy érezzük, hogy ez rengeteg személyes adat, és mintha az SCA szellemiségében teljesen szembe menne a tavaly bevezetett GDPR adatvédelmi direktívával, akkor az érzés teljesen jogos, mindazonáltal a GDPR betűjével nem ellentétes, hiszen itt a célhoz kötöttség elvének megfelelően, illetve jogos érdek alapján valósul meg az adattovábbítás. A cél pedig ebben az esetben a csalásfelderítés, illetve a jogszabályi elvárásoknak való megfelelés, ami a vásárlónak, a kereskedőnek és a teljes pénzügyi szolgáltatói rendszernek is közös érdeke. Mindezzel együtt az adatkezelési tájékoztatóban az SCA miatt történő bővített adatátadást minden kereskedőnek részletesen és megfelelő módon le kell kezelnie.
A fizetési integráció(ka)t szinte mindenkinek bővítenie kell – akár gateway szolgáltató közreműködésével, akár natívan kapcsolódunk a fizetési szolgáltatókhoz. A kívánt adatokat egy új API-szálon kell majd átadni, paraméterként minden egyes tranzakcióval együtt.
Ehhez az adatokat össze is kell gyűjtenünk a webáruházunk mögött üzemelő különböző adatbázisokból, front- és backend rendszerekből, majd az adatokat a szolgáltató által kért formátumra kell hoznunk (pl. vásárló vezetéknevét és keresztnevét vagy a címét megfelelően, mezőkre bontva kell továbbítanunk).
Az egykattintásos és az ismétlődő fizetés folyamatai innentől el fognak válni. Eddig a szolgáltatók ugyanazt a technikai módszert használták a két esetben, a különbség mindössze annyi volt, hogy a vásárló vagy a kereskedő indította-e a tárolt kártyával végzett tranzakciót. Az egykattintásos fizetésnél innentől kezdve viszont az ügyfelet át kell irányítani a kibocsátó bankjának hitelesítő oldalára, amennyiben a kockázati megítélés alapján ez szükséges.
Tehát változtatni kell megintcsak a fizetési rendszer integrációján, hiszen egy új szál fog megjelenni az egykattintásos fizetésekhez, továbbá a checkout folyamatban a mentett kártyás fizetéseknél is meg kell teremtenünk az át- és vissza irányítás folyamatát.
Fehér lista
Szolgáltatótól függően lehetőségünk lesz hozzájárulást kérnünk a vásárlóinktól, hogy úgynevezett fehér listára tegyenek minket, mint megbízható kereskedőt. Ez esetben a későbbiekben az ügyfél elkerülheti az erős hitelesítést, és sokkal gyorsabb lehet a fizetési folyamat, akár ismét valódi egykattintásos fizetésként. Ehhez viszont a megfelelő kapcsolót, checkboxot (és a hozzá kapcsolódó backend folyamatot, kommunikációs szálat) ki kell vezetnünk a checkout folyamatba és az ügyfélfiókba, a megfelelő vásárló informálással és az engedély visszavonási lehetőségével egyetemben. Ez az opció várhatóan nem lesz elérhető szeptemberben a legtöbb fizetési szolgáltató, illetve kibocsátó bank rendszerében, de körülbelül egy éven belül megjelenik.
Fejlesztési tennivalók
Az, hogy mennyi fejlesztési munkával jár megfelelnünk az SCA követelményeinek, attól is nagyban függ, hogy milyen informatikai hátterű webshop megoldást alkalmazunk és ahhoz hogyan integráltuk az elektronikus fizetési megoldásainkat:
- Amennyiben közvetlenül, teljesen egyedi fejlesztéssel (SDK használata nélkül) került integrációra a fizetés az online felületbe, úgy a módosításokat az integráció kódjában közvetlenül kell elvégezni.
- Abban az esetben, ha valamilyen SDK használatával történt a fejlesztés, úgy frissíteni lesz szükséges a várhatóan publikálásra kerülő, továbbfejlesztett SDK-ra, illetve ki kell alakítani az SCA követelményeknek megfelelő vásárlói és tranzakciós adatok átadását az SDK-ba bekerülő új paramétereken keresztül.
- Ha webáruházi keretrendszert használunk és telepíthető modulon keresztül kapcsolódtunk fizetési kapuhoz, szolgáltatóhoz (pl. WordPress WooCommerce, Magento, OpenCart, Joomla, stb.) úgy a modul frissítése válik majd szükségessé az adott keretrendszer modul-tárából. (Amennyiben a modulszállító partner a fejlesztést elvégzi és az új modulverziót publikálja.) Sok esetben itt a webáruházi keretrendszer (fő)verzió frissítésére is szükség lehet, mert egyáltalán nem biztos, hogy az új modulok a régi (fő)verziókkal kompatibilisek lesznek.
- Végül ha bérelhető webáruház rendszer (pl. Shoprenter, Unas), vagy más, harmadik fél által üzemeltetett keretrendszer (pl. szállodai foglalási rendszer, piactér, stb.) alatt valósulnak meg a fizetések, kereskedőként nem sok mindent tehetünk, a keretrendszer üzemeltetőjének kell a szükséges módosításokat elvégezni, vele célszerű ez ügyben felvenni a kapcsolatot.
Látni kell tehát, hogy minden híreszteléssel ellentétben az erős ügyfélhitelesítés komoly hatást fog gyakorolni az e-kereskedelmi, elektronikus fizetési folyamatokra és a kapcsolódó ügyfélélményre. A kereskedőknek pedig fontos, és fejlesztési erőforrást igénylő feladatuk van, ha biztosítani akarják a megfelelést, illetve megőrizni a minél simább ügyfélélményt.
A cikkben bemutatott tennivalókat a BIG FISH Payment Gateway tapasztalatai alapján foglaltuk össze, amely a kártyatársaságokkal és a rendszert képező több mint 50 fizetési szolgáltatóval való több hónapos, folyamatos egyeztetés során gyűlt össze.
A BIG FISH Payment Gateway várhatóan még ebben a hónapban elkészül a továbbfejlesztett rendszerével, amelyen keresztül az SCA-követelmények között szereplő kötelező és opcionális ügyféladatokat egységes szerkezetben tudja majd fogadni, valamint továbbítani bármelyik, a rendszerhez csatlakozó fizetési szolgáltatónak az elvárt formátumában.
További kereskedői és vásárlói információk a MasterCard Magyarország által létrehozott http://www.erosugyfelhitelesites.hu oldalon találhatóak.
