Tok kartične transakcije online počinje na checkoutu, ali se ne završava odmah kada kupac vidi poruku da je plaćanje uspešno. Podaci ili token sa checkouta prosleđuju se payment provideru, zatim banci prihvatiocu, kartičnoj mreži i banci koja je izdala karticu. Odgovor se vraća kroz isti lanac, dok vaš sistem posebno mora da obradi potvrdu plaćanja i ažurira porudžbinu.
Najvažnija praktična razlika je između autorizacije, potvrde statusa u aplikaciji i poravnanja sredstava. Autorizacija znači da je transakcija odobrena ili odbijena. Porudžbina se u vašem sistemu pouzdano označava kao plaćena tek kada backend dobije verifikovan događaj od payment providera, a novac se na račun trgovca prenosi kasnije, prema pravilima konkretnog procesora.
Ko učestvuje u online kartičnoj transakciji
Pre nego što se prikaže sam tok, korisno je razdvojiti uloge:
- Kupac i browser unose podatke kartice ili koriste sačuvani način plaćanja.
- Trgovac prikazuje proizvode, formira iznos i odlučuje kada će isporučiti robu ili aktivirati uslugu.
- Checkout komponenta može biti deo stranice trgovca, iframe, modal ili hosted payment page payment providera.
- Payment service provider obrađuje zahtev za plaćanje i povezuje trgovca sa bankarskom infrastrukturom.
- Acquirer, odnosno banka prihvatilac, obrađuje kartične transakcije u ime trgovca.
- Kartična mreža, kao što su Visa ili Mastercard, prosleđuje zahtev između prihvatioca i banke izdavaoca.
- Issuer, odnosno banka izdavalac, proverava karticu, raspoloživost sredstava i pravila za odobravanje transakcije.
U praksi payment provider može objediniti više ovih uloga. Zbog toga korisnik često vidi samo naziv jednog servisa, iako se iza zahteva odvija komunikacija kroz nekoliko sistema.
Tok kartične transakcije online: korak po korak
1. Checkout formira zahtev za plaćanje
Kupac na checkoutu potvrđuje korpu, adresu, način isporuke i iznos. Sistem trgovca treba da formira jedinstvenu narudžbinu sa jasnim identifikatorom, valutom i konačnim iznosom. Taj iznos ne bi trebalo slepo preuzimati iz browsera; backend treba ponovo da izračuna cenu na osnovu proizvoda, poreza, popusta i dostave.
U ovoj fazi određuje se i tip toka: jednokratno plaćanje, rezervacija sredstava pa kasnija naplata, pretplata ili eventualno plaćanje kroz redirect. To nije samo UX odluka. Izabrani model utiče na statusne oznake, refundacije, čuvanje tokena i način obrade neuspešnih pokušaja.
2. Podaci kartice se prikupljaju i štite
Kada kupac unese broj kartice, datum isteka i sigurnosni kod, podaci se ne bi smeli nepotrebno slati kroz vaš server. U zavisnosti od integracije, checkout ih prosleđuje direktno payment provideru ili ih zamenjuje tokenom. Token predstavlja referencu koju provider može da koristi za konkretnu naplatu, dok trgovac ne mora da čuva puni broj kartice.
Hosted checkout i providerova ugrađena komponenta često smanjuju količinu kartičnih podataka koju dodiruju vaša aplikacija i infrastruktura. To ne znači da su bezbednost i obaveze trgovca automatski rešene, ali arhitektura može značajno uticati na obim sistema koji ulazi u PCI DSS razmatranje. Više o toj odluci objašnjeno je u tekstu PCI DSS scope i smanjenju količine kartičnih podataka.
3. Kreira se payment intent ili ekvivalentan objekat
Moderni payment sistemi obično prvo kreiraju objekat koji predstavlja nameru plaćanja. On sadrži iznos, valutu, referencu narudžbine, izabrani način plaćanja i početni status. Naziv i tačan model razlikuju se po provideru, ali je princip isti: transakcija dobija identitet i može da prođe kroz više stanja.
To je važno zato što online plaćanje može da bude asinhrono. Kupac može napustiti redirect, banka može zahtevati dodatnu autentikaciju, a odgovor providera može stići nakon što je browser već promenio stranicu. Sistem koji se oslanja samo na jedan trenutni odgovor iz checkouta teško može pouzdano da prati takve situacije.
4. Pokreće se autentikacija kupca
U zavisnosti od kartice, zemlje, rizika i pravila izdavaoca, kupac može biti preusmeren na dodatnu autentikaciju. Kod 3-D Secure toka to može biti potvrda u mobilnoj aplikaciji, jednokratni kod ili drugi postupak koji određuje banka izdavalac.
Autentikacija nije isto što i konačna autorizacija. Ona potvrđuje dodatni element identiteta ili legitimnosti pokušaja, ali nakon nje transakcija i dalje mora da prođe kroz autorizacioni proces. Kako se 3-D Secure 2 uklapa u checkout, koje podatke koristi i gde može da prekine tok objašnjeno je u vodiču 3-D Secure 2 i autentikacija kupca.
5. Zahtev putuje do banke izdavaoca
Payment provider ili acquirer prosleđuje zahtev kroz kartičnu mrežu banci koja je izdala karticu. Issuer proverava više elemenata, između ostalog:
- da li je kartica važeća i omogućena za online plaćanja;
- da li postoje raspoloživa sredstva ili dovoljan kreditni limit;
- da li se iznos, valuta i trgovac uklapaju u pravila transakcije;
- da li postoje indikatori rizika ili neuobičajenog ponašanja;
- da li je potrebna dodatna autentikacija.
Rezultat može biti odobrenje, odbijanje ili status koji zahteva dodatnu radnju. Poruka o odbijanju nije uvek dovoljno precizna da bi trgovac znao tačan razlog, pa korisnički interfejs treba da prikaže neutralnu i korisnu instrukciju: pokušaj ponovo, proveri podatke ili izaberi drugi način plaćanja.
6. Transakcija se autorizuje ili odbija
Autorizacija je odluka da se transakcija odobri i, kod određenih modela, da se sredstva rezervišu. Ona sama po sebi ne znači da je novac već prenet trgovcu. Ako je naplata podešena kao automatsko potvrđena, payment provider može odmah preći na capture. Ako se koristi odvojena autorizacija i naplata, trgovac mora eksplicitno da potvrdi capture u predviđenom roku.
Razlika je naročito važna kod proizvoda koji se šalju kasnije, rezervacija ili usluga čija dostupnost se proverava naknadno. Pre implementacije treba utvrditi šta se dešava kada autorizacija istekne, kada capture bude odbijen i da li se rezervacija automatski oslobađa.
7. Browser dobija povratni odgovor, ali backend nije završen
Kupac može biti vraćen na success, failure ili pending stranicu. Ta stranica je važna za korisničko iskustvo, ali ne bi trebalo da bude jedini izvor istine. Browser može izgubiti vezu, korisnik može zatvoriti prozor, a napadač može pokušati da pozove URL potvrde bez stvarnog plaćanja.
Zato backend treba da primi webhook ili drugi server-to-server događaj od payment providera, proveri njegov potpis i poveže ga sa očekivanom narudžbinom. Tek nakon provere treba promeniti status iz „u obradi“ u „plaćeno“, izdati digitalni proizvod, poslati potvrdu ili pokrenuti isporuku.
Koje statuse treba modelovati
Jednostavan model sa samo „plaćeno“ i „nije plaćeno“ često nije dovoljan. Nazivi zavise od providera, ali poslovni sistem obično mora da razlikuje sledeće situacije:
| Status | Šta znači za trgovca |
|---|---|
| Payment initiated | Zahtev je kreiran, ali nema potvrde da je naplata završena. |
| Requires action | Kupac mora da završi dodatnu autentikaciju ili drugu radnju. |
| Authorized | Izdavalac je odobrio zahtev, ali capture ili konačna naplata mogu biti odvojeni. |
| Paid / captured | Provider je potvrdio naplatu prema definisanom modelu. |
| Failed | Pokušaj nije uspeo; razlog može biti privremen ili konačan. |
| Refunded | Sredstva su vraćena delimično ili u celosti, prema statusu refundacije. |
Webhook obrada treba da bude idempotentna. Ako isti događaj stigne dva puta, sistem ne sme dvaput da kreira porudžbinu, pošalje digitalni sadržaj ili evidentira prihod. Takođe je korisno čuvati audit trag: identifikator narudžbine, identifikator payment objekta, primljene događaje, vreme obrade i rezultat validacije.
Šta se dešava posle potvrde plaćanja
Nakon uspešne naplate sledi clearing i settlement, odnosno obračun i poravnanje između učesnika. Trgovac ne mora da vidi svaki interni korak, ali treba da zna da se stanje na dashboardu providera, stanje narudžbine i stanje novca na bankovnom računu ne moraju promeniti istog trenutka.
Kasnije mogu nastati refundacija, dispute ili chargeback. Refundacija je povraćaj koji pokreće trgovac ili provider, dok chargeback uključuje spor koji kupac pokreće kroz banku. Zato evidencija narudžbine ne treba da se zasniva samo na početnom success odgovoru. Finansijski status mora moći da se menja i nakon isporuke.
Kod pretplata se na ovaj tok dodaju budući pokušaji naplate, istek kartice, ažuriranje payment metoda i ponovni pokušaji. To je zasebna arhitektonska tema; detaljniji pregled nalazi se u tekstu Recurring payments: arhitektura pretplata i automatskih naplata. Za neuspela ponavljanja naplate važni su i pravila komunikacije sa korisnikom, o čemu govori vodič Failed payments i dunning.
Hosted checkout ili integrisana forma?
Ne postoji univerzalno najbolja varijanta. Hosted checkout prebacuje korisnika na stranicu providera ili koristi njegovu gotovu komponentu. Prednosti su manja količina kartičnih podataka u vašoj infrastrukturi, jednostavniji početak i manje elemenata koje sami održavate. Trade-off je manja kontrola nad izgledom, navigacijom i nekim detaljima checkouta.
Integrisana forma ili SDK daje više kontrole nad korisničkim tokom i može se bolje uklopiti u složen checkout. Istovremeno zahteva pažljiviju implementaciju, testiranje promena u browseru, obradu grešaka, zaštitu ključeva i jasnu granicu između frontend i backend odgovornosti.
Odluka treba da se zasniva na potrebama toka, a ne samo na tome kako forma izgleda. Praktičan pregled celokupne tehničke odluke i povezivanja payment servisa sa sajtom nalazi se na stranici integracija platnih kartica. Ako se plaćanje uvodi kao deo novog ili redizajniranog korisničkog toka, relevantna je i izrada sajta, posebno kada checkout zavisi od strukture kataloga, naloga i narudžbina.
Kontrolna lista za pouzdan tok plaćanja
- Backend sam izračunava iznos i valutu, umesto da veruje vrednostima iz browsera.
- Svaka narudžbina ima jedinstven interni identifikator i vezu sa payment objektom.
- Podaci kartice se prikupljaju kroz odobrenu providerovu komponentu ili hosted tok kad je to odgovarajuće.
- Frontend razlikuje neuspeh, čekanje i zahtev za dodatnom autentikacijom.
- Webhook potpis se proverava, a obrada događaja je idempotentna.
- Isporuka robe ili usluge pokreće se na osnovu verifikovanog statusa, ne samo URL-a uspeha.
- Postoje testovi za odbijanje kartice, 3-D Secure, prekid redirecta, duplirani webhook i refundaciju.
- Administracija može da pronađe transakciju po broju narudžbine i identifikatoru providera.
- Čuvaju se samo podaci koji su potrebni za poslovni proces i podršku.
Pravi sledeći korak nije da se odmah izabere dugme ili forma, već da se nacrta stanje kroz koje prolazi jedna narudžbina: od kreiranja zahteva, preko autentikacije i autorizacije, do webhook potvrde, isporuke i eventualne refundacije. Kada su te granice jasne, izbor payment providera i način integracije mogu da se procene prema konkretnom procesu, a ne prema izolovanom checkout ekranu.
