Chargeback workflow za web shop treba da omogući jednu stvar: da se za spornu transakciju brzo sastavi proverljiv lanac događaja od porudžbine do isporuke ili refundacije. U praksi to znači da sistem mora da poveže interni ID porudžbine, referencu payment providera, status autorizacije i naplate, podatke o kupcu, podatke o isporuci i relevantnu komunikaciju.
Najvažniji podatak nije broj kartice. Web shop treba da čuva poslovni i tehnički kontekst transakcije, dok se osetljivi podaci kartice ostavljaju payment provideru. PCI Security Standards Council navodi da i trgovac koji je outsourcingovao obradu plaćanja i dalje mora da razume podelu odgovornosti, proveri usklađenost pružaoca usluge i zaštiti podatke koji ostaju u njegovom okruženju. Outsourcing plaćanja ne ukida sve obaveze trgovca.
Zato je chargeback pre svega pitanje arhitekture podataka i procesa. Ako su porudžbine, payment događaji i logistika razdvojeni u nepovezanim sistemima, odgovor se često sastavlja ručno i nepotpuno. Ako su povezani stabilnim identifikatorima i audit tragom, tim može da proveri slučaj bez nagađanja.
Šta chargeback workflow treba da obuhvati
Za svaku kartičnu transakciju korisno je posmatrati četiri sloja:
- poslovni sloj — porudžbina, artikli, cena, valuta, porezi, popusti i adresa za isporuku;
- payment sloj — referenca transakcije, status autorizacije, capture, refundacije, storna i konačnog settlementa;
- operativni sloj — pakovanje, preuzimanje, kurirski sken, isporuka, povrat i komunikacija sa kupcem;
- kontrolni sloj — vreme događaja, izvor podatka, korisnik ili servis koji je izvršio promenu i istorija statusa.
Ovi slojevi ne moraju biti u jednoj bazi. Važno je da postoji pouzdana veza između njih. Najčešći ključ je interni order_id, uz dodatni payment_reference ili PSP referencu koju generiše payment provider.
Minimalni skup tehničkih podataka
1. Identitet porudžbine i transakcije
Za početak, sistem treba da sačuva dovoljno podataka da operater može da pronađe tačno jednu porudžbinu i odgovarajuće payment događaje:
- interni ID porudžbine;
- referencu transakcije kod payment providera;
- iznos i valutu;
- vreme kreiranja porudžbine;
- vreme autorizacije, naplate, refundacije ili storna;
- status porudžbine i status plaćanja;
- tip payment metode i, kada provider to dozvoljava, ograničene podatke poput brenda kartice i poslednje četiri cifre.
Ne treba čuvati kompletan broj kartice, sigurnosni kod ili druge osetljive autentikacione podatke za potrebe spora. PCI SSC posebno navodi da se osetljivi autentikacioni podaci, kao što je card verification code, ne smeju čuvati nakon autorizacije. PCI SSC objašnjenje o osetljivim autentikacionim podacima korisno je kao kontrolna tačka pri definisanju šeme baze i logovanja.
2. Sadržaj i cena porudžbine
Za spor je često važnije šta je tačno kupljeno nego sam payment status. Sačuvajte snapshot porudžbine u trenutku kupovine, a ne samo vezu ka trenutno izmenjenom katalogu. Snapshot treba da obuhvati naziv ili SKU proizvoda, količinu, cenu po jedinici, popust, troškove dostave, porez, konačan iznos i valutu.
To sprečava problem u kome se artikl kasnije preimenuje, promeni cena ili ukloni iz kataloga, pa više nije moguće rekonstruisati šta je kupac video i platio. Kod digitalnih proizvoda treba dodati i informaciju o trenutku aktivacije naloga, preuzimanju fajla ili korišćenju usluge, ali samo u obimu koji je potreban za konkretan slučaj.
3. Payment događaji i webhook audit
Payment provider obično šalje više događaja tokom životnog ciklusa transakcije. Aplikacija ne bi trebalo da tretira samo povratak korisnika na success stranicu kao dokaz da je plaćanje uspešno. Pouzdaniji izvor za promenu statusa je verifikovani server-to-server događaj, odnosno webhook ili drugi mehanizam koji provider predviđa.
Za svaki događaj sačuvajte:
- naziv događaja;
- referencu transakcije;
- vreme prijema i, ako postoji, vreme nastanka događaja kod providera;
- status obrade u vašem sistemu;
- rezultat verifikacije potpisa ili drugog mehanizma autentičnosti;
- bezbedno redigovan payload ili njegovu kontrolnu kopiju;
- informaciju da li je događaj obrađen jednom ili je ponovljen.
Provider dokumentacija često razdvaja referencu originalnog plaćanja od reference samog spora. Adyen, na primer, u dispute webhook porukama navodi pspReference za spor i originalReference za prvobitnu uplatu. Taj model je dobar primer za dizajn internog sistema: ne pretpostavljajte da je identifikator chargebacka isti kao identifikator transakcije.
Za konkretnu integraciju proverite dokumentaciju izabranog providera i uključite relevantne događaje. Adyen dokumentacija o dispute webhook događajima pokazuje kako se kroz događaje mogu pratiti zahtev za informacijama, najava chargebacka, sam chargeback i eventualna reverzija.
Kako povezati porudžbinu, uplatu i isporuku
Najpraktičniji model je da porudžbina ima jedan stabilan interni identifikator, a da se za svaki spoljašnji sistem vode posebne reference. Na primer:
| Objekat | Primer podatka | Svrha |
|---|---|---|
| Porudžbina | order_id | Interni ključ za ceo slučaj |
| Plaćanje | payment_reference | Veza sa payment providerom |
| Dispute | dispute_reference | Veza sa chargeback slučajem |
| Isporuka | shipment_id | Veza sa skladištem i kurirom |
| Komunikacija | ticket_id | Veza sa podrškom i razgovorom sa kupcem |
Ne oslanjajte se na ime kupca, email adresu ili iznos kao jedini način povezivanja. Ti podaci mogu da se ponove ili promene. Stabilne reference treba da budu vidljive u administraciji, izvozu podataka i internim izveštajima.
Ovo je direktno povezano sa reconciliation procesom. Ako želite detaljniji model povezivanja porudžbina, payment transakcija i bankarskih izveštaja, pogledajte reconciliation vodič za web shop. Isti princip pomaže i kod chargebacka: svaka finansijska promena mora da ima trag do konkretne porudžbine.
Koji dokazi obično imaju tehničku vrednost
Dokaz nije vredan zato što je obiman, već zato što direktno odgovara na razlog spora. U zavisnosti od slučaja, relevantni mogu biti:
- snapshot porudžbine sa artiklima, količinama, cenama i valutom;
- potvrda da je payment provider prihvatio autorizaciju i naplatu;
- dokaz o isporuci sa referencom pošiljke, statusom i vremenom preuzimanja;
- dokaz o preuzimanju ili korišćenju digitalne usluge;
- istorija refundacije, storna ili pokušaja rešavanja problema;
- komunikacija sa kupcem koja objašnjava šta je traženo i kako je slučaj rešen;
- evidencija da je kupac prihvatio uslove, ako je to relevantno za konkretan razlog spora.
Dokumente treba organizovati prema konkretnom reason code-u i zahtevima providera ili kartične šeme. Ne postoji univerzalni paket koji je dovoljan za svaki spor. Adyen, na primer, navodi da se dozvoljeni razlozi za odbranu i potrebni tipovi dokumenata određuju prema konkretnom slučaju. Dokumentacija o Disputes API-ju takođe opisuje tok u kome se najpre preuzimaju zahtevi za dokazima, zatim dodaju dokumenti i tek onda šalje odbrana.
Rokovi: sistem mora da čuva deadline, ne samo datum prijema
Jedna od čestih grešaka je čuvanje samo datuma kada je tim video obaveštenje. Za operativni rad potreban je poseban rok za odgovor koji dolazi od providera, acquirera ili kartične šeme. Taj rok može zavisiti od vrste spora i kanala kroz koji je obaveštenje stiglo.
U internom modelu uvedite najmanje sledeća polja:
- received_at — kada je sistem primio događaj;
- defense_period_ends_at — krajnji rok koji je dostavio provider, ako postoji;
- reviewed_at — kada je slučaj preuzeo član tima;
- submitted_at — kada je odgovor zaista poslat;
- status — otvoren, u proveri, prihvaćen, odbranjen, izgubljen, reverziran ili istekao.
Adyen u webhook primerima prosleđuje i informaciju o završetku odbrambenog perioda. Bez takvog polja dashboard može da prikazuje slučaj kao otvoren, ali ne i da pokaže da je rok praktično istekao. Zato alarm treba da se zasniva na roku koji dolazi iz konkretnog sistema, a ne na ručno unetom opštem pravilu.
Bezbednost dokaza i ograničavanje pristupa
Chargeback dokumentacija može sadržati lične podatke, adrese, podatke o isporuci i komunikaciju sa kupcem. Zbog toga folder sa dokazima ne treba da bude javno dostupan niti da se šalje kroz neproverene kanale.
Praktične kontrole uključuju:
- role-based pristup za finansije, podršku i administratore;
- logovanje pregleda, izmene i slanja dokumenta;
- redakciju podataka koji nisu potrebni za konkretan spor;
- kontrolu rokova čuvanja i bezbedno brisanje nakon poslovne potrebe;
- verifikaciju webhook potpisa i zaštitu API ključeva;
- odvajanje testnih i produkcionih podataka.
Hosted payment page ili redirect mogu smanjiti količinu podataka kartice koja prolazi kroz infrastrukturu web shopa, ali ne znači da je ceo sistem automatski van obima bezbednosnih obaveza. PCI SSC naglašava da se status i obim procenjuju prema stvarnom načinu na koji se payment stranica i podaci učitavaju. Zato izbor načina integracije platnih kartica treba posmatrati zajedno sa webhookovima, administracijom, logovima i procesom za sporove.
Kako testirati chargeback workflow pre produkcije
Chargeback proces ne treba prvi put proveravati kada stvarni kupac otvori spor. U sandboxu ili test okruženju proverite sledeće scenarije:
- uspešno plaćanje i uredan webhook;
- ponovljeni webhook i idempotentna obrada;
- neuspešna validacija potpisa;
- refundacija pre chargebacka;
- prijem dispute događaja bez pronađene porudžbine;
- istek roka bez poslatog odgovora;
- više događaja za isti dispute;
- reverzija ili promena konačnog statusa.
Za širi plan testiranja payment integracije, uključujući edge case scenarije i failure mode-ove, koristan je vodič za testiranje payment integracije. Nakon puštanja u rad, monitoring, bezbednosne kontrole i rollback plan treba da budu deo istog procesa; pogledajte i payment launch checklistu.
Praktičan sledeći korak
Pre nego što menjate checkout, napravite mapu jednog stvarnog toka: kreiranje porudžbine, autorizacija, naplata, isporuka, refundacija i chargeback. Za svaki korak zapišite izvor podataka, identifikator, status, vreme i vlasnika procesa. Ako ne možete da povežete payment referencu sa porudžbinom bez ručnog pretraživanja više sistema, tu je najverovatnije najveći tehnički dug.
Tek nakon te mape odlučite da li su potrebne izmene checkouta, webhook obrade, administracije ili izrade web shopa. Za širi kontekst strukture i razvoja prodavnice možete pogledati stranicu izrada sajta, ali chargeback workflow treba da ostane zaseban zahtev sa jasnim podacima, rokovima i odgovornostima.
Dobar chargeback odgovor nije improvizovana zbirka screenshotova. To je rekonstruisan, vremenski označen i bezbedno ograničen zapis o tome šta se dogodilo sa konkretnom porudžbinom.
