200 OK care a însemnat eșecul plății

O eroare critică de procesare a plăților a apărut atunci când un gateway de plăți a returnat un status HTTP 200 OK pentru tranzacții refuzate, determinând marcarea incorectă a 1.400 de comenzi ca fiind plătite într-un singur weekend. Problema a apărut deoarece clientul HTTP partajat, conceput inițial pentru o altă integrare unde rezultatele transportului și cele de business se aliniau, trata orice răspuns 2xx ca un succes, fără a parsa complet corpul răspunsului. Această neglijență a însemnat că refuzurile de plată, indicate de un rezultat 'REJECTED' și un cod de răspuns 51 pentru fonduri insuficiente în corp, erau de nediferențiat de plățile reușite la nivel de transport.

Cauza principală a fost identificată ca fiind reutilizarea unui client HTTP generic care a confundat succesul la nivel de transport (HTTP 200) cu succesul la nivel de business (confirmarea plății). Gateway-ul în sine funcționa corect conform propriei definiții, deoarece a primit, înțeles și procesat cererea, ceea ce un status 200 semnifică. Greșeala a constat în presupunerea că un transport HTTP reușit implică o tranzacție financiară reușită, o capcană comună la integrarea sistemelor disparate.

Pentru a remedia acest lucru, integrarea utilizează acum decodoare de răspuns dedicate pentru fiecare partener, clasificând răspunsurile în stări de succes, retryable sau terminal prin examinarea corpului răspunsului. Au fost implementate teste de contract folosind răspunsuri reale înregistrate, inclusiv cazuri limită precum refuzuri și corpuri goale în timpul ferestrelor de mentenanță. Mai mult, un job zilnic de reconciliere compară fișierele de decontare cu înregistrările interne, declanșând alerte pentru orice discrepanțe, subliniind că acordul financiar necesită verificare explicită, nu presupunere implicită din codurile de status.