csob / paymentgateway

English documentation of the ČSOB Payment Gateway that offers an API for credit card payments, Apple Pay, Google Pay, mallpay and ČSOB Payment Button.
https://platbakartou.csob.cz/platebni-brana
GNU General Public License v3.0
121 stars 68 forks source link

Refund - změna stavu #593

Closed jahr closed 3 years ago

jahr commented 3 years ago

Dobrý den,

chtěl bych se zeptat, jak dlouho po volání payment/refund trvá, než se změní stav z 8 (Platba zúčtována) na 9 (Zpracování vrácení). Dříve ke změně stavu docházelo prakticky ihned, nyní je to různé.

Děkuji

Mspisar commented 3 years ago

Dobrý den, Váš požadavek byl zaevidován a předán k řešení. O dalším průběhu Vás bude informovat odpovědný servisní technik. S pozdravem

Milan Spisar 1st level support - Team Leader

dkomarek2 commented 3 years ago

Dobrý den, mělo by to trvat opravdu jen řády sekund, tedy v praxi by stav 9 neměl být vůbec zobrazovaný, jedná se jen o jakýsi mezistav během zpracování. Výsledný refund je stav 10.

Pokud evidujete transakci ve stavu 9 déle, pak je to nejspíše chyba.

S pozdravem,

Daniel Komárek IT application specialist

jahr commented 3 years ago

Dobrý den, ve chvíli, kdy jsem to psal, byl problém v tom, že transakce nepřešla ani do stavu 9 ani do stavu 10, ale zůstávala ve stavu 8. V aplikaci při stornu dělám to, že zavolám payment/refund, počkám 2 s a pak zjistím stav. Pokud je 9 nebo 10, pak storno proběhlo v pořádku, pokud je stav jiný, tak neproběhlo a musím situaci nějak řešit. Nyní se zdá, že po volání payment/refund dojde ke korektní změně stavu. Bylo by možné zjistit, čím mohlo být způsobeno, že se stav nezměnil ani po několika hodinách? A jaké by mělo být správné chování ohledně změny stavu? Mám na mysli za jak dlouho dojde ke změně 8 -> 9/10 a co znamená, když k žádné změně nedojde? Děkuji

dkomarek2 commented 3 years ago

Dobrý den,

jak jsem již psal minule, tak state 9 je mezistav během zpracovávání refundu, tedy se nejedná o tížený výsledek podle kterého se dá říci, že refund byl úspěšný. je totiž šance, že se transakce v tomto stavu "zasekne" z důvodu chyby nebo nečekané odpovědi systému. A nebo se transakce ze state 9 vrátí zpět do stavu 8 pokud je refund zamítnut. Tedy pro vás by měl být jako ukazatel úspěšného refundu state 10 + hodnoty v odpovědi, resp.odpovědi na request payment/status, protože proces refundu je asynchronní a může vrátit neaktuální výsledek: "resultCode": 0, "resultMessage":"OK", "paymentStatus": 8, Viz: https://github.com/csob/paymentgateway/wiki/Z%C3%A1kladn%C3%AD-metody#payment-refund-operation

Ohledně problému s funkcionalitou refundu na integračním prostředí jsme evidovali konfigurační chybu, která je již opravená, takže by se již nemělo stávat. Nedokážu vám říci přesný čas za jak dlouho se má změnit stav, záleží to na zatížení systému atd. Ale můžeme se bavit o jednotkách sekund za běžného provozu. Dovedu si představit, že ty 2s nemusí někdy za určitých okolností stačit. Proto bych navrhoval odeslat opakovaně request payment/status v nějakém rozumném intervalu (např. 5-10s) a po několika cyklech (30s) vyhodnotit výsledek: State 9 -> zaseknuté (nemělo by se běžně stávat) State 8 -> zamítnuto State 10 -> úspěšné

S pozdravem,

Daniel Komárek IT application specialist

dkomarek2 commented 3 years ago

Dobrý den, ještě mi došlo, že existuje varianta, kdy transakce již měla jeden úspěšný refund a pokud se pokusíte o druhý, tak se vrací zpět do state 10 i když byl ten druhý zamítnut, tedy opravdu je potřeba validovat i ty hodnoty v odpovědi: "resultCode": 0, "resultMessage":"OK",

S pozdravem,

Daniel Komárek IT application specialist

jahr commented 3 years ago

Dobrý den, děkuji za zprávy a za objasnění. Pochopil jsem správně, že zmíněné konfigurační problémy byly pouze v integračním prostředí a v produkčním ne? Stejnou chybu, jakou jsem popisoval, jsem sice detekoval v integračním prostředí, ale zaznamenali jsme ji i v produkci. Je tedy pravděpodobné, že v produkci byla tato chyba způsobena příliš krátkým intervalem mezi voláními paument/refund a payment/status? Myslíte tedy, že po 30 s bude "jisté", že pokud je transakce stále ve stavu 8, znamená to, že refund byl zamítnut (došlo ke změnám 8 -> 9 -> 8, ale stav 9 jsem nezachytil), a ne to, že stále nedošlo k prvnímu přechodu 8 -> 9? Děkuji

dkomarek2 commented 3 years ago

Dobrý den, konfigurační chyba o které mluvím byla jen na integračním prostředí. Pokud evidujete nějaké transakce z produkce kde nesedí status tak mi je prosím zašlete v emailu a já je prověřím - dkomarek@monetplus.cz Nerad bych vynášel nějaké soudy nad obecnou domněnkou, ty časy jsou jen odhad a nechci tvrdit, že se tím musíte řídit. Obecně implementace mají obvykle řešeno tím opakováním requestu payment/status. Jak dlouho to zkoušet je na vás ale nějaký čas bych tomu dal. Opravdu je to situace od situace. Jestli můžete, dejte tomu např. 60s a podle toho vyhodnoťte.

S pozdravem,

Daniel Komárek IT application specialist

jahr commented 3 years ago

Dobrý den, děkuji, vyřeším to tedy prodloužením intervalu, kdy budu zledovat stav transakce. Pokud jde o produkční případy, tak už byly dořešeny a nyní není třeba je řešit. Pokud by se problém objevil znovu, ozvu se. Děkuji