Javaslat (V3)

  1. Bevezetés

    Az itt olvasható szabványverzió javaslat a V2-es javaslat hátrányainak kiküszöbölésére, annak továbbfejlesztésével jött létre. A javasolt megoldás JSON alapú, könnyen bővíthető és támogatja a deeplink technológiát, valamint két plusz biztonsági megoldást is. A szabvány működésének demonstrációjára elkészültek nyílt forráskódú "proof of concept" applikációk, melyek a döntéshozóknak, valamint későbbiekben a banki szoftverek fejlesztőinek nyújtanak segítséget:

  2. Előnyök
    • A JSON adatstruktúra az IETF által RFC 8259 néven szabványosított formátum, mely egyszerű, mind gépi, mind emberi feldolgozásra kifejezetten alkalmas.
    • Könnyen bővíthető, akár új szabványverzió kiadása nélkül is.
    • JSON séma segítségével lehetőség van a szabványos adatformátum gépi validációjára, az adatmezők mind gépi, mind emberi értelmezését támogató meta-információk közzétételére.
    • Támogatja a deeplink technológiát, ezáltal változatos fizetési helyzetekben és módszerekkel (QR kód / link) alkalmazható.
    • Összetett objektumok alkalmazásával struktúrálja az összetartozó adatokat. Ez előnyt jelent a validáció során, amire jó példa az összeg mező, ahol az érték és a pénznem együtt értelmes, külön-külön nincs értelme megadni.
    • Egybetűs adatmező kulcsok alkalmazásával az adatmennyiség lényegesen csökkentett, ez könnyebb beolvashatóságot eredményez QR kódok esetében.
    • A szabvány javaslat két kiegészítő adatmezőjének segítségével további biztonsági ellenőrzésekre alkalmas:
      • A Repeatability (M/R) metaadat mezővel jelezhető, amennyiben egy fizetési kérelem csak egyszeri kifizetésre szolgál, például eladóhelyi (POS) értékesítés esetén. A mező ellenőrzésével, valamint a korábbi utalások figyelembe vételével a banki szoftverben megoldható a kérelem elutasítása "Már fizetve" hibával.
      • A Domain (R/d) kedvezményezetti mezővel megadható egy gyökér domain (pl. nav.gov.hu), melyel előre meghatározott elérési úton keresztül (pl. https://nav.gov.hu/afr/<IBAN>) lekérdezhető a kedvezményezett neve egy hitelesítő szervezet szerveréről (példánk esetében a NAV-tól) az IBAN alapján. Ennek segítségével a banki szoftver négy státuszt tud egy fizetési kérelemhez feltüntetni:
        • "Sablon-validált kedvezményezett (megbízható)" - az IBAN szerepel az utaló fél utalási sablonjai között
        • "Domain-validált kedvezményezett (megbízható)" - az IBAN segítségével lekérdezett kedvezményezett neve megegyezik a fizetési kérelemben szereplő névvel (itt érdemes feltüntetni a lekérdezés során használt domain nevet)
        • "Domain validáció sikertelen (elutasítva)" - az IBAN segítségével lekérdezett kedvezményezett nem egyezik a kérelmen szereplő névvel (utalás letiltása)
        • "Nem validált számlaszám (nem megbízható)" - az IBAN nem szerepel a sablonok között, és domain-t sem tartalmaz a kérelem (ilyenkor figyelmeztetést követően az utalás indítható)
  3. Hátrányok
    • Nem hasonlít az EPC szabványra, ez azonban nem igazán releváns, mivel a módosítások és bővítések miatt már az aktuális szabvány (V1) sem kompatibilis vele.
  4. Szabvány leírása

    A szabványos fizetési kérelem egy URL-t tartalmaz az alábbi szegmensekkel:

    • URI séma (https://)
    • az MNB kezelésében lévő, központi domain név, mely lehet az MNB gyökér domain neve (mnb.hu), vagy ha ez technikailag nem megoldható, akkor egy tetszőleges, egybetűs subdomain, pl. q.mnb.hu
    • a szabvány verziókódja (v3)
    • a JSON sémának megfelelő JSON adatstruktúra (sortörésmentes) Base64 enkódolással

    Példa: https://q.mnb.hu/v3/<base64>

    A Base64 enkódolás során használandó karakterkészlet: UTF-8

  5. Minta
Státusz | Minta QR kód | Instascan | MNB Útmutató | Szabványleírás