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.

Ž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.
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.
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

Mokėjimo nuoroda verslui: nuo užsakymo iki patvirtinto mokėjimo
Kaip naudoti mokėjimo nuorodą versle, patikrinti sumą ir valiutą bei susieti mokėjimo būseną su užsakymo vykdymu.
Skaityti straipsnį
Mokėjimų apskaita: kasdienė ataskaita, kuri padeda rasti skirtumus
Mokėjimų apskaita: kasdienė ataskaita, kuri padeda rasti skirtumus. Praktiniai pavyzdžiai, patikros ir aiškios paslaugų ribos prekybininkams.
Skaityti straipsnį
Paysera alternatyva verslui: ką palyginti prieš keičiant integraciją
Paysera alternatyva verslui: ką palyginti prieš keičiant integraciją. Praktiniai pavyzdžiai, patikros ir aiškios paslaugų ribos prekybininkams.
Skaityti straipsnį