Kérdések és válaszok internetes kártyás fizetésről
Hálózattal kapcsolatos kérdések
A banki szerver miért nem válaszol?
A bank szervere az áruházzal nem a hagyományosan erre a célra szánt 80-as vagy 443-as TCP porton keresztül kommunikál, ezért amennyiben az áruházi szerver és az internet között található bármely hálózati szűrő (switch, router, tűzfal) nincs felkészítve az ezeken a portokon keresztül történő kommunikációra, a kérés nem juthat el a bankhoz A kapcsolat az áruházi szerverről parancssori alkalmazások segítségével ellenőrizhető (pl. cUrl vagy wget segítségével).
A vásárlók xxx szolgáltatótól/országból miért nem jutnak el a fizetőoldalra?
A banki szerver ip címét a vásárló internetszolgáltatója oldja fel. Elképzelhető, hogy a vásárló internetszolgáltatója szinkronizációs problémákkal küzd, vagy egyéb okból nem sikerült megállapítania a bank szerverének pontos címét. Ilyen esetekben javasoljuk, hogy a vásárló jelentse be a hibát az internetszolgáltatónak, illetve ha teheti, próbálkozzon meg a vásárlással egy másik internetszolgáltatón keresztül.
A bank válasza miért csak „500 Server error” vagy „403 Forbidden”?
A bank válasza minden esetben az oldal forrásában (content) érkezik text/plain mime kódolással. Sikeres feldolgozás esetén a http státusz 200, hiba esetén azonban vagy 403 (titkosítási hiba) vagy 500 (feldolgozási hiba). Léteznek olyan kapcsolatkezelők (alkalmazások vagy függvénykönyvtárak/osztályok) melyen ilyenkor azonnal megszakítják a kapcsolatot, így a hibaüzenet elvész. Célszerű olyan eszközt használni, amely hiba esetén is kiolvassa a teljes tartalmat.
Minden kérésre RC=D04 hibaüzenetet kapok, miért?
A bank adott idő alatt csak bizonyos számú kérést szolgál ki, az e számosság feletti üzenetekre RC=D04 hibaüzenetet ad.
Mik a banki szerver elérhetőségei?
A teszt szerver az ekit.cib.hu, az éles az eki.cib.hu címeken érhető el. A kereskedői url minden esetben https:///market.saki, a vásárló url minden esetben https:///customer.saki
Titkosítással kapcsolatos kérdések
A teszt szerveren tökéletesen működött a titkosítás/kititkosítás. Az éles szerveren miért nem?
A teszt és éles működéshez a bank két külön kulcsot biztosít. Ezek nevei azonosak, tartalmuk azonban kötelezően eltérő. A webáruházat üzemeltető felelőssége, hogy a kulcsok a megfelelő helyükre kerüljenek.
Használható-e az IEB0001 azonosító a hozzá kapott titkosítókulccsal?
Nem. Minden kereskedő egyedi azonosítót kap melyek egyike sem lehet IEBXXXX. A titkosítókulcs, melyet a dokumentációhoz és az ekiCrypt titkosítómodulhoz csatoltunk, pusztán a csatolt alkalmazás működésének tesztelésére alkalmas, a banki kommunikációra nem.
A,B és C üzenet tökéletesen működik a banki kapcsolatban, de X és Y nem, ez miért lehet?
Kérjük győződjön meg arról, hogy minden kérést ugyanazzal a kulccsal titkosítanak. A teszt és éles kulcsok azonos nevei elvileg kiküszöbölik az azonos forrásból származó üzenetek különböző kulccsal történő titkosítását, elosztott rendszereknél (pl felhő alapú szolgáltatások) azonban elképzelhető, hogy a szerverpark némely elemeire nem sikerült a kulcsok telepítése.
Áttértünk Windows operációs rendszerű kiszolgálóról Unix alapúra. Miért nem működik a titkosítás?
A Unix alapú rendszerek a file neveknél különbséget tesznek a kis és nagybetűk között. Amennyiben a titkosító alkalmazás UER_NOFILE hibakóddal tér vissza, célszerű ellenőrizni a file nevét. A file webszerver számára elérhetetlensége is okozhat problémát. A telepítés során a webszerver technikai
felhasználójának (és csak annak!) olvasási jogot kell biztosítani a kulcsfilera és az azt tartalmazó könyvtárra.
A vásárlóval együtt visszaérkező üzenet (MSGT21) időnként miért kititkosíthatatlan?
Az ekiCrypt függvénykönyvtár és az arra épülő sakide alkalmazás alapértelmezés szerint urlkódolt üzeneteket képes kezelni. A visszatérő üzenetet a webszerverek urldekódolhatják, emiatt az üzenetben szereplő + és / jelek miatt a nevezett alkalmazáscsomag hibát adhat. Javasoljuk a beérkező üzenet automatikus urlkódolását, mivel ez az urldekódolt üzenetet „kijavítja”, az eleve urlkódolt üzeneten pedig nem változtat.
A titkosító algoritmus egyaránt használható 32 és 64 bites rendszereknél?
A virtuális gépeket használó technológiák illetve a hardver sajátosságait „eltakaró” nyelvek esetén igen. Hardver-specifikus binárisok esetén mellékeltünk mind 32, mind 64 bites verziót.
A sakide alkalmazás az operációs rendszer frissítése óta hibát jelez, mit tegyek?
Előfordulhat, hogy az operációs rendszerrel együtt módosultak olyan (jellemzően string és memóriakezelő) rendszerfüggvények, melyek az eltérő hivatkozások miatt hibát eredményezhetnek. Ebben az esetben kérjük vegye fel a kapcsolatot a bank ügyintézőjével, megadva a hiba reprodukálásának lépéseit, a régi és az új operációs rendszer valamint a futtatásukhoz használt hardver pontos paramétereit.
Hogyan lehet ellenőrizni a CIB Bank fizetőoldalának hitelességét?
Elsődlegesen a böngésző címsorában található zöld lakatra kattintva. A böngésző ekkor minden elérhető információt közöl a kapcsolat titkosságáról, valamint lehetőséget ad az ún certificate-lánc (certificate chain) megtekintésére is (bővebb információ itt található). A CIB Bank a titkosításhoz szükséges certificate-et a Symantec Corp.-tól vásárolja, ezt a fizetőoldal jobb felső sarkában található „Norton-secured” logóra kattintva ellenőrizheti. Amennyiben a fizetőoldal a böngésző szerint nem biztonságos, kérjük győződjön meg arról, hogy a böngésző legfrissebb verzióját használja-e (régebbi verziók hiányos listával rendelkezhetnek az ún top level root CA certificate-kről), és amennyiben igen, kérjük haladéktalanul tájékoztasson minket.
A sakide alkalmazás miért nem ad semmilyen kimenetet?
Sikeres futás esetén az alkalmazás a standard kimenetre írja az eredményt, hiba esetén viszont nem lehet kimenet. A pontosabb hibakereséshez az alkalmazást verbose módban célszerű indítani (-v), ekkor a hibaüzenet a standard error csatornára kerül.
A sakide program UER_BADURL hibakóddal tér vissza, mi a probléma?
Kérjük ellenőrizze, hogy helyes irányban próbálta meg a titkosítást alkalmazni. A –e paraméter segítségével titkosít, a –d paraméterrel kititkosít. Fordított esetben az alkalmazás UER_BADURL hibát ad.
A sakide program (vagy a saját rendszerben implementált alkalmazás) a titkosítás eredményeként a következő titkosított értéket adta: PID=&CRYPTO=1&DATA=AwMD, amire a bank hibaüzenetet adott. Mi a gond az üzenettel?
Az AwMD az üres üzenet titkosítása, tehát a bolti algoritmus bemenő értéke sérült a feldolgozás során.
A bank szervere támogatja az SSL kapcsolatot?
Az SSL titkosításban rejlő hiba (lásd POODLE attack) miatt a bank nem támogatja az SSL titkosítást. Helyette a TLS titkosítást ajánljuk, annak minden elérhető verziójával.
A kereskedői url-t hívva miért fut hibára a TLS kapcsolat?
A kereskedői url csak http protokollon keresztül érhető el.
Fizetési folyamattal kapcsolatos kérdések
Mikor tekinthető egy tranzakció sikeresen befejezettnek?
Csak akkor, ha a bank a lezáró üzenetre (MSGT32) adott válaszában (MSGT31) az authorizációt sikeresnek jelöli (RC=00). Önmagában a lekérdező üzenetre (MSGT33) adott válaszban (MSGT31) szereplő válasz (RC=00) nem elég.
A tranzakciók rendre időtúllépés miatt meghiúsulnak, mit lehet ez ellen tenni?
A lezáráshoz szükséges üzenet (MSGT32) a bank szempontjából csak abban az esetben fogadható el, ha az authorizáció már megtörtént (tetszőleges eredménnyel). Az authorizáció megtörténtét az áruház a vásárló visszaérkezésekor (MSGT21) nyugtázhatja, illetve ennek elmaradása esetén (pl. a vásárló bezárja a böngésző ablakot ezzel meghiúsítva a visszairányítást) az erre a célra fenn tartott üzenet (MSGT33) segítségével ellenőrizheti a tranzakció állapotát, és az authorizáció befejeztével a vásárló visszaérkezése nélkül is megerősítheti azt. Javasolt a következő algoritmus szerint eljárni:
1. A kereskedő inicializálja a tranzakciót (MSGT10) egy új TrID azonosítóval
2. A kereskedő feldolgozza az inicializálás eredményét (MSGT11) és amennyiben nem engedélyezett (RC!=00), a folyamatot az első lépéstől újrakezdi, maximum 3x. A 3. próbálkozás után a folyamatot hibaüzenettel megszakítja
3. A kereskedő a vásárlót a banki fizetőoldalra irányítja (MSGT20)
4. A kereskedő fogadja a banktól visszatérő vásárlót (MSGT21)
5. A kereskedő ellenőrzi, hogy a tranzakció lezárható állapotban van-e (MSGT33)
6. Ha lezárható (fenti felsorolás 2. és 4. esete, vagyis RC=00 illetve RC=), lezárja (MSGT32), a válaszüzenetben (MSGT31) található adatokat megjeleníti, és a folyamatot befejezi
7. Ha nem zárható le (fenti felsorolás 3. esete, vagyik RC=TO), akkor a MSGT33 üzenetre adott bank válasz MSGT31 üzenetben található adatokat megjeleníti és a folyamatot befejezi A bank válasza (MSGT31) MSGT33-ra, értelmezése és a lehetséges követő lépések: RC érték Magyarázat Megerősítés Újabb MSGT33
A bank válasza (MSGT31) MSGT33-ra, értelmezése és a lehetséges követő lépések:
Mi történik az időtúllépés miatt meghiúsult tranzakciókkal?
A bank minden ilyen esetben ún. reverzálást kezdeményez, melynek lényege, hogy a vásárló számláján lefoglalt összeget ismét a vásárló szabad rendelkezésére bocsátjuk. A tranzakciót ezután megerősíteni már nem lehet, a státusz lekérdező üzenetre (MSGT33) RC=TO érték lesz a válasz.
A vásárló üres oldalt kap a Fizetés gomb megnyomása után, ez mi miatt lehet?
A fizetés több lépésből áll, ennek során a vásárló böngészője több érintett társaság (CIB Bank, MasterCard, VISA illetve a kártyát kibocsátó bank) weboldalán is megfordulhat. Az utolsó érintett oldal a böngésző címsorában (Location bar) szerepel, ez alapján határolható be, hogy a feltételezett hiba melyik társaság webszerverén fordult elő. Kérjük minden ilyen esetet haladéktalanul jelezzenek felénk, a Location bar-ban található szervernévvel együtt (ha paraméter is szerepel benne, azt kérjük takarják 7 ki), a minél gyorsabb hibaelhárítás érdekében. A biztonság kedvéért kérjük a Vásárlót, hogy hiba jelentése előtt győződjön meg internetkapcsolata megfelelő működéséről.
Miért kapok RC=NT értéket a bank válaszában (MSGT31)?
NT értéket a banki szerver akkor ad, ha nem talált a kérésnek megfelelő tranzakciót. Kérjük ellenőrizze, hogy a kérésben helyes kereskedő azonosítót, tranzakció azonosítót és összeget használt.
Miért kapok RC=X0 értéket a bank válaszában (MSGT31)?
Amennyiben a vásárláshoz használt kártya rendelkezik 3D Secure védelemmel (bővebben itt és itt olvashat róla), a CIB bank a vásárlót minden esetben a kibocsátó bankhoz irányítja authentikációra. Amennyiben az authentikáció sikertelenül zárul, a CIB bank a tranzakciót X0 válaszkóddal elutasítja.
Mennyi idő után tekinthető az authorizáció időtúllépés miatt meghiúsultnak? Változtatható-e ez az időtartam? Letiltható-e?
Az authorizáció alapértelmezés szerint 10 perc után minősül időtúllépés miatt meghiúsultnak. Letiltani nem lehet, de a megfelelő üzenetek kombinációjával a sikeres authorizációt meg lehet erősíteni (MSGT33 és MSGT32 üzenetek), az időtúllépés bekövetkezte előtt.
Az átirányítás megtörténhet az inicializációs üzenettel (MSGT10)?
Nem, mert a vásárló böngészője nem képes a bank titkosított válaszát (MSGT11) értelmezni, így a fizetési folyamat ennél a lépésnél meg fog szakadni. Átirányítani csak az arra a célra szánt üzenettel (MSGT20) szabad a vásárlót.
Átirányítás nélkül, a vásárló helyett letöltve is megjeleníthető a fizetőoldal?
Sikeres inicializációt követően minden esetben át kell irányítani a vásárlót a bank fizetőoldalára.
Lehetséges előre inicializálni tranzakciót és csak valamennyi idő elteltével a fizetőoldalra irányítani a vásárlót?
A tranzakciót a bank az előre definiált időtúllépés után lezárja.
Lehetséges többször megerősíteni (MSGT32) authorizációt?
Az első megerősítéssel a bank az authorizációt lezárja, azon módosítani többször nem lehet. Minden, ezután küldött megerősítő üzenet hibát eredményez.
A vásárlót a fizetés után vissza lehet irányíttatni nem standard portra is?
Igen, az inicializáló üzenetben (MSGT10) az URL értékénél a szervernév után kell megadni a portszámot, kettősponttal elválasztva (http://server.dom:/). Ügyelni kell azonban arra, hogy a vásárlók többségénél a hálózati szabályok ezt a kapcsolatot nem engedélyezik.
A vásárló jelezte, hogy sokáig (10-60 másodperc) tart, amíg a kártyaadatok beírása és a Fizetés gomb megnyomása után visszajut a webáruházba. Mi történik ilyenkor?
Miután a vásárló megadta a kártyainformációkat, a bank a vásárlót továbbirányítja a kártyatársaságok, rajtuk keresztül pedig (amennyiben szükséges) a kibocsátó bankhoz, hogy a tranzakcióhoz tartozó megerősítő kódot (ez lehet általános vagy egyszer használatos jelszó) megadhassa (3D Secure).
MasterCard és Maestro típusú kártyák esetében az átirányítás mindenképp megtörténik, ez átlagosan 5-10 másodperccel növeli meg az authorizáció idejét. A kód megadását követően a bank authorizálja a tranzakciót (ez további szintén 5-10 de maximum 40 másodperc), majd ezt követően irányítja vissza a vásárló böngészőjét a webáruházba.
Egyéb kérdések
A bank válaszüzenete miért csak RC=SXX vagy RC=DXX kódot tartalmaz?
A bank szervere akkor tud titkosított válaszüzenetet küldeni, ha sikerült a kereskedő üzenetét feldolgoznia. Hiba esetén a hiba típusának megfelelő hibakódot ad, ezeknek a listája a Reference guideban érhető el. Ilyen esetekben célszerű meggyőződni arról, hogy az üzenet a megfelelő paraméterek felhasználásával készült, a folyamat megfelelő lépéseként lett-e elküldve, a megfelelő titkosítókulcs felhasználásával. Kiemelendő, hogy jelen dokumentációhoz csatolt titkosítókulcs egyik banki szerverrel való kommunikációra sem alkalmas, pusztán az alkalmazás működésének tesztelésére való.
Az inicializáló üzenetben (MSGT10) milyen URL értéket lehet alkalmazni?
Teljes értékű domain nevet (FQDN), ami nincs felparaméterezve. A teljesség igénye nélkül néhány példa:
A tranzakció azonosítóba miért került a banki válaszban + jel?
Az azonosító kötelezően 16 karakter hosszú kell legyen. Amennyiben a kereskedő szoftvere ennél rövidebbet küld, a bank szervere automatikusan 16 karakter hosszúra egészíti ki, szóközökkel, melyek urlkódolt formája a + jel.
Miért kapok az MSGT11 üzenetben RC=02 értéket?
Az inicializáló üzenetben (MSGT10) küldött tranzakció azonosító már foglalt. Az azonosítót minden fizetés megkezdése előtt pszeudovéletlen értékként szükséges előállítani. A modern programnyelvi verziók minden véletlenszám-generálás előtt végrehajtanak ún reseed lépést (a véletlenszám-képzés alapjául szolgáló érték újragenerálása), célszerű azonban ezt explicit módon, kényszerítve is végrehajtani az azonosító számítása előtt.
A fizetendő összeget milyen formában kell megadni?
Magyar forint esetén egész számként, Euró esetében pedig két tizedesjegy pontossággal. Utóbbi esetben a két tizedesjegy minden esetben kötelező. Az egész részt a törtrésztől pont választja el.
A tranzakció adatait el kell tárolni?
Igen, ez egyrészt előfeltétele a tranzakciók sikerességének, másrészt nagyban segít az esetleges későbbi vásárlói tájékoztatásban.
Milyen formában kell átadni a bank számára a tranzakcióhoz tartozó kosár adatait?
A bank nem fogad és nem tárol kosár adatot, csak a fizetéshez szükséges információkat (MSGT10)
Milyen formában kell átadni a bank számára a vásárló személyes adatait?
Amennyiben a vásárló előzetesen, explicit jóváhagyta (GDPR), a vásárló neve, számlázási címe és e-mail címe átadható a bank számára, a PSD2-re épülő EMV 3DS authentikáció gyorsításának érdekében. A mezők típusát és megengedett értékkészletüket a Technikai dokumentáció tartalmazza.
Célszerű-e a vásárlónak e-mailt küldeni a tranzakció eredményéről?
Igen. Előfordulhat, hogy a vásárló nem várja meg az authorizáció eredményét és becsukja a böngészőjét, emiatt az azonnali tájékoztatás lehetetlenné válik. Az e-mailben ugyanazokat az adatokat szükséges küldeni, melyeket a visszaigazoló weblapon is láthat a vásárló (tranzakció azonosító, összeg, devizanem, válaszkód leírással és engedélyszám).
A vásárlót a fizetés megkezdése előtt azonosítani kell?
Igen, ez előfeltétele a sikeres banki tesztnek. Az azonosítás tetszőleges, általánosan elfogadott módon (egyszeri vagy állandó jelszó megadásával, illetve biometrikus adatok ellenőrzésével) történhet.
A vásárlóazonosító (UID) tartalmazhat e-mail címet?
Az UID mező csak a specifikációban megengedett karaktereket tartalmazhat (kis és nagybetű, szám, kötőjel, aláhúzás illetve szóköz).
A kommunikációnál használt paraméterek escape-elhetőek-e, illetve tartalmazhatnak-e extra karaktereket (pl sortörés)?
Sem a titkosítatlan sem a titkosított paraméterek nem escape-elhetőek (az urlkódolás miatt egyébként sincs rá szükség) és nem is tartalmazhatnak ún whitespace karaktereket (pl sortörés vagy tabulátor).
A vásárló tájékoztatásakor furcsán jelennek meg a karakterek, ez mitől lehet?
A bank szervere az üzeneteket, így az authorizáció eredményét (MSGT31, RT paraméter) is ISO-8859-2 kódolással küldi. Amennyiben a bolt ettől eltérő kódolást (pl UTF-8) használ, az értékeket explicit konvertálni kell megjelenítés előtt.
