Mokėjimo pranešimas: kaip patikrinti webhook ir išvengti dvigubo poveikio

Mokėjimo pranešimas perduoda rezultatą iš paslaugų teikėjo į jūsų sistemą. Tačiau gauta HTTP užklausa dar nėra patikimas įrodymas. Reikia patikrinti jos autentiškumą, susieti ją su tinkamu užsakymu ir saugiai pritaikyti rezultatą, net jei tas pats įvykis atkeliauja kelis kartus arba ne ta tvarka, kurios tikėjotės.

OrsunPay komandaPaskelbta
Straipsnio iliustracija: Mokėjimo pranešimas: kaip patikrinti webhook ir išvengti dvigubo poveikio

Žinokite, ką tiksliai tikrinate

Vadovaukitės konkretaus teikėjo dokumentacija. Jei parašo tikrinimui naudojamas originalus užklausos turinys, jo pakeitimas ar pakartotinis JSON formavimas gali sugadinti patikrą. Duomenų apdorojimo grandinėje numatykite vietą, kur tikrinimui reikalingi originalūs baitai dar nebuvo pakeisti.

Tai nereiškia, kad visą turinį ir parašo antraštes reikia rašyti į bendrus žurnalus. Juose gali būti jautri informacija. Diagnostikai paprastai naudingesni saugūs įvykio ir užsakymo identifikatoriai, klaidos klasė ir aiški apdorojimo būsena, o ne pilnas išorinis pranešimas.

Mokėjimų pranešimai

Naudokite tinkamos paskyros konfigūraciją

Slaptas webhook raktas turi priklausyti teisingai aplinkai ir gavimo adresui. Bandomoji ir reali konfigūracija neturi būti sumaišytos. Jei palaikote kelias prekybininkų jungtis, iš anksto apibrėžkite, kaip parenkama tinkama patikros konfigūracija, neatskleidžiant jos viešai.

Trūkstamas raktas ir neteisingas parašas nėra tas pats gedimas. Pirmą problemą gali išspręsti operatorius, antras atvejis gali reikšti galutinai nepriimtiną pranešimą. Sistemos atsakas ir pakartojimo taisyklė turi atspindėti šį skirtumą, kad nebūtų prarastas pataisomas įvykis.

Įrankiai programuotojams

Susiekite įvykį su mokėjimo bandymu

Po parašo patikros suraskite atitinkamą mokėjimą pagal patikimą teikėjo nuorodą. Patikrinkite prekybininką, sumą, valiutą ir tikėtiną operacijos tipą. Net autentiškas pranešimas neturi keisti svetimo užsakymo vien todėl, kad jame nurodytas panašus tekstinis numeris.

Nežinomą nuorodą perduokite apibrėžtam peržiūros procesui. Automatiškai priskirti ją pirmai panašiai porai pavojinga. Komanda turi matyti, kodėl įvykis nebuvo pritaikytas, tačiau klaidos įraše nereikia skelbti klientų duomenų ar visos mokėjimo užklausos.

Pakartojimą laikykite įprasta situacija

Teikėjas gali pakartoti pranešimą, jei negavo tinkamo atsakymo. Jūsų sistema turi atpažinti jau pritaikytą rezultatą. Vienas mokėjimas neturi du kartus papildyti kredito likučio, išsiųsti prekės arba sukurti bilieto. Apsauga turi veikti ir kelioms serverio instancijoms vienu metu.

Pavyzdžiui, pirmas procesas įrašo mokėjimo sėkmę, bet nutrūksta prieš atsakydamas. Pakartotas įvykis turi užbaigti trūkstamą saugų veiksmą arba grąžinti žinomą rezultatą. Jis neturi pradėti viso užsakymo vykdymo iš naujo, ignoruodamas jau atliktus pakeitimus.

Atsakymą susiekite su patvariu priėmimu

Sėkmingas HTTP atsakas turi reikšti aiškiai apibrėžtą rezultatą: įvykis apdorotas arba patikimai išsaugotas patvariam pristatymui pagal jūsų architektūrą. Jei vidinė paslauga neveikia ir įvykis niekur neišsaugotas, automatinis patvirtinimas gali prarasti mokėjimo informaciją.

Numatykite laikinas klaidas, galutinius atmetimus ir operatoriaus pakartojimo procesą. Pakartojimai turi turėti ribas ir stebėjimą. Išsekus leistinam laikui įvykis neturi tyliai dingti: reikalinga aiški eilė su saugia priežastimi ir atsakingu žmogumi.

Patikrinkite tikrą verslo poveikį

Bandymas baigiasi ne tada, kai adresas grąžina kodą, o tada, kai teisingai pasikeičia užsakymas. Pakartokite tą patį įvykį ir palyginkite balansą, išsiųstų prekių ar suteiktų teisių skaičių. Išbandykite neteisingą parašą, vėlavimą ir laikiną vidinės paslaugos gedimą.

OrsunPay gaunami teikėjų pranešimai ir jūsų verslui siunčiami webhook yra skirtingos kryptys. Naudokite atitinkamą dabartinę dokumentaciją, o ne vienos pusės raktą kitai pusei. Prieš paleidimą užrašykite, kas stebi nepavykusius pristatymus ir kaip saugiai atnaujina konfigūraciją neskelbdamas slaptų reikšmių.

Kontrolinis scenarijus: pirmas įvykis patvirtina mokėjimą, antras yra identiška jo kopija, o trečias pateikia neteisingą parašą. Užsakymas turi būti įvykdytas vieną kartą. Diagnostikos įraše turi būti atskiri saugūs rezultatai kiekvienam pristatymui. Patikrinkite ne tik HTTP kodus, bet ir galutinį suteiktų kreditų, prekių ar teisių skaičių bei operatoriui matomą istoriją.

Susiję produktai

Susisiekite

Šaltiniai

Susiję straipsniai