Sikertelen online bankkártyás fizetés: kereskedői vizsgálati sorrend

Keresd meg a rendelést és minden próbálkozását

Kérj biztonságos rendelési referenciát, és nézd meg az időpontot, összeget, pénznemet. Ne kérj teljes kártyaszámot vagy hitelesítési titkot. A rendeléshez több próbálkozás is kapcsolódhat, ezért ne állj meg az első sikertelen sornál. Lehetséges, hogy egy másik próbálkozás már igazoltan befejeződött, vagy még ellenőrzésre vár.

Egy időpontfoglalásnál az ügyfél például frissíthette az oldalt, majd ismét megnyomhatta a gombot. A két próbálkozás nem jelent két foglalási szándékot. Őrizd meg a kapcsolatot a rendelés és az egyes szolgáltatói referenciák között. Ez segít elkerülni, hogy a támogatás egy régi hibát értelmezzen a teljes rendelés aktuális eredményeként.

Kereskedői felület

Különítsd el az elutasítást és az ismeretlen eredményt

Ha a szolgáltató igazolt elutasítást ad, azt a megfelelő, biztonságos tájékoztatás szerint kezeld. Ha viszont a kérés válasza nem érkezett meg, az eredmény lehet ismeretlen. Egy időtúllépés nem bizonyítja, hogy a külső rendszer nem fogadta el a műveletet. Előbb ellenőrizd a meglévő próbálkozást, mintsem újabb fizetésre kérnéd az ügyfelet.

Az ügyfélnek világos különbséget kell látnia a vizsgálat és a végleges eredmény között. Ne találj ki konkrét elutasítási okot, ha a rendszer nem szolgáltat ilyet. Ne ígérj biztos elfogadást egy újabb próbálkozásra. A támogatás feladata ilyenkor a helyes információ és következő lépés közlése, nem a szolgáltatói döntés magyarázatának találgatása.

Fizetési webhookok

Ellenőrizd a hiteles visszajelzés útját

A Stripe fizetési és webhook-dokumentációja bemutatja az aszinkron eredmények szerepét. A böngésző visszatérése elmaradhat, miközben a szerver később megerősítést kap. Vizsgáld meg, megérkezett-e a megfelelő esemény, sikeres volt-e a forrás ellenőrzése, és a rendszer helyesen társította-e a rendeléshez.

Az OrsunPay saját HMAC-alapú értesítései nem azonosak a közvetlen szolgáltatói üzenetek protokolljával. A megfelelő ellenőrzési szabályokat kell használni. Egy fogadott esemény nem feltétlenül alkalmazott esemény: adatbázis- vagy feldolgozási hiba közbejöhet. A belső napló külön mutassa a beérkezést, az állapotváltozást és a rendelés végrehajtását, hogy a támogatás a megfelelő hibát továbbítsa.

Vizsgáld külön a teljesítési hibát

A sikeres fizetés mellett elakadhat a hozzáférés létrehozása, az időpontfoglalás vagy az értesítő levél. Ilyenkor a kereskedelmi feladatot kell helyreállítani. Ne változtasd a pénzügyi eredményt sikertelenre csak azért, mert az ügyfél még nem kapta meg a szolgáltatást. A két állapot külön kezelése megakadályozza a felesleges újrafizetési kérést.

Például egy tanfolyam hozzáférési szolgáltatása átmenetileg nem válaszolhat. Ha a fizetés igazolt, a feladat újraindítható a meglévő rendeléshez. A visszaállítást végző kolléga ellenőrizze, hogy a hozzáférés közben nem jött-e már létre. A helyreállításnak is egyszeri, követhető eredménye legyen, ne ismételt teljesítéseket generáló kézi gombnyomások sorozata.

Dokumentáld a vizsgálatot és a kommunikációt

Rögzítsd a referenciát, az ellenőrzött forrást, a megállapított állapotot és a következő felelőst. A másik műszaknak ebből kell folytatnia az ügyet. A teljes szolgáltatói válasz másolása helyett biztonságos és szükséges adatokat tárolj. A hozzáférés feleljen meg a munkatárs feladatának, és legyen visszakereshető a módosítás szerzője.

• Ellenőrizd az összes kapcsolódó próbálkozást új fizetés kérése előtt.
• Válaszd külön az elutasítást, az ismeretlen állapotot és a teljesítési hibát.
• Ne kérj kártyatitkot vagy jóváhagyási kódot üzenetben.
• Minden nyitott esethez rendelj következő lépést és felelőst.

A visszatérő okokat a folyamatban javítsd

Hetente tekintsd át, mely problémák ismétlődnek. Sok hiányzó visszajelzés technikai hibára utalhat, míg a nehezen kereshető referenciák a rendelési nyilvántartás hiányosságát mutathatják. A kategóriák célja nem az ügyfelek minősítése, hanem a kereskedői működés javítása. Csak olyan okot állíts, amelyet az ellenőrzött adatok ténylegesen alátámasztanak.

Az OrsunPay szoftverréteg, külön díjjal; a kereskedő megtartja saját szolgáltatói szerződéseit és fiókjait. Ne ígérj automatikus szolgáltatóváltást vagy biztos elfogadást a jelenlegi rendszerben. A jó támogatási folyamat a bizonyított állapotból indul, világosan jelzi a bizonytalanságot és a megfelelő munkát állítja helyre, ahelyett hogy minden hibajelzésre új fizetést kérne.

Források

• Stripe — Fizetések
• Stripe — Webhook-értesítések