Fizetési webhook: aláírás, ismételt esemény és rendelési állapot

Rendelj minden eseményhez konkrét döntést

Határozd meg, milyen belső objektumot és milyen megengedett állapotváltozást jelent az esemény. A rendelés, a fizetési próbálkozás és a szolgáltatás teljesítése külön fogalom. Kapcsold a külső referenciát a belső rekordhoz, és ellenőrizd a fiókot, az összeget és a pénznemet, mielőtt a visszajelzést a rendelés pénzügyi eredményeként elfogadod.

Egy online képzésnél a sikeres fizetés elindíthatja a hozzáférés létrehozását. Ha a hozzáférési szolgáltatás nem válaszol, az nem teszi szükségessé a fizetés megismétlését. A rendszernek meg kell őriznie a pénzügyi eredményt és külön követnie a hátralévő teljesítést. Így a támogatás a megfelelő munkát állítja helyre, és nem kér új összeget egy már rendezett vásárlásért.

Fizetési webhookok

A forrás saját protokollját ellenőrizd

A Stripe hivatalos webhook-dokumentációja meghatározza a saját üzeneteinek ellenőrzését, beleértve a kérés törzsére vonatkozó követelményeket. Az Adyen külön szabályokat dokumentál. Ne használd ugyanazt az ellenőrzőt eltérő forrásokra pusztán azért, mert hasonló mezőket látsz. Az OrsunPay saját HMAC-aláírású webhook-protokollja sem azonos a közvetlen szolgáltatói formátumokkal.

A teszt- és éles konfigurációk maradjanak külön. Az ellenőrzési titok ne kerüljön a böngészőbe, nyilvános kódba vagy általános naplóba. Egy hihető szerkezetű üzenet az ellenőrzés előtt nem hiteles. Az elutasítást biztonságosan dokumentáld, anélkül hogy a teljes érzékeny tartalmat automatikusan több megfigyelőrendszerbe másolnád. A hibakereséshez használt adat mennyisége igazodjon a tényleges feladathoz.

Fejlesztői eszközök

Tartósan rögzíts a hosszú feladatok előtt

Validálás után hozz létre helyreállítható fogadási rekordot, és külön ütemezd a hosszabb kereskedelmi feladatokat. Egy dokumentum előállítása vagy több email küldése ne veszélyeztesse az eredeti megerősítés megőrzését. A sikeres fogadási válasz tényleges elfogadást jelentsen, ne fedjen el adatbázishibát, amely után az üzenet csak egy folyamat memóriájában létezett.

Különböztesd meg a beérkezett, alkalmazott és végrehajtott állapotokat. Egy esemény már biztonságosan tárolható, miközben a kapcsolódó feladat még várakozik. A referencia, forrás és időpont segít megállapítani a hibás lépést. Személyes adatot csak indokoltan tárolj, és ne tekintsd az összes tartalom korlátlan másolását az áttekinthető üzemeltetés szükséges feltételének vagy alapértelmezett megoldásának.

Védd a hatást az ismétléstől

Az ismételt kézbesítés normális integrációs helyzet. Tárold a feldolgozott események azonosítóját, és védd az állapotváltozást párhuzamos végrehajtás ellen. Két folyamat egyszerre is arra juthat, hogy az üzenet új. A szerver memóriájában végzett egyszerű ellenőrzés ezért nem elegendő; a konzisztenciát a közösen használt tárolásban is biztosítani kell.

A késői eseményeket is kezeld. Az utoljára megérkezett üzenet nem feltétlenül a legfrissebb szolgáltatói állapotot írja le. Egy régi jelzés ne írjon felül ellenőrizetlenül végleges eredményt. Ellentmondásnál kérdezd le a megfelelő hiteles objektumot vagy jelölj ki kivizsgálást. Őrizd meg a döntést magyarázó történetet, ne cseréld le nyomtalanul minden új üzenetnél a korábbi információt.

A helyreállítást is teszteld

Minden próbánál vizsgáld a rendelés állapotát és a létrejött kereskedelmi hatások számát. Egy megfelelő HTTP-válasz nem bizonyítja, hogy nem keletkezett két hozzáférés. Szakítsd meg a feldolgozást a mentés után, és ellenőrizd, hogy a folytatás nem indít új fizetést vagy ismételt teljesítést. A teszt eredményét üzleti állapotként is írd le.

• Hibás aláírás ne módosítson rendelést vagy fizetési állapotot.
• Ugyanaz az esemény csak egy végleges hatást eredményezzen.
• Külső függőség hibája után csak a hiányzó munka induljon újra.
• Régi esemény érkezése ne törölje az igazolt eredményt.

Jelölj ki felelőst a nyitott eseményekhez

A befejezetlen események vagy feladatok listája tartalmazzon okot, következő lépést és felelőst. Az ügyfélszolgálat belső referencia alapján kereshessen, ne kérjen titkos adatokat a vásárlótól. Dokumentáld, ki indíthat újra egy feladatot, és hogyan ellenőrzi előtte, hogy a kívánt hatás közben nem valósult-e már meg másik úton.

Az OrsunPay kézbesítési újrapróbálkozásai korlátozottak, ezért hosszabb kimaradás után egyeztetés és szabályozott helyreállítás lehet szükséges. Ne feltételezz végtelen ismétlést. A cél egy hiteles visszaigazolástól a teljesített rendelésig vezető, magyarázható kapcsolat. Ennek akkor is követhetőnek kell maradnia, ha közben valamelyik munkafázist kézzel indították újra, vagy a hálózat csak később tette lehetővé az eredmény feldolgozását.

Források

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