1 EFER, INTERFACE TERV ÉS MINTAPROGRAM INTÉZMÉNYEK RÉSZÉRE V február 13.2 Dokumentum adatlap Projekt/modul megnevezése: Elektronikus fizetési és elszá...
Dokumentum adatlap Projekt/modul megnevezése: Projekt/modul fantázia neve: Projekt/modul azonosító: Dokumentáció típusa: Verziószám: Oldalszám címlappal, dokumentum adatlappal: Állapot: Kiadás kelte: Utolsó mentés kelte: Készítette: Fájlnév: Kapják: Dokumentáció tárgya:
Elektronikus fizetési és elszámolási rendszer EFER 177 01 Interface terv és mintaprogram 2.2.4 8080 Jóváhagyott 2009.11.18. 2014.02.13. IND EFER_IFint_v2.2.5_20140213.doc KIFÜ, Getronics Interface terv és mintaprogram leírás az elektronikus fizetési és elszámolási rendszerhez – Intézmények részére
Ellenőrzések Név
Dátum
Aláírás
Dátum
Aláírás
Jóváhagyás Név
Módosítások Verzió v0.3 V1.4.
Dátum 2009.10.16. 2009.10.30.
V1.5 V1.5.1
2009.11.07 2009.11.16
V1.6.0
2009.12.16.
V1.6.1 V1.6.2 V1.6.3 V1.6.4
2010.01.06. 2010.02.22 2010.04.08 2010.07.02.
Módosítás rövid leírása Első átadott verzió Bekerültek a hiányolt hibakezelési lépések Új hibakód lista Eltérésjelentés fejezet (félkész állapotban, mivel még nincs lezárva a kérdés) Zalaszámmal egyeztetett módosítások Módosítások a PMISZK-val tartott egyeztetés (11.12) alapján ÁLRT miatt és Zalaszámmal egyeztetett módosítások Minor módosítások. RLRT döntési javaslat alapján módosított verzió ÁLRT változások követése Tesztelés utáni finomítások
Mellékletek ............................................................................................... 54 4.1 1. melléklet: Szolgáltatás és adat-definíciók .................................................................... 54 4.1.1 Az EFER által nyújtott szolgáltatások.......................................................................... 54 4.1.1.1 EFERIntezmenyService.wsdl............................................................................ 54 4.1.1.2 EFERIntezmenyService.xsd ............................................................................. 59 4.1.2 Az intézmény által nyújtott szolgáltatások ................................................................... 66 4.1.2.1 IntezmenyService.wsdl ..................................................................................... 66 4.1.2.2 IntezmenyService.xsd....................................................................................... 71
5/80
1 VEZETŐI ÖSSZEFOGLALÓ A közigazgatás hatékonysága növelésének, az elektronikus közszolgáltatások bővítésének, az elektronikus ügyintézési folyamatok kiteljesítésének egyik fontos, mára kikerülhetetlenné vált eszköze az elektronikus fizetés általánossá tétele a közigazgatásban. A Pénzügyminisztérium Informatikai Szolgáltató Központ (PMISZK) „Elektronikus fizetés megvalósítása” címmel Elektronikus Közigazgatás Operatív Program projektjavaslatot nyújtott be, melynek eredményeként a Közreműködő Szervezet és a PMISZK által vezetett konzorcium Támogatási Szerződést kötött a projekt megvalósítására. A projekt célja az Elektronikus Fizetési és Elszámolási Rendszer (EFER), valamint az Intézményi Pénztár Program (IPP) létrehozása, amely intézmények számára nyújt szolgáltatást a piacon elérhető korszerű elektronikus fizetési megoldások integrálásával. Jelen dokumentum célja, hogy áttekintő képet nyújtson az EFER rendszerről valamint, hogy bemutassa az intézmény fizetési és elszámolási folyamatban betöltött szerepét, az üzleti folyamatok technikai megvalósítását és a csatlakozáshoz szükséges interface-k leírását.
6/80
2 BEVEZETÉS Jelen dokumentum definiálja az EFER rendszer intézményi kapcsolatának interface terv és mintaprogram leírását.
2.1 FOGALMAK Fogalom
Magyarázat
Kérésüzenet
A kommunikációt indító üzenet.
Szinkron üzenet
Nem átviteli protokoll szintű fogalom, hanem üzleti fogalom. Bár a https átviteli protokollt általában szinkronnak, a JMS átviteli protokollt pedig aszinkronnak tekintik, jelen dokumentumban – ahol nem emeljük ki külön – átviteli protokolltól függetlenül fogalmazunk. Az üzenet küldője akkor tekinti elküldöttnek a kérésüzenetet, ha adott időn belül (t) a fogadó fél válaszüzenetet küld vissza. A küldő fél a válaszüzenet megérkezéséig felfüggeszti a folyamatát, vagyis megvárja a válaszüzenetet. Ha nem jön válaszüzenet adott időn belül, a küldő megismételheti a kérésüzenetet és ismételten várakozhat a válaszüzenetre. A t idő értéke maximum perces nagyságrendű. A t idő értéke kommunikációs esetenként van meghatározva a dokumentumban, és az időtúllépés elnevezéssel hivatkozunk rá. A t tehát az az idő, amennyit a küldő fél maximum vár a szinkron válaszüzenet megérkezéséig. A t technikai (kommunikációs) időtúllépés. Ha válaszüzenet nem érkezik meg t időn belül, a hívónak a kérésüzenet elküldését újra kell próbálnia. Az újrapróbálkozások javasolt maximális száma 2, az egyes újrapróbálkozások megkezdése között pedig javasoltan 2*t időt kell hagyni.
Üzenetváltás típusa
A válaszüzenet feldolgozásának módja.
Válaszüzenet
A kérésüzenetre adott válasz. Lehet csak nyugtázó jellegű, de tartalmazhat üzletileg értékes adatokat is.
Tag (ejtsd: teg)
Angol elnevezés. XML-ben használatos elem, címke, amely rendelkezik névvel, rendelkezhet konkrét értékkel (az XMLben a tag értéke a „” és „” közötti rész), ill. gyermekekkel. Maga az XML hierarchikusan felépített tagekből áll. A gyermek-tag egy adott tag gyermekét jelenti.
Whitespace karakter
Az alábbi karakterek valamelyike: szóköz, tabulátor, vertikális tabulátor, új lap karakter, újsor karakter, kocsivissza karakter.
7/80
2.2 RÖVIDÍTÉSEK Fogalom
Magyarázat
B2B
A Business-to-Business a vállalatok, szervezetek között, elektronikus úton megvalósuló gazdasági kapcsolatok öszszességét jelenti.
EFER
Egységes Fizetési és Elszámolási Rendszer
FMSZ
Fizetési Megoldás Szolgáltató
JMS
A Java Message Service (JMS) API egy üzenetkezelési szabvány, amely elsősorban JEE platformon futó alkalmazások számára teszi lehetővé üzenetek létrehozását, küldését, fogadását és olvasását. Amennyiben SOAP transzfer protokollként használják, önmagában megvalósítja a megbízható üzenetváltást. Az EFER által megkövetelt JMS verzió: 1.1
SOAP
A Simple Object Access Protocol rövidítése. Egy – elsősorban heterogén rendszerek közötti - üzenetküldésre használt, XML-alapú formátum. Az SOAP formátumot használó üzenetek azután különböző protokollok segítségével továbbíthatók. Legelterjedtebb protokoll a http. Az EFER által használt verzió: SOAP 1.1.
VPOS
Virtual Point Of Sale
WSDL
Web Services Description Language
WS-AT
Web Services Atomic Transaction Web service szabvánnyal kapcsolatos protokoll, mely elosztott alkalmazások közötti tranzakcionális viselkedést képes megvalósítani a kétfázisú commit protokollra támaszkodva. Az EFER által megkövetelt verzió: WS-AT 1.0 (http://specs.xmlsoap.org/ws/2004/10/wsat/wsat.pdf)
WS-RM
OASIS Web Services Reliable Messaging Protocol Web service szabvánnyal kapcsolatos protokoll, mely elosztott alkalmazások közötti megbízható üzenetváltást tesz lehetővé komponens, alkalmazás vagy hálózati hibák kompenzálása miatt. Az EFER által használt verzió: WS-RM 1.1 (http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1spec-cd-04.pdf). (Az EFER alatti WS stack WS-RM releváns szabványok verziói: WS-ReliableMessaging v1.1, WSReliableMessaging Policy v1.1.)
WS-Sec
OASIS SOAP Message Security szabvánnyal kapcsolatos protokoll, mely elosztott alkalmazások közötti biztonságos üzenetváltást tesz lehetővé. Az EFER számára a szabvány használata azért szükséges, mert biztosítja az üzenetek sértetlenségét és hitelességét az által, hogy az üzenetek fejléce tartalmaz egy – az üzenet törzséből képzett - digitális aláírás,
8/80
mellyel az üzenet ellenőrizhető. Az EFER által használt verzió: WS-Sec 1.1 (http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-specos-SOAPMessageSecurity.pdf). (Az EFER alatti WS stack WS-Sec releváns szabványok verziói: WS-Security v1.1, WS-SecurityPolicy v1.1, WS-Trust v1.0, WSSecureConversation v1.0.) XSD
XML Schema Definition
2.3 EFER ÁTTEKINTÉS 2.3.1 Az EFER feladata Az EFER rendszer lehetővé teszi, hogy a lehető legszélesebb körben elérhetővé váljanak a teljesen elektronikus közszolgáltatások, aminek magától értetődő része, hogy a szolgáltatások „ellenértékének” (illetékek, díjak, stb.) kiegyenlítése, továbbá más, állammal szembeni fizetési kötelezettségek megfizetése is történhessen elektronikusan. A központi elektronikus fizetési szolgáltatás az intézményi szakrendszerek számára lehetővé teszi az elektronikus és hagyományos ügyintézéshez illeszkedő elektronikus fizetési megoldások felkínálását az ügyfelek számára, garantálja a befizetett díjösszegek célszámlákra történő eljuttatását. A fizetési kötelezettség-teljesítés megállapításának előfeltétele minden esetben, hogy a befizetés szakrendszerbeni egyedi azonosításra alkalmas ügyszámmal és a fizetéshez kapcsolódóan pénzügyi ügyazonosítóval rendelkezzen. Az EFER-ben megvalósított főbb folyamatok: A fizetési folyamat támogatása
Az ügyfél eljárást kezdeményez az intézménynél, vagy bekapcsolódik az intézmény által indított ügyintézési folyamatba. Az ügyintézés során az intézményi szakrendszerben megállapításra kerül a fizetési kötelezettség (fizetendő összeg, jogcím), amelyet az ügyfél tudomására kell hozni. A szakrendszerben ekkor képződik az ügyszám.
Az ügyintéző vagy (elektronikus ügyintézés esetén) az ügyfél az IPP-ben vagy ennek hiányában a szakrendszerben összeállítja a fizetési tranzakciót (azaz meghatározza az egyben fizetendő ügyeket, összegeket, jogcímeket), majd ehhez az IPP vagy a szakrendszer (gyűjtő) pénzügyi ügyazonosítót képez. Pénzügyi ügyanozosító felépítése Megnevezés
Hossz
Maszk
intézményi azonosító
8
nnnnnnnn
alrendszer azonosító
2
nn
dátum
6
ééhhnn
sorszám
7
nnnnnnn
hossz összesen
23
9/80
Az ügyfél ezt követően meghatározza, hogy milyen módon kíván fizetni: hagyományos ügyintézés esetén ez bankkártyás (POS), mobil- vagy házibanki, készpénzátutalási megbízással vagy készpénzzel történő, illetve vegyes fizetés; elektronikus ügyintézés esetén bankkártyás (VPOS), mobil banki vagy házibanki fizetés lehet.
Elektronikus fizetési megoldás választása esetén az ügyfél elindítja a fizetést
Bankkártyás fizetés esetén: o
Az ügyfél átadja az ügyintézőnek a bankkártyáját
o
Az ügyintéző a kártya ellenőrzését követően lehúzza a POS terminálon a bankkártyát, ezzel határozva meg a fizetéshez szükséges fizetői adatokat.
o
Az FMSZ elvégzi az authorizációt, és elindítja az ügyfél számlájának megterhelését célzó folyamatokat. Az authorizációt követően az FMSZ visszajelez az ügyfélnek és az IPP-nek (vagy a szakrendszernek) a tranzakció azonosító átadásával. Ez a visszajelzés az ún. fizetési ígérvény, amely a fizetés visszavonhatatlan megindításának elektronikus igazolása.
o
A fizetési ígérvény előállításának folyamata a következő: az FMSZ értesíti az ügyfelet, az IPP-t (vagy a szakrendszert) (továbbá a fizetési megoldáson belül az Ügyfél számlavezetőjét), majd az IPP értesíti a szakrendszert. o Házi-, mobilbankos és VPOS fizetés esetén:Az IPP (vagy szakrendszer) továbbitja az EFER-nek a fizetési megoldásnak megfelelően kitöltött fizetési kérelmet. Az EFER a fizetési kérelem fizetéshez szükséges adatait továbbítja a megfelelő FMSZ felé. o
Az ügyfél bejelentkezik az FMSZ fizetési felületre.
o Az ügyfél jóváhagyja a fizetési tételt, az FMSZ elvégzi az authorizációt, és elindítja az ügyfél számlájának megterhelését célzó folyamatokat. Az authorizációt követően az FMSZ visszajelez az ügyfélnek és az EFER-nek a tranzakció azonosító átadásával. Ez a visszajelzés az ún. fizetési ígérvény, amely a fizetés visszavonhatatlan megindításának elektronikus igazolása. o Az EFER az FMSZ-től megkapott visszavonhatatlan fizetési igérvény alapján üzenetben értesíti az IPP-t (vagy a szakrendszert). Az üzenet tartalmazza az FMSZ által kiállított eredeti fizetési igérvényt is.
A fizetési ígérvény birtokában az intézmény az ügyintézést folytatja vagy lezárja.
Amennyiben a fizetési tranzakció sikertelen, az ügyfél új fizetési megoldást választhat az IPP-ben. Ezt követően az eljárás megegyezik az előzőekben leírtakkal.
10/80
2.3.1.1 Fizetési folyamatok 2.3.1.1.1 A Házibankos fizetési megoldás folyamata sd Fizetési folyamat HB Ügyfél
Intézmény
EFER
FMSZ
critical Fizetési kérelem befogadása Fi zetés indítása() IPP_EFER_FIZKER() Fi zetési megoldás = HB (HáziBank)
alt Sikertelen fizetés Ügyfél fi zetés sikertelen() FMSZ_EFER_ELUT ASIT OTT FIZIGERVENY()
FMSZ_EFER_ELUT ASIT OT T FIZIGERVENYVALASZ()
EFER_IPP_ELUT ASIT OT T FIZIGERVENY()
EFER_IPP_ELUT ASITOT T FIZIGERVENYVALASZ()
Ügyfél áti rányítása i ntézményi felületre()
A fizetések elszámolásának folyamata
13/80
Az ügyintézés során elektronikusan megfizetett illetékek, díjak elszámolása az arra jogosultak, vagy kedvezményezettek felé a Magyar Államkincstárban az EFER szolgáltatásainak használatával történik.
Az ügyintézés során megfizetett illetékek és díjak elszámolásának lebonyolítása, a kedvezményezettek részére történő felosztása érdekében az alábbi három információforrásból kell adatokat kapnia az EFER-nek: o
Előírásokra vonatkozóan: Az intézményektől az ügyintézés során sikeresként jelzett fizetési tranzakciók adatai folyamatosan érkeznek.
o
Elindított fizetésekre vonatkozóan: A FMSZ naponta átadja az elindított – és utalt – fizetések teljes összegét, ezek analitikáját.
o
A Magyar Államkincstárhoz beérkezett összegekre vonatkozóan: A Magyar Államkincstár átadja az átvezetési számlakivonatokat a FMSZ által az intézményi átvezetési számlákra utalt teljes összegről. Ez – az utalás bonyolításához szükséges időt figyelembe véve – későbbi időpontban történik, mint az előző két forrásból érkező adatátvétel.
Az EFER a fenti adatokat összehasonlítja. Az adategyeztetés úgy történik, hogy első körben az előírásokra vonatkozó és a FMSZ-tól érkezett analitikák hasonlíthatók össze. Ezt követően – a számlakivonat átvétele után – történhet meg a számlakivonaton szereplő összeggel való összehasonlítás.
Az összegek és analitikák egyezése esetén elvégzi azok kedvezményezettenkénti (pl. APEH, VPOP, KEKKH, önkormányzatok, stb.) részösszegekre bontását (elszámolás).
Eltérés esetén hibalista készül, amely alapján a hibakeresés, hibajavítás megkezdhető és elvégezhető. A hibát annak a szintnek, szervezetnek kell kijavítania, ahol az előfordult, de a hibakeresésben valamennyi érintettnek részt kell vennie.
Az EFER átadja a KSZR-nek az átutalási megbízásokat.
A KSZR a számla felett rendelkezésre jogosult által adott átutalási megbízás alapján a kedvezményezettnek járó összeget átutalja az intézmény bevételi célszámlájára.
Az EFER az átutalási megbízások adatait átadja az intézményeknek a saját bevételeik elszámolása érdekében.
A tranzakciós díj elszámolásának folyamata A FMSZ szolgáltatásáért tranzakciós díjat számol fel. A díjat várhatóan havonta egyszer határozza meg, amelyet átad az EFER részére. Az EFER a díjat a Megrendelő által rugalmasan változtatható paraméterek szerint felosztja a költségviselő intézmények szerint, majd azok adatait átadja az intézményeknek. A tranzakciós díj felosztásának módját, a paraméterek körét a rendszertervezés során Megrendelőnek meg kell határoznia. A díjak elszámolása a Megrendelő által meghatározott időszakonként történik.
2.3.2 Az EFER szolgáltatás orientált működése Az EFER, mint központi rendszer a külvilág felé - így az intézményi rendszerek felé is szolgáltatásokat publikál. Az egyes szolgáltatások atomiak, közöttük nincs nem adatbázison alapuló állapottárolás, vagyis nincs munkamenet-kezelés. Adatbázison alapuló állapottárolást
14/80
végeznek a szolgáltatások a releváns üzleti objektumokon, és kezelik azok státuszát is. Az EFER által hívott szolgáltatások esetében az EFER kezeli az időtúllépést is (ld. szinkron üzenet fogalma). A szolgáltatások B2B kapcsolat révén érhetők el, csak informatikai rendszerek által és nem humán felhasználók által. Minden, EFER által megvalósított szolgáltatás szinkron jelleggel hívandó, vagyis minden esetben meg kell várni a hívó oldalon a magas szintű válasz megérkezését, a válasz megérkeztéig a hívónak blokkolódnia kell. Ha nem érkezik magas szintű válasz, a hívó a beküldött kérést nem tekintheti beérkezettnek, és meg kell ismételnie a hívást az egyes eseteknél leírt paraméterek szerint.
2.3.3 EFER és környezete telephely
Intézmény Rendszere
IPP
EFER 1
HTTPS
2 Fizetési Megoldás Szolgáltató
4
HTTPS
2.3.3.1 Az IT környezet
Az EFER-rel való integráció megvalósítása érdekében az intézménynek rendelkeznie kell legalább egy olyan informatikai rendszerrel, amely képes SOAP üzenetváltáson alapuló kommunikációt kezelni mindkét irányban: vagyis képes ilyen technológiával szolgáltatásokat publikálni, ill. szolgáltatásokat hívni azt EFER-ből. Továbbá, támogatja az alábbi protokollok közül egynek a SOAP transzfer protokollként történő használatát: o
https (preferált), a WS-RM (a megbízható üzenetváltás megvalósítása végett) és WS-AT (tranzakcionális viselkedés megvalósítása végett) kiterjesztések megvalósítása opcionális, ld. a Megbízható üzenetváltás fejezetet.
15/80
o
JMS, az alábbi feltételekkel: Az EFER-hez csatlakozó Intézmény rendelkezik egy üzenetorientált middleware szerverrel, és a JMS kommunikációt Intézmény oldalon ez a szerver biztosítja. Nem elvárás, de erősen javasolt, hogy Intézmény oldalon is ugyanilyen típusú szerver álljon rendelkezésre, egyéb esetben az Intézmény EFER-be történő integrálásának részeként a két JMS implementációt összekötését is meg kell valósítani, mely bár konfigurációs feladat, technikai kockázatot jelent.
A https átviteli protokollon képes kölcsönös SSL autentikációt kezelni; rendelkezik egy, az EFER tanúsítvány kiállítója által aláírt tanúsítvánnyal, amellyel azonosítja önmagát minden egyes kérés előtt. Illetve megbízik az EFER tanúsítványában.
A JMS átviteli protokoll esetén a JMS alatti TCP/TLS protokolloni képes kölcsönös SSL autentikációt kezelni.
Az intézmény EFER tanúsítvány kiállítója által aláírt tanúsítványa kliens tanúsítványként van felhasználva az SSL autentikáció során – OU (Organizational Unit) mezőjének kötelezően a „INT” értéket kell tartalmaznia. Az EFER tanúsítvány kiállítója nem írja alá a tanúsítvány aláírási kérést, ha ez a kritérium nem teljesül. Meg kell valósítania a WS-Sec 1.1 szabványt, mert ez biztosítja az üzenetek sértetlenségét és hitelességét az által, hogy az üzenetek fejléce tartalmaz egy – az üzenet törzséből képzett - digitális aláírás, mellyel az üzenet ellenőrizhető. Az aláíráshoz a jogszabályoknak megfelelően nem használhatja ugyanazon tanúsítványt, amit a transzfer protokoll kölcsönös SSL autentikációjánál.
2.3.3.1.1 JMS alapú kommunikáció A JMS átviteli protokollon történő SOAP kommunikációhoz szükséges infrastruktúra felépítése nem triviális, emiatt ebben a fejezetben külön kitérünk rá. Az irányelvek az alábbiak: Az EFER moduljai input üzenetsorokból olvasnak, és output üzenetsorokba írnak. Nincs olyan üzenetsor, ahonnan egyaránt olvasnának, és ahova egyaránt írnának. A tényleges JMS alapú kommunikációt a JMS-t implementáló szerverek, ill. a hozzájuk kapcsolódó kliens API-k végzik. Ez azt jelenti, hogy mind az EFER, mind az Intézmény oldalán rendelkezésre áll egy JMS szerver. A JMS üzenetek két fél közötti továbbítását a szerverek ill. a kliens API végzik. Ezek valósítják meg a két fél közötti hibatűrő és megbízható üzenetváltást is (pl. hálózati detektálása, kapcsolatok újrafelépítése, stb.). Az EFER oldali JMS implementáció a Sun Open Message Queue 4.3. Intézmény oldalon is ez a preferált JMS szerver, mert két ilyen szerver közötti kapcsolat kialakítása nem hordoz technikai kockázatot. Az input üzenetsorok lokálisak, vagyis a helyi szerveren léteznek fizikailag. Emiatt az adott fél mindig lokális üzenetsorból olvas. Az outout üzenetsorok távoliak, vagyis a fizikai üzenetsor a másik fél szerverén található. A JMS implementációtól függően lehetséges, hogy a távoli üzenetsorhoz létezik egy lokális üzenetsor is, mely transzfer céllal létezik. Emiatt az adott fél mindig távoli üzenetsorba tesz üzenetet. Az üzenetek fejlécében elhelyezésre kerülnek az alábbi String típusú propertyk: 1. CONTENT_TYPE=”text/xml; charset=utf-8” (tartalma fixen ez legyen, idézőjelek nélkül, ennek megfelelően a message body-ban lévő SOAP XML kódolása is UTF-8 legyen) 2. TARGET_URI=”x-jms://:<port>//?path=<service>” ahol host: az intézmény saját broker-jának hosztneve
16/80
port: az intézmény saját broker-jának portja az intézmény oldali QCF JNDI neve, amelyen keresztül az intézmény eléri az EFER-t az intézmény oldali Q JDNI neve, amibe az intézmény az EFER-nek szánt üzeneteket adja fel service: fixen „EFERIntezmenyService” (idézőjelek nélkül) Összességében mivel a rendszer szempontjából csak a formátum és a path paraméter értéke számít, így javasoljuk a következő konstans használatát: x-jms://www.example.com:1234/qcf/q?path=EFERIntezmenyService A válaszüzenet kérésüzenethez történő párosításának alapja a JMSMessageID és JMSCorrelationID mezők. Ez azt jelenti, hogy a kérést kiszolgáló félnek olyan válaszüzenetet kell előállítania, melynek JMSCorrelationID-je a kérésüzenet JMSMessageID mezőjével egyezik meg. A JMSMessageID mező generálását a kérésüzenetben és a válaszüzenetben is a JMS szerver generálja, azokra nincs hatása egyik félnek sem. A felek a válaszüzenetre várakozás során időtúllépést figyelnek. Adott időn belül meg nem érkező válasz annak a tranzakciónak a visszavonását eredményezi, amelyben a válaszra várakozás történik. A fentiek alapján a következő történik, amikor az EFER az Intézmény 1 szolgáltatását hívja: 1. Tranzakció indul, az EFER elvégzi a szolgáltatásspecifikus műveleteket, majd elkészíti a kérésüzenetet. 2. Új tranzakció indul. 3. Az üzenet fizikailag a lokális transzfer üzenetsorba, a távoli üzenetsor lokális aliaszába vagy magába a távoli üzenetsorba kerül. A kérésüzenethez JMSMessageID generálódik a JMS szerver által. 4. Lokális traszfer vagy aliasz üzenetsor esetén a JMS szerver a kérésüzenetet eljuttatja az Intézmény 1 JMS szerverének lokális, input üzenetsorába. Az EFER Intézmény 1-hez tartozó output üzenetsora tehát az Intézmény 1 szemponjából lokális input üzenetsorra „van kötve”. Távoli üzenetsor esetén az üzenettovábbításért a kliens API felelős. 5. Az új tranzakció jóváhagyásra kerül. A folyamat a szolgáltatás elején indított tranzakcióban megy tovább. Az EFER várakozik a lokális input üzenetsorán olyan válaszüzenetre, melyben az előzőleg létrehozott kérésüzenet JMSMessageID mezője van beállítva JMSCorrelationID-ként. 6. Az Intézmény 1 előállítja a válaszüzenetet, és beállítja annak JMSCorrelationID mezőjébe a kérésüzenet JMSMessageID mezőértékét. Az elkészült üzenetet feladja a számára lokális transzfer üzenetsorba, a távoli üzenetsor lokális aliaszába vagy magába a távoli üzenetsorba. 7. Lokális traszfer vagy aliasz üzenetsor esetén a válaszüzenetet az Intézmény 1 JMS szervere eljuttatja az EFER lokális input üzenetsorába. Távoli üzenetsor esetén az üzenettovábbításért a kliens API felelős. 8. Az EFER fogadja a válaszüzenetet. 9. A tranzakció jóváhagyásra kerül. A fenti folyamat alapján végigkövethető az az eset is, amikor az Intézmény 1 hívja az EFER szolgáltatásait, annyi eltéréssel, hogy nincs új tranzakció indítva a válaszüzenet feladásakor.
2.3.3.2 Kommunikáció leírása
17/80
Mindig szinkron, push és kérdés válasz alapú. Ez azt jelenti, hogy mindig van egy a hívó által egy kérdés üzenetre meghatározott határidőn belül, a hívott fél által adott válaszüzenet. Push jellegű pedig azért, mert ha egy másik modulban vagy rendszerben megjelenik egy információ, amit át kell adni az EFER részére, akkor a vonatkozó rendszer felelőssége, hogy kezdeményezze az átadást, nem az EFER-é. A magasszintű protokoll az EFER és az intézmény között SOAP. A SOAP transzfer protokollja https vagy JMS lehet. JMS esetén a JMS implementáció a Glassfish-be integrált Sun Open Message Queue 4.3 üzenetorientált middleware szerver, amely képes összekapcsolódni és kapcsolatot fenntartani az intézmény oldaliJMS-t implementáló szerverrel. A https protokollon és a TCP/TLS protokollon kölcsönös SSL autentikáció előzi meg a két fél közötti kapcsolat felépülését. Az EFER és az intézmény megvalósítja a WS-Sec 1.1 szabványt. A SOAP szabványnak megfelelően a szolgáltatásokat és a velük kapcsolatos adatokat WSDL és XSD állományok írják le. Ezek tételesen az 1. mellékletben találhatók. A WS-Sec kiterjesztés biztosítja az üzenetváltások védelmi elvárásait, úgymint:
Sértetlenség: Az üzenet nem volt harmadik fél által módosítva.
Hitelesség: Annak biztosítása, hogy az üzenetet valóban a feladó küldte.
Letagadhatatlanság: A küldő fél nem tudja letagadni, hogy az üzenetet ő és akkor küldte. Az EFER által támogatott SSL verzió: SSL V3.
Az egyes szolgáltatásoknál látható példaüzenetek az egyszerűség kedvéért csak a törzsben lévő adatrészt tartalmazzák, a befoglaló SOAP borítékot nem, így nem láthatók a különböző WS kiterjesztések miatti addicionális tag-ek sem. Függetlenül attól, hogy mi a transzfer protokoll, a SOAP üzenetváltásnak megfelelően a kérés és a válasz üzenetek egyaránt XML formátumúak. Az üzenettípus hordozására az üzenetekben nincs dedikált adatmező - mint ahogy az a fix rekordhosszúságú, szöveges fájl alapú kommunikációnál megszokott - , hanem az üzenettípust a kérés és válasz „Body” nevű tagjében lévő egyetlen gyermek-tag neve azonosítja (ahogy az a kommunikációs esetekhez tartozó minta kérés- és válaszüzenetekben is látszik). Pl.: EFERfogadFizetesiKeres, EFERfogadFizetesiKeresResponse. Az üzenetekben található tételek száma maximum 5000 lehet. Ha ennél nagyobb tételszámú üzenetre van szükség, akkor azt darabolni kell. Az üzenetek mérete továbbá nem haladhatja meg a 1.5Mbyte-ot.
2.3.3.3 Hibakezelés A technikai és lekezeletlen hibák kezelése a szolgáltatásokban egységes módon történik. Általánosan igaz, hogy minden szolgáltatás maximum egy hibát – pontosabban szólva annak hibakódját és hibaszövegét – adhat vissza. Ez a hiba pedig a szolgáltatás során előforduló első hiba. A szolgáltatások tehát nem képesek egynél több hibát detektálni egy meghívás alkalmával. Ha nem fordult elő hiba, akkor a visszaadott hibakód 0 lesz, a hibaszöveg pedig üres. Speciális jelentéssel bír a 97-es hibakód, ld. a Megbízható üzenváltás fejezetet. A hiba leírása egy magyar nyelvű üzenet, a hibák értelmezéséhez azonban hibakatalógus mindenképpen szükséges, amelyben hibakód alapján lehet keresni. A hibaleírást nem javasolt intézményi oldalon felhasználói felületen megjeleníteni, csak naplóba kiíratni, mert a célja
18/80
a hibakeresés megkönnyítése, nem pedig a humán felhasználó felé történő közlése, a hiba elsődleges beazonosításására a hibakód szolgál. Ha EFER szolgáltatásokban hiba keletkezik, akkor a válasz, amennyiben képes megérkezni a hívó oldalára, mindig utal a hiba okára. Az alábbi típusú hibákat lehet megkülönböztetni. Technikai hiba: Minden olyan hiba, ami az EFER alsóbb rétegekből, de várt módon érkezik (pl.: az EFER szolgáltatás elveszti a kapcsolatot az adatbázisával). A hibát a réteg javítja hibatűrő mechanizmussal, ha lehetséges. A hiba akkor jut el az EFER legfelső szintjére, ha a javítás sikertelen volt (Pl.: többszöri próbálkozás a hálózati kapcsolat helyreállítására). A hiba lehet: kommunikációs hiba, valamely, EFER által használt külső szolgáltatás nem elérhető. Input validációs hiba: Inputok formai ellenőrzése (pl.: kötelezőség, megengedett értéktartománnyal való összehasonlítás) során keletkezett hiba. Az első hibás input blokkolja a szolgáltatást. Az EFER 1-es hibakóddal válaszol az üzenetetre. Üzleti logikai hiba: Olyan hiba, melyhez az alkalmazáslogikában külön ág tartozik, tehát várt hiba. Ide tartoznak az EFER által hívott külső szolgáltatások válaszában található üzleti hibák is. Tartozhatnak ide potenciális biztonságsértéssel kapcsolatos hibák is. Lekezeletlen hiba: Minden olyan hiba, mely a fenti hibatípusok egyikébe sem sorolható. Az egyes hibák kezelését illetően az alábbiakat kell megemlíteni: Az egyszeres – nem alkalmazásmodul-szintű – technikai hibákkal kapcsolatos hibatűrő mechanizmusért a detektáló réteg – általában az alkalmazásszerver – felel. Ide tartozik az adatbázis eléréssel kapcsolatos mechanizmus. A SOAP kommunikációval kapcsolatos hibatűrő mechanizmus megvalósítása átviteli protokoll függő: JMS esetén a JMS önmaga biztosítja, https esetén egyedileg fejlesztett, újraküldési mechanizmust alkalmazó megoldással biztosítjuk, ld. a Megbízható üzenetváltás fejezetet.A hiba üzenet nem tartalmaz Java stacktrace-t, sem specifikus hibaleírást. Input validációs hibák kezelése: minden szolgáltatás az inputok ellenőrzésével indul. Ha validációs hiba lép fel, akkor az üzleti válasz részeként az első hibás mezőnek megfelelő hibakód lesz beállítva. Az üzleti logikai hibákra vonatkozó üzenetek a szolgáltatásokban az üzleti válasz részeként kerülnek elküldésre a szinkron válaszüzenetben. Az alkalmazásmodul-szintű lekezeletlen hibák kezelése a szolgáltatásokban egységes módon kezelődik. Az üzleti válaszban lévő hibák átvitelére a hibakód és hibaleírás elnevezésű mezők szolgálnak. A hibakód egy 0-1000-ig terjedő szám, amit az EFER számként fog értelmezni, nem szabad kitölteni sem balról, sem jobbról semmilyen whitespace karakterrel, sem pedig 0-val.
2.3.3.4 Megbízható üzenetváltás A megbízható üzenetváltás során a kommunikáló felek újraküldési és nyugtázási mechanizmust használnak. Az újraküldés teljes egészében a hívó fél felelőssége. Az újraküldés és nyugtázás megvalósítására az alábbi lehetőségek adottak:
19/80
JMS átviteli protokoll esetén maga a JMS biztosítja, nem szükséges alkalmazásszintű implementáció.
https átviteli protokoll esetén a WS-RM és WS-AT kiterjesztések biztosíthatják, nem szükséges alkalmazásszintű implementáció.
https átviteli protokoll esetén alkalmazásszintű megoldás biztosíthatja.
A fejezet további részeiben az utolsó esettel foglalkozunk. Az alábbiakban leírt elveket kell alkalmazni.
2.3.3.4.1 Újraküldés 2.3.3.4.1.1 AZ EFER, MINT SZERVER Ha az Intézmény nem kap választ a kérésére az EFER felől a beállított idő alatt időtúllépés, vagy hálózati probléma miatt, akkor megadott idő után megismétli azt, változatlan formában. A hívó hiba esetén az esetleges üzleti adatmódosításokat tartalmazó tranzakciót visszavonja. Ha az EFER olyan kérést kap, melynek az azonosítója már el van tárolva az adatbázisban, akkor ellenőrzi, hogy a többi – kérésben szereplő - adat megegyezik-e az előzőleg beküldöttel. Ha igen, és az eredeti kérést egyébként sikeresen végrehajtotta, akkor az új kérés „Ismételt beküldés” (97-es kódú) hibakóddal tér vissza, a válaszban az EFER pedig elhelyezi az eredeti válaszüzenet összes adatát. Amennyiben az eredeti kérés üzleti hibára futott, akkor a megismételt válasz az eredeti kérés hibáját tartalmazza. Az Intézménynek az „Ismételt beküldés” státuszú üzeneteket sikeresnek kell tekintenie. Ha az Intézmény sikeres választ fogad az EFER felől a beállított időn belül, akkor az esetleges adatmódosításokat tartalmazó tranzakciót jóváhagyja. Az Intézmény felől az újraküldést addig kell ismételni, amíg sikeres vagy „Ismételt beküldés” választ nem kap. Itt tisztázzuk a 15-ös és 97-es kódok közti eltérést. A 15-ös hibakód azt mutatja, hogy ugyanaz a pénzügyi ügyazonosító más adatokkal került beküldésre, azaz egy azonosító alatt több ügy is fut. Ez a beküldő rendszer hibás működésére utal. A 97-es kód akkor kerül visszaadásra ha a beküldött kérés minden adata megegyezik az ugyanilyen pénzügyi ügyazonosítóval eltárolt kérésével. Ez kommunikációs hibára utalhat, de üzleti szempontból sikeres tranzakciónak minősül.
2.3.3.4.1.2 AZ EFER, MINT KLIENS Ebben az esetben, ha az EFER nem kap választ adott ideig, vagy kommunikációs hibát kap vissza, akkor megadott idő elteltével újraküldi az üzenetet. Az EFER hiba esetén az esetleges üzleti adatmódosításokat tartalmazó tranzakciót visszavonja. Az Intézmény oldaltól ugyanazon működés az elvárt, mint az EFER-től, amikor szerverként viselkedik. A lenti kommunikációs esetekben kitérünk arra is, hogy a küldő félnek milyen paraméterekkel kell megismételnie az üzenet elküldését.
2.3.3.4.2 Nyugtázás 2.3.3.4.2.1 FIZETÉSI KÉRELEM ESETÉN A fizetési kérelem feldolgozása ügyfél oldalon idő és a kommunikáló felek tranzakcionalitása miatt is kritikus folyamat, ezért az üzenetváltás megbízhatóságának növelése érdekében
20/80
technikai célú üzenetváltás is szükséges, ezek piros téglalappal vannak körberajzolva a következő ábrán.
A megbízhatatlanság csökkentésére az üzenetek redundanciája szolgál. A feladó, amennyiben nem kap választ, többször megismétli a kérését. Az ismétlések segítenek az esetleges pillanatnyi hálózati problémák kikerülésében. 2.3.3.4.2.1.1 Lehetséges kommunikációs hibák és akciók A kommunikációs hiba mindegyik átmenet esetén azt okozza, hogy az adott üzenet nem érkezik meg a fogadó fél részére. 1: A hibát az intézmény észleli, a kérelmet adott alkalommal újraküldi, amíg le nem telik a próbálkozások száma, vagy sikeres választ nem kap. 2: A hibát az EFER észleli, az első kommunikációs hiba esetén hibát tartalmazó választ ad vissza az intézmény részére. Az ebben a pontban bekövetkezett hiba esetén biztos, hogy a fizetési kérelem nem érkezett meg az FMSZ felé. Ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé, ami ennek hatására engedi az ügymenetet folytatni más fizetési megoldás választásával. 3: Az EFER azt észleli, hogy az FMSZ-től nem kapott választ adott időn belül, emiatt hibát ad vissza az intézmény számára. A hiba hatására az intézmény a kérelmet újra beküldi. Az ebben a pontban bekövetkezett hiba esetén biztos, hogy a fizetési kérelem nem érkezett meg az FMSZ felé. Ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé, ami ennek hatására engedi az ügymenetet folytatni más fizetési megoldás választásával. 4: A hibát az EFER észleli, az első kommunikációs hiba esetén hibát tartalmazó választ ad vissza az intézmény részére. Ha az FMSZ sikeresnek észlelte a válasza átadását, akkor az EFER által beküldött ugyanazon kérelemre visszaadja ugyanazt a választ, melyet korábban visszaadott (97-es státusz). Az ebben a pontban bekövetkezett hiba esetén biztos, hogy a fizetési kérelem nem érkezett meg az FMSZ felé. Ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé, ami ennek hatására engedi az ügymenetet folytatni más fizetési megoldás választásával.
21/80
5: Az EFER azt észleli, hogy az FMSZ-től nem kapott választ adott időn belül, emiatt hibát ad vissza az intézmény számára. A hiba hatására az intézmény a kérelmet újra beküldi. Ebben a pontban bekövetkezett hibánál a fizetési kérelem már megérkezhetett az FMSZ-hez, ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé. A intézmény ennek hatására, az esetleges dupla fizetések elkerülése miatt nem engedélyezi az ügymenet folytatását a hiba elhárításáig. 6: Az intézmény azt észleli, hogy az EFER-től nem kapott választ adott időn belül, ezért a kérelmet újra beküldi. Ha az EFER sikeresnek észlelte a válasza átadását, akkor az intézmény által beküldött ugyanazon kérelemre visszaadja az FMSZ-től korábban kapott választ. 7: A hibát az intézmény észleli, a kérelmet adott alkalommal újraküldi, amíg le nem telik a próbálkozások száma, vagy sikeres választ nem kap. 8: Az intézmény azt észleli, hogy az EFER-től nem kapott választ adott időn belül, ezért a nyugtát újra beküldi. Ha az EFER sikeresnek észlelte a válasza átadását, akkor az intézmény által beküldött ugyanazon nyugtára visszaadja ugyanazt a választ, melyet korábban visszaadott. 2.3.3.4.2.1.2 A kommunikációs hibák kezelésének módja Megjegyzés: végleges hiba alatt azt az esetet értjük, amikor a küldő fél a maximális újraküldésszám elérése után sem kapott választ. Általánosan feltételezhetjük, hogy amennyiben a hiba a válasz ágakon (3,5,6,8) jelentkezik, akkor valamely hálózati eszköz csomagszűrési beállításai miatt nem valósul meg a kommunikáció. Kérés ágak esetében (1,2,4,7) a kapott hibaüzenetek segíthetnek a hiba kiderítésében (hibás hálózati eszköz, nem létező hálózati kapcsolat, a szerver meghibásodása). A hiba pontos helyének és okának kiderítése és elhárításának módja túlmutat jelen dokumentum keretein, mivel az a hálózati infrastruktúra valamely elemében jelentkezik, az EFER hatókörén kívül. 1: A hiba az intézményi rendszeren kerül kijelzésre, mivel az EFER elérhetetlen. A hiba elhárításáig az ügyfél nem tudja folytatni az eljárást. 2: A hiba az FMSZ kapcsolatban van. Végleges hiba esetén az ügyfél más FMSZ-t alkalmazó fizetési megoldás választásával megpróbálhatja folytatni a folyamatot. 3: A hiba az FMSZ kapcsolatban van. Végleges hiba esetén az ügyfél más FMSZ-t alkalmazó fizetési megoldás választásával megpróbálhatja folytatni a folyamatot. 4: A hiba az FMSZ kapcsolatban van. Végleges hiba esetén az ügyfél más FMSZ-t alkalmazó fizetési megoldás választásával megpróbálhatja folytatni a folyamatot. 5: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárításáig az eljárás folytatása nem javasolt. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad, és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. A hiba elhárításának folyamata: Ellenőrizni kell EFER-ben, hogy a kérelem látható-e az EFER-ben és státusza Továbbítás alatt-e. Ha igen, akkor az EFER nem fogadta az FMSZ esetleges válaszát, így bizonytalan, hogy a függő fizetés a bank oldalán létrejött-e. Emiatt nem szabad más fizetési módot választani. Az EFER-FMSZ kapcsolatot helyre kell állítani.
22/80
Ha található kérelem Nyugtázásra vár státusszal, akkor a fizetést el kell végezni, a megérkező fizetési ígérvény pedig Fizetve státuszt állít be mind az EFER, mint az intézmény oldalán. Ilyen esetben is javasolt az EFER-FMSZ kapcsolat felülvizsgálata. 6: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárításáig az eljárás folytatása nem javasolt. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. A hiba elhárításának folyamata: Ellenőrizni kell EFER-ben, hogy a kérelem látható-e az EFER-ben és státusza Továbbítás alatt-e. Ha igen, akkor az EFER nem fogadta az FMSZ esetleges válaszát, így bizonytalan, hogy a függő fizetés a bank oldalán létrejött-e. Emiatt nem szabad más fizetési módot választani. Az EFER-FMSZ kapcsolatot fixálni. Ha található kérelem Nyugtázásra vár státusszal, akkor a fizetést el kell végezni, a megérkező fizetési ígérvény pedig Fizetve státuszt állít be mind az EFER, mint az intézmény oldalán. Ilyen esetben is javasolt az EFER-FMSZ kapcsolat felülvizsgálata. 7: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. 8: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik.
2.3.3.4.2.2 EGYÉB ESETBEN Nem szükséges nyugtázás, a hívó addig ismétli a kérésüzenetet, amíg helyes választ nem kap.
2.3.3.4.3 Authentikáció Az EFER magát az intézményt autentikálja az által publikált szolgáltatások hívásakor. Az autentikáció módja kölcsönös SSL autentikáció minden átviteli protokoll esetén. Amikor az EFER hívja az intézmény szolgáltatásait, ugyanezen autentikációs módot kell alkalmazni. Az EFER nem szólítható meg ettől eltérő módon, vagyis olyan intézményből, aki nem rendelkezik a megfelelő, az EFER tanúsítvány kiállítója által aláírt tanúsítvánnyal. Ha a SOAP átviteli protokollja https, akkor az EFER az intézmény kliens tanúsítványából kiemeli a Distinguished Name (DN) és Organizational Unit (OU) mezőket, emiatt nem szükséges explicit módon – üzenet szinten – átadni számára minden kérésüzenetben. JMS protokoll esetén hálózatilag biztosított, hogy az intézmény nem hívhat meg olyan szolgáltatást, amelyre nem jogosult. Az EFER az intézmény felé nyújtott interfészen keresztül nem autentikál humán felhasználót.
2.3.3.4.4 Authorizáció Az EFER az intézményt szolgáltatásonként authorizálja az alábbi szabályok szerint:
23/80
Az intézmény csak a saját átvezetési számláját adhatja meg kedvezményezettként.
24/80
3 EFER ÉS AZ INTÉZMÉNYEK KÖZÖTTI KAPCSOLAT 3.1 FIZETÉSI KÉRELEM ÁTADÁSA EFER-NEK A folyamat rövid leírása: Az elektronikus fizetési megoldás választása esetén az Intézmény a fizetési kérelmet átadja az EFER számára a fizetési tranzakció lebonyolítása érdekében. Az EFER az intézménytől átveszi a fizetési kérelmet, ellenőrzi az adattartalom helyességét. Az átvétel sikerességéről/sikertelenségéről értesíti az Intézményt. Típus: szinkron Időkorlát: 45 másodperc Indító üzenet: IPP_EFER_FIZKER Válasz üzenet: IPP_EFER_FIZKERVALASZ Ismétlés: 90 másodperc
3.1.1 Folyamat leírása Az Ügyfél elektronikus fizetési megoldást választott az Intézmény oldalán. Az Intézmény a választott fizetési megoldás, és az FMSZ beállításainak megfelelően (lásd. IPP_FMSZLISTAKER) függvényében további adatokat kér be az Ügyféltől, házibankos és mobilbankos fizetés esetén a bankszámla számát. A fizetési kérelmet egyedi azonosítóval (pénzügyi ügyazonosító) látja el majd a fizetési kérelemnek megfelelő adatokkal kitöltött üzenetet küld az EFER felé. (IPP_EFER_FIZKER) A fej adatok tartalmazzák a fizetéshez szükséges adatokat mind az egyedi mind az összevont tételek esetén, a tétel adatok - az egyösszegben fizetett - az elszámoláshoz szükséges tételt vagy tételeket tartalmazzák, míg a láb adatok a tételadatok ellenőrzésére szolgálnak. Ha a Hozzájárulás mező értéke hamis vagy a mező nincs megadva, akkor a tételadatok nem lesznek az FMSz részére továbbítva. Az EFER az intézménytől átveszi a fizetési kérelmet, ellenőrzi az adattartalom helyességét és a választott fizetési megoldáshoz tartozó kiegészítő mezők kitöltöttségét. Ha hibátlan az üzenet, akkor házi- és mobilbankos fizetés esetén továbbítja az FMSZ-nek a fizetési adatokat VPOS esetén bankkártyás fizetési tranzakciót indít Sikeres adatátadás ill. tranzakció indítás esetén az EFER „0” hibakóddal ellátott válasz üzenetet küld az intézmény felé. (IPP_EFER_FIZKERVALASZ) Az Intézmény a megkapott válasz, a fizetési megoldás és az ügyintézői módnak megfelelően vagy azonnal folytatja a fizetési folyamatot az Ügyfélnek a megkapott URL-re történő átirányításával, vagy a választ letárolja és értesíti Ügyfelét a további teendőkről. Hiba esetén a kérelem elutasításra kerül, a válasz üzenet hibakódja utal a hiba okára lásd. Hibakódok, ebben az esetben az intézménynek új pénzügyi ügyazonosítóval kell megpróbálnia újra beadni a fizetési kérelmet. Hibának minősül a kötelező mezők hiányos kitöltése, a nem egyedi pénzügyi ügyazonosító és a hibás kumulált adatokat tartalmazó üzenet.
25/80
A kérelemben megadott intézményi átvezetési számlához tartozó intézményi számlának az EFER törzsadatai között szerepelnie kell, különben a kérelem visszautasításra kerül. Amennyiben az EFER nem tudja átvenni a fizetési kérelmet (pl hálózatkiesés miatt), az intézmény megpróbálhatja azt később újra elküldeni (a fizetési határidő lejárata előtt), tehát a kérelem megismételhető az eredeti formájában az eredeti pénzügyi ügyazonosítóval. Az intézményi oldallal szemben elvárás, hogy jelezze a kezelő felé, ha a meghatározott ismétlésszám elérése után sem sikerült választ kapnia az EFER-től. Ilyen esetben az ügyintéző az EFER rendszerben ellenőrizheti, hogy a fizetés megtörtént-e. Az ellenőrzés hiányában a fizetés állapotára semmiféle feltételezés nem tehető. Interneten történő ügyintézés esetén az intézményi oldalon jelezni kell az ügyfélnek, hogy az esetlegesen készült fizetési tranzakció az FMSZ megfelelő eszközével ne hagyja jóvá vagy írja alá. Az ismétlési szám a vonatkozó folyamat valósidejű jellege miatt van maximálva.
Ellenőrzés üzenet szintaktikailag megfelelő számlaszám szintaktikailag megfelelő (pl. nem CDV hibás) üzenet azonosító (pénzügyi ügyazonosító) egyedi intézmény és alrendszer azonosító megfelelő az intézménykód és a címzett/kedvezményezett számlaszám nem tartozik össze vagy nem használható a megadott fizetési móddal, nem létező átvezetési számlaszám célszámla létezik, és EFER-hez tartozó forrás (terhelendő) számlaszám nem létezik tételek darabszáma és összegei helyesek érvénytelen fizetési megoldás fizetési határidő érvénytelen / nem konzisztens az üzenettel fizetési megoldást az FMSZ támogatja devizanem = HUF Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal) FMSZ válaszra vár
Hibakód 1 2,3,4 15 20,30,31 32
56 50,51 10,11 22 40 33 23 97 98
Sikertelen üzenetátadás esetén az intézménynek maximum 3 alkalommal kell megkísérelnie az üzenet újraküldését. Az ismétlési szám a fizetési kérelem befogadási folyamat valósidejű jellege miatt van maximálva.
3.1.2 Adatkör leírás (IPP_EFER_FIZKER) Mező neve FEJ intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító devizanem fizetési határidő fizetési megoldás fizető bankszámlaszáma
Tag neve
Típus
Kötelező
intazon alrszazon penzazon dev fizhatido fizmegold kotszlaszam
intazon alrszazon penzazon dev idopont fizmegold
I I I I I I fizetési megoldás
szlaszam
26/80
kottelszam fizető mobilszáma
mobiltel kotugyfazon
fizető ügyfélazonosítója kedvezményezett (intézményi átvezetési) számla száma vissza URL hiba vissza URL hozzájárulás TÉTEL igazgatási ügyazonosító összeg kedvezményezett neve kedvezményezett intézményi bankszámlája ÁHT azonosító KTK kód könyvelési azonosító ügyleírás LÁB tételek száma tételek összértéke
Minta válasz üzenet: <ns2:EFERfogadFizetesiKeresResponse xmlns:ns2="http://kfm.efer.com/"> PR117000000INT01INT01000PR1004200000001
3.2 FIZETÉSI KÉRELEM VÁLASZ NYUGTÁZÁSA AZ EFER FELÉ A folyamat rövid leírása: Az intézmény által előzőleg beküldött fizetési kérelemre EFER-től visszakapott válasz nyugtázása. A nyugtát közvetlenül a fizetési kérelemre érkezett válasz (IPP_EFER_FIZKERVALASZ) fogadása után kell küldeni. Ha a nyugta nem érkezik be az EFER-be 90 másodpercen belül az IPP_EFER_FIZKERVALASZ kiküldését követően, az EFER-ben riasztás keletkezik, mert ez EFER ezt helytelen működésnek tekinti. A nyugtázás minden átviteli protokoll esetén szükséges, a fizetési kérelem befogadási folyamatának szerves része. Típus: szinkron Időkorlát: 45 másodperc Indító üzenet: IPP_EFER_FIZKERNYUGTA Válasz üzenet: IPP_EFER_FIZKERNYUGTAVALASZ Ismétlés: 90 másodperc
28/80
3.2.1 Folyamat leírása A nyugtában a fizetés azonosító jellegű adatait és a fizetési kérelemre EFER-től kapott válasz azonosító jellegű adatait kell megadni. Sikertelen üzenetátadás esetén az intézménynek maximum 3 alkalommal kell megkísérelnie az üzenet újraküldését. Az ismétlési szám a fizetési kérelem befogadási folyamat valósidejű jellege miatt van maximálva.
Ellenőrzés Hibakód üzenet szintaktikailag megfelelő 1 intézmény és alrendszer azonosító megfelelő 20,30,31 Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hiba- 97 kóddal)
3.2.2 Adatkör leírás (IPP_EFER_FIZKERNYUGTA) Mező neve intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító FMSZ tranzakció azonosító
Tag neve intazon alrszazon penzazon fmsztrazon
Típus intazon alrszazon penzazon fmsztrazon
Kötelező I N I N
Minta üzenet: <ns2:EFERfogadFizetesiKeresNyugta xmlns:ns2="http://kfm.efer.com/"> <request> INT01PRINT01000PR100420000000111700000
3.2.3 Adatkör leírás (IPP_EFER_FIZKERNYUGTAVALASZ) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító hibakód hibaszöveg
Intazon alrszazon penzazon hibakod hibaszoveg
intazon alrszazon penzazon hibakod hibaszoveg
I N I I N
Minta válasz üzenet: <ns2:EFERfogadFizetesiKeresNyugtaResponse xmlns:ns2="http://kfm.efer.com/"> INT01PRINT01000PR10042000000010
29/80
3.3 FIZETÉSI IGÉRVÉNY ÁTADÁSA INTÉZMÉNYNEK A folyamat rövid leírása: A FMSZ által kiállított visszavonhatatlan fizetési ígérvényt az EFER a megfelelő formában továbbítja intézmény felé. Az Intézmény igazolja a fizetési igérvény átvételét. Típus: szinkron Időkorlát: 30 másodperc Indító üzenet: EFER_FIZIGERVENY Válasz üzenet: EFER_FIZIGERVENYVALASZ Ismétlés: 60 másodperc
3.3.1 Folyamat leírása FMSZ fizetési ígérvényt bocsátott ki a fizető ügyfél által jóváhagyott fizetési tranzakcióra, amit elküld az EFER részére. Az EFER ellenőrzi az FMSZ fizetési ígérvényben kapott adatokat (FMSZ azonosító, tranzakció azonosító, összeg összevetése a kérelemben szereplővel stb.) és amennyiben mindent rendben talál előállítja az Intézmény felé küldendő üzenetet (EFER_FIZIGERVENY). Az Intézmény EFER_FIZIGERVENYVALASZ üzenettel igazolja a fizetési igérvény átvételét. Ha az Intézmény olyan fizetési igérvényt kap, amelyre nem jogosult, vagy nem tud beazonosítani, akkor ez a kommunikáló rendszerek valamelyikének konfigurációs hibájára utal, és a hiba felderítését és elhárítását azonnal meg kell kezdeni. Ezekben az esetekben „0” hibakódtól különböző hibakódú EFER_FIZIGERVENYVALASZ-t kell küldeni az EFER felé. Amennyiben az intézményi rendszer nem tudja átvenni a fizetési igérvényt (pl hálózatkiesés miatt), az EFER megpróbálja azt később újra elküldeni az intézmény felé. Ellenőrzés üzenet szintaktikailag megfelelő üzenet azonosító (pénzügyi ügyazonosító) egyedi pénzügyi ügyazonosító létezik intézmény és alrendszer azonosító megfelelő célszámla létezik, és EFER-hez tartozó összeg megfelel a kérelemnek devizanem = HUF átvezetési számla létezik fizetési megoldás létezik FMSZ azonosító létezik FMSZ azonosító és fizetési megoldás nincs ellentmondásban az ígérvényben szerelő pénzügyi ügyazonosítóhoz nem tartozik már fizetési kérelem
Hibakód 1 15 26 30,31 56 12 23 56 22 24 33 42
30/80
a fizetés állapota nem: fizetésre átadva eltérő fizetési megoldás a fizetési kérelemben és az ígérvényben (Csak ha VPOS van a kérelemben, vagy az ígérvényben) tranzakció időpontja és a kérelem dátuma inkonzisztens Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal)
78 79 82 97
Sikertelen üzenetátadás esetén az EFER mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
3.3.2 Adatkör leírás (EFER_FIZIGERVENY) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító terhelt bankszámlaszám FMSZ azonosító fizetési megoldás kedvezményezett (intézményi átvezetési) számla száma FMSZ tranzakció azonosító FMSZ tranzakció dátuma összeg devizanem FMSZ-től kérésüzenetként kapott fizetési ígérvény
3.3.3 Adatkör leírás (EFER_FIZIGERVENYVALASZ) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító státuszinformáció / hibakód hibaszöveg
intazon alrszazon penzazon hibakod hibaszoveg
intazon alrszazon penzazon hibakod hibaszoveg
I I I I N
Minta válasz üzenet: <ns2:IntFogadFizetesiIgervenyResponse xmlns:ns2="http://ws.web.efer.ind.com/"> PR0INT01INT01000PR1004200000001
3.4 ELUTASÍTOTT FIZETÉS ÁTADÁSA AZ INTÉZMÉNYNEK A folyamat rövid leírása: A FMSZ által elutasított fizetési ígérvényt az EFER átadja az intézménynek, ahonnan a fizetési kérés származott.. Típus: szinkron Időkorlát: 30 másodperc Indító üzenet: EFER_ELUTASITOTTFIZIGERVENY Válasz üzenet: EFER_ELUTASITOTTFIZIGERVENYVALASZ Ismétlés :60 másodperc
3.4.1 Folyamat leírása A fizetésre kötelezett ügyfél az előkészített átutalási megbízást, vagy VPOS fizetési tranzakciót elutasítja, az FMSZ kiállítja az elutasított fizetési ígérvényt és elküldi azt az EFER részére, vagy az EFER elutasított fizetési igérvényt állít ki mert a kérelemben megjelölt fizetési határidő letelt. Az
EFER
az
intézmény
felé továbbítja az elutasított fizetési igérvényt Amennyiben az intézményi rendszer nem tudja átvenni a az üzenetet (pl hálózatkiesés miatt), az EFER megpróbálja azt később újra elküldeni az intézmény felé. (EFER_ELUTASITOTTFIZIGERVENY).
Fizetési igérvény elutasításának okai fizetési határidő lejárt (az EFER lejáratta a tételt) elutasítás fedezethiány miatt ügyfél által elutasított fizetés
Hibakód 41 54 55
32/80
időtúllépés (time-out) VPOS fizetésnél egyéb ok
58 95
Az intézmény az átvételt válaszüzenetben igazolja vissza. (EFER_ELUTASITOTTFIZIGERVENYVALASZ)
Ellenőrzés Hibakód üzenet szintaktikailag megfelelő 1 üzenet azonosító (pénzügyi ügyazonosító) egyedi 15 pénzügyi ügyazonosító létezik 26 intézmény és alrendszer azonosító megfelelő 30,31 fizetési megoldás létezik 22 FMSZ azonosító létezik 24 FMSZ azonosító és fizetési megoldás nincs ellentmondásban 33 az ígérvényben szerelő pénzügyi ügyazonosítóhoz nem tartozik 42 már fizetési kérelem a fizetés állapota nem: fizetésre átadva 78 eltérő fizetési megoldás a fizetési kérelemben és az ígérvényben 79 (Csak ha VPOS van a kérelemben, vagy az ígérvényben) tranzakció időpontja és a kérelem dátuma inkonzisztens 82 Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hiba97 kóddal) Sikertelen üzenetátadás esetén az EFER mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
3.4.2 Adatkör leírás (EFER_ELUTASITOTTFIZIGERVENY) Mező neve intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító FMSZ azonosító fizetési megoldás elutasítás időpontja hibakód hibaszöveg
Tag neve intazon alrszazon penzazon fmszazon fizmegold elutidopont hibakod hibaszoveg
Típus intazon alrszazon penzazon fmszazon fizmegold idopont hibakod hibaszoveg
Kötelező I I I I I I I N
Minta üzenet: <ns2:IntFogadElutasitottFizetesiIgerveny xmlns:ns2="http://ws.web.efer.ind.com/"> <request> 00 <elutidopont>2010-05-01T15:53:01.533+02:00 OTP011170000054INT03
33/80
INT03000001004200000001
3.4.3 Adatkör leírás (EFER_ELUTASITOTTFIZIGERVENYVALASZ) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító hibakód hibaszöveg
intazon alrszazon penzazon hibakod hibaszoveg
intazon alrszazon penzazon hibakod hibaszoveg
I I I I N
Minta válasz üzenet: <ws:IntFogadElutasitottFizetesiIgervenyResponse xmlns:ws="http://ws.web.efer.ind.com/"> 000RendbenINT03INT03000001004200000001
3.5 FIZETÉSI ÍGÉRVÉNY ÁTADÁSA AZ EFER RÉSZÉRE A folyamat rövid leírása: Az Intézmény a sikeresként lezárt bankkártyás fizetési tranzakciók fizetési ígérvényeit a fizetések és tranzakciós díjak elszámolása érdekében átadja az EFER részére. Típus: szinkron Időkorlát: 30 másodperc
3.5.1 Folyamat leírása Az Intézmény a sikeresként lezárt bankkártyás fizetési tranzakciók fizetési ígérvényeit a fizetések és tranzakciós díjak elszámolása érdekében átadja az EFER részére. Az EFER az átvételről válasz üzenetet ad.
34/80
Hiba esetén a benyújtott IPP_FIZIGERVENY elutasításra kerül, a válasz üzenet hibakódja utal a hiba okára lásd. Hibakódok. Hibának minősül különösen a kötelező mezők hiányos kitöltése, a nem egyedi pénzügyi azonosító és a hibás kumulált adatokat tartalmazó üzenet. Ha a beadott adatok eltérést mutatnak az FMSZ-től érkező analitikával, az eltérést az EFER az EFER_INT_FIZHIBA üzenetben közli az intézménnyel. Az eltérésben kimutatott hibás, vagy hiányzó tételeket az intézménynek újra el kell küldenie. Amennyiben az EFER nem tudja átvenni a fizetési igérvényt (pl hálózatkiesés miatt), az intézménynek köteles azt újra elküldeni. Ellenőrzés üzenet szintaktikailag megfelelő számlaszám szintaktikailag megfelelő (pl. nem CDV hibás) üzenet azonosító (pénzügyi ügyazonosító) egyedi pénzügyi ügyazonosító létezik intézmény és alrendszer azonosító megfelelő az intézménykód és a címzett/kedvezményezett számlaszám nem tartozik össze vagy nem használható a megadott fizetési móddal, nem létező átvezetési számlaszám célszámla létezik, és EFER-hez tartozó tételek darabszáma és összegei helyesek érvénytelen fizetési megoldás fizetési határidő érvénytelen / nem konzisztens az üzenettel fizetési megoldást az FMSZ támogatja devizanem = HUF Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal)
Hibakód 1 2,3,4 15 26 20,30,31 32
56 10,11 22 40 33 23 97
3.5.2
Sikertelen üzenetátadás esetén az intézmény mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
intazon alrszazon penzazon dev fizhatido fizmegold fmsztrazon fmsztrdatuma intatvszlaszam
intazon alrszazon penzazon dev idopont fizmegold fmsztrazon idopont
I I I I I I I I
szlaszam
I
igazgugyazon osszeg
igazgugyazon penzosszeg
I I
35/80
kedvezményezett neve kedvezményezett intézményi bankszámlája ÁHT azonosító KTK kód könyvelési azonosító LÁB tételek száma tételek összértéke
kedvnev intbankszlaszam
szemelynev
I
szlaszam
I
ahtazon ktkkod konyvazon
ahtazon ktkkod konyvazon
N N N
tetelszam tetelossz
dbszam penzosszeg
I I
36/80
Minta üzenet: <ns2:EFERfogadFizetesiIgervenyIntezmenytol xmlns:ns2="http://kfm.efer.com/"> <request> INT01PR111122223333444455556666OTP01INT01000PR1004200000003 <dev>HUF 2010-05-01T14:59:59.999+01:00OTP219387213923122010-05-01T14:00:00.001+01:00INT01PR0011Teszt Elek666666667777777788888888495014950
3.5.4 Adatkör leírás (IPP_FIZIGERVENYVALASZ) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító pénzügyi ügyazonosító hibakód Hibaszöveg
intazon alrszazon penzazon hibakod hibaszoveg
intazon alrszazon penzazon hibakod hibaszoveg
I I I I N
Minta válasz üzenet: <ns2:EFERfogadFizetesiIgervenyIntezmenytolResponse xmlns:ns2="http://kfm.efer.com/"> PR0INT01INT01000PR1004200000003
3.6 UTALÁSI ADATOK ÁTADÁSA AZ INTÉZMÉNYNEK A folyamat rövid leírása: Az EFER –az Intézményektől, az FMSZ-ektől és a KSZR-től kapott adatok alapján előállítja az intézményi átvezetési számláról a célszámlákra történő utalások megbízásának listáit és azt átadja az intézménynek.
3.6.1 Folyamat leírása Az EFER – az Intézményektől, az FMSZ-ektől és a KSZR-től kapott adatok alapján előállítja az intézményi átvezetési számláról a célszámlákra történő utalások megbízásának listáit Az utalások a MÁK 2. fájlformátumban készülnek el és így kerülnek átadásra az intézmény részére.. Az Intézmézmény az átutalási megbízásokat ellenőrzi és jóváhagyás után benyújtja azt a KSZR-nek. A KSZR átveszi és ellenőrzi az utalási megbízásokat, a hibás tételeket visszaküldi az Intézménynek, amely javítás után újból benyújtja azokat. Amennyiben az intézményi rendszer nem tudja átvenni a utalási állományt (pl hálózatkiesés miatt), az EFER megpróbálja azt később újra elküldeni az intézmény felé. Ha az Intézmény olyan adatokat kap, amelyre nem jogosult, vagy nem tud beazonosítani, akkor ez a kommunikáló rendszerek valamelyikének konfigurációs hibájára utal, és a hiba felderítését és elhárítását azonnal meg kell kezdeni. Ezekben az esetekben „0” hibakódtól különböző hibakódú EFER_IPR_UTALASVALASZ-t kell küldeni az EFER felé. Ellenőrzés üzenet szintaktikailag megfelelő
Hibakód 1
utalás azonosító egyedi intézmény azonosító megfelelő intézményi átvezetési számla létezik, és EFER-hez tartozó devizanem = HUF tételek darabszáma helyesek Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal) telen üzenetátadás esetén az EFER mindaddig ismétli az üzenetet, amíg adásra nem kerül.
15 30 56 23 10 97 Sikeraz sikeresen át-
3.6.2 Adatkör leírás (EFER_IPR_UTALAS) Mező neve FEJ egyedi utalás azonosító intézményi azonosító esedékesség dátuma
Tag neve
Típus
Kötelező
egyutalazon intazon eseddatum
egyanalazon intazon idopont
I I I
38/80
TÉTEL intézményi átvezetési bankszámlaszáma devizanem utalás állomány LÁB tételek száma
3.6.3 Adatkör leírás (EFER_IPR_UTALASVALASZ) Mező neve
Tag neve
Típus
Kötelező
egyedi utalás azonosító hibakód hibaszöveg
egyutalazon hibakód hibaszoveg
egyutalazon hibakód hibaszoveg
I I N
Minta válasz üzenet: <ws:IntFogadUtalasResponse xmlns:ws="http://ws.web.efer.ind.com/"> <egyutalazon>UA01 0
39/80
3.7 UTALÁSI MEGBÍZÁS ANALITIKA ÁTADÁSA AZ INTÉZMÉNYEKNEK A folyamat rövid leírása: Az EFER – az Intézményektől, az FMSZ-ektől és a KSZR-től kapott adatok alapján előállítja az intézményi átvezetési számláról a célszámlákra történő utalások analitikájának listáit. Típus: szinkron Időkorlát: 300 másodperc Indító üzenet: EFER_IPR_UTALANALITIKA Válasz üzenet: EFER_IPR_UTALANALITIKAVALASZ Ismétlés :10 perc
3.7.1 Folyamat leírása Az EFER – az Intézményektől, az FMSZ-ektől és a KSZR-től kapott adatok alapján előállítja az intézményi átvezetési számláról a célszámlákra történő utalások megbízásának és analitikájának listáit. Amennyiben az intézményi rendszer nem tudja átvenni az analitikát(pl hálózatkiesés miatt), az EFER megpróbálja azt később újra elküldeni az intézmény felé. Ha az Intézmény olyan analitikát kap, amelyre nem jogosult, vagy nem tud beazonosítani, akkor ez a kommunikáló rendszerek valamelyikének konfigurációs hibájára utal, és a hiba felderítését és elhárítását azonnal meg kell kezdeni. Ezekben az esetekben „0” hibakódtól különböző hibakódú EFER_IPR_UTALANALITIKAVALASZ-t kell küldeni az EFER felé. Ellenőrzés üzenet szintaktikailag megfelelő
Hibakód 1
analitika azonosító egyedi
15
intézményazonosító megfelelő átvezetési számla létezik, és EFER-hez tartozó célszámla létezik, és EFER-hez tartozó tételek darabszáma és összegei helyesek devizanem = HUF
30,32 56 56 10,11 23
Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal)
97
Sikertelen üzenetátadás esetén az EFER mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
3.7.2 Adatkör leírás (EFER_IPR_UTALANALITIKA) Mező neve
Tag neve
Típus
Kötelező
40/80
FEJ egyedi analitika azonosító intézményi azonosító devizanem kedvezményezett neve esedékesség dátuma kedvezményezett intézményi bankszámlája intézményi átvezetési bankszámlaszáma TÉTEL igazgatási ügyazonosító pénzügyi ügyazonosító összeg könyvelési azonosító tranzakcio azon tranzakcio idopont LÁB tételek száma tételek összértéke
egyanalazon intazon dev kedvnev eseddatum intbankszlaszam
egyanalazon intazon dev szemelynev idopont szlaszam
Minta üzenet: <ns2:IntFogadUtalasiAnalitika xmlns:ns2="http://ws.web.efer.ind.com/"> <request> <dev>HUF <egyanalazon>UA01 <eseddatum>2010-07-02T08:32:38.000+02:00 111122223333444455556666INT01666666667777777788888888Teszt Intézmény2010-07-02T08:32:38.000+02:00INT01PR00012500INT01000PR1004200000001
3.7.3 Adatkör leírás (EFER_IPR_UTALANALITIKAVALASZ) Mező neve
Tag neve
Típus
Kötelező
egyedi analitika azonosító hibakód hibaszöveg
egyutalazon hibakod hibaszoveg
egyanalazon hibakod hibaszoveg
I I N
Minta válasz üzenet: <ws:IntFogadUtalasiAnalitikaResponse xmlns:ws="http://ws.web.efer.ind.com/"> <egyanalazon>UA01 0Rendben
41/80
3.8 TRANZAKCIÓS DÍJAK ADATAINAK ÁTADÁSA AZ INTÉZMÉNYEKNEK A folyamat rövid leírása: A tranzakciós díjak tranzakciós díj elszámoló ügyintéző által jóváhagyott analitikája és a meghatározott módszer alapján felosztott, intézményt terhelő tranzakciós díj analitikáját a csatlakozó intézmények számára biztosítja az EFER. Ennek célja, hogy az intézmények az általuk fizetendő tranzakciós díjat ellenőrizni (kiszámlázott értékkel összehasonlítani) tudják. Típus: szinkron Időkorlát: 300 másodperc Indító üzenet: EFER_INT_DIJANALITIKA Válasz üzenet: EFER_INT_DIJANALITIKAVALASZ Ismétlés: 10 perc
3.8.1 Folyamat leírása A tranzakciós díjak tranzakciós díj elszámoló ügyintéző által jóváhagyott analitikája és a meghatározott módszer alapján felosztott, intézményt terhelő tranzakciós díj analitikáját a csatlakozó intézmények számára biztosítja az EFER. Ennek célja, hogy az intézmények az általuk fizetendő tranzakciós díjat ellenőrizni (kiszámlázott értékkel összehasonlítani) tudják. Amennyiben az intézményi rendszer nem tudja átvenni a fizetési igérvényt (pl hálózatkiesés miatt), az EFER megpróbálja azt később újra elküldeni az intézmény felé. Ha az Intézmény olyan analitikát kap, amelyre nem jogosult, vagy nem tud beazonosítani, akkor ez a kommunikáló rendszerek valamelyikének konfigurációs hibájára utal, és a hiba felderítését és elhárítását azonnal meg kell kezdeni. Ezekben az esetekben „0” hibakódtól különböző hibakódú EFER_INT_DIJANALITIKAVALASZ-t kell küldeni az EFER felé.
Ellenőrzés üzenet szintaktikailag megfelelő analitika azonosító egyedi intézményazonosító megfelelő átvezetési számla létezik, és EFER-hez tartozó tételek darabszáma és összegei helyesek devizanem = HUF Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal)
Hibakód 1 15 30 56 10,11 23 97
42/80
Sikertelen üzenetátadás esetén az EFER mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
3.8.2 Adatkör leírás (EFER_INT_DIJANALITIKA) Mező neve FEJ egyedi anal. azonosító intézményi azonosító fizetési megoldás devizanem elszámolási időszak kezdete vége intézményi átvezetési bankszámlaszáma FMSZ azon PMISZK számla sorszáma TÉTEL pénzügyi ügyazonosító FMSZ tranzakció azonosító FMSZ tranzakciós díj összeg LÁB tételek száma tételek összértéke
3.8.3 Adatkör leírás (EFER_INT_DIJANALITIKAVALASZ) Mező neve
Tag neve
Típus
Kötelező
egyedi anal. azonosító hibakód hibaszöveg
egyanalazon hibakód hibaszoveg
egyanalazon hibakód hibaszoveg
I I N
43/80
Minta válasz üzenet: <ws:IntFogadDijAnalitikaResponse xmlns:ws="http://ws.web.efer.ind.com/"> <egyanalazon>BBDIJANAL001 0OK
3.9 FMSZ-EK ÉS AZOK FIZETÉSI MEGOLDÁSAINAK LEKÉRDEZÉSE EFER-TŐL (IPP_FMSZLISTAKER) A folyamat rövid leírása: Az Intézmények napi rendszerességgel lekérdezik az EFER rendszerben elérhető FMSZ-ek listáját és az azok által biztosított fizetési megoldásokat. Az ügyfél csak ezen fizetési lehetőségek közül választhat. Típus: szinkron Időkorlát: 10 másodperc Indító üzenet: IPP_FMSZLISTAKER Válasz üzenet: IPP_FMSZLISTA Ismétlés:20 másodperc
3.9.1 Folyamat leírása Az Intézmények napi rendszerességgel lekérdezik az EFER rendszerben elérhető FMSZ-ek listáját és az azok által biztosított fizetési megoldásokat. Az ügyfél csak ezen fizetési lehetőségek közül választhat. Amennyiben az intézményi rendszer nem tudja átvenni a listát (pl hálózatkiesés miatt), a kérést később újra meg kell ismételnie. Ellenőrzés intézményi és alrendszer azonosító megfelelő
Hibakód 20,30
Sikertelen üzenetátadás esetén az intézmény mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
3.9.2 Adatkör leírás (IPP_FMSZLISTAKER) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító
intazon alrszazon
intazon alrszazon
I N
44/80
Minta üzenet: <ns2:EFERatadFMSZLista xmlns:ns2="http://kfm.efer.com/"> <request> INT01PR
3.9.3 Adatkör leírás (IPP_FMSZLISTA) Mező neve FEJ intézményi azonosító alrendszer azonosító TÉTEL FMSZ azonosító FMSZ neve érvényes bankszámla szükséges mobilszám szükséges ügyfélazonosító szükséges fizetési megoldás megnevezés LÁB FMSZ-ek száma hibakód hibaszöveg
Tag neve
Típus
Kötelező
intazon alrszazon
intazon alrszazon
I N
fmszazon fmsznev ervenyes szlaszukseges telszamszuksege s ugyfazonszukseg es fizmegold fizmegoldelnevez es
fmszazon fmsznev B B B
I I I I I
B
I
fizmegold fizmegoldelnevez es
I I
tetelszam hibakód hibaszoveg
dbszam hibakód hibaszoveg
I I N
Minta válasz üzenet: <ns2:EFERatadFMSZListaResponse xmlns:ns2="http://kfm.efer.com/"> PRINT0103 <ervenyes>true OTPVPOTP VPOS11700000OTP Bank <szlaszukseges>false falsefalse <ervenyes>true OTP01OTP Netbank
45/80
11700000OTP Bank <szlaszukseges>true falsefalse <ervenyes>true BBPOSBB POS10100000Budapest Bank <szlaszukseges>false falsefalse
3.10 FIZETÉS HIBA ÁTADÁSA INTÉZMÉNY SZÁMÁRA (EFER_INT_FIZHIBA) A folyamat rövid leírása: Amennyiben az EFER eltérést észlel az intézmények által beküldött adatok és az FMSZ-től érkező analitika között, az eltérések listáját az EFER az EFER_INT_FIZHIBA üzenetben közli az intézménnyel. Az eltérésben kimutatott hibás, vagy hiányzó tételeket az intézménynek újra el kell küldenie. Típus: szinkron Időkorlát: 300 másodperc Indító üzenet: EFER_INT_FIZHIBA Válasz üzenet: EFER_INT_FIZHIBAVALASZ Ismétlés: 10 perc
3.10.1 Folyamat leírása Amennyiben az EFER eltérést észlel az intézmények által beküldött adatok és az FMSZ-től érkező analitika között, az eltérések vagy hibák listáját az EFER az EFER_HIBALISTA üzenetben közli az intézménnyel. Az eltérésben kimutatott hibás, vagy hiányzó tételeket az intézménynek újra el kell küldenie. Minden tétel rendelkezik egy típussal (ld. EFER_INT_FIZHIBA/TÉTEL/típus), amely meghatározza az adott tétel, mint eltérés értelmezését intézmény oldalon. Csak abban az esetben jelezzük a hibát az intézmény felé, ha a fizetési csatorna bankkártya. Alkalmazott névkonvenciók: Az analitikára vonatkozó adatok mindig az „A_” kezdetű mezőkbe kerülnek betöltésre, a fizetéshez tartozók pedig az „F_” kezdetűekbe. A hiba típusának lehetséges értékei:
46/80
OH - Analitika és fizetési ígérvény található, de az összeg eltér. Adott átvezetési számlára és az analitika tételben szereplő pénzügyi ügyazonosítóra találunk tételt a fizetések között, de az összegek eltérnek. Töltésre kerülnek az „A_” és az „F_” kezdetű mezők. FH - Analitikához nem található fizetési ígérvény Adott átvezetési számlára és az analitika tételben szereplő pénzügyi ügyazonosítóra nem találunk tételt a fizetések között. Töltésre kerülnek az „A” kezdetű mezők.
Amennyiben az intézményi rendszer nem tudja átvenni a listát (pl hálózatkiesés miatt), az EFER megpróbálja azt később újra elküldeni az intézmény felé. Ha az Intézmény olyan listát kap, amelyre nem jogosult, vagy nem tud beazonosítani, akkor ez a kommunikáló rendszerek valamelyikének konfigurációs hibájára utal, és a hiba felderítését és elhárítását azonnal meg kell kezdeni. Ezekben az esetekben „0” hibakódtól különböző hibakódú EFER_INT_HIBALISTAVALASZ-t kell küldeni az EFER felé. Ellenőrzés üzenet szintaktikailag megfelelő
Hibakód 1
lista azonosító egyedi intézmény és alrendszer azonosítható tételek darabszáma és összegei helyesek
15 30 10,11
átvezetési számla létezik, és EFER-hez tartozó 56 Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hiba97 kóddal) Sikertelen üzenetátadás esetén az EFER mindaddig ismétli az üzenetet, amíg az sikeresen átadásra nem kerül.
Minta válasz üzenet: <ws:IntFogadFizetesiHibaListaResponse xmlns:ws="http://ws.web.efer.ind.com/"> 100254480OK
48/80
3.11 AZ EFER AKTÍV TESZTELÉSE (EFER_AKTIV_TESZT) A folyamat rövid leírása: A szolgáltatás annak ellenőrzésére szolgál, hogy az EFER az intézmény számára rendelkezésre áll-e: képes-e hívásokat kezdeményezni felé, ill. hívásokat fogadni tőle. Ha intézményi oldalon szükséges az EFER minimális monitorozása, akkor ezzel a szolgáltatással megvalósítható. Típus: szinkron Időkorlát: 30 másodperc Indító üzenet: EFER_AKTIV_TESZT Válasz üzenet: EFER_AKTIV_TESZT_VALASZ Ismétlés: Az intézmény döntése szerint.
3.11.1 Adatkör leírás (EFER_AKTIV_TESZT) Mező neve
Tag neve
Típus
Kötelező
intézményi azonosító alrendszer azonosító
intazon alrszazon
intazon alrszazon
I N
Minta üzenet: <ns2:EFERIntAktivTeszt xmlns:ns2="http://kfm.efer.com/"> <request> INT01PR
3.11.2 Adatkör leírás (EFER_AKTIV_TESZT_VALASZ) Mező neve
Tag neve
Típus
Kötelező
KFM rendelkezésre áll-e
kfmok
B
I
Minta válasz üzenet: <ns2:EFERIntAktivTesztResponse xmlns:ns2="http://kfm.efer.com/"> true
3.12
ADATTÍPUSOK
Ebben a fejezetben az adattípusok kerülnek bemutatásra. Egy adattípus leírásánál az alábbiakra térünk ki: - Azonosító: Szöveges azonosító, ezzel hivatkozunk az adatok leírásánál a releváns típusra. - Jelentés: Az adattípus üzleti tartalma.
49/80
- Egyszerű típus: Formátuma: xyyy[.zz], ahol x az értéktartományra utal (A – alfanumerikus, N – numerikus, D – dátum, B - logikai), yyy a hossz, zz pedig valós szám esetén a tizedes rész hossza a teljes hosszból. Az adattípusok felhasználása két helyen történik meg: - az adatkörök leírásánál, - a szolgáltatások input- és output adatainak szintaktikai ellenőrzésénél. Azonosító
Jelentés
Egyszerű típus
intazon
intézményi azonosító
A8
alrszazon
alrendszer azonosító
A2
ugyfazon
ügyfél azonosító
A3
fizmegold
fizetési megoldás
A12
fizmegoldelnevezes
fizetési megoldás elnevezése
A50
penzazon
pénzügyi ügyazonosító
A23
szemelynev
személynév
A35
fmsznev
FMSZ neve
A50
kozlemeny
közlemény
A70
mobiltel
mobiltelefonszám
A15
igazgugyazon
igazgatási ügyazonosító
A30
konyvazon
könyvelési azonosító
A24
ugyleiras
ügyleírás
A24
egyutalazon
egyedi utalás azonosító
A20
egyanalazon
egyedi analitika azonosító
A20
fmszazon
FMSZ azonosító
A8
fmsztrazon
FMSZ tranzakció azonosító
A29
penzosszeg
összeg
N16.0
dbszam
darabszám
N6
dev
devizanem, meghatározott értékeket vehet csak fel: „HUF”
A3
hibakod
hibakód
N2
hibaszoveg
hibaszöveg
A256
szlaszam
számlaszám GIRO formátumban, formátuma reguláris kifejezéssel leírva: \d{8}\d{8}\d{8} A jelenleg használt hossz 24, a 3x8-as rész van benne kötőjelek nélkül. Az EFERjelenleg mindenhol pontosan 24 hosszú számlaszámokat képes kezelni, 16 hosszú számlaszámok A24(A28) esetén az utolsó 8 jegyet nullával kell feltölteni, hogy a EFER kezelni tudja. Az IBAN-nal való kompatibilitás előkészítése végett a számlaszám az adatbázis szintjén 28 hosszon van tárolva.
Szövegesen leírva: legalább egy tetszőleges karakter, amit „@” követ, utána tetszőleges számú nem pont karakter, majd pont, utána pont és az ABC kis és nagybetűi jöhetnek, ez a rész legalább 2 karakterből áll.
Ahol nem szükséges ilyen pontosságú időkezelés, ott jobbról, az ezredmásodperctől kezdődően nullákkal kell feltölteni az időpontot. Pl. a 2000. január 1. ebben a formátumban: 200001-01T00:00:00.000+02:00 Az időpontot az egységesség jegyében kezeli az EFER minden esetben ilyen pontossággal.
A29
fajl
szöveges fájl
A256*
fizhibaazon
fizetési hiba azonosító
A20
fizhibatipus
Fizetési hiba típus, értékei: FH - Analitikához nem található fizetési ígérvény, és a fizetés házi/mobilbank A2 OH - Analitika és fizetési ígérvény található, de az összeg eltér
base64string
szöveg base64-el kódolva
A*
szlasorszam
számlasorszám
A30
51/80
3.13
HIBAKÓDOK
Az alábbi hibakódok minden, EFER és külső rendszer közötti üzenetváltásra egyaránt érvényesek. Üzenet vagy kapcsolatszintű hibakódokat nem különböztetünk meg. Hibatartományok: - 1-9: mezőszintű hibák - 10-14: számszaki hibák - 15-19: egyediség hibák - 20-29: érvényesség hibák - 30-39: autorizációs hibák - 40-49: EFER üzleti hibák - 50-69: kizárólag FMSZ által detektálható hibák - 70-94: fenntartott tartomány - 95-99: egyéb hibák HIBAKÓD
HIBALEÍRÁS
0 1
sikeres válasz XSD szintaktikai hiba (egy részletesebb angol nyelvű hibaüzenettel kiegészítve, mely a hiba pontos okát tartalmazza). Szintaktikai hiba akkor van, amikor minimum egy kötelező mező értéke vagy maga a mező hiányzik, ugyanazon mező többször van megadva, ill. minimum egy mező nem felel meg a megfelelő formai előírásoknak. rossz CDV-jű vagy csak nullákból álló kezdeményező/kötelezett számlaszám a FEJben. rossz CDV-jű vagy csak nullákból álló címzett/kedvezményezett számlaszám a FEJben. rossz CDV-jű vagy csak nullákból álló számlaszám az egyik TÉTELben. érvénytelen tételszám a LÁBban érvénytelen végösszeg a LÁBban az ígérvényben szereplő összeg nem azonos a kérelemben szereplő összeggel nem egyedi entitás (Az entitás az azonosítóval korábban már sikeresen be lett küldve.) Ez a kód a fizetési kérelem beküldése esetén azt a hibaesetet hivatott jelölni, amikor az intézmény ugyanazt az azonosítót más esetnek újra kiosztja. Ilyenkor az EFER a tartalmi eltérés miatt 15-ös hibakódot határoz meg. érvénytelen intézményi azonosító a FEJben (nem létezik) érvénytelen bankszerv* a FEJ rekordban (nem létezik) érvénytelen fizetési megoldás a FEJ rekordban érvénytelen devizanem érvénytelen FMSZ azonosító inkonzisztens összeg
hivatkozott azonosító nem létezik autorizációs hiba a megadott alrendszer azonosító és intézmény azonosító nem tartozik össze az intézménykód és a címzett/kedvezményezett számlaszám nem tartozik össze vagy nem használható a megadott fizetési móddal az FMSZ és a megadott fizetési mód nem tartozik össze fizetési határidő érvénytelen / nem konzisztens az üzenettel fizetési határidő lejárt az ígérvényhez nem található fizetési kérelem dátum jövőbéli nem létező címzett/kedvezményezett számlaszám megszűnt címzett/kedvezményezett számlaszám a címzett/kedvezményezett számlaszáma nem értelmezhető (az ügyfél számlaszáma helyett a bank ügyfélforgalmi számlaszáma szerepel) fedezethiány miatti elutasítás általános elutasítás (az ügyfél megbízása alapján) címzett / számlatulajdonos számlaszáma érvénytelen ügyfél azonosító / címzett azonosító érvénytelen időtúllépés (time-out) VPOS fizetésnél A fizetés állapota nem: fizetésre átadva Eltérő fizetési megoldás a fizetési kérelemben és az ígérvényben (Csak ha VPOS van a kérelemben, vagy az ígérvényben) Elutasítás időpontja és a kérelem dátuma inkonzisztens egyéb hiba válasz idő túllépése (timeout) Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal) FMSZ válaszra vár
3.14
MINTAPROGRAM
32
33 40 41 42 43 50 51 52
54 55 56 57 58 78 79
82 95 96 97
EFER,INT EFER,INT EFER,INT
26
EFER,INT
EFER EFER EFER EFER,INT EFER FMSZ FMSZ FMSZ
FMSZ FMSZ FMSZ FMSZ FMSZ INT INT
INT Mind EFER Mind KFM
A EFER intézményi kommunikációja az elosztott alkalmazások kapcsolattartásánál használt szabványos módon valósul meg. Ez HTTPS protokollon továbbított SOAP üzenetváltásokat jelent. A szabvány leírása, mintakódok és referenciák a következő címen érhetők el: http://www.w3.org/TR/soap12-part1/
