Kupac tvrdi da mu je novac skinut, a porudžbina u administraciji nije plaćena. Ili je transakcija označena kao uspešna, ali sredstva još nisu na računu trgovca. U takvim situacijama pitanje kako proveriti status kartične naplate nije samo operativni detalj. Od odgovora zavise isporuka robe, korisničko iskustvo, reklamacije i poverenje u online prodavnicu.
Najčešća greška je posmatranje kartične naplate kao jednog događaja. Ona je, međutim, niz koraka između kupca, izdavaoca kartice, payment gateway-a, banke prihvatioca i trgovca. Status koji vidite na platformi za naplatu može da potvrdi da je kupčeva banka odobrila transakciju, ali ne mora da znači da je novac već knjižen na račun trgovca. Zato je potrebno proveravati pravi status na pravom mestu.
Kako proveriti status kartične naplate bez nagađanja
Provera treba da počne od identifikacije konkretne transakcije. Pripremite broj porudžbine, jedinstveni ID transakcije iz payment platforme, iznos, valutu, datum i približno vreme plaćanja. Ako imate samo ime kupca ili poslednje četiri cifre kartice, pretraga može biti nepouzdana, posebno kada isti kupac pravi više pokušaja plaćanja.
U kontrolnom panelu payment gateway-a proverite status transakcije i pripadajuće detalje: odgovor banke, rezultat 3D Secure autentifikacije, autorizacioni kod, vreme obrade i eventualnu poruku o grešci. Kada se naplata obrađuje putem API integracije, uporedite status iz administracije sa API odgovorom i webhook obaveštenjem koje je primio vaš sistem.
Ova tri podatka ne moraju uvek da stignu istovremeno. Kupac može uspešno završiti plaćanje, dok vaš server zbog prekida veze ili greške u obradi ne zabeleži obaveštenje. Obrnuto, aplikacija može kreirati porudžbinu pre konačne potvrde naplate. Zato status porudžbine u e-commerce platformi ne treba automatski smatrati dokazom finansijskog ishoda.
Proverite da li je transakcija autorizovana ili naplaćena
Autorizacija znači da je banka izdavalac kartice proverila raspoloživost sredstava i rezervisala iznos. Kupac tu rezervaciju često vidi kao terećenje ili rezervisana sredstva u mobilnom bankarstvu. Ipak, trgovac još nije nužno primio sredstva niti je naplata završena.
Kod jednokratne prodajne naplate, autorizacija se najčešće neposredno nastavlja na naplatu. Kod preautorizacije, česte u hotelijerstvu, rent-a-car poslovanju ili kada se konačan iznos naknadno određuje, sredstva se prvo samo rezervišu. Trgovac zatim izvršava potvrdu naplate za konačan iznos ili oslobađa rezervaciju ako usluga nije realizovana.
Ova razlika direktno utiče na komunikaciju sa kupcem. Ako je transakcija samo autorizovana, nije ispravno reći da je novac trajno naplaćen. Ako je naplata potvrđena, ali još nije prošla bankarski ciklus poravnanja, kupcu treba objasniti da je porudžbina uspešno plaćena, dok će trgovac sredstva dobiti prema ugovorenoj dinamici isplate.
Proverite fazu knjiženja i poravnanja
Posle uspešne naplate transakcija ulazi u proces kliringa i poravnanja između banaka. U zavisnosti od banke prihvatioca, kartične šeme, dana u nedelji, valute i ugovorenog modela isplate, sredstva nisu odmah raspoloživa na poslovnom računu.
Zato razlikujte status „successful” ili „approved” u payment platformi od statusa isplate trgovcu. Prvi govori da je kartična transakcija prošla. Drugi potvrđuje kada je grupa obrađenih transakcija evidentirana u obračunu i isplaćena na vaš račun. Finansijski tim treba da uskladi izveštaj iz gateway-a sa izvodom banke i obračunom banke prihvatioca, a ne sa pojedinačnim prikazom kupca u njegovoj banci.
Za kompanije sa većim brojem transakcija, dnevno usklađivanje sprečava da mali problem postane niz ručnih reklamacija. Najkorisnije je da se transakcije povežu sa internim brojem porudžbine, računom i identifikatorom iz payment sistema. Tako se odstupanja mogu pronaći za nekoliko minuta, bez pretrage kroz više sistema.
Šta znače najčešći statusi kartične naplate
Nazivi statusa razlikuju se između platformi, ali njihova poslovna značenja uglavnom su slična. Transakcija može biti inicirana, u obradi, odobrena, odbijena, otkazana, stornirana, refundirana ili osporena.
Status „u obradi” zahteva oprez. Ponekad znači da gateway čeka odgovor banke, a ponekad da vaš sistem nije obradio završno obaveštenje. Nemojte kupcu odmah predlagati novo plaćanje dok ne proverite originalni pokušaj. Dva uzastopna klika na dugme za plaćanje, osvežavanje stranice ili povratak iz bankarske aplikacije mogu stvoriti utisak neuspeha, a zapravo proizvesti duplu naplatu.
„Odbijena” transakcija znači da naplata nije odobrena. Razlog može biti nedovoljno sredstava, ograničenje za internet kupovinu, pogrešan unos podataka, neuspešna 3D Secure autentifikacija ili pravilo banke izdavaoca. Payment gateway prikazuje raspoloživi kod odgovora, ali trgovac obično nema uvid u sve interne razloge odluke banke. Kupca treba uputiti da proveri karticu kod svoje banke ili da izabere drugi način plaćanja, bez traženja osetljivih kartičnih podataka preko telefona ili e-maila.
„Stornirana” ili „reversed” transakcija često označava da je prethodna autorizacija poništena. To se može desiti kada je došlo do prekida tokom procesa, kada trgovac otkaže plaćanje pre završetka ili kada sistem automatski oslobodi rezervisana sredstva. Vreme kada će kupac videti oslobađanje rezervacije zavisi od banke izdavaoca kartice.
Refundacija je drugačija. Ona se pokreće nakon uspešno završene naplate, kada trgovac vraća ceo ili deo iznosa. Refundacija ima sopstveni status i rok obrade. Nemojte je mešati sa storniranjem autorizacije, jer kupac kod refundacije može najpre videti originalno terećenje, a zatim zaseban povraćaj sredstava.
Kada treba proveriti tehničke zapise
Ako se status u administraciji razlikuje od statusa porudžbine, tehnički tim treba da proveri tok zahteva. Posebno su bitni API odgovor, potpis webhook poruke, vreme prijema obaveštenja i logovi aplikacije. Jedan neuspešan webhook ne znači automatski neuspešnu naplatu. Može značiti da je naplata uspešna, ali da vaš endpoint nije bio dostupan ili nije pravilno potvrdio prijem poruke.
Dobro implementiran sistem zato ne zavisi samo od povratne stranice na koju se kupac vraća nakon plaćanja. Povratak kupca može biti prekinut zatvaranjem pregledača, slabom mobilnom vezom ili promenom uređaja. Konačno ažuriranje porudžbine treba zasnivati na verifikovanom serverskom obaveštenju i proveri transakcije preko API-ja.
Takođe proverite da li ste pravilno razdvojili testno i produkciono okruženje, valute, identifikatore porudžbina i pravila za ponovne pokušaje. Neadekvatno generisanje jedinstvenog ID-ja porudžbine može otežati usklađivanje, dok agresivno automatsko ponavljanje zahteva može proizvesti duple naplate.
Kako postupiti kada kupac prijavi problem
Prvo pronađite transakciju prema pouzdanim parametrima i utvrdite njen finansijski status. Zatim proverite da li postoji više pokušaja za istu porudžbinu. Tek nakon toga odlučite da li porudžbinu treba isporučiti, otkazati, sačekati potvrdu ili pokrenuti refundaciju.
Ako je naplata odobrena, a porudžbina nije evidentirana, problem je najčešće u razmeni podataka između payment sistema i trgovčeve aplikacije. Ako je transakcija odbijena, ne tražite od kupca broj kartice, CVV ili jednokratni kod. Ti podaci ne smeju da se prikupljaju van bezbednog toka plaćanja.
Kod prijave duple naplate proverite da li postoje dve odvojene, uspešne transakcije sa različitim identifikatorima. Ako postoje, razmotrite povraćaj jednog iznosa prema internoj politici i realnom statusu isporuke. Ako kupac vidi dve stavke, ali je jedna samo rezervacija, potrebno je razlikovati rezervaciju od knjiženog terećenja pre nego što pokrenete refundaciju koja možda nije potrebna.
Ako kupac ospori već izvršenu naplatu, sačuvajte dokumentaciju o porudžbini, isporuci, komunikaciji i potvrdi plaćanja. Sporovi se rešavaju kroz formalni proces kartičnih šema i banaka, pa brz i uredan pristup dokazima smanjuje operativni pritisak na tim.
Statusi koji pomažu prodaji, ne samo podršci
Praćenje statusa kartičnih naplata nije rezervisano za finansije. E-commerce tim iz ovih podataka vidi gde kupci odustaju, product tim prepoznaje neuspešne povratke sa plaćanja, a tehnički tim otkriva prekide u webhook komunikaciji. Finansije, podrška i razvoj treba da rade sa istim izvorom podataka i jasno definisanim statusima porudžbine.
Platforma kao što je AllSecure centralizuje pregled transakcija, refundacija, preautorizacija i odgovora sistema, uz lokalnu podršku koja razume odnose sa bankama u regionu. Ipak, najbolji rezultat dolazi kada i trgovac interno definiše ko prati izuzetke, kada se porudžbina pušta u isporuku i ko komunicira sa kupcem.
Dobra provera statusa ne svodi se na pitanje da li je novac „prošao”. Ona daje timu sigurnost da svaka porudžbina dobije ispravan sledeći korak – isporuku, ponovni pokušaj plaćanja, oslobađanje rezervacije ili povraćaj sredstava – dok kupac dobija jasan odgovor bez čekanja i pretpostavki.