Egy dolgot már most, az elején megígérek! Ez lesz a sorozat leghosszabb cikke és soha többé nem fogok arra vetemedni, hogy ilyen hosszan raboljam a kedves olvasók figyelmét, de ez a rész annyira egybe tartozik, hogy nem szeretném szétszabdalni. Azért bízom benne, hogy megéri elolvasni.
A kontaktusos, chipes tranzakció bemutatásával odáig jutottunk, hogy a terminál már feltérképezte, hogy a bankkártyán milyen fizető alkalmazások találhatók. Egyáltalán nem jellemző, de ha több lenne ezek közül az adott helyzetben használható, akkor a vásárlónak a terminál felajánlja, hogy válasszon ezek közül. Ilyenkor lehet dönteni, hogy csak belföldi fizetésre korlátozott debit kártyaként, vagy esetleg az USD elszámolású hitelkártyaként szeretné-e használni a plasztikját a kártyabirtokos. Ez a megoldás nem igazán terjedt el, és ezekre a célokra általában külön-külön kártyát használunk, de ebből is látszik, hogy a chipünk mi mindenre lenne képes.
Maradjunk a legtöbbünk által ismert, egy alkalmazásos modellnél, amikor is a terminálunk magától kiválasztja a fizetésre használható alkalmazást. Ahogy korábban már említettem, innentől egy bonyolult műveletsor indul el a kártya és a terminál közreműködésével, ami nem is véletlen, hiszen az ő számukra minden fizetési tranzakció olyan, mint egy vakrandi. Persze mindkettőről tudni lehet, hogy csak AZT akarja – fizetési tranzakciót végrehajtani –, de arról előzetesen meg kell győződniük, hogy megbízhatnak-e egymásban és a másik képes-e megfelelni az elvárásaiknak.
Első lépésként a chip az alkalmazás kiválasztására már kapásból egy csomó értékes információval válaszol, és megmondja például, hogy milyen emberi nyelvek jöhetnek szóba a kártyabirtokossal történő kommunikáció során a terminál részéről. Nekem sem jön rosszul, ha külföldön nem a helyi nyelvvel kell megküzdenem, hanem mindjárt az ATM által is támogatott angolt látom a kijelzőn, ha esetleg a saját anyanyelvemre nem készítették fel azt az eszközt. A visszakapott adatok emellett meg is győzik az elfogadó eszközt arról, hogy a chipen lévő fizető alkalmazást képes futtatni és elindulhat a tranzakció.
A terminál ezek után alaphelyzetbe állítja a tárolóit és kiad egy utasítást a kártyának („Get Processing Option”), amivel újabb fontos információkhoz jut. A válaszban a kártya elmondja magáról, hogy milyen hitelesítési eljárásokat tud használni és megadja, hogy a terminálnak melyik chipre írt fájlokból kell a tranzakció folytatásához az adatokat kiolvasnia. Ez utóbbi, ami egy felsorolás a szükséges fájlokról („Application File Locator”), azért fontos, mert eltérő értékeket kell használni, ha a tranzakció érintésmentes fizetéskor indul, vagy ha az olvasóba be is dugtuk a kártyát. Ezt úgy lehet megoldani, ha más-más listát ad meg a chip a terminálnak a különböző esetekben, így az majd az adott körülményekhez illeszkedő értékekkel dolgozhat.
Ezt követően a terminál „Read Record” utasításokkal szépen végigolvassa az előzőleg kapott fájllistát és az ott talált rekordokat értelmezve kinyeri a tranzakcióhoz szükséges adatokat a chipről. Ezekben a rekordokban nem csak úgy ömlesztve vannak az értékek, hanem strukturáltan (ha valakit pontosan érdekel, akkor BER encoding néven kereshet rá a neten), ahol minden értéket egy úgynevezett TLV ír le, ami az angol Tag-Length-Value elnevezésből képzett betűszó. Ennek alapján fájlból kiolvasott hexadecimális karaktersorozat értelmezése úgy történik, hogy először találunk egy tag-et (címkét), aztán látható az adat hossza, végül pedig maga az adat. Ezt általában egy újabb tag követi, újra jön a hossz és megint az adat. Azért mondtam, hogy általában, mert a BER szabvány kicsit ennél bonyolultabb és vannak például speciálisan összerendezett adatcsoportok, de ez már igazán tényleg csak azoknak fontos, akik kártyaprofilok tervezésével és paraméterezésével foglalkoznak, mint például nekünk néhány kollégámmal.
Az EMV szabvány, illetve a kártyatársasági specifikációk minden adatmezőhöz hozzárendelnek egy tag-et, így például a kibocsátó bank országkódját („Issuer Country Code”) a jól csengő nevű 5F28 tag tárolja. Az alkalmazás által alapértelmezetten kezelt valutanemet („Application Currency Code”) a hangzatos 9F42. Ezekből a kis címkékből, azaz tagekből, rengeteg van és mindent a meghatározott módon kell felírni a chipekre, mikor a bankkártya elkészül a „bankkártya gyárban”. A rend kedvéért meg kell jegyezni, hogy vannak bizonyos speciális adatok, amiket nem az előbb említett fájlokban tárolunk, hanem közvetlenül kell kiolvasni a chipből „Get Data” utasításokkal. A lényeg az, hogy a terminálnak minden olyan információt, amit a kártyabirtokos bankja meg kell, hogy osszon az elfogadó eszközzel, azt a fenti módon kell a chiptől megszereznie.
Talán meglepő, de eddig semmi olyasmi nem történik a kártya és a terminál között, ami nagyon titkos lenne, és aki ért hozzá, akár maga is elvégezheti otthon a fenti műveleteket a bankkártyájával, minden felhatalmazás, vagy titok ismerete nélkül. Ezek után viszont a terminálnak már lehetősége nyílik az adatok offline hitelesítésére, amikor is a nélkül meg tud győződni a kártyától kapott értékek valódiságáról, hogy ezt bárki mástól – például a kibocsátó banktól online módon – megkérdezné. Erre többféle módszer lehetséges. Ezek közül választ az elfogadó eszköz az alapján, ahogy fent leírtak szerint megismerte a chip képességeit a „Get Processing Option” során, de az adatok offline hitelesítése mindig digitális tanúsítványok ellenőrzésével történik. Erről majd egy későbbi fejezetben lesz szó részletesen.
A következő lépésben a terminál elvégez még további ellenőrzéseket („Processing Restrictions”), amelyekkel megvizsgálja, hogy bizonyos kritériumokat teljesít-e a chip a tranzakcióhoz, például, hogy nem járt-e le, vagy ha éppen egy ATM előtt toporgunk, akkor vajon a kártya kézpénzfelvételre is használható-e, nem csak vásárlásra.
Ha nincsenek a tranzakcióra nézve korlátok, akkor jöhet a kártyabirtokos azonosítása („Cardholder Verification”), azaz most kell meggyőzni az elfogadót, hogy nem valaki más kártyájával akarunk-e éppen vásárolni, vagy pénzt levenni. Erre szintén több lehetőség kínálkozik. A chip a rekordok kiolvasása során már átadott egy listát a terminálnak, amit úgy hívunk, hogy CVM lista („Cardholder Verification Method List”). A kibocsátó bank ebben felállít egy sorrendet, hogy milyen prioritással szeretné a lehetséges ellenőrzéseket elvégeztetni. Íme, egy tipikus CVM lista:
- Online PIN ellenőrzés
- Offline PIN ellenőrzés titkosított PIN-el
- Offline PIN ellenőrzés nem titkosított PIN-el
- Aláírás ellenőrzés
- Nincs CVM
Ilyen CVM lista esetén a terminál először bekéri a PIN-t és azt, ha az eszköz online képes, titkosítva elküldi ellenőrzésre a host számára. Ha nincs kapcsolat, akkor utasítja a chipet, hogy ellenőrizze le, hogy a PIN egyezik-e a chipen tárolt értékkel. Ez azért biztonságos, mert ehhez a chip sosem adja ki az általa tárolt PIN-t, csak megválaszolja a kérdést a terminálnak, hogy az szerinte jó-e, vagy sem, és soha, senki nem tudja kiolvasni magát a PIN-t a kártyáról. Ezt az ellenőrzési módszert hívjuk offline PIN ellenőrzésnek, aminél ebben az esetben is a titkosított adatcsere a preferált módszer, hiszen előrébb szerepel a listán, mint a titkosítás nélküli. Ha valamiért nem lehetséges a PIN ellenőrzése, mert mondjuk nem működik a PIN pad a terminál mellett, akkor az elfogadó eszköz kinyomtat egy cetlit, amin a kártyabirtokos aláírhat és ezt az eladó összevetheti a kártya hátoldalán lévő aláírással. (Aha, hát ezért érvénytelen a kártya a hátoldali aláírásunk nélkül!). Bár itt nincs felsorolva, olyan eset is lehet, hogy az elfogadó eszköz beolvassa a PIN-t, majd aláírást is kér, de ilyen szigorú módszert ritkán alkalmaznak a kártyakibocsátók. Példánkban az aláírás ellenőrzése után, már csak egy sor marad a „No CVM”, ami a tranzakciók egy speciális esete. Ez alapvetően meghatározza a kártya viselkedését, mert az kevésbé lesz engedékeny a további műveletek elvégzését illetően, mivel nem sikerült ellenőrizni a kártyabirtokost.
Ezt követi az elfogadó eszköz oldali kockázatkezelés („Terminál Risk Management”). Ez magyarra fordítva elég rondán hangzik, de valójában itt csak arról van szó, hogy a terminál a kártyától kapott adatok alapján pár körülményt elemez, elsősorban azért, hogy eldöntse, hogy ezt a tranzakciót vajon elintézhetik-e kettesben a kártyával (offline tranzakció), vagy az elfogadás kockázatát inkább hárítsák a kibocsátóra (online tranzakció). Ha például a tranzakció összege túl nagy, vagy a kártya már nagyon régen (értsd: sok tranzakcióval ezelőtt) volt ellenőrizve a host által, akkor a terminál biztosan online tranzakciót fog kezdeményezni, már ha erre képes.
Mire idáig eljutunk, az elfogadó eszköz mindent tőle telhetőt megtett, hogy kielemezze a körülményeket és itt az ideje döntést hoznia („Terminal Action Analyis”), hogy mi is legyen a tranzakció lefolyása ezek után. Három lehetőség közül választhat:
1. Fogadják el a kártyával a tranzakciót offline
2. Kezdeményezzenek online tranzakciót
3. Azonnal utasítsák el a tranzakciót
Ezt a döntését egy utasítás formájában („1st Generate AC” parancs) megosztja a kártyával – és talán ez is meglepő – arra utasítja a kártyát, hogy hozza meg ő a végső döntést. Ehhez persze az utasításban a terminál is átad egy csomó adatot a chipnek, hogy ezek alapján a kártya el tudja végezni a döntést előkészítő vizsgálatot („Card Action Analysis”). A chip hozzájut sok egyéb más mellett a tranzakció összegéhez és annak valutaneméhez, a terminál típusához és országkódjához, valamint a terminál oldali ellenőrzések eredményéhez („Terminal Verification Result” és „CVM Result”). Most már a chip is mindent tud az aktuális tranzakcióról. Látja például, hogy a terminál mely országból való és így meg tudja ítélni, hogy ez egy nemzetközi, vagy egy belföldi tranzakció. Látja az összeget és ez azért jó, mert a saját számlálói révén tovább tudja finomítani a döntést a tranzakció lefolyásáról. Van például egy olyan rekesz a chipben, ami eltárolja, hogy az utolsó online tranzakció óta mennyi összeget költöttünk offline módon. Ezt a terminál nem tudhatja, de a chip igen, és ha az így halmozott összeg átlépi a beállított határt, akkor bizony a chip nem lesz hajlandó kettesben elintézni a fizetési műveletet a terminállal, hanem online elfogadást kér a kártyakibocsátótól, azaz a hosttól. A lényeg, hogy a chip a terminálhoz hasonlóan döntést hoz a tranzakció lefolyásáról, bár ebben egy kicsit meg van kötve a keze (… vagy lába? Egy chipeknek inkább a lábáról szoktunk hallani, de ki tudja mit hoz még az evolúció?!):
A. Ha a terminál előzőleg úgy döntött, hogy utasítsák el a tranzakciót, akkor a chip sem tehet mást és ekkor bizony nem történik fizetés a kártyánk által.
B. Ha terminál szerint online tranzakcióra van szükség, akkor a kártya ebbe beleegyezhet, vagy elutasíthatja a tranzakciót.
C. Amennyiben a terminál szerint ez a tranzakció nem számít túl veszélyesnek és elegendő a kevésbé biztonságos offline tranzakció, akkor chip ezzel is egyetérthet, esetleg szigoríthat, és ő maga kezdeményezhet online műveletet, vagy egyszerűen elutasíthatja a tranzakciót.
A két offline művelet viszonylag egyszerűen zárul, mert a terminál vagy tudomásul veszi a tranzakció az elutasítást, vagy elfogadja a művelet sikerességét és eszerint végzi el az ilyenkor szokásos műveleteket (pl. kinyomtatja a mindannyiunk által jól ismert bizonylatot), de ilyenkor a kártyakibocsátó bankot nem kérdezik meg arról, hogy mi a véleménye a tranzakcióról. Itt szeretném megjegyezni, hogy az már nem témája a sorozatomnak, hogy hogyan történik meg az elszámolás a kereskedő, az elfogadó eszközt üzemeltető pénzintézet és a kártyakibocsátó bank között, de természetesen előbb-utóbb az offline tranzakciók eredménye is a kártyabirtokos bankjának tudomására jut.
Ennél sokkal érdekesebb az online művelet, mert ilyenkor a chip nem is csak egyszerűen közli a döntését a terminállal, hanem egyből összeállít egy üzenetet a host számára. Ettől kezdve a host már elsődlegesen a chiptől kapott információk kiértékelésével győződik meg a beérkező kérés jogosságáról, de majd még erről is írok egy későbbi részben. A fő, hogy minden ilyen üzenet (ezeket egyébként engedélyezés kérő üzenetnek, azaz ARQC-nek hívják – „Authorisation Request Cryptogram”) eljut a kártyabirtokos bankjához, ahol azt saját szabályrendszer szerint tudják elbírálni. A kibocsátó bank egy választ küld (ARPC – „Authorisation Response Cryptogram”), amiben vagy jóváhagyja, vagy elutasítja a tranzakciót. A terminál a választ felhasználva új üzenetet küld a chipnek („2nd Generate AC”), amiben arra bíztatja a kártyát, hogy akkor most már vagy így, vagy úgy de zárják le a tranzakciót egymás között. A chip, mielőtt válaszolna, kiértékeli a helyzetet, aztán a fentiekhez hasonlóan vagy egy elutasító vagy egy jóváhagyó üzenetet küld a terminálnak, ami ennek alapján zárja a tranzakciót. A hostról érkező ARPC-nek van egy további hozadéka, mégpedig az, hogy a chip ez alapján nullázza az offline számlálóit, vagyis a legközelebbi vásárlásnál már fogja tudni, hogy nem is olyan régen, egy online tranzakció során kapott engedélyt a bankjától a fizetésre.
Huhhh! Ez tényleg nem lett rövid, de a fentiekből látszik, hogy erről nem én tehetek. A fizetési tranzakciók elég bonyolultak, még akkor is, ha vásárláskor néhány másodperc alatt zajlik le mindez a háttérben. Néhol igyekeztem egyszerűsíteni is és nem mentem bele abba, hogy az egyes döntéseket milyen más paraméterek befolyásolnak, kihagytam pár speciális tranzakciós esetet és nem szóltam arról sem, hogy a kibocsátó bank hogyan tud átírni néhány értéket egy olyan kártyán, ami már a kártyabirtokos használatában van és a kártya későbbi működését befolyásolja. Ez utóbbiakat hívjuk kibocsátás utáni, azaz „Post Issuance” műveleteknek, amire a legismertebb példa a PIN változtatás. Szerintem elég messze jutottunk a bankkártyáink felfedezésében, de lesz még mivel folytatni.