-
Notifications
You must be signed in to change notification settings - Fork 0
Fizetés életciklus
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 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.
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.
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.
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).
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.
- Fizetés életciklus
- Integráció és biztonság
- Éles környezet aktiválása
- Teszt kártyák és hitelesítési adatok
- API Integration
- Request Signing and Response Signature Validation
- API Methods Overview
- Basic Methods
- Methods for OneClick Payment
- Methods for Apple Pay
- Methods for Google Pay
- Purchase metadata