Un chargeback ajunge în inbox la patruzeci de zile după vânzare. Cumpărătorul jură că nu a primit niciodată marfa. Agentul tău de suport scormonește prin loguri, face o captură a confirmării de livrare, scrie trei paragrafe de proză și le încarcă câteva ore mai târziu. Pierzi oricum, pentru că dovada nu se potrivea cu codul de motiv. Așa luptă majoritatea echipelor cu disputele: manual, târziu și reactiv. Nu se poate scala și îți erodează marja pe tăcute.
Ciclul de viață este o mașină de stări, nu un mister
Un chargeback nu este un eveniment aleatoriu. Este un flux bine definit, cu stări denumite: autorizare, capturare, dispută, contestare, arbitraj. Fiecare tranziție are un termen măsurat în zile și un set de documente cerut, iar rețelele de carduri publică chiar și codurile de motiv care îl declanșează. Codul 10.4 este fraudă. Codul 13.1 este marfă neprimită. Codul 13.3 este produs neconform descrierii. Fiecare cod cere dovezi specifice, iar dovada care nu se mapează pe cod este inutilă, oricât de bine ar fi scrisă. Modelează totul ca pe o mașină de stări și munca devine evidentă: termenele devin cronometre, iar contestarea devine un șablon selectat după codul de motiv.
Capturează dovezile în momentul vânzării
Cea mai mare pârghie este momentul. Dovada care câștigă o contestare există aproape întotdeauna în clipa tranzacției și aproape niciodată nu este capturată atunci. Amprenta dispozitivului, IP-ul, rezultatul AVS, token-ul de autentificare 3DS, descriptorul exact afișat cumpărătorului, confirmarea de livrare, termenii semnați pe care i-a acceptat. Colectează totul la autorizare și leagă-le de înregistrarea plății. Apoi contestarea este o căutare, nu o investigație: sosește un webhook de dispută, sistemul citește codul de motiv, extrage pachetul preasamblat pentru acea tranzacție, îl formatează pe șablonul rețelei și îl trimite. Niciun om nu scrie proză, iar rata de câștig crește pentru că pachetul este complet.
Previne ce poți, măsoară restul
Cea mai ieftină dispută este cea care nu se deschide niciodată. O proporție șocantă dintre chargeback-uri nu sunt deloc fraudă, ci confuzie: un cumpărător nu recunoaște un descriptor criptic din extrasul de cont și sună la bancă. Repară mai întâi descriptorul, fă-l lizibil și consecvent cu ce a văzut cumpărătorul la checkout, iar o categorie întreagă de dispute dispare înainte să fie nevoie de vreo dovadă. Apoi stratifică controalele tehnice. AVS și 3DS mută responsabilitatea și filtrează actorii rău-intenționați, iar un scor de fraudă la autorizare îți permite să refuzi sau să escaladezi cele mai riscante încercări înainte să se deconteze. Reglează-le pe baza datelor reale de dispută, nu a fricii.
Nimic din toate acestea nu contează dacă nu le poți vedea. Dacă disputele trăiesc doar într-un fișier de calcul al finanțelor, ingineria nu le simte niciodată. Pune rata de dispută pe același dashboard cu latența și rata de eroare, segmentată după descriptor, după produs, după acquirer, după cohortă, și urmărește-o cum se mișcă atunci când lansezi. Un vârf după un release este un raport de bug deghizat, iar o schimbare de descriptor care coboară rata este o funcționalitate pe care o poți arăta cu degetul.
Când proiectezi ciclul de viață al disputei în loc să stingi incendii, disputele devin o metrică pe care o reglezi, nu o criză pe care o supraviețuiești.— Protocore · Inginerie plăți
Am construit exact această disciplină în stiva de plăți care a procesat 2,4 milioane de euro pentru 80.000 de participanți, iar cifra care a contat cel mai mult nu a fost debitul. A fost zero dispute. Asta nu vine din noroc sau dintr-o mulțime iertătoare. Vine din capturarea dovezilor la atingere, din descriptori pe care nimeni nu trebuie să îi descifreze și din tratarea fiecărui cod de motiv ca pe o ramură pe care o gestionezi deja. Proiectează ciclul de viață o dată și încetezi să mai plătești pentru el pentru totdeauna.
Ai un sistem de construit?
Spune-ne care e problema. Revenim cu o arhitectură și un plan.
Începe un proiect