Payment gateway, processor i banka prihvatilac učestvuju u istoj kartičnoj transakciji, ali ne rade isti posao. Gateway je najčešće tehnički sloj koji prosleđuje podatke i prikazuje rezultat plaćanja, processor obrađuje komunikaciju između učesnika u platnoj mreži, a banka prihvatilac odnosno acquiring banka ima odnos sa trgovcem i omogućava prihvat kartica.
U praksi se ove uloge često preklapaju u komercijalnoj ponudi. Jedan payment service provider može nuditi gateway, processing, antifraud alate i odnos sa bankom pod jednim ugovorom. Zato je pri izboru rešenja važnije razumeti funkcije i odgovornosti nego oslanjati se samo na naziv proizvoda. Ako planirate tehničku realizaciju, detalji o komponentama pripadaju široj temi integracije platnih kartica, dok se ovaj vodič zadržava na tome ko šta radi.
Tri osnovne uloge u kartičnom plaćanju
Payment gateway: tehnički prolaz do plaćanja
Payment gateway je interfejs između checkouta na sajtu ili u aplikaciji i platne infrastrukture. On može da prikaže ili hostuje formu za unos kartice, prenese zahtev za autorizaciju, vrati status transakcije i prosledi podatke potrebne za sledeće korake kao što su refundacija ili ponovljena naplata.
Gateway ne mora biti banka i ne mora sam donositi odluku da li novac može da bude naplaćen. Njegova uloga je da bezbedno poveže trgovčevu aplikaciju sa odgovarajućim payment processorom ili drugim platnim servisom. Kod nekih rešenja podaci o kartici napuštaju stranicu trgovca kroz hosted checkout, dok se kod drugih koristi tokenizacija ili klijentska komponenta provajdera.
Praktično, gateway je deo koji najviše osećaju korisnik i razvojni tim: utiče na tok checkouta, povratne poruke, redirekcije, webhook događaje i način na koji se greška prikazuje kupcu.
Payment processor: obrada poruke i transakcije
Payment processor obrađuje komunikaciju potrebnu da zahtev za plaćanje stigne kroz odgovarajuću kartičnu šemu do banke koja je izdala karticu, a zatim vraća odgovor nazad trgovcu. U tom lancu učestvuju kartične mreže, kao što su Visa ili Mastercard, banka izdavalac kartice i banka prihvatilac.
Processor može da podrži autorizaciju, capture odnosno potvrdu naplate, void, refundaciju i druge operativne poruke. Može učestvovati i u proverama rizika, 3-D Secure toku ili usmeravanju transakcija, ali tačan obim zavisi od konkretnog provajdera i ugovorenog proizvoda. Zato nije bezbedno pretpostaviti da svaki processor nudi iste mogućnosti.
U pretragama se često koristi izraz payment gateway processor, iako on nije uvek precizan naziv jedne zasebne komponente. Nekada označava gateway i processor zajedno, a nekada se koristi kao širi opis dobavljača koji obrađuje online kartična plaćanja.
Banka prihvatilac: odnos sa trgovcem i poravnanje
Banka prihvatilac, odnosno acquiring banka, institucija je koja prihvata kartične transakcije u ime trgovca. Ona je deo lanca koji omogućava da trgovac dobije sredstva nakon uspešnog plaćanja, prema uslovima ugovora i pravilima platne infrastrukture.
Odnos sa prihvatiocem može obuhvatiti otvaranje ili aktivaciju trgovačkog naloga, određivanje podržanih tipova transakcija, poravnanje sredstava, izveštavanje i postupanje u sporovima. U zavisnosti od modela, trgovac možda direktno ugovara uslugu sa bankom ili sve dobija preko payment service providera koji objedinjuje više uloga.
Acquirer nije isto što i banka izdavalac. Izdavalac je banka korisnika kartice i proverava da li je kartica važeća, da li postoje raspoloživa sredstva ili kredit i da li transakcija prolazi njene kontrole. Prihvatilac zastupa trgovca u kartičnom sistemu.
Kako izgleda tok jedne online transakcije
- Kupac unosi podatke i potvrđuje plaćanje. Checkout ili payment forma prikuplja podatke i šalje zahtev gatewayu ili direktno integrisanoj komponenti provajdera.
- Gateway prosleđuje zahtev. Gateway proverava format poruke, povezuje zahtev sa nalogom trgovca i prosleđuje ga processoru ili drugom platnom servisu.
- Processor usmerava autorizaciju. Zahtev prolazi kroz relevantnu kartičnu mrežu do banke izdavaoca. Ako je potrebno, kupac prolazi dodatnu autentifikaciju, na primer 3-D Secure korak.
- Banka izdavalac vraća odgovor. Odgovor može biti odobrenje, odbijanje ili status koji zahteva dodatnu akciju. Razlog odbijanja ne mora uvek biti detaljno otkriven trgovcu.
- Status se vraća kroz sistem. Gateway ili provider obaveštava checkout o rezultatu, a server trgovca treba da primi pouzdanu potvrdu kroz server-to-server odgovor ili webhook, umesto da se oslanja samo na ono što se prikazuje u browseru.
- Capture i poravnanje. Kod neposredne naplate autorizacija i capture mogu biti praktično spojeni. Kod modela sa odloženim captureom, trgovac kasnije potvrđuje naplatu, na primer nakon provere zaliha ili slanja porudžbine. Sredstva se zatim poravnavaju prema pravilima provajdera i prihvatioca.
Ovaj tok objašnjava zašto poruka „plaćanje nije uspelo” ne govori automatski gde je problem. Greška može nastati u checkoutu, gatewayu, processor-u, 3-D Secure koraku, banci izdavaocu, prihvatiocu ili u komunikaciji sa sistemom trgovca.
Šta se menja kada se komponente kombinuju
Na tržištu se često nude objedinjena rešenja. Isti dobavljač može imati korisničku komponentu za checkout, gateway, procesiranje i ugovorni odnos sa prihvatiocem. Za trgovca je to jednostavnije za početak jer postoji manje integracionih tačaka i jedan kanal za podršku.
Sa druge strane, objedinjavanje može smanjiti fleksibilnost. Ako želite da promenite prihvatioca, uvedete alternativni način plaćanja ili preusmerite deo transakcija, možda ćete morati da menjate više delova sistema. Kod odvojenih komponenti dobijate veću kontrolu, ali i više odgovornosti za kompatibilnost, testiranje, monitoring i usklađivanje statusa.
| Model | Prednost | Trade-off |
|---|---|---|
| Objedinjeni provider | Jedna integracija, ugovor i kontakt za podršku | Manje kontrole nad pojedinačnim komponentama i migracijom |
| Odvojeni gateway i processor | Fleksibilnije usmeravanje i izbor partnera | Više integracionih tačaka i složenije praćenje grešaka |
| Direktnija bankarska integracija | Jasan odnos sa konkretnim prihvatiocem | Veća zavisnost od njegovih API-ja, formata i operativnih pravila |
Ko je odgovoran za koji deo problema?
Pre integracije vredi napraviti mapu odgovornosti, jer ona kasnije ubrzava dijagnostiku i komunikaciju sa podrškom.
- Checkout i frontend: prikaz forme, validacija korisničkog unosa, poruke o grešci i ponašanje posle redirekcije.
- Backend trgovca: kreiranje payment intenta ili naloga, idempotency zaštita, čuvanje poslovnog statusa porudžbine i obrada webhookova.
- Gateway ili provider: transport poruke, autentifikacioni tok, API statusi, tokeni i tehnički odgovor integraciji.
- Processor: obrada i usmeravanje platnih poruka, podrška za konkretne operacije i povrat relevantnih statusa.
- Banka prihvatilac: prihvat trgovca, ugovorni i operativni deo usluge, poravnanje i deo komunikacije u vezi sa sporovima.
- Banka izdavalac: odluka vezana za karticu korisnika, raspoloživa sredstva, limite i kontrole rizika na strani izdavaoca.
Granice nisu uvek identične. Jedan provider može preuzeti više tačaka sa ove liste, pa u dokumentaciji treba proveriti ko je vlasnik konkretnog API-ja, statusa, povraćaja novca i eskalacije problema.
Šta proveriti pre tehničke integracije
1. Operacije koje su zaista podržane
Nemojte proveravati samo da li postoji „kartično plaćanje”. Potrebno je razjasniti da li sistem podržava autorizaciju i odloženi capture, delimičnu refundaciju, void, ponovljenu naplatu, preautorizaciju i više valuta, ako su vam potrebne. Posebno proverite da li se statusi razlikuju između inicijalnog odgovora, webhooka i izveštaja o poravnanju.
2. Način zaštite podataka kartice
Razjasnite da li se koristi hosted payment page, hosted fields, tokenizacija ili drugi model. Tokenizacija može omogućiti da sistem sačuva referencu za buduću naplatu bez čuvanja punog broja kartice u aplikaciji trgovca, ali ne uklanja potrebu da se provere konkretne obaveze i konfiguracija. Za povezanu temu pogledajte vodič Tokenizacija kartica: čuvanje payment metode bez čuvanja broja kartice.
3. Webhookovi, idempotency i usklađivanje statusa
Browser može biti zatvoren, redirekcija može izostati, a korisnik može ponoviti klik na dugme. Zato backend treba da ima pouzdanu obradu događaja, zaštitu od duplog kreiranja naplate i mogućnost da naknadno proveri status transakcije. Poslovni status porudžbine ne treba menjati u „plaćeno” samo zato što je korisnik stigao na success URL.
4. Sandbox i neuspešni scenariji
Testiranje ne treba ograničiti na jednu uspešnu karticu. Proverite timeout, odbijenu transakciju, neuspešnu autentifikaciju, ponovljeni webhook, prekid tokom redirekcije, refundaciju i razliku između autorizacije i capturea. Detaljniji plan nalazi se u tekstu Testiranje payment integracije: sandbox, edge cases i failure scenariji.
5. Monitoring i operativni kontakt
Pre puštanja utvrdite ko prima obaveštenje kada poraste broj odbijenih transakcija, kada webhookovi kasne ili kada poravnanje ne odgovara internom izveštaju. Korisna je i unapred definisana procedura za povratak na prethodnu konfiguraciju. Checklista za ovu fazu obuhvata bezbednost, monitoring i rollback plan za payment launch.
Kako odabrati arhitekturu bez pogrešnog pitanja
Pitanje „koji je najbolji payment gateway processor” nema univerzalan odgovor. Preciznije je početi od poslovnog i tehničkog modela: da li vam je potreban jedan prihvatilac ili više njih, da li prodajete jednokratno ili pretplatnički, da li refundacije obrađuju korisnička podrška ili automatizovani sistem i koliko kontrole želite nad checkoutom.
Zatim proverite četiri grupe kriterijuma:
- Pokriće procesa: potrebne operacije, valute, zemlje, kartične šeme i 3-D Secure tok.
- Integracija: kvalitet dokumentacije, SDK-ova, sandboxa, webhookova i mogućnost bezbednog testiranja.
- Operativa: izveštaji, settlement, refundacije, dispute proces, korisnička podrška i vreme dostupnosti sistema.
- Kontrola i održavanje: vlasništvo nad podacima, promena providera, migracija tokena, verzionisanje API-ja i plan za prekid rada.
Ako je checkout deo novog ili redizajniranog sajta, izbor payment komponenata treba uskladiti sa informacijskom arhitekturom, performansama i upravljanjem sadržajem. U tom slučaju može biti relevantna i stranica o izradi sajta, ali kartičnu integraciju treba tretirati kao zaseban tehnički podsistem sa sopstvenim testiranjem i operativnim pravilima.
Gde se uklapa chargeback?
Chargeback nije isto što i obična refundacija. Refundaciju pokreće trgovac kroz svoj sistem ili provider, dok chargeback nastaje kada korisnik ospori transakciju kroz banku izdavaoca, prema pravilima kartične mreže. U tom procesu korisni mogu biti identifikatori transakcije, podaci o isporuci, komunikacija sa kupcem i tehnički zapisi o autentifikaciji.
Zato nije dovoljno znati da li je gateway vratio status „success”. Treba proveriti koje podatke sistem čuva i kako se izvoz podataka koristi u sporu. Za tehnički ugao ove teme pogledajte chargeback workflow i podatke koji pomažu u sporu.
Praktičan zaključak
Gateway je najčešće tehnički prolaz i deo korisničkog toka, processor obrađuje i usmerava platne poruke, a banka prihvatilac predstavlja ključnu bankarsku stranu trgovca i učestvuje u poravnanju. Međutim, jedan provider može objediniti dve ili sve tri uloge, pa se stvarna arhitektura mora čitati iz ugovora, API dokumentacije i operativnih pravila.
Pre početka rada zabeležite tok od checkouta do poravnanja, vlasnika svakog statusa, podržane operacije i postupak za neuspeh ili spor. Tako ćete lakše proceniti da li vam više odgovara objedinjeno rešenje ili kombinacija odvojenih komponenti, a zatim specifikaciju preneti u plan integracije platnih kartica.
