Mokėjimų API: saugus pakartojimas ir neaiškaus rezultato valdymas

Atskirai identifikuokite užsakymą ir bandymą

Užsakymas aprašo verslo pardavimą, o mokėjimo bandymas yra konkretus veiksmas paslaugų teikėjo sistemoje. Vienas užsakymas gali turėti kelis bandymus, bet jų istorija neturi susilieti. Saugokite sumą, valiutą, bandymo identifikatorių ir gautą teikėjo nuorodą patikimame serverio įraše.

Pavyzdžiui, pirmas bandymas buvo aiškiai atmestas, o klientas pasirinko kitą metodą. Tai skiriasi nuo pirmo bandymo, kurio rezultatas nežinomas. Naujos operacijos leidimo taisyklė turi atsižvelgti į šį skirtumą, o ne vien į tai, kad klientas dar kartą paspaudė mygtuką.

Įrankiai programuotojams

Apibrėžkite idempotentinės užklausos ribas

Tas pats verslo veiksmas turi turėti stabilų pakartojimo raktą. Jei kiekvienam tinklo bandymui sukuriamas naujas raktas, apsauga gali nepadėti. Užfiksuokite, kokiam veiksmui jis priklauso, kiek laiko galioja ir kokį rezultatą klientas gauna pakartojęs užklausą.

Raktą susiekite su svarbiais parametrais. Pakartojimas su kita suma ar valiuta neturi tyliai pakeisti pradinio mokėjimo. Tokį neatitikimą reikia aiškiai atmesti. Rakte nenaudokite elektroninio pašto adreso ar kitų jautrių duomenų, kurie galėtų patekti į diagnostikos žurnalus.

Mokėjimo paslaugų jungtys

Nežinomo rezultato nepaverskite atmetimu

Pasibaigęs laukimo laikas po išsiuntimo neįrodo, kad teikėjas nieko nesukūrė. Jis galėjo priimti mokėjimą prieš nutrūkstant ryšiui. Išsaugokite neaiškią būseną ir turėkite būdą gauti to paties bandymo rezultatą. Klientui nereikia rodyti vidinės klaidos teksto.

Automatinis persiuntimas kitam teikėjui šioje būsenoje gali sukurti antrą mokėjimą. Maršruto keitimas turi remtis patvirtinta verslo logika. Aiškus atmetimas, vietinė validacijos klaida ir neaiškus išorinis rezultatas yra skirtingos situacijos su skirtingais tolesniais veiksmais.

Apsaugokite vienalaikį vykdymą

Dvi užklausos gali pasiekti skirtingas serverio instancijas tuo pačiu metu. Vien vietinės atminties žyma tokio atvejo neišsprendžia. Reikia patvaraus įrašo ir tinkamo konkurencijos valdymo, kad išorinė operacija būtų pradėta tik pagal leistiną vieną vykdymo kelią.

Jei procesas nutrūksta, būsena turi išlikti atkuriama. Negalima palikti įrašo, kurio niekas nemoka patikrinti paslaugų teikėjo sistemoje. Numatyti atsakingą peržiūros eilę ir saugų atkūrimą naudinga dar prieš pirmą realų incidentą, o ne tik jam įvykus.

Užbaikite operaciją patikrintu pranešimu

Webhook arba būsenos užklausa gali patvirtinti anksčiau neaiškų rezultatą. Prieš keisdami užsakymą patikrinkite pranešimo autentiškumą ir teisingą ryšį su prekybininku. Pasikartojanti sėkmės žinutė neturi du kartus papildyti balanso ar suteikti skaitmeninio produkto.

Taip pat saugokite leistinus būsenų perėjimus. Vėliau atėjęs senas pranešimas neturi be pagrindo panaikinti jau patvirtinto rezultato. Istorija turi padėti suprasti, kas įvyko, išlaikant diagnostiką be kortelės informacijos, slaptų raktų ir perteklinių asmens duomenų.

Integravimo sutartį padarykite aiškią

Dokumentuokite reikalingus antraščių laukus, pakartojimo elgesį ir laukiančio rezultato gavimo kelią. Pavyzdžiuose naudokite tik netikras saugias reikšmes. Integruojanti komanda turi žinoti, kada kartoti tą pačią užklausą, o kada laukti ankstesnio bandymo patvirtinimo.

OrsunPay API ir konkretaus teikėjo funkcijos nėra automatiškai tapačios. Patikrinkite dabartinę jungties apimtį. Prieš paleidimą išbandykite vienalaikį pakartojimą, ryšio nutrūkimą po išsiuntimo ir vėluojantį patvirtinimą, palygindami tikrą sukurtų operacijų skaičių su numatytu verslo veiksmu.

Priėmimo bandymui vienu metu išsiųskite dvi vienodos operacijos užklausas su tuo pačiu raktu. Tada pakartokite užklausą su pakeista suma. Pirmas scenarijus turi nesukurti dvigubo poveikio, antras turi aiškiai parodyti parametrų neatitikimą. Užrašykite gautus statusus ir operacijų skaičių. Toks pavyzdys yra konkretesnis už abstraktų teiginį, kad API palaiko saugų kartojimą.

Šaltiniai

• Stripe: idempotentinės užklausos
• Stripe: webhook dokumentacija