Skip to content

Fizetés életciklus

Daniel Marek edited this page Apr 15, 2024 · 21 revisions

A webshopban vásárlók szempontjából, a fizetés ugyanúgy megy végbe, ahogyan azt a vevő hasonló megoldások használatakor már megszokta. A vásárlás befejezésekor a vevőt a webshopból átirányítják a payment gateway-hez/ fizetőoldalhoz. Itt megadja a kártyaadatait, és megerősíti fizetési szándékát. Ezt követi a hitelesítés és megtörténik a fizetés engedélyezése. A vevő tájékoztatást kap a tranzakció eredményéről, majd visszairányítják a webshop oldalára.

A színfalak mögött a vevő számára láthatatlanul, több esemény is zajlik. A háttérben folyó műveleteket a következő ábra mutatja be. Az alábbiakban ismertetjük a fizetési folyamat lépéseit, a rendszerek közötti adatátvitelt és a belső folyamatokat.

Az ábra azt mutatja, hogy a vevő fizetett. Abból az alapfeltételezésből indulunk ki, hogy a vásárlás sikeres volt, és a webshop kiszállítja a termékeket. Komplikációk esetén, ha a vevő vagy a kereskedő módosítja vagy törli az ügyletet, a következő folyamat lépésben rendelkezésre áll egy olyan felület, ahol lehetőség nyílik a fizetések kezelésére és a további fizetés törlésére.


A tranzakció életciklusa  

A fizetési tranzakciók több lépésből állnak, amelyek mindegyikét befolyásolja a kereskedő, a vevő, valamint a fizetési kártya státusza. A következő ábra bemutatja a teljes életciklust, a fizetés kezdeményezésétől a fizetés teljesüléséig, beleértve a kereskedő által kezdeményezett további lehetséges státuszokra is. A részletes leírás az ábra alatt található:

1) Fizetés kezdeményezése / Payment initiated – ez a tranzakció kezdeti státusza a payment/init fizetési mód meghívását követően. Amennyiben a payment/init sikeres, a vevőnek várnia kell, amíg átirányítják a webshop oldaláról a fizetőoldalra / payment gateway-re. Amennyiben a tranzakció kezdeményezése sikertelen, például azért, mert a vevő helytelen adatokat adott meg, vagy a kereskedő nem jogosult ilyen művelet végrehajtására, a fizetési igény 6) Fizetés visszautasítva / Payment denied fizetés elutasítva státuszúvá változik.

2) Fizetés folyamatban / Payment in progress – a státusz miután a vevő átirányításra került a payment gateway-re / fizetőoldalra. A háttérben számos fizetési lépés zajlik, ezek azonban rejtve maradnak a kereskedők előtt, mivel őket kizárólag az eredmény érdekli. Az eredmény a következő lehet:

  • 3) Fizetés törölve / Payment cancelled – a vevő a payment gateway-en / fizetőoldalon törölte a fizetést;
  • 6) Fizetés visszautasítva / Payment denied – a tranzakciót a bank visszautasította például: fedezet hiányában, a 3D biztonsági kód megerősítésének elmaradása miatt, vagy más okból a fizetési folyamat megszakadt, (például, mert a vevő bezárta a böngészőt);
  • 4) Fizetés megerősítve / Payment confirmed – sikeres fizetés, a tranzakció várakozik, amíg a kereskedő beküldi (Elszámolásra vár / Waiting for settlement státuszra állítással) az este elszámolandó tételek közé. A sikeres fizetések akkor kerülnek ilyen státuszba, ha az elszámolandó tételek közé bekerülés nem automatikus;
  • 7) Elszámolásra vár / Waiting for settlement – a fizetés megtörtént, és automatikusan bekerül az este elszámolandó tételek közé.

3) Fizetés törölve / Payment cancelled   – A tranzakció akkor kerül ebbe a státuszba, ha a vevő a fizetőoldalon a Törlés gombra kattint. A vevő automatikusan visszakerül a webshop oldalára (ahová a fizetőoldal / Payment gateway irányítja át). A tranzakció életciklusa szempontjából ez a státusz végleges. Abban az esetben, ha a vevő kártyával kíván fizetni egy ugyanolyan megrendelésért a webshopban, a webshopnak új fizetési folyamatot kell generálnia.

4) Fizetés megerősítve / Payment confirmed   – A tranzakció akkor kerül ebbe a státuszba, ha a fizetés sikeresen megtörtént, és várakozik, mert az elszámolandó tételek közé történő beküldés nem automatikus. Már a „fizetés kezdeményezése / payment initiated” lépésnél ki kell választani, hogy a sikeres fizetést követően automatikusan bekerüljön a tranzakció az elszámolási listába, annak érdekében, hogy annak összegét a K&H Pénzforgalmi szolgáltató átutalja a kereskedő számlájára, vagy a tranzakció nem kerüljön automatikusan elszámolási listára beküldésre, csak várakozik, beküldése később történik meg - ilyen eset lehet például akkor amikor a termék összekészítése folyik, vagy amíg a termékeket ki nem szállították.

A fizetés nem maradhat legfeljebb három napig ebben a státuszban (eredetileg hét nap volt beállítva, 09/2023-tól változott). Ez alatt az időszak alatt a kifizetést a K&H pénzforgalmi szolgáltató garantálja, és az összeg zárolva van a vevő kártyáján. FIGYELEM! A fent említett időszak lejáratát követően a tranzakció nem küldhető be elszámolásra! (A rendszer automatikusan feloldja az összeg zárolását a vevő kártyáján, és a K&H pénzforgalmi szolgáltató kifizetésre vonatkozó garanciája megszűnik.)

5) Fizetés visszavonva / Payment reversed – A sikeresen megtörtént fizetés mindaddig visszavonható (sztornózható), amíg az elszámolásra történő beküldés meg nem történt. Ez azt jelenti, hogy a kártyabirtokos számláját nem terheljük meg, a kártyán az összeg zárolását feloldjuk, és nem számítjuk fel a díjat a tranzakcióval kapcsolatban. Ez a státusz végleges, és nem fordítható vissza. A K&H PSz nyomon követi, hogy a kereskedő hány fizetési tranzakciót von vissza.

Mindaddig lehetőség van a fizetést visszavonni, amíg a tranzakciót nem küldik be elszámolásra, azaz ez megtörténhet a „Fizetés megerősítve / Payment confirmed” státuszú fizetések esetében is. Az „Elszámolásra vár / Waiting for settlement” státuszú fizetések az adott napon éjfélig sztornózhatók, ezt követően bekerülnek az elszámolás feldolgozás folyamatba. Az elszámolt fizetések esetén kizárólag visszatérítésre van lehetőség.

6) Fizetés visszautasítva / Payment denied   – Ezt a státuszt fentebb már ismertettük. A fizetés visszautasítására számos okból kerülhet sor, ezek megkülönböztetésről a visszatérési kódok / Operation Return Code oldalon talál részletesebb leírást. Lényegüket tekintve az okok több csoportra oszthatók:

  • A fizetés kezdeményezése hibás adatokat tartalmazott;
  • A kereskedő nem jogosult a fizetési művelet végrehajtására;
  • A vevő helytelenül erősítette meg a 3D biztonsági kódot;
  • A vevő bankja (kártyakibocsátó) nem hagyta jóvá a kártyás fizetést;
  • A vevő bezárta a böngészőt és a tranzakció időtúllépés miatt lejárt.

A fizetés bank általi megtagadása sajátos státusz. Kizárólag a Reason kód jelzi, milyen okból utasította vissza a kibocsátó bank a tranzakciót. A kereskedő szempontjából ez sikertelen fizetésnek minősül, és ez az adat kizárólag a kereskedő tájékoztatását szolgálja. A sikertelenség oka megmutatható a kártyabirtokosnak is elősegítve a további sikertelen tranzakciók elkerülését.

Amikor egy kártyás fizetés sikertelen, ez nem jelenti azt, hogy a vevő kártyás fizetési próbálkozásai kudarcra vannak ítélve. A fizetőoldal / payment gateway felajánlja a vevőnek a következő lehetőséget: fizetés másik kártyával. Ennek az a célja, hogy a webshopba való visszatérés és a fizetés sikertelensége ne tántorítsa el a vevőt vásárlási szándékától. A kereskedő szempontjából ez az „ismételt tranzakció” egész idő alatt a Fizetés folyamatban / Payment in progress státuszban van, vagyis a fizetés státusza nem változik, amíg nem ismert, hogy véglegesen sikeresnek vagy sikertelennek minősül-e.

7) Elszámolásra vár / Waiting for settlement   az ezzel a státusszal ellátott tranzakciók már elszámolási listán az elszámolásra várnak , és a K&H PSz elszámolási szabályai függvényében feldolgozásra kerülnek. Amint azt fentebb írtuk, az elszámolás megtörténtéig a tranzakció visszavonható.

8) Fizetés elszámolva / Payment settled a kereskedő szempontjából ez a kívánt végső státusz: minden lebonyolódott, a tranzakció elszámolási listában sorban állt, a K&H PS oldali elszámolás megtörtént, és az összeg úton van. Noha ez a státusz végleges, a kereskedő dönthet úgy, hogy törli a tranzakciót (például a vevő törli a megrendelést, vagy a termékeket az elévülési időn belül visszaküldik), és elindíthatja a visszatérítés / refund műveletét.

9) Visszatérítés folyamatban / Refund processing –Ebbe a státuszba kerül a tranzakció, amikor a kereskedő visszatérítés feldolgozását kéri, és a művelet folyamatban van. A visszatérítés feldolgozását a bank a kereskedőtől kapott információk alapján hagyja jóvá, és ez a státusz napokig fennállhat.

10) Fizetés visszatérítve / Payment returned – A tranzakció az életciklusa során azután kerül ebbe a szakaszba, miután a visszatérítést jóváhagyták és a tranzakció a vevő részére jóváírásra került.

A fizetési folyamat lépései  

Fizetés kezdeményezése / Payment initiation payment/init Amint a vásárlás utolsó szakasza megkezdődik a webshopban, a vevő továbblép a fizetéshez és a kártyás fizetést választja, a webshop kezdeményezi a fizetőoldalon / payment gateway-en történő fizetést. Az standard információkon túl, mint a kereskedő azonosítója, az összeg és a megrendelés referenciaszáma, a webshop a vásárlás adatait – például a kosár tartalom megnevezését – is továbbíthatja a fizetőoldalra, hogy a fizetési folyamat egyértelműbbé és átláthatóbbá váljon a kibocsátó bank részére, elősegítve a frictionless vásárlás megvalósulását. Ezzel növeli a vevő bizalmat a webshop és a fizetőoldal iránt.

Megrendelés referenciaszáma / Order reference number - ezt a számot a kereskedő webshopja rendeli a megrendeléshez. Végezetül, a megrendelés referencia számát a tranzakció kimutatás tartalmazza. A referencia szám segítségével párosíthatja a kereskedő (könyvelési) rendszere a fizetéseket a megrendelésekkel. Ezért a kód használata kötelező (legfeljebb 10 számjegyből álló számsor). A megrendelés referenciaszámát a K&H POS 24 rendszerben Variable symbol / További szöveg, kiegészítő információ néven találja.

A fizetés kezdeményezését követően a fizetőoldal minden egyes tranzakcióhoz egy payID, egyedi fizetési azonosítót rendel hozzá. Ezt az azonosítót küldjük vissza a payment/init -ra/re adott válaszban, és társítjuk a fizetési tranzakció minden státuszához.

Annak a megrendelés referenciaszámnak (variable symbol), amit a kereskedő a fizetés kezdeményezésekor a payment gateway / fizetőoldalra továbbít, egyedinek kell lennie a kereskedő webshopjában. Abban az esetben, ha a kereskedő a fizetőoldalon két azonos megrendelésszámú tranzakciót kezdeményez, a tranzakciók payID’s -jai különbözőek lesznek ugyan, azonban a banki kimutatásában két, azonos azonosítóval / variable symbol-lal jelennek meg.

Visszairányítás a fizetőoldalra / Redirecting to gateway payment/process

Ha a fizetőoldalon sikerült a fizetés kezdeményezése, a webshop az alábbi lépések megtételével irányíthatja át a vevőt a fizetőoldalra. A webshop kizárólag a fizetés egyedi azonosítóját továbbítja a linkben, mivel a fizetési művelet összes adata, a kosár tartalmával és a kereskedő azonosítójával együtt már készen áll a fizetőoldalon a fizetés-kezdeményezési lépés elvégzése óta.

Az átirányítás a fizetőoldalra műveletet akkor kell végrehajtani, ha a vevő többször vált a webshop oldala és a fizetőoldal között (például a böngésző navigációját használva). Az azonos megrendelésszámú fizetés kezdeményezése művelet nem választható a rögzített megrendelés számmal rendelkező, kezdeményezett fizetéshez; ha a fizetőoldal az adott fizetéshez egyedi payID -t rendelt hozzá, akkor egy új, duplikált megrendelésszámú fizetés jön létre.

Fizetési státusz lekérdezése/ payment status detection payment/status Ezzel a státusz lekérdező hívással a webshop rendszere mindenkor képes a fizetőoldalon végrehajtott bármely fizetés státuszának lekérdezésére. Ennek a módszernek az alkalmazásával a kereskedő tájékozódhat arról, hogy a fizetés folyamatban van-e, melyik lépésnél tart, továbbá, a fizetés befejezése után a kereskedő értesülhet a fizetés eredményéről is.

Ez opcionális művelet; és nem feltétlenül szükséges egyszerű webshop programoknál alkalmazni, ebben az esetben a webshop kivárja a vevő visszairányítását a webshop URL oldalára.


A tranzakció státusz menedzsment  

Amint azt korábban már említettük, a webshop ellenőrizheti a tranzakció státuszát annak befejezése után. A tranzakció a befejezés után 48 órán át a fizetőoldal aktív blokkjában marad. Nem okoz gondot, ha a vevő, akár tévedésből behívja a fizetőoldalt a böngészési előzményekből: ekkor a fizetőoldal megerősítő oldala töltődik be, amely tájékoztatást ad a fizetés eredményéről.

A tranzakció sikeres befejezése után a kereskedő számára további lehetőségek állnak rendelkezésére státusza kezeléséhez:

Tranzakció visszavonás / Transaction reversal payment/reverse A művelet sztornózza a sikeresen befejezett tranzakciót, és kitörli azt a rendszerből; a tranzakció meg nem történt lesz, és a kártyán zárolt összeg feloldásra kerül. Ez a módszer kizárólag el nem számolt tranzakciók esetén használható. Fontos tudnivaló, hogy amennyiben a műveletet olyan fizetésre alkalmazzák, amely a 7) Elszámolásra vár / Waiting for settlement státuszban van, és a elképzelhető, hogy a tranzakció elszámolása már folyamatban van – úgy a művelet - hibát jelez vissza, és a tranzakció elszámolása megtörténik.

A tranzakció elszámolási listára felvéve / Putting transaction in the queue for settlement payment/close A művelet csak akkor alkalmazható, ha a tranzakció elszámolási listába történő felvétel nem történik meg automatikusan (ez az opció a fizetés-kezdeményezési lépés végrehajtása alatt inaktív). A funkció beemeli a tranzakciót a listába az elszámoláshoz; ez például összeköthető a webshop termékeinek kiszállításával.

Visszatérítési kérés / Refund request payment/refund A művelet alkalmazására akkor kerül sor, ha a vevő részére pénzt kell visszatéríteni. Erre a leggyakoribb példák: reklamáció, a megrendelés törlése vagy elállás a webshopban való vásárlástól az elévülési időn belül. A payment gateway támogatásával lehetőség van az eredeti tranzakció összegénél alacsonyabb – részösszeg – összeg visszatérítésére. A funkció akkor a leghasznosabb, amikor a vevő több megvásárolt termék közül csak egyetlen tétel árának visszatérítését kéri.

Részletes státusz adatok  

A tranzakció státuszának részletes adatai révén a webshop részletesebb információt kaphat a tranzakció feldolgozásának előrehaladásáról vagy státuszáról. A részletes státuszadatok megtekintése kiegészítő funkció, és használata opcionális. A fizetőoldalon végrehajtott tranzakciók kezeléséhez nem szükséges a részletes státuszadatok ismerete. (Alapesetben) elegendő a tranzakció életciklusának alapállapotaival foglalkozni. A fizetőoldal megadja a státusz részleteit a webshop által adott válaszban, amely tartalmazza a tranzakció feldolgozás státuszát (azaz válaszul a payment/status-ra/re).

Részletes státusz adatok használata  

A webshop a részletes státusz adatokat arra használhatja, hogy jobb betekintést nyerjen a tranzakció feldolgozásának előrehaladásáról vagy státuszáról. A mikro-státusz fontossága és üzleti értéke attól a fő státuszkategóriától függ, amelyben a tranzakció található.

** A 2. számú státusz részletes státusz adatai (fizetés folyamatban / payment in progress)** arról nyújtanak tájékoztatást, mit csinál a vevő a fizetőoldalon, pontosabban arról, hogy a vevő a fizetési folyamat melyik lépésénél tart éppen. A közvetlenül a webshopba integrált fizetési módozatok esetén (Apple Pay, Google Pay, OneClick fizetés), ez az információ a szolgáltatóval kapcsolatos – és általában igen korlátozott mértékű. Sokkal értékesebb információ áll rendelkezésre, ha a kártyás fizetést maga a fizetőoldal / payment gateway dolgozza föl.

A 3. számú státusz részletes státuszadatai (fizetés törlölve / Payment cancelled) a fizetés törlésének módjáról szolgáltatnak információt, vagy (ha van rá lehetőség) tájékoztatják a webshopot arról, hogy a vevő megkísérelte-e a fizetést.

A 6. számú státusz részletes státuszadatai (fizetés elutasítva – Payment declined) a fizetés elutasításának vagy lejáratának okáról szolgáltatnak információt.

A 10. számú státusz részletes státuszadatai (fizetés visszatérítve / Payment returned) lehetővé teszik a teljes összegű visszatérítés (az adott tranzakciónál további visszatérítés rögzítése már nem lehetséges) és a részösszeg-visszatérítés (az eredetileg engedélyezett összeg erejéig további visszatérítésekre van lehetőség) közti különbségtételt.

Clone this wiki locally