Makse webhook: usaldusväärne teavitus tellimussüsteemile

Lepi kokku sündmuse tähendus

Alusta sündmustest, millel on ettevõtte tegevusele selge mõju. Makse loomine, kliendi suunamine kassasse ja lõplik maksekinnitus kirjeldavad erinevaid hetki. Kui kõiki neid käsitleda tasumisena, võib tellimus minna täitmisele liiga vara. Koosta vastavustabel teenuse sündmuste ja oma tellimuse olekute vahel.

Näiteks digitaalse teenuse juurdepääsu avamine võib vajada kinnitatud makset, kuid pooleli oleva makse korral saadetakse ainult ooteinfo. Määra ka sündmused, mis on pelgalt informatiivsed. Iga teavitus ei pea tekitama kliendikirja või laotööd. Selge eristus vähendab kõrvalmõjusid ja teeb hilisema vea uurimise märksa lihtsamaks.

Allkirjastatud makseteavitused

Kontrolli allkirja enne töötlemist

Vastuvõtja peab järgima just selle teenuse allkirjastamise juhiseid, kust teavitus tuleb. Stripe webhooki kontrollimise näidet ei saa automaatselt kasutada OrsunPay teavituse jaoks. Erineda võivad päised, sõnumi kuju ja kontrollimise tingimused. Vajalik saladus kuulub serverisse, mitte avalikku JavaScripti.

Säilita päringu keha kontrollimiseks sellisel kujul, nagu dokumentatsioon nõuab. Kui vahesüsteem seda enne kontrolli muudab, võib korrektne allkiri näida vigasena. Ebaõnnestunud kontrolli korral ära muuda tellimuse olekut. Logi tehniliseks uurimiseks piisav viide ja põhjus, kuid ära kopeeri kogu makseandmestikku igasse rakenduse logisse.

Arendustööriistad

Muuda kordused ohutuks

Teavitused võivad saabuda mitu korda, näiteks pärast võrguvea tõttu kadunud vastust. See on integratsiooni normaalne olukord, mitte tingimata rünnak või teenuse rike. Salvestatud sündmuse identifikaator ja kontrollitud olekumuutus aitavad vältida sama töö kordamist.

Ära piirdu ainult meeles peetud identifikaatoriga rakenduse mälus, sest taaskäivitus kustutab selle. Kasuta püsivat andmehoidlat ning korralda maksekinnituse ja tellimuse uuendamine kooskõlas. Kaks samaaegselt saabuvat sündmust ei tohi tekitada kahte saadetist. Kui eraldi tööjärjekord saadab e-kirju, vajab ka see enda korduskaitset.

Eralda vastuvõtmine pikast tööst

Webhooki vastuvõtja ei peaks ootama kõigi aeglaste kõrvaltegevuste lõpetamist. Arve loomine, kolmanda süsteemi uuendamine ja mitme kirja saatmine võivad võtta kaua. Mõistlik lahendus kontrollib teavitust, salvestab vajaliku töö ning jätkab seda juhitavas järjekorras vastavalt integratsiooni lepingule.

Edukas vastus peab siiski tähendama midagi kindlat. Kui teavitus kinnitatakse enne turvalist salvestamist ja server kohe seiskub, võib sündmus kaduda. Määra, millisel hetkel loetakse vastuvõtmine õnnestunuks. Ajutise tõrke korral peab korduskatsete loogika olema teada nii saatjale kui ka vastuvõtjale, ilma lõputu ja jälgimatu kordamiseta.

Valmista ette uurimine ja taastamine

Klienditugi vajab tellimuse viidet, makse viidet ja viimast teadaolevat olekut. Arendaja vajab lisaks sündmuse vastuvõtmise aega ning töötlemise tulemust. Need andmed võimaldavad eristada olukorda, kus teavitust ei tulnud, olukorrast, kus see saabus, kuid sisemine töö ebaõnnestus.

OrsunPay pakub allkirjastatud webhooke ja teavituste tööga seotud nähtavust, kuid see ei asenda ettevõtte enda tellimuste kontrolli. Enne käsitsi uuesti töötlemist kontrolli praegust makseolekut ning varasemaid kõrvaltegevusi. Taastamine peab olema auditeeritav: kes käivitas töö, millise sündmuse alusel ja millise tulemusega.

Testi järjekorda ja ajastust

Katseta sama sündmuse kordamist, vale allkirja, ajutist andmebaasiviga ja teavituse saabumist pärast kliendi lahkumist. Kontrolli ka juhtumit, kus sündmus jõuab kohale enne, kui brauseri maksevastus on töödeldud. Süsteem ei tohiks eeldada, et kõik kanalid töötavad alati ühes järjekorras.

Ära kasuta päris kliendi teavet näidispäringutes. Loo kontrollitud tellimused ning dokumenteeri oodatav olek pärast iga katset. Kui teenuse versioon või sündmuse kuju muutub, vaata vastavustabel uuesti üle. Integratsiooni kvaliteet ilmneb kõige paremini tõrkeolukorras, kus sama makse peab jääma üheks makseks ja sama tellimus üheks tellimuseks.

Harjuta ühte taastamisjuhtumit

Valige kontrollitud keskkonnas tellimus, mille teavitus salvestatakse edukalt, kuid järgnev sisemine töö peatatakse teadlikult. Laske teisel töötajal leida juhtum jälgimisvaatest ja selgitada, kas makse ise vajab uut katset. Õige vastus võib olla, et makse on juba kinnitatud ning taastada tuleb ainult tellimuse uuendamine. Käivitage seejärel sama sündmuse töötlemine uuesti ja kontrollige, et tulemus tekib ühe korra. Selline harjutus näitab, kas tehniline ajalugu on inimese jaoks arusaadav. Kui taastamine nõuab andmebaasis käsitsi oletuste tegemist, täiendage juhist või tööriistu enne laiemat kasutust. Salvestage harjutuse tulemus ilma päris kliendiandmeteta ning leppige kokku, kes vastutab sama protsessi eest siis, kui juhtum tekib tootmiskeskkonnas päriselt.

Allikad

• Stripe Webhooks
• Stripe API: idempotent requests