Master rad iz oblasti sistemi elektronskog plaćanja. Analizirati Maksekeskus sistem za online plaćanje. Specificirati model sistema za plaćanje na primeru web sajta na kojem posetilac plaća savete iz oblasti osiguranja uz oslonac na Maksekeskus sistem. Projektovati i implementirati definisani model uz oslonac na Laravel okruženje. Dokumentovati rešenje. Rad napisala Zlata Milošević.

1. UNIVERZITET U NOVOM SADU
FAKULTET TEHNIĈKIH NAUKA U
NOVOM SADU
Zlata Milošević
MAKSEKESKUS SISTEM ZA
ONLINE PLAĆANJE
MASTER RAD
Novi Sad, 2016. godine

3. UNIVERZITET U NOVOM SADU
FAKULTET TEHNIĈKIH NAUKA
2 1 0 0 0 N O VI SA D, T r g Do si t e ja
O b r a d o v i ć a 6
Broj:
ZADATAK ZAMASTER RAD
Datum:
STUDIJSKI PROGRAM: Računarstvo i automatika
RUKOVODILAC
STUDIJSKOG PROGRAMA:
prof. dr Miroslav Popović
Student: Zlata Milošević Broj indeksa: E10381
Oblast: Sistemi elektronskog plaćanja
Mentor: prof. dr Goran Sladić
NA OSNOVU PODNETE PRIJAVE, PRILOŽENE DOKUMENTACIJE I ODREDBI
STATUTA FAKULTETA IZDAJE SE ZADATAK ZA MASTER RAD, SA SLEDEĆIM
ELEMENTIMA:
 problem – tema rada;
 način rešavanja problema i način praktične provere rezultata rada, ako
je takva provera neophodna;
NASLOV MASTER RADA:
Maksekeskus sistem za online plaćanje
TEKST ZADATKA:
Rukovodilac studijskog programa: Mentor rada:
Primerak za:  - Studenta;  - Mentora
Analizirati Maksekeskus sistem za online plaćanje. Specificirati model sistema
za plaćanje na primeru web sajta na kojem posetilac plaća savete iz oblasti
osiguranja uz oslonac na Maksekeskus sistem. Projektovati i implementirati
definisani model uz oslonac na Laravel okruženje. Dokumentovati rešenje.

5. V
Kljuĉna dokumentacijska informacija
Redni broj, RBR:
Identifikacioni broj, IBR:
Tip dokumentacije, TD: monografska publikacija
Tip zapisa, TZ: tekstualni štampani dokument
Vrsta rada, VR: master rad
Autor, AU: Zlata Milošević
Mentor, MN: dr Goran Sladić, vanr. prof.
Naslov rada, NR: Maksekeskus sistem za online plaćanje
Jezik publikacije, JP: Srpski
Jezik izvoda, JI: srpski / engleski
Zemlja publikovanja, ZP: Srbija
Uže geografsko područje, UGP: Vojvodina
Godina, GO: 2016
Izdavač, IZ: autorski reprint
Mesto i adresa, MA: Novi Sad, Fakultet tehničkih nauka,
Trg Dositeja Obradovića 6
Fizički opis rada, FO:
(poglavlja/strana/
citata/tabela/slika/grafikona/priloga)
6 / 61 / 0 / 0 / 24 / 0 / 0
Naučna oblast, NO: Računarske nauke i informatika
Naučna disciplina, ND: Sistemi elektronskog plaćanja
Predmetna odrednica /
ključne reči, PO:
platni gejtvej, elektronsko plaćanje, Maksekeskus
UDK
Čuva se, ČU: Biblioteka Fakulteta tehničkih nauka, Trg Dositeja
Obradovića 6, Novi Sad
Važna napomena, VN:
Izvod, IZ: U radu je implementiran sistem za plaćanje troškova
saveta iz oblasti osiguranja, posredstvom Maksekeskus
sistema. Sistem je implemplementiran u formi web
aplikacije za šta je korišćen Laravel okruženje. Podržano
je plaćanje karticom i bankovnim linkom.
Datum prihvatanja teme, DP:
Datum odbrane, DO:
Članovi komisije, KO:
Predsednik dr Branko Milosavljević, red. prof., FTN Novi Sad
Član dr Imre Lendak, docent, FTN Novi Sad
Član, mentor dr Goran Sladić, vanr. prof., FTN Novi Sad
Potpis mentora

6. VI

7. VII
Key words documentation
Accession number, ANO:
Identification number, INO:
Document type, DT: monographic publication
Type of record, TR: textual material
Contents code, CC: MSc thesis
Author, AU: Zlata Milošević
Mentor, MN: Goran Sladić, PhD, assoc. prof.
Title, TI: Maksekeskus Online Payment System
Language of text, LT: Serbian
Language of abstract, LA: serbian / english
Country of publication, CP: Serbia
Locality of publication, LP: Vojvodina
Publication year, PY: 2013
Publisher, PB: author’s reprint
Publication place, PP: Novi Sad, Faculty of Technical Sciences,
Trg Dositeja Obradovića 6
Physical description, PD:
(chapters/pages/ref./tables/pictures/graph
s/appendixes)
6 / 61 / 0 / 0 / 24 / 0 / 0
Scientific field, SF: computer sciences and informatics
Scientific discipline, ND: Electronic payment systems
Subject / Keywords, S/KW: payment gateway, electronic payments, Maksekeskus
UDC
Holding data, HD: Library of the Faculty of Technical Sciences,
Trg Dositeja Obradovića 6, Novi Sad
Note, N:
Abstract, AB: This paper presents a web based application for paying
insurance tips using the Maksekeskus payment gateway.
The system is implemented using the Laravel framework.
The proposed solution supports credit card payments
and bank link payments.
Accepted by sci. board on, ASB:
Defended on, DE:
Defense board, DB:
President Branko Milosavljević, PhD, full prof., FTN Novi Sad
Member Imre Lendak, PhD, assist. prof., FTN Novi Sad
Member, Mentor Goran Sladić, PhD, assoc. prof., FTN Novi Sad
Mentor’s sign

8. VIII

9. IX
Sadržaj
Predgovor..............................................................................................XI
1. UVOD................................................................................................. 1
1.1. Platni procesori I gejtvejevi u svetu........................................... 2
1.1. Platni proceosri I gejtvejevi kod nas.......................................... 5
2. MAKSEKESKUS .............................................................................. 9
2.1. Registracija.................................................................................. 9
2.2. Metode plaćanja........................................................................ 10
2.3. Usluge........................................................................................ 13
2.4. Portal za trgovca ....................................................................... 14
3. RESTful JSON API ......................................................................... 21
3.1. Autentifikacija i autorizacija .................................................... 21
3.2. HAL ........................................................................................... 22
3.3. Struktura API zahteva (API request)....................................... 23
3.3.1. URL struktura.................................................................... 23
3.4. Struktura API odgovora (API response) ................................. 24
3.4.1. Validacija odgovora .......................................................... 24
3.4.2. Response body ................................................................... 25
3.5. Paginacija (Pagination)............................................................ 26
3.6. Lista HTTP metoda dostupnih u API-ju.................................. 27
3.6.1. Maksekeskus API metode................................................. 28
4. MODEL SISTEMA ......................................................................... 35
4.1. Plaćanje karticom...................................................................... 40
4.2. Plaćanje preko bankovnog linka .............................................. 42
5. IMPLEMENTACIJA SISTEMA.................................................... 45
5.1. Frontend veb sajta i proces naplate.......................................... 47
5.2. Backend veb sajta za administratora ....................................... 50
5.3. Implementacija platnog gejtveja .............................................. 51
6. ZAKLJUČAK .................................................................................. 61
LITERATURA..................................................................................... 63

10. X

11. XI
Predgovor
Iako je naplata preko kreditnih i debitnih kartica na onlajn
prodavnicama nadaleko poznata funkcionalnost u svetu a i kod nas, i dalje
postoji prostor za razvoj ovog segmenta elektronskog plaćanja. Današnji
trendovi teţe da se upotreba kartica zameni nekim drugim metodama
plaćanja, ali su kartice i dalje aktuelne kako u offline tako i u online svetu. I
dalje postoji bojazan ljudi kada vrše bilo kakvu kupovinu preko interneta,
zbog čega je neophodno napraviti bezbedniji, brţi i pouzdaniji sistem
naplate na sajtovima. Potrebno je skratiti broj koraka u interfejsu pri
kupovini, poštovati standardne i na taj način uliti poverenje kod kupaca.
Jedan od novijih postojećih sistema za onlajn plaćanje je
Maksekeskus, estonski platni gejtvej. Maksekeskus je tehničko rešenje koje
nudi mogućnost jednostavne integracije plaćanja na onlajn prodavnici. Radi
se o posredniku izmeĎu kupca i prodavca na siguran i jednostavan način.
Tema ovog rada je analiza Maksekeskus platnog gejtveja i njegovih
mogućnosti. Drugi deo rada je posvećen specifikaciji i implementaciji ovog
sistema na primeru naplate saveta iz oblasti osiguranja. Tekst rada sastoji se
iz šest poglavlja.
Prvo poglavlje sadrţi uvodna razmatranja o platnim sistemima,
objašnjeni su osnovni pojmovi i kako se kategoriše platni gejtvej u
kompleksnom sistemu procesiranja transakcija. Analizirano je opšte stanje
platnih sistema u svetu i u Srbiji, šta je potrebno da poseduje jedan
kvalitetan platni gejtvej, kao i kakvi su generalni trendovi u svetu kada je u
pitanju elektronsko plaćanje.
Drugo poglavlje opisuje Maksekeskus gde se prvo opisuje način
registracije na sistem iz ugla korisnika sistema. Potom se detaljno opisuje
koje metode plaćanja postoje u ponudi, kao i koje dodatne usluge nudi
sistem. Na kraju se detaljno opisuje i jedna od usluga - portal za trgovce.
Detaljan osvrt na API obraĎuje se u trećem poglavlju. Prvo se
objašnjava struktura dostupnih HTTP metoda, a potom se i objašnjavaju sve

12. XII
dostupne metode.
Model implementiranog sistema se objašnjava u četvrtom poglavlju.
Posmatra se prvo model plaćanja karticama, a zatim plaćanja preko
bankovnog linka.
U petom poglavlju je prikazana implementacija sistema, objašnjene
su tehnologije koje su korišćene za implementaciju, osvrt na frontend,
potom na bekend, i na kraju su prikazani i detalji implementacije.
Šesto poglavlje sadrţi zaključna razmatranja i ocenu kvaliteta ovog
platnog sistema.
Novi Sad, septembar 2016.
Zlata Milošević

13. 1
1. UVOD
Internet payment gateway koji se prevodi kao platni gejtvej
predstavljaju vrata za ostvarivanje onlajn prodaje na veb portalima. Platni
gejtvej treba posmatrati kao tehničko rešenje, ekvivalent fizičkog terminala
za naplatu, koje omogućuje naplatu kreditnim i debitnim karticama na
online prodavnicama i drugim web lokacijama [1]. Zadatak platnih
gejtvejeva je da obezbedi autorizaciju i sigurnost korisnika pri onlajn
kupovini i ponaša se kao medijator izmeĎu transakcija koje dolaze sa veb
lokacije do internet platnog procesora (Internet payment processor) [1].
Platni gejtvej štiti poverljive podatke koji se razmenjuju izmeĎu kupca i
prodavca kao i izmeĎu prodavca i platnog procesora [1].
Internet platni procesori i finansijske institucije (acquirer) su
pojmovi koji se često koriste kao isti pojmovi, a radi se o dve različite
funkcije. Finansijska institucija obraĎuje transakcije kreditnih i debitnih
kartica, a platni procesor je kompanija koja komunicira sa finansijskim
institucijama. Platni procesor je medijator izmeĎu finansijske institucije i
platnog gejtveja kada su u pitanju onlajn prodavnice [2]. Procesori prenose
podatke izmeĎu banke koja je izdala kreditnu/debitnu karticu i banke gde je
onlajn trgovac otvorio merchant account, trgovački nalog [3]. Često su
platni procesori upravo finansijske institucije, zbog čega i dolazi do
poistovećivanja ovih pojmova. U nekim slučajevima platni procesori
implementiraju i njihov platni gejtvej, sami rade na promovisanju i direktno
komuniciraju sa prodavcima [3]. Ipak, većina platnih procesora se fokusira
samo na obradu plaćanja i ne bavi se promocijom usluga, nego to
prepuštaju takozvanim nezavisnim prodajnim organizacijama Independent
sales organizations (ISOs) [4]. Poznat je i pojam „član dobavljača usluga“,
Member service providers (MSPs) [5], MasterCard objašnjava da su to
najčešće banke ili finansijske institucije koje imaju ugovore sa MasterCard-
om, njihovi su članovi i poštuju sve MasterCard standarde. ISO i MSP su
nezavisne firme koje imaju potpisane ugovore o saradnji sa više različitih
platnih procesora i one se bave promocijom i prodajom servisa [6].
Platni gejtvej je interfejs, tehnološko rešenje koje na kraju

14. 2
komunicira izmeĎu korpe za kupovinu (shopping cart) na veb sajtu i
servera platnog procesora. Ovaj sloj je neophodan zato što korpe za
kupovinu nemaju ovlašćenje da direktno komuniciraju sa serverom platnih
procesora, prvenstveno zbog sigurnosti. Platni gejtvej često moţe biti i
zasebna kompanija koja radi partnerski ili ima ISO ugovor sa bankom ili
platnim procesorom kako bi obezbedio vrhunske usluge [7].
Da bi korisnik usluge mogao da integriše usluge plaćanja karticama
na vebsajtu, potrebno je da sklopi ugovor sa kompanijom koja ima platni
gejtvej. Korisnik treba da ima internet trgovački nalog (Internet Merchant
Account) [7]. Internet trgovački nalog je vrsta bankarskog računa koji ima
mogućnost naplate kreditnih i debitnih kartica preko veb sajtova. Trgovački
nalog se moţe dobiti od internet platnog procesora, od platnog gejtveja, od
ISO-a ili MSP-a. [7]
1.1. Platni procesori i gejtvejevi u svetu
Danas u svetu postoje različiti platni procesori i platni gejtvejevi, pa
stoga usluga varira, kako sa kvalitetom, tako i sa cenom. Obično se cena
usluga formira na osnovu opisa biznisa, procene da li se radi o mikro ili
makro transakcijama i broja predviĎenih transakcija na mesečnom nivou.
Na osnovu ovih parametara cena se izraţava najčešće u tri segmenta:
mesečna fiksna cena za odrţavanje softvera, fiksna cena po svakoj
transakciji (zarada platnog gejtveja) i procenat od svake transakcije (zarada
platnog procesora) [8].
Cene poprilično variraju, pa je neophodno dobro razmisliti koji platni
gejtvej najviše odgovara biznis modelu. Kvalitet platnog gejtveja se moţe
posmatrati iz dva ugla, iz ugla vlasnika onlajn lokacije i ugla developera.
Dobar platni gejtvej treba da pokrije oba aspekta da bi se dobro
pozicionirao na trţištu [9].
Vlasnik onlajn prodavnice očekuje od platnog gejtveja:
 podršku većeg broja različitih valuta

15. 3
 brzu obradu kartica
 razumni period isplate
 podršku od banke
 prijemčljive cene
 panel za praćenje transakcija
 mogućnost refundacije (povraćaja) novca
 zrelost i stabilnost platnog gejtveja
Dobar platni gejtvej treba developeru da obezbedi:
 kvalitetan aplikacioni programski interfejs
 dobru dokumentaciju za implementaciju
 administratorski panel za praćenje transakcija
 test okruţenje
 test kartice
 mogućnost prilagoĎavanja izgleda
 tehničku podršku
 podršku za mobilne ureĎaje
 plugin podrška za različite CMS (Content Management System)
platforme i framework-e (programske okvire)
Sve su ovo parametri po kojima moţemo rangirati različite sisteme za
plaćanje na trţištu. Zemlje na severu Evrope su poprilično razvijene na
ovom polju, jer imaju ureĎen bankarski sistem, ureĎene domaće banke i

16. 4
otvorene su za komunikaciju i razvoj nezavisnih platnih gejtvejeva. Tako,
samo u nordijskim zemljama postoji desetak popularnih platnih gejtvejeva
koji se razlikuju po ponudi usluga.
Prostor za razvoj usluga za veb kupovinu se ogleda u tome da se teţi
izbegavanju upotrebe kreditnih kartica i utvrĎivanje novih rešenja za
autentifikaciju i naplatu.
Na primer:
 Klarna [10], švedski platni gejtvej daje mogućnost kupcu da pri
kupovini unese samo social ID (ekvivalent JMBG) i šifru, sistem
prepoznaje kupca, njegove lične podatke automatski unosi u
formular i korisnik obavlja kupovinu. Interesantno je da se ljudi
plaše upotrebe kreditnih kartica zbog zloupotrebe podataka, ali su
prihvatili da unose identifikacioni broj i šifru na osnovu kojeg
online prodavnice prepoznaju korisnika i vrše naplatu.
 ApplePay [11], Apple mobilni sistem za naplatu koji koristi NFC
(near field communication) tehnologiju, planira da u najnovijoj
verziji iOS 10 (Apple operativni sistem za mobilne ureĎaje) i
macOS Sierra (Apple operativni sistem sa računare) prošire
mogućnost ApplePay sistema i na veb. Korisnik bi na veb
prodavnici odabrao opciju da se slaţe sa uslovima ApplePay
kupovine i autentifkacija korisnika bi se vršila preko Apple
pametnog sata (Apple Watch), tako što će korisnik dobiti
obaveštenje da li ţeli da potvrdi identitet i kupovinu na veb lokaciji.
Prostor za razvoj i unapreĎenje veb usluga platnog gejtveja se nalazi i
u osavremenjavanju samih usluga [12]:
 olakšavanje procesa kupovine
 smanjenje koraka u interfejsu pri kupovini
 ponudi alternativnih načina kupovine

17. 5
 inovativan pristup kupovini
 podrška za aplikacije na mobilnim ureĎajima
Na primer:
 Klarna[10] nudi mogućnost da ne izvršite uplatu pre nego što
dobijete proizvod. Kada dobijete naručeni proizvod i potvrdite da
ste zadovoljni, onda se izvrši transakcija na računu.
 Finska kompanija Paytrail [13] nudi mogućnost da se korisnik
jednom registruje i da se taj korisnički nalog koristi na svim
sajtovima gde je integrisan PayTrail sistem naplate.
Trenutno i najveći prostor za razvoj onlajn kupovine se oseti na
mobilnoj platformi. Velika je borba na ovom trţištu i pitanje je koji sistem
će opstati i biti široko prihvaćen.
1.1. Platni procesori i gejtvejevi kod nas
Kada je u pitanju Srbija, spadamo u nerazvijenije zemlje. Trenutno
na trţištu postoji samo nekoliko sistema integracije onlajn plaćanja na veb
sajtovima. Tri banke (Intesa, Raiffeisen Bank, UniCredit) [14] [15] koje
posluju u Srbiji, registrovane su kao ISO ili eventualno kao MSP i
omogućavaju plaćanje karticama na domaćim veb prodavnicama u dinarima
i iz inostranstva u devizama. Pre četiri godine to je omogućavala samo
banka Intesa. Ove banke imaju svoje gejtvejeve koje razvijaju. Postoje još
dve firme u Srbiji koje se bave preprodajom sistema ovih banaka. Na trţištu
se pojavio i platni gejtvej strane kompanije SecurePay [16].
Problem nerazvijenosti se prvenstveno odnosi na poslovnu logiku

18. 6
kojom se vode banke koje nude platne gejtvejeve. Banke se ponašaju
previše korporativno i deluju netransparentno, što recimo malom trgovcu
koji planira da prodaje čarape domaće proizvodnje na lokalnom trţištu,
nikako ne odgovara.
Bitne stvari prilikom odabira sistema za onlajn plaćanje su:
 cena usluge
 da li postoji plugin za standardna CMS rešenja onlajn prodavnica
 ukoliko se radi o prilagoĎenoj (custom) integraciji sistema na veb
sajtu, developera zanima dokumentacija za API (Application
programming interface)
Ni na jednom sajtu platnih gejtvejeva koji su dostupni u Srbiji nisu
istaknute ove tri osnovne stavke. Neophodno je direktno kontaktirati agenta
ponuĎača za više informacija. Za svrhe ovog rada, kontaktirani su svi
pomenuti sistemi dostupni u Srbiji, kako bi se obezbedila verodostojnost
njihove ponude. Svaki od njih je traţio detaljan biznis plan, sem firme koja
zastupa SecurePay. Neki ponuĎači traţe podatke registrovane firme sa
pozitivnim poslovanjem. Kada ponuĎači dobiju sve informacije koje traţe,
dostavljaju ponudu, nakon čega se potpisuje ugovor. Banka Intesa ima
posebno rigorozna pravila o dizajnu veb stranice na kojoj se vrši transakcija
što govori o njihovoj staromodnoj implementaciji platnog gejtveja i o
nepostojanju automatizovanih servisa za testiranje prodavnice.
Narodna banka Srbije (NBS) je objavila zvaničnu statistiku o onlajn
kupovini u Srbiji u julu ove godine [17]. U prva tri meseca ove godine,
prema podacima NBS, graĎani su imali najviše transakcija platnim
karticama preko Interneta u evrima, odnosno imali su ukupno 396.802
plaćanja u toj valuti, a slede dolari sa 360.972 plaćanja, dok su na trećem
mestu dinarske transakcije, kojih je bilo ukupno 244.330. Broj transakcija iz
izveštaja pretočene u valute su za dinarske transakcije milijardu dinara, u
evrima oko 17 miliona eura, a u dolarima oko 7,8 miliona eura. Iz ovih

19. 7
brojeva moţe se doneti zaključak da graĎani Srbije kupuju najviše na
stranim onlajn prodavnicima i vebsajtovima. Na osnovu statistike se moţe
videti i da se u odnosu na 2015. godinu broj ostvarenih transakcija povećao
za 30% u 2016. godini. GraĎani Srbije ţele i rado kupuju na internetu i
očekuje se dalji rast ostvarenih transakcija.

20. 8

21. 9
2. MAKSEKESKUS
Sloţenica Maksekeskus [18] na estonskom znači "centar za naplatu".
Kao startap, 2012. godine su krenuli da razvijaju platformu koja će
omogućavati manjim firmama da lako i jednostavno integrišu onlajn
naplatu na veb sajtovima i imaju odmah agregirani pristup različitim
bankama i kartičarskim uslugama.
U avgustu 2013. godine Estonska pošta (Eesti Post) [19] je kupila
51% tadašnjeg startapa Maksekeskus AS i tako postala većinski vlasnik.
Njihova ideja je da prošire poslovanje pošte sa logistike na usluge onlajn
kupovine u Baltičkim drţavama. Maksekeskus je u tom momentu poslovao
samo u Estoniji, a za 3 godine se proširo i na Letoniju i Litvaniju, i pred
kraj 2015. godine na Finsku sklapanjem partnerskog ugovora sa
kompanijom PayTrail [13]. Imaju partnerske ugovore sa bankama u
Švedskoj i Danskoj [20].
2.1. Registracija
Kada trgovac onlajn prodavnice poţeli da implementira onlajn
plaćanje koje nudi Maksekeskus potrebno je da proveri na listi od deset
tačaka, da li njegova prodavnica zadovoljava sve zahteve koje traţi
Maksekeskus. Lista je javno dostupna [21], a po njoj se podrazumeva da su
na sajtu jasno prikazani kontakt podaci, da sadrţi stranicu o zaštiti privatnih
podataka, stranicu o uslovima korišćenja, da je naznačeno na sajtu kako se
vrši isporuka, da je prodavnica funkcionalna i ispravna. Kao deseta tačka
navodi se da firma koja stoji iza onlajn prodavnice nema poreskog duga
prema drţavi Estoniji.
Nakon toga je potrebno da se popuni formular koji je takoĎe javno
dostupan na sajtu. Prijavu moţe da popuni fizičko lice ili kompanija. Unose

22. 10
se informacije o vebsajtu, podaci firme, podaci kontakt osobe, bira se od
ponuĎenih opcija koja CMS platforma je korišćena i bira se koje vrste
plaćanja ţele da omoguće na vebsajtu. Od specifičnijih informacija
potrebno je uneti procenjeni broj transakcija na mesečnom nivou i vrednost
prosečne transakcije. Potrebno je uneti i informacije o bankovnom računu
trgovca koji će se koristiti za isplatu novca koji se zaradi preko prodavnice.
Sistem registracije je izuzetno transparentan i jasan. Pre bilo kakvog
pristupa servisu, trgovac moţe i da pogleda dokumentaciju API-a kao i da
proveri dostupnost već gotovog modula za CMS koji koristi. Na ovaj način
trgovac moţe da isprojektuje troškove unapred i da bude siguran koliko će
vremena biti potrebno za integraciju i kojeg developera treba zaposliti za taj
proces.
Nakon registracije, trgovac dobija prvo pristup test portalu za
trgovce. Nakon uspešne implementacije platnog gejtveja, Maksekesus
odobrava upotrebu i daje pristup live portalu za trgovce. Za testiranje na
sajtu, javno su dostupne test kartice i test podaci za banke.
Test portal i live portal su skoro identični, a nalaze se na različitim
adresama. Test portal je na https://merchant-test.maksekeskus.ee, a live
portal je na https://merchant.maksekeskus.ee. Sve funkcionalnosti koje se
nalaze na test portalu nalaze se i na live portalu.
Maksekeskus je na sajtu napravio i javno postavio dostupan alat API
explorer[18] koji pomaţe da developer brţe startuje sa implementacijom i
da lakše razume kako sistem funkcioniše.
2.2. Metode plaćanja
Maksekeskus nudi integraciju dve metode plaćanja [18]:
1. Bankovni link (bank link) je metod plaćanja koji je vrlo popularan u

23. 11
Baltičkim zemljama. Maksekeskus omogućava da potpisivanjem
ugovora sa njima trgovac dobija pristup bankama u Estoniji,
Letoniji, Litvaniji i Finskoj, što je ukupno 11 banaka. Trgovac ne
mora da ima ugovore sa jedanaest banaka nego samo sa firmom
Maksekeskus, čime se smanjuju troškovi za takse pri otvaranju
naloga i značajno ubrzava ceo proces [22].
2. Integracija naplate kreditnim i debitnim karticama (Visa,
MasterCard i Maestro) se vrši na stranici onlajn prodavnice gde
korisnik popunjava podatke sa kartice i vrši plaćanje ne napuštajući
stranicu prodavnice. Postoji i mogućnost 3D secure zaštite koja
moţe dodatno da se uključi na nalogu po zahtevu onlajn trgovca.
Maksekeskus sistem moţe da se integriše i tako da omogući
korisniku da sačuva podatke sa kartice na svom nalogu na veb
sajtu. TakoĎe, integracija je moguća i tako da korisnik uopšte ne
mora biti registrovan na vebsajtu i da kupovinu izvrši kao gost, a ne
ostavi podatke o kartici na sajtu [23].
Pri kupovini, kupac bira da li ţeli da plati karticom ili preko bankovnog
linka.
Ukoliko izabere kupovinu preko bankovnog linka, dobija listu banaka koje
su dostupne u njegovoj zemlji (lista banaka se isporučuje preko API-ja tako
što se POST metodom pošalje oznaka zemlje korisnika). Kupac selektuje
ţeljenu banku (najčešće banku u kojoj i sam ima račun zbog manje
provizije) i klikom na dugme za potvrdu se preusmerava na veb sajt banke.
Na stranici veb sajta banke kupac popunjava formular i vrši kupovinu,
nakon čega biva preusmeren nazad na onlajn prodavnicu sa koje je pre toga
došao (slika 2.1.).

24. 12
Slika 2.1. Kako funkcioniše plaćanje preko bankovnog linka
Ukoliko korisnik izabere plaćanje karticom, pokreće se javascript popup na
stranici vebsajata i korisnik unosi podatke sa kartice u popap prozor. Nakon
potvrde, ukoliko su podaci ispravni, popap se zatvara, prikazuje se stranica
sa porukom o uspešnoj naplati i transakcija je završena (slika 2.2.).
Slika 2.2. Kako funkcioniše plaćanje direktno karticama

25. 13
2.3. Usluge
Maksekeskus u ponudi ima još nekoliko usluga [24]:
 Ponovljene naplate – za onlajn servise kao što su SaaS, pretplate,
donacije i slične vrste servisa, omogućena je ponovljena periodična
naplata (dnevno, nedeljno, mesečno i tromesečno). Moţe se
integrisati čuvanje podataka kartice na nalogu korisnika kada će
Maksekeskus automatski periodično skidati odreĎenu sumu novca
sa naloga korisnika (ukoliko ima novca na računu).
 Naplata jednim klikom (one-click payment) - za korisnike onlajn
prodavnice koji su uneli svoje podatke sa kartice na nalogu
prodavnice moţe se omogućiti brza naplata sa samo jednim klikom.
 Portal za trgovca je dostupan svakom registrovanom trgovcu gde
moţe da prati realizovane i nerealizovane transakcije. Više o
portalu će biti reči u narednom poglavlju 2.4.
 Link za naplatu – trgovac moţe na Portalu za trgovce ručno da
kreira link za naplatu i pošalje ga direktno krajnjem kupcu. Moţe
biti korisno za blogove i omogućavanje uplate donacija.
 Povraćaj novca – trgovac preko Portala za trgovce moţe da u
nekoliko klikova izvrši povraćaj novca.
 Automatizovani povraćaj novca – trgovac moţe da koristi usluge
automatizovanog povraćaja novca čime štedi vreme.
 Automatizovan izvoz podataka – trgovac moţe da implementira
preko API-ja da se automatski periodično izvoze i uvoze podaci o
transakcijama u eksterni softver.

26. 14
2.4. Portal za trgovca
Na portalu trgovac moţe da vidi i preuzima jedinstveni ID
prodavnice (Shop ID), a moţe da izgeneriše tajni ključ (Secret key) i
objavljivi ključ (Publishable key). Pogledati sliku 2.3.
Ove informacije se koriste pri implementaciji sistema kako bi sistem
identifikovao prodavnicu i kako bi poslati zahtevi bili verifikovani i
autorizovani. Detaljnije o ovome se moţe naći u poglavlju 3.
U podešavanjima portala treba podesiti link za povratak (Return url)
koji se koristi kao lokacija za preusmeravanje nakon transakcije, link za
prekid (Cancel url) ukoliko korisnik usred transakcije odustane i link za
obavešenje (Notification url) na koji sistem šalje asinhrona obaveštenja
prilikom uspešne transakcije. Linkovi mogu da se podese kao GET ili
POST linkovi, a takoĎe je i moguće postaviti linkove koji ukazuju na
localhost ukoliko se razvoj vrši na računaru u lokalu (slika 2.3.).
Slika 2.3. Stranica portala za generisanje ključeva i podešavanje
Portal je neophodan za pregled svih transakcija koje su obavljene na
prodavnici. Svaka transakcija ima jedinstvenu referentnu oznaku obavljene
kupovine. Kod svake transakcije se moţe videti ime i prezime kupca (sa
kartice ili sa formulara preko bankovnog linka), datum transakcije kada je
kreirana, datum kada je uspešno završena, status transakcije, ukupna
vrednost transakcije, vrednost provizije, vrednost poreza i na kraju neto

27. 15
zarada trgovca. Portal nudi i jednostavan grafički prikaz realizovanih i
refundiranih transakcija. Prikaz na slici 2.4.
Slika 2.4. Glavna kontrolna tabla sa grafičkim i tabelarnim prikazom
transakcija
Pri integraciji sistema trgovac ima mogućnost da kreira sopstveni
bekend unutar onlajn prodavnice, gde bi podatke i transakcije prikazao na
drugačiji način.
Ţivotni ciklus transakcije moţe dobiti 8 različitih statusa. Statusi
označavaju da li je transakcija uspešno realizovana i u kojoj situaciji je
došlo do promene.
 CREATED - prvi status svake transakcije, transakcija je inicijalno
kreirana

28. 16
 PENDING – kupac je selektovao sistem plaćanja koji ţeli da koristi
(npr. Selektovao je da će platiti preko bankovnog linka i
redirektovan je na sajt banke)
 CANCELLED – transakcija je namerno prekinuta od strane kupca
 EXPIRED – transakcija je inicijalizovana, ali uplata nije izvršena
(stanje istekle transakcije se beleţi nakon 25 minuta)
 APPROVED – Naplata je protekla uspešno, ali je neophodna još
neka dodatna akcija. Kupac je prošao sve neophodne korake i
transakcija je autorizovana, ali u zavisnosti od metode plaćanja,
nekada je potrebna dodatna akcija od strane trgovca, Maksekeskusa
ili platnog procesora. Tako recimo, kod plaćanja preko bankovnog
linka, transakcija je autorizovana, ali se čeka konačna potrvda
banke. Kod plaćanja karticom, transakcija je autorizovana, sredstva
su dostupna i rezervisana na računu kupca i čeka se finalna
realizacija. Neke od metoda za plaćanje preskaču status
APPROVED i odmah sa PENDING prelaze na status
COMPLETED.
 COMPLETED – Transakcija je autorizovana i uspešno završena.
Novac je prebačen na račun trgovca i trgovac moţe da isporuči
robu ili uslugu.
 PART_REFUNDED – transakcija je delimično refundirana, ne u
potpunosti.
 REFUNDED – transakcija je potpuno refundirana.
Na portalu se mogu filtrirati transakcije na osnovu statusa transakcije.
Pogledati na slici 2.5.

29. 17
Slika 2.5. Tabelarni prikaz svih transakcija po datumu kreiranja
Na portalu za trgovce na posebnim stranicama izlistani su pregledi
refundiranih transakcija (slika 2.6.), isplata na račun trgovca (slika 2.7.),
kao i kompletna istorija ulaza i izlaza novca na Maksekeskus platformi
(slika 2.8.). Na posebnoj stranici je uvek dostupna aţurirana lista banaka i
njihovih provizija.
Slika 2.6. Tabelarni prikaz refundiranih transakcija

30. 18
Slika 2.7. Tabelarni prikaz isplata
Slika 2.8. Kompletan pregled ulaz/izlaz pogodan za računovoĎe
Maksekeskus je napravio i posebnu stranicu kojoj se moţe pristupiti i
kada korisnik servisa nije ulogovan, gde u realnom vremenu uvek moţe da
se proveri da li je server onlajn i kada je bio poslednji pad servera [25].
Na portalu, trgovac moţe da kreira i link za naplatu (Payment link)
koji je već spomenut u prethodnom poglavlju. Link za naplatu se moţe
korisititi u slučajevima kad trgovac ţeli da pošalje link kupcu sa posebnom
cenom. Na stranici portala se unosi konkretna cena, portal izgeneriše QR
kod za ovaj link i daje mogućnost kopiranja linka za dalju distribuciju.
Prikaz na slici 2.9.

31. 19
Slika 2.9. Prikaz stranice za ručno kreiranje platnog linka
Na izgenerisanom linku se kupcu prikazuje račun i mogućnost
odabira metode za plaćanje (slika 2.10.).
Slika 2.10. Izgenerisani račun za ručno kreiran platni link

32. 20
Ukoliko trgovac ima više onlajn prodavnica, one sve mogu da se
prate sa istog naloga na portalu. Potrebno je samo selektovati domen iz
padajućeg menija koji predstavlja onlajn prodavnicu, i prikazaće se
kompletna statistika za izabranu prodavnicu (slika 2.11.).
Slika 2.11. Odabir jedne od više onlajn prodavnica na istom nalogu

33. 21
3. RESTful JSON API
Maksekeskus API je implementiran u Javi u Spring framework-
u[26]. API je implementiran kao bazični JSON (JavaScript Object
Notation)[27] objekat preko HTTPS (Hypertext Transfer Protocol
Secure)[28] protokola koji koristi četiri REST (Representational State
Transfer)[29] komande – GET, POST, PUT i DELETE.
3.1. Autentifikacija i autorizacija
API zahtevi se šalju preko HTTPS protokola. Svaki zahtev mora biti
autentifikovan sa ID-jem prodavnice i sa API autentifikacionim ključem
koristeći HTTP Basic autentifikaciju[30].
Postoje dva tipa autentifikacionog ključa[31]:
 Objavljivi ključ (Publishable Key) se koristi za API zahteve od
strane frontenda prodavnice gde token moţe biti javno vidljiv.
Koristi se za zahteve kao što su kreiranje transakcionih objekata,
povlačenje liste metoda za naplatu, prihvatanje valuta i slično.
 Tajni ključ (Secret Key) koji nazivamo i API ključ se koristi za
zahteve kao što je kreiranje naplate, naplaćivanje kartica i slično.
U zavisnosti od zahteva koji se kreira, zavisi i tip autentifikacionog
tokena koji se koristi. Postoje dva nivoa autentifikacije [31].
Nivo 1 - klijent se autentifikuje sa objavljivim ključem (koristi se
kao korisničko ime, lozinka moţe biti prazna)

34. 22
Nivo 2 - klijent se autentifikuje sa ID-jem prodavnice i tajnim
ključem
Za svaki API endpoint (krajnje tačke) u dokumentaciji je eksplicitno
navedeno koji nivo autentifikacije treba koristiti.
U Listingu 3.1. dat je primer zaglavlja koje se šalje za kreiranje transakcije.
Vidi se primer kako se gradi Basic autentifikacija sa ID-jem prodavnice i
tajnim ključem. $shopId je promenljiva koja sadrţi ID prodavnice i koristi
se kao korisničko ime za kreiranje autorizacionog tokena. $secretKey je
lozinka u Basic autentifikaciji
'headers' => [
'Content-Type' => 'application/json',
'Authorization' => 'Basic ' . base64_encode($shopId .
':' . $secretKey)
],
Listing 3.1. - header koji se šalje u slučaju kreiranja transakcije
3.2. HAL
API u situacijama kada je to moguće koristi HAL+JSON media-type. (HAL
- Hypertext Application Language). HAL je format koji omogućava
dokumentaciju za API vidljivu iz samih API response poruka. Konkretno,
HAL omogućava developerima da istraţuju API slanjem praznih JSON
objekata, gde kao odgovor od API-ja u telu poruke dobijaju šta to API
očekuje da dobije u zahtevu. HAL čini API lakšim za rad i poţeljnijim u
krugu developera [32].

35. 23
3.3. Struktura API zahteva (API request)
Maksekeskus se drţi RESTful principa u API-ju, pa tako prikazivanje,
izlistavanje i druge slične akcije su uraĎene sa GET, kreiranje sa POST,
aţuriranje sa PUT i brisanje sa DELETE zahtevom.
3.3.1. URL struktura
https://shop_id:secret_key@api.maksekeskus.ee/v1/transa
ctions/{trx_id}/refunds/{refund_id}
Listing 3.2. - URL breakdown
Na listingu 3.2. je prikazana struktura linka, a u daljem tekstu je objašnjen
svaki segment URL-a.
 https - HTTP protokol sa enkriptovanom konekcijom SSL (Secure
Sockets Layer) ili TLS (Transport Layer Security)
 shop_id - korisničko ime za Basic autentifikaciju
 api_key – lozinka za Basic autentifikaciju
 api.maksekeskus.ee – domen API-ja
 transactions – resurs koji je zatraţen u zahtevu
 trx_id – identifikacija resursa (ID transakcije)
 refunds – podresurs koji deluje u okviru prethodnog resursa u linku
 refund_id – identifikacija podresursa (ID refundacije)

36. 24
U request body-ju moţe da se šalje samo JSON objekat. U request header-u
mora biti definisan Content-Type: application/json
3.4. Struktura API odgovora (API response)
Status: 200
Content-Length: 27
Content-Type: application/json; charset=utf-8
Listing 3.3. - Response header
Na listingu 3.3 je prikazan response header sa HTTP status kodom 200 i
poljima koja nose dodatne informacije o odgovoru.
3.4.1. Validacija odgovora
Prilikom slanja zahteva, sve što je vezano direktno za poruku, šalje se kao
JSON objekat u request parametru 'json', a autentifikacioni kod MAC
(message authentication code) se šalje kao parametar 'mac'.
Kreiranje 'mac' parametra:
UPPERCASE(HEX(SHA-512(string(JSON)+string(SecretKey))))
Da bi se proverila autentičnost poruke potrebno je kreirati MAC baziran na
JSON i SecretKey informacijama i uporediti ih sa MAC koji se dobije iz
zahteva.

37. 25
3.4.2. Response body
Odgovor nakon kreiranja transakcije ima ovakav response header sa status
kodom 200:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
dok se u telu odgovora dobija JSON sa sledećim podacima koji su prikazani
na Listingu 3.4.
{
"id": "7c579fd0-8d46-11e1-b0c4-0800200c9a66",
"object": "transaction",
"created_at": "2014-04-14T02:15:15Z",
"status": "CREATED",
"amount": 12.93,
"currency": "EUR",
"reference": "abc123",
"merchant_data":
"234567890;abc123;new_transaction=5432",
"type": null,
"customer": {
"id": "7c579fd0-8d46-11e1-b0c4-0800200c9a66",
"object": "customer",
"created_at": "2014-04-14T02:15:15Z",
"email": "customer@email.com",
"ip": "234.12.34.567",
"ip_country": "fi",
"country": "ee",
"locale": "et"
},
"payment_methods": {
"banklinks": [
{
"name": "swedbank",
"url":
"https://payment.maksekeskus.ee/banklink.html?trx=23424
213&method=EE_SWED"

38. 26
},
{
"name": "lhv",
"url":
"https://payment.maksekeskus.ee/banklink.html?trx=23424
213&method=EE_LHV"
}
],
"cards": [
{
"name": "visa"
},
{
"name": "mastercard"
}
]
}
}
Listing 3.4. - Telo odgovora transakcije
Kao što se vidi na Listingu 3.4, u odgovoru zahteva pri kreiranju
transakcije, API vraća pored podataka vezanih za transakciju i korisnika, i
podatke vezane za metode plaćanja. Na ovaj način API omogućava
kompletnu integraciju bez slanja dodatnog zahteva za metode plaćanja.
MeĎutim, u samom API-ju postoji mogućnost slanja i dodatnnog zahteva
koji vraća dostupne metode za plaćanje kako bi se uradila i prilagoĎena
implementacija.
3.5. Paginacija (Pagination)
API ima rešenje za paginaciju u slučajevima kada zahtev vraća više
rezultata u obliku liste ili kolekcije. Ovi zahtevi su uvek GET https zahtevi i
automatski će vratiti 30 rezultata. U samom linku se moţe dodatno
precizirati nastavak ?page parametar koji predstavlja redni broj stranice

39. 27
rezultata. Moţe se dodati i parametar ?per_page koji označava broj
rezultata po stranici umesto podrazumevanih 30.
https://api.maksekeskus.ee/transactions?page=2&per_page=100
Informacija o paginaciji se prenosi u Header-u kao Link. Neophodno je
pratiti ovakvu strukturu:
Link:
<https://api.maksekeskus.ee/transactions?page=3&per_pag
e=100>; rel="next",
<https://api.maksekeskus.ee/transactions?page=50&per_pa
ge=100>; rel="last"
rel atribut moţe imate sledeće vrednosti:
next – prikazuje url od narednog seta rezultata
last – prikazuje url od poslednjeg seta rezultata
first – prikazuje url od prvog seta rezultata
prev - prikazuje url od prethodnog seta rezultata
3.6. Lista HTTP metoda dostupnih u API-ju
U poglavljima 3.3. i 3.4. uopšteno je objašnjeno kako se kreiraju zahtevi i
šta se dobija u odgovoru zahteva. Maksekeskus API je kreiran kao JSON
RESTful API, gde se razmenjuju samo JSON objekti. Tako se u telu
zahteva šalje uvek JSON objekat i u telu odgovora se vraća JSON objekat
sa podacima. U narednom podpoglavlju biće nabrojane sve metode koje su
dostupne u API-ju [31].

40. 28
3.6.1. Maksekeskus API metode
1. GET metoda na link https://api.maksekeskus.ee/v1/shop vraća
JSON objekat Shop koji predstavlja entitet sa osnovnim
podešavanjima prodavnice. Podešavanja se mogu vršiti i preko
onlajn portala za trgovce, a i preko API-a. Response zahteva je
prikazan na Listingu 3.5. JSON objekat se sastoji iz:
identifikacionog broja, tipa objekta, datuma kreiranja i izmene,
statusa, linkova za povratak i notifikacionih linkova.
{
"id": "4aacecdc-e665-41cf-8d46-31a20f7c407d",
"object": "shop",
"created_at": "2014-10-17T14:27:35Z",
"modified_at": "2014-11-30T11:09:15Z",
"status": "active",
"return": {
"url": "http://localhost/return",
"method": "post"
},
"notifications": {
"url": "http://localhost/notification",
"method": "get",
"email": "notifications@url.com"
}
}
Listing 3.5. - JSON objekat za entitet Shop
2. PUT metoda na link https://api.maksekeskus.ee/v1/shop daje
mogućnost izmene podataka u podešavanjima prodavnice.
Obavezan parametar je url i koristi se autentifikacija Nivoa 2.
3. GET metoda za dobijanje liste provizija se šalje sa obaveznim
parametrima datuma od i do i autentifikacijom Nivoa 2. Primer
URL-a https://api.maksekeskus.ee/v1/shop/fees?since=2016-08-

41. 29
01&until=2016-09-01&page=1&per_page=5
4. GET metoda vraća listu dostupnih metoda plaćanja za potencijalnu
transakciju. U zahtevu treba poslati ukupnu sumu, oznaku zemlje i
oznaku valute. Koristi se autentifikacija Nivoa 1. Primer GET
URL-a:
https://api.maksekeskus.ee/v1/methods?amount=12.95&currency=
EUR&country=ee
5. GET metoda koja vraća listu dostupnih metoda za plaćanje za već
kreiranu transakciju. Koristi se autentifikacija Nivoa 1 i šalje se
parametar transaction ID. Primer:
https://api.maksekeskus.ee/v1/methods?transaction=7c579fd0-
8d46-11e1-b0c4-0800200c9a66
JSON objekat se definiše izmeĎu vitičastih zagrada. Mogu sadrţati
nizove JSON objekata koji se definišu izmeĎu uglastih zagrada sa
name/value sintaksom. U telu odgovora se dobija JSON objekat
koji se sastoji od ugnjeţdenih nizova sa nazivima 'banklinks' i
'cards' i vrednostima kompletnog objekta. U JSON-u prikazanom na
Listingu 3.6. vide se dva objekta u nizu 'banklinks' koja daju
informacije o linkovima ka dostupnim bankama za odabranu zemlju
na osnovu poslate transakcije. U nizu 'cards' su izlistani objekti koji
predstavljaju vrste kartica koje se mogu koristiti za traţenu
transakciju.
{
"banklinks": [
{
"name": "swedbank",
"url":
"https://payment.maksekeskus.ee/banklink.html?meth
od=EE_SWED&trx=",
"country": "ee"
},
{

42. 30
"name": "lhv",
"url":
"https://payment.maksekeskus.ee/banklink.html?meth
od=EE_LHV&trx=",
"country": "ee"
}
],
"cards": [
{
"name": "visa"
},
{
"name": "mastercard"
},
{
"name": "maestro"
}
]
}
Listing 3.6. - JSON objekat za metode naplate
6. Kreiranje transakcije se vrši sa POST metodom na URL
https://api.maksekeskus.ee/v1/transactions. Neophodni atributi za
kreiranje transakcije su: ukupna suma, oznaka valute, IP adresa
kupca i oznaka zemlje kupca. U zahtevu se mogu poslati i
transakcioni linkovi (return_url, cancel_url, notification_url) i na
taj način osveţiti njihove vrednosti unutar portala za trgovce.
Transakcije su centralni resurs u API-ju. Svaka transakcija se
sastoji iz sledećih atributa: id, object, created_at, status, amount,
fees, net_amount, currency, reference, merchant_data, type,
customer i transaction_url. Atributi kao što su id, object i
created_at se dodeljuju u trenutku kreiranja transakcije. Sve
metode koje rade sa transakcijama koriste autentifikaciju Nivoa 2.
7. Metoda koja vraća listu transakcija filtriranu na osnovu različitih
kriterijuma. U samom URL-u GET zahteva se šalju svi parametri
https://api.maksekeskus.ee/v1/transactions?since=2014-07-
02+0300&until=2014-08-02+0300&completed_since=2014-07-

43. 31
02+0300&completed_until=2014-08-
02+0300&status=COMPLETED,REFUNDED
8. Vraćanje pojedinačnog objekta transakcije sa GET metodom
https://api.maksekeskus.ee/v1/transactions/id gde je id oznaka
transakcije.
9. Kreiranje naplate za transakciju sa specifičnim tokenom za naplatu.
Metoda treba da se izvrši nakon kreiranja transakcije u slučaju da je
korisnik odabrao kreditnu karticu kao metodu plaćanja. Pravi se
POST zahtev na URL
https://api.maksekeskus.ee/v1/transactions/id/payments. U telu
zahteva treba poslati pored valute, sume i token koji se dobija iz
javascript popup-a u koji se unose podaci sa kartice. U ovom
momentu se status transakcije prebacuje iz CREATED u
APPROVED, odnosno u COMPLETED. U telu odgovora se dobija
JSON objekat koji sadrţi podatke vezane za naplatu i podatke
transakcije.
JSON objekat, nakon uspešno izvršene naplate, prikazan je na
Listingu 3.7. Ovaj objekat se sastoji iz više ureĎenih parova tipa
name/value i nizova koji sadrţe objekte. U prvom delu JSON
objekta su informacije o izvršenoj naplati zajedno sa objektom
'card' koja nosi informacije sa kartice korisnika gde su sakriveni
osetljivi podaci (ime, prezime i broj kartice).
Objekat 'transaction' sadrţi informacije o prethodno kreiranoj
transakciji na osnovu koje se vrši naplata. U 'transaction' se nalaze i
dodatni podaci o kupcu koji mogu da se koriste za internu upotrebu
na vebsajtu (za kreiranje naloga i čuvanje podataka o kupcima).
{
"id": "7c579fd0-8d46-11e1-b0c4-0800200c9a66",
"object": "payment",
"created_at": "2014-04-14T02:15:15Z",
"status": "CREATED",
"amount": 12.93,
"currency": "EUR",
"card": {

44. 32
"type": "visa",
"name": "M***** K***",
"last2": 42,
"exp_month": 12,
"exp_year": 15
},
"transaction": {
"id": "7c579fd0-8d46-11e1-b0c4-0806500c9a66",
"object": "transaction",
"created_at": "2014-04-14T02:15:15Z",
"status": "COMPLETED",
"amount": 12.93,
"currency": "EUR",
"reference": "abc123",
"merchant_data": "",
"type": "card",
"customer": {
"id": "7c579fd0-8d46-11e1-b0c4-
0800200c9a66",
"object": "customer",
"created_at": "2014-04-14T02:15:15Z",
"email": "customer@email.com",
"ip": "234.12.34.567",
"ip_country": "fi",
"country": "ee",
"locale": "et"
}
}
}
Listing 3.7. - JSON objekat u telu odgovora nakon naplate karticom
10. Transakcija moţe biti refundirana u potpunosti ili parcijalno. Za
povraćaj novca potrebno je poslati POST zahtev na URL
https://api.maksekeskus.ee/v1/transactions/id/refunds gde je id
oznaka transakcije. U telu zahteva obavezno je poslati sumu na
koju se vrši povraćaj novca i komentar kao razlog povraćaja novca.
Kada su u pitanju transakcije plaćene karticama, moguće je izvršiti
povraćaj novca samo jedanput. Transakcije preko banaka mogu da
se refundiraju više puta do konačne maksimalne sume. Transakcija
tada dobija status PART_REFUNDED ili REFUNDED.

45. 33
11. Vraćanje liste refundiranih transakcija koje mogu da se filtriraju po
statusu i datumu kreiranja. Šalje se GET zahtev sa potrebnim
parametrima što se vidi na linku:
https://api.maksekeskus.ee/v1/refunds?since=2014-07-
02&until=2014-08-02&status=CREATED,SENT

46. 34

47. 35
4. MODEL SISTEMA
Za potrebe ovog rada implementiran je Maksekeskus platni gejtvej na
primeru veb sajta koji nudi usluge savetovanja iz oblasti osiguranja. Veb
sajt nudi mogućnost korisniku da postavi pitanja iz odabrane oblasti
osiguranja uz novčanu nadoknadu. U ovom poglavlju predstavljen je model
sistema sa kupovinom karticama i bankovnim linkom.
Kupac na vebsajtu unosi: ime i prezime, email, bira kategoriju u vezi
koje postavlja pitanje, selektuje koliko pitanja ţeli da postavi, selektuje
metod plaćanja, selektuje kojom brzinom ţeli da dobije odgovor i konačno
unosi pitanja i šalje zahtev.
Na osnovu odabira kategorije, broja pitanja i brzine odgovora
izračunava se i prikazuje kolika je ukupna suma sa porezom koja će se
naplatiti kupcu. Klikom na dugme Submit, kupac se preusmerava na novu
stranicu gde se jasno prikazuje račun sa svim stavkama, cenama i taksama.
Ukoliko je odabrao na prethodnoj stranici karticu kao metod plaćanja,
pritiskom na dugme Checkout, prikazuje se checkout javascript popup u
koji unosi podatke kartice i potvrĎuje kupovinu. Ukoliko je izabrao metod
plaćanja bankovni link, potrebno je da odabere jednu od ponuĎenih banaka,
pritisne potom Pay Now dugme, nakon čega se preusmerava na stranicu
banke gde potvrĎuje kupovinu. Na kraju kupovine korisnik se preusmerava
nazad na stranicu vebsajta sa porukom o uspešnoj transakciji. (slika 4.1.)
Sistem moţe i drugačije da se implementira. Moţe se implementirati
da korisnik ne bira metod plaćanja u prvom koraku, nego na sledećoj
stranici kada se prikaţe račun, ponude se opcije za plaćanje. Pozivom preko
API-ja se povuku dostupne metode za plaćanje u zavisnosti od zemlje iz
koje je korisnik.
Kupac ne mora da bude registrovan korisnik sajta, nego moţe i kao
gost da izvrši kupovinu. Administrator na kontrolnoj tabli veb sajta prati
sve unose. Za ovaj rad je bitno sagledati kako funkcioniše implementirani
gejtvej, tako da će dalja razmatranja biti usmerena ka kupcu i

48. 36
implementaciji.
Slika 4.1. Use case dijagram korišćenja sistema od strane kupca
Korisnik sajta ima mogućnost da pošalje maksimalno 4 pitanja u
jednoj odabranoj kategoriji. Cene i takse su različite za različite kategorije.
Cene se formiraju u zavisnosti od odabranog broja pitanja, kategorije,
duţine pitanja i brzine odgovora. Potrebno je administratoru sajta omogućiti
da menja cene i procente taksi za različite kategorije i za različit broj
pitanja.
Sistem je implementiran u Laravel framework-u [33] o čemu će biti
detaljnijih objašnjenja u poglavlju 5. Potrebno je da administrator moţe da
vidi koja pitanja su postavljena, kome treba da odgovori, kao i u kom
vremenskom intervalu. Zbog toga je u Laravelu kreiran nezavisni modul
Inquires koji se stara za sekciju u vezi postavljanja pitanja. Modul ima
sopstveni MVC patern, pa se sastoji iz modela koji se sastoji od 5 entiteta.
Svaki entitet predstavlja jednu tabelu u bazi podataka gde su tabele
meĎusobno povezane primarnim ključevima. Kako je sajt multijezičan, bilo

49. 37
je neophodno napraviti i tabelu sa prevodom za nazive kategorije. Na slici
4.2. je predstavljen class dijagram za modul Inquires.
Kontroleri su implementirani unutar modula. Kreirani su i posebni
blade fajlovi za kreiranje, izmenu i brisanje kategorija i cena kojima se
pristupa preko kontrolne table sajta.
Slika 4.2. Class diagram za module Inquires
Osetljivi podaci kao što su ShopId i SecretKey se čuvaju u
environment promenljivama projekta. Podaci o karticama se ne čuvaju

50. 38
lokalno. Maksekeskus prati PCI-DSS standard (Payment Card Industry
Data Security Standard) [34] što ne omogućava preuzimanje i čuvanje
podataka. Podaci sa kartice se čuvaju preko SSL konekcije, preko
javascript popup-a. Iz Maksekeskus kompanije preporučuju korišćenje
SSL-a na onlajn prodavnicama, ali za integraciju njihovog platnog sistema
nije obavezno imati SSL sertifikat.
Na slici 4.3. prikazan je dijagram toka aktivnosti za obe metode
plaćanja (karticom i bankovnim linkom).

51. 39
Slika 4.3. Dijagram toka aktivnosti

52. 40
4.1. Plaćanje karticom
Ukoliko korisnik odabere karticu kao metod plaćanja, pritiskom na
Checkout dugme dobija popap sa formom gde je potrebno da ukuca podatke
o kartici. Obavezno je uneti:
 ime i prezime vlasnika kartice
 broj kartice
 datum isteka kartice
 bezbednosni kod (cvv2)
Nakon unosa podataka, korisnik treba da potvrdi kupovinu klikom na
dugme Submit. U slučaju da je došlo do nepravilnog unosa podataka, forma
će označiti koji podaci su pogrešno uneti. Ukoliko su uneti podaci dobro
uneti, ali netačni (nevalidni), forma će ispisati poruku o grešci (npr. istekao
je datum vaţenja kartice).
Ako je implementiran 3D secure sistem sa karticama, onda se nakon
potvrde na dugme Submit korisnik preusmerava na posebnu stranicu koja se
hostuje na sajtu Maksekeskusa i tu dodatno potvrĎuje kupovinu. Na slici
4.4. prikazan je dijagram sekvence za naplatu karticom.

53. 41
Slika 4.4. Dijagram sekvence za naplatu karticom

54. 42
4.2. Plaćanje preko bankovnog linka
Ukoliko korisnik odabere bankovni link kao metod plaćanja, potrebno je da
odabere banku od ponuĎenih banaka na stranici. Pritiskom na dugme
Checkout biva preusmeren na stranicu odabrane banke. Svaka banka ima
vizuelno drugačiju stranicu za završavanje plaćanja. Korisnik treba da
unese podatke i potvrdi plaćanje. Stranica banke se brine o validaciji
podataka i njihovom pravilnom unosu. Na kraju, korisnik treba da klikne
dugme potvrde i plaćanje se izvršava. Na slici 4.5. je prikazan dijagram
sekvence za plaćanje preko bankovnog linka.

55. 43
Slika 4.5. Dijagram sekvence za naplatu bankovnim linkom

56. 44
4.3. Uspešna transakcija
Kada se izvrši transakcija bilo kojom od navedenih metoda plaćanja,
korisnik i vlasnik onlajn prodavnice dobijaju obaveštenja o izvršenoj
transakciji.
Ako je plaćanje prošlo uspešno
 korisnik se preusmerava na stranicu o uspešnoj transakciji
 korisnik dobija email od Maksekeskusa o izvršenoj uplati
 vlasnik onlajn prodavnice dobija email od Maksekeskusa o
izvršenoj transakciji
 korisnik vebsajta dobija email o kupovini od strane vebsajta
 administrator vebsajta dobija email o izvršenoj kupovini od strane
vebsajta
Na portalu za trgovce se registruje nova transakcija, na kontrolnoj tabli u
bekendu vebsajta se prikazuje i nov upit sa pitanjima, sa oznakom
transakcije.
Administrator sajta moţe da vidi koja pitanja su postavljena, u kojoj
kategoriji, kojom brzinom treba da odgovori korisniku, kao i email adresu
na koju treba da pošalje odgovor.

57. 45
5. IMPLEMENTACIJA SISTEMA
Za implementaciju je korišćen Laravel framework[33] koji je
besplatan, tzv. open-source PHP web framework objavljen pod MIT
licencom na GitHub-u (originalno MIT - Massachusetts Institute of
Technology).
Laravel prati MVC (Model View Controller) softverski patern. Neke
od ugraĎenih funkcionalnosti su modularni sistemi paketa sa namenskim
menadţerima zavisnosti (dependency manager) [35]. Laravelov Eloquent
ORM (Object-Relational Mapping) se zasniva na Active Record
softverskom paternu gde je svaka tabela u relacionoj bazi podataka
predstavljena korespondirajućim "Modelom" preko koga se komunicira sa
datom tabelom u bazi. Laravel podrţava MySQL, Postgres, SQLite, i SQL
Server [34]. Za implementaciju je korišćena MySQL baza podataka.
Frontend, sve što korisnik veb aplikacije vidi uključujući i
administratorski panel, realizovano je koristeći Blade šablone koji su
sastavni deo Laravela i jQuery JavaScript biblioteke [36]. Blade šabloni se
koriste za "View" aplikacije i oni se kompajliraju u čist PHP kod koji se
kešira u pozadini nakon prvog izvršavanja stranice. Blade šabloni ne
zabranjuju korišćenje i standardne PHP sintakse u istom fajlu i čuvaju se sa
ekstenzijom .blade.php. Za administratorski panel korišćena je AdminLTE
tema zasnovana na Bootstrap 3 CSS framework-u [37]. Frontend aplikacije
za korisnike koristi Materializecss framework [38] radi lakše optimizacije
za različite veličine ekrana i rezolucije. jQuery JavaScript se koristi kao
osnovna biblioteka za manipulaciju elementima u HTML (HyperText
Markup Language) dokumentu.

58. 46
Slika 5.1. - početna stranica sa formom gde se bira metod plaćanja
U kontrolerima se izvršava sva poslovna logika, pozivi vezani za
transakcije i proces naplate. Za kreiranje HTTP zahteva koristi se PHP
biblioteka Guzzle [39]. Guzzle je PHP HTTP klijent koji omogućava slanje
HTTP zahteva i integraciju sa veb servisom. Guzzle poseduje jednostavan
interfejs za graĎenje string upita, POST zahteva, za strimovanje velikih
fajlova za upload (podizanje) i download (preuzimanje), koristi HTTP
kolačiće (cookies), upload JSON podataka i druge funkcionalnosti. Guzzle
klijent moţe da šalje sinhrone i asinhrone zahteve koristeći isti interfejs.
Koristi PSR-7 interfejs [40] za zahteve, odgovore i strimove.

59. 47
5.1. Frontend veb sajta i proces naplate
Na slici 5.2 prikazan je izgled računa kada korisnik kao metodu
plaćanja odabere karticu. Na stranici se prikazuje ikonica kartice i dugme za
checkout je aktivno. Kada korisnik proveri informacije na računu i klikne
na dugme checkout prikazuje se javascript popup u koji je potrebno uneti
podatke sa kartice (slika 5.3.). Nakon unošenja kartice, korisnik potvrĎuje
kupovinu i tada se izvršava naplata.
Slika 5.2. - prikaz računa ako je odabrano plaćanje karticom

60. 48
Slika 5.3. - checkout.js popup
Na slici 5.4. je prikazan izgled računa ukoliko korisnik izabere da ţeli da
plati preko bankovnog linka. Na računu se korisniku prikazu stilizovani
radio button-i sa dostupnim bankama za naplatu. Radio button se koristi
kako korisnik ne bi mogao da selektuje više od jedne opcije. Onog
momenta kada korisnik selektuje jednu od ponuĎenih banaka, aktivira se
dugme Pay Now za potvrdu. Kada korisnik klikne na dugme za potvrdu,
sajt ga preusmeri na stranicu odabrane banke, gde korisnik dalje unosi
podatke za konačnu kupovinu. Na slici 5.5. je prikazan primer stranice za
naplatu SEB banke.

61. 49
Slika 5.4. - prikaz računa ako je odabran metog plaćanja bankovni link
Slika 5.5. - primer stranice SEB banke

62. 50
5.2. Bekend veb sajta za administratora
U bekendu je implementiran prikaz postavljenih pitanja u vezi osiguranja
od strane korisnika. Administrator ima uvid u pitanja, kojom brzinom i na
koju email adresu treba da pošalje odgovor. Bekend je prostor gde mogu da
se integrišu i mnoge druge funkcionalnosti, kao npr. da se povuku
transakcije preko API-ja i prikaţu na posebnoj stranici sa grafičkim
prikazom. Na slici 5.6. je prikazana stranica sa poslatim upitima, dok je na
slici 5.7. prikazana stranica sa poslatim pitanjima. Na slici 5.8. se vidi
stranica na kojoj administrator moţe da dodaje nove kategorije osiguranja,
menja i briše postojeće.
Slika 5.6. - administratorska kontrolna tabla sa poslatim upitima
Slika 5.7. - administratorska kontrolna tabla sa poslatim pitanjima

63. 51
Slika 5.8. - administratorska kontrolna tabla – izmenu kategorije na dva
jezika
5.3. Implementacija platnog gejtveja
Na početnoj stranici veb sajta, implementirana je forma u kojoj se bira
metoda plaćanja (slika 4.1.). Pritiskom na dugme za slanje kreira se POST
zahtev sa akcijom na funkciju postPaymentInvoice u kontroleru.
Funkcija postPaymentInvoice (listing 5.1) kupi podatke koji su poslati
preko forme i čuva ih u MySql bazi podataka. Nakon toga se kreira Guzzle
klijent za kreiranje transakcije sa dobijem podacima. U telu zahteva
potrebno je poslati i referencu koja predstavlja unikatnu oznaku transakcije.
Referenca se kreira od prefiksa "ref" i id-ja koji se dobije nakon INSERT-a
podataka u bazu.
/**
* Create transaction
* @return View

64. 52
*/
public function postPaymentInvoice()
{
$shopId = env('SHOP_ID');
$secretKey = env('SECRET_KEY');
$requestPost = env('API_URL');
//save invoice
$invoice = new Inquery;
$invoice->category_id = request()-
>input('category');
$question_no = request()->input('question_no');
$price = Price::where('num_question', '=',
$question_no)
->where('category_id', '=', request()-
>input('category'))->first();
$invoice->price_id = $price->id;
$invoice->category_id = request()-
>input('category');
$invoice->phone = request()->input('phone');
$invoice->email = request()->input('email');
$invoice->method_reply = request()-
>input('method_reply');
$long_price = request()->input('long_price');
$invoice->method_payment = request()-
>input('method_payment');
$full_name = request()->input('name');
$parts = explode(" ", $full_name);
$firstname = array_pop($parts);
$lastname = implode(" ", $parts);
$invoice->name = $firstname;
$invoice->surname = $lastname;
if ($invoice->save()) {
$lastInvoiceId = $invoice->id;
$lastQuestionId = 0;
$questions = array();
//save question
for ($i = 1; $i <= $question_no; $i++) {
$question = new Question;
$question->question = request()-
>input('question' . $i);
$question->inquery_id = $lastInvoiceId;

65. 53
$question->save();
$lastQuestionId = $question->id;
array_push($questions, $question);
}
}
//Express reply price
if ($invoice->method_reply == 1) {
$express_reply_price = $this->setting-
>get('inqueries::12hours-response');
} else if ($invoice->method_reply == 2) {
$express_reply_price = 10;
} else if ($invoice->method_reply == 3) {
$express_reply_price = $this->setting-
>get('inqueries::48hours-response');
}
$total_price = round(($price->price +
$express_reply_price) * (1 + $price->tax / 100), 2);
$client_ip = request()->ip();
//Create transaction
$items = array(
'transaction' => array(
'amount' => $total_price,
'currency' => 'EUR',
'reference' => 'ref' . $lastInvoiceId,
'merchant_data' => 'IP:' . $client_ip .
'q:' . $lastQuestionId . ';ref' . $lastInvoiceId,
),
'customer' => array(
'email' => $invoice->email,
'ip' => $client_ip,
'country' => 'ee',
'locale' => 'et',
)
);
$client = new Client;
$rp = $requestPost . 'transactions';
$response = $client->post($rp, [

66. 54
'headers' => [
'Content-Type' => 'application/json',
'Authorization' => 'Basic ' .
base64_encode($shopId . ':' . $secretKey)
],
'body' => json_encode($items)
]);
$transaction = json_decode($response-
>getBody());
$pm = $transaction->payment_methods;
//return dd($transaction);
return view('pages.confirmation', ['invoice' =>
$invoice, 'questions' => $questions, 'transaction' =>
$transaction, 'pm' => $pm, 'long_price' =>
$long_price]);
}
Listing 4.1. - funkcija koja kreira transakciju
Na kraju funkcija redirektuje korisnika na novu stranicu na kojoj se
prikazuje račun (Listing 4.1). Za ovu stranicu se koristi view naziva
confirmation.blade.php koji prikazuje podatke prenetih objekata iz
kontrolera. Vizuelno se kreira račun za korisnika.
U slučaju da je korisnik odabrao karticu kao metodu plaćanja, na stranici se
kreira i forma koja nije vidljiva i sadrţi hidden polja. Unutar ove forme se
poziva checkout.js skripta i dodatnom javaskriptom se preuzima token za
autentifikaciju naplate i dodaje u polje forme. Forma je prikazana u Listing
4.2. gde se mogu videti i javaskripte.
Klikom na dugme Submit u popup-u kreira se POST zahtev sa akcijom koja
poziva funkciju postFinalPayment u kontroleru (Listing 4.3.). Podaci iz
forme zajedno sa tokenom se koriste za kreiranje Guzzle klijenta koji šalje
ove podatke Maksekeskus API-u i kreira naplatu. Nakon toga, korisnik se
preusmerava na view koji govori o realizovanoj uspešnoj transakciji.

67. 55
{!! Form::open([
'route' => ['postFinalPayment'],
'method' => 'post',
'id'=>'pay-confirm',
'class'=>'right-align'])
!!}
<input type="hidden"
name="token"
value=""
id="token">
<input type="hidden"
name="id"
value="{{ $transaction->id }}"
id="id">
<input type="hidden"
name="amount"
value="{{ $transaction->amount }}"
id="amount">
<script type="text/javascript">
function completed(data) {
document.getElementById("token").setAttribute("value",
arguments[0].paymentToken);
document.getElementById("pay-confirm").submit();
}
function cancelled(data) {
console.log('cancelled callback invoked', arguments);
}
</script>
<script src="https://payment-test.maksekeskus.ee/
checkout/dist/checkout.min.js"
data-key="yN6zkfeIggsNiEbW6Wo1qfxEGWYPvGG5"
data-transaction="{{ $transaction->id }}"
data-amount="{{ $transaction->amount }}"
data-currency="{{ $transaction->currency }}"
data-email="{{ $transaction->customer->email }}"
data-client-name="{{ $invoice_fullname }}"
data-name="City Oigusbuuro"

68. 56
data-description="Order {{ $invoice->id }}"
data-completed="completed"
data-cancelled="cancelled">
</script>
{!! Form::close() !!}
Listing 4.2. – forma sa javascript-ama u confirmation.blade.php fajlu
/**
* Create payment based on transaction
* @return View
*/
public function postFinalPayment()
{
$shopId = env('SHOP_ID');
$secretKey = env('SECRET_KEY');
$requestPost = env('API_URL');
$token = Input::get('token');
$amount = Input::get('amount');
$amount = round($amount, 2);
$id = Input::get('id');
//Create payment
$items = array(
'amount' => $amount,
'currency' => 'EUR',
'token' => $token,
);
$headers = [
'Content-Type' => 'application/json'
];
$client = new Client([
'base_uri' => $requestPost,
'timeout' => 5.0,
]);

69. 57
$response = $client->post('https://api-
test.maksekeskus.ee/v1/transactions/' . $id .
'/payments', [
'headers' => $headers,
'auth' => [$shopId, $secretKey],
'body' => json_encode($items)
]);
$transaction = json_decode($response-
>getBody());
return view('pages.taname', ['transaction' =>
$transaction]);
}
public function
postKontakt(SendCustomerEmailRequest $request)
{
$customer = new Customer();
$customer->name = request()->input('name');
$customer->phone = request()->input('phone');
$customer->email = request()->input('email');
$customer->address = request()-
>input('address');
$customer->notes = request()->input('notes');
$customer->save();
$data = $request->only('name', 'email',
'phone', 'title', 'address', 'notes');
$data['messageLines'] = explode("n", $request-
>get('message'));
Mail::send('emails.customer', $data, function
($message) use ($data) {
$message->subject('Aitäh sulle! ' .
$data['name'])
->to($data['email'])
->replyTo($data['email']);
});
Mail::send('emails.customeradmin', $data,
function ($message) use ($data) {
if ($this->setting->get('inqueries::admin-
email')) {

70. 58
$admin_email = $this->setting-
>get('inqueries::admin-email');
} else {
$admin_email =
'zlata.velickovic@gmail.com';
}
$message->subject('New customer: ' .
$data['name'])
->to($admin_email)
->replyTo($data['email']);
});
return view('pages.success');
}
Listing 4.3. - funkcija u kontroleru koja kreira naplatu ukoliko je odabrana
kartica
U slučaju da je korisnik odabrao bankovni link kao metodu plaćanja, na
stranici se prikazuju izlistani linkovi dostupnih banaka za zemlju iz koje
dolazi korisnik. Linkovi izgledaju ovako, primer: https://payment-
test.maksekeskus.ee/banklink.html?method=EE_SEB&trx=c18b9f38-4a30-
4a62-8971-9defbd06b09d
Link sadrţi atribut method koji predstavlja oznaku banke i atribut trx koji
predstavlja oznaku transakcije (listing 4.4.). Kako bi se odrţala
konzistentnost interfejsa, onemogućen je momentalan odlazak na link
klikom na jednu od banaka, nego je javaskriptom kreirana akcija koja se
okida na klik dugmeta Maksa.
$('.bank-btn').on('click', function (e) {
e.preventDefault();
var bank_url = $(this).attr('data-url');
$('.bank-btn').removeClass('btn-flat');
$(this).siblings().addClass('btn-flat');
$('#pay-via-bank').attr('href',
bank_url).removeClass('disabled');
});
Listing 4.4. - jQuery kod za pokretanje bankovnog linka na kojem se kreira
naplata

71. 59
Klikom na ovo dugme, korisnik se preusmerava na stranicu banke gde
završava plaćanje do kraja. Oko kreiranja naplate se u ovom slučaju brine
banka jer se nakon kreirane transakcije sve dalje dešava na stranici sajta
banke.

72. 60

73. 61
6. ZAKLJUĈAK
Maksekeskus platni gejtvej je odličan primer modernog JSON
RESTful API-ja koji se pridrţava ustanovljenih standarda [41]. API je vrlo
jasan, odlično dokumentovan, a hostuje se na poznatom servisu za API
apiary.io [42] koji pruţa dodatne pogodnosti za timski rad developera. API
je izuzetno jasno dokumentovan da bi se i neiskusniji programeri lako
snašli. Postoje i dodatni alati koji olakšavaju razumevanje API-ja i kako ga
implementirati. Sva dokumentacija je javno dostupna i za neregistrovane
korisnike ovog servisa. Maksekeskus je kreirao i dokumentovao dodatne
module koji ubrzavaju integraciju ovog sistema na poznatim CMS
sistemima za online prodavnice. Ukoliko je potrebna prilagoĎena
integracija, mogu se naći primeri koda za integraciju na 14 programskih
jezika.
Maksekeskus ne zahteva od vlasnika online prodavnica da
prilagoĎavaju dizajn prodavnice i kartice za kupovinu kako bi se
ispoštovala pravila Visa i MasterCard organizacija. Maksekesus API je
rešio sve moguće probleme pozivom javascript iframe-a gde se jasno vidi
brending koji je neophodan. Osetljivi podaci sa kartica se unose u iframe i
ne zadrţavaju se na hostingu onlajn prodavnice. Iz ugla sigurnosti, podaci
su van domašaja javascript-e koju moţe developer da integriše na vebsajtu.
MeĎutim, postoji mogućnost da se podaci preuzmu keylogging-om [43]
tako što će se pratiti unosi sa tastature u browser-u korisnika za šta je
potrebno instalirati dodatni softver u browser-u kupca.
Maksekesus API ostavlja mogućnost vlasniku onlajn prodavnice da u
backend-u implementira dodatne stranice za praćenje transakcija na sajtu,
kao i da manipuliše sa email-ovima korisnika koji izvrše kupovinu. Ovo
moţe biti pogodno za integraciju sa posebnim CRM (Customer relationship
management) softverom [44] koji bi omogućio vlasniku online prodavnice
kreiranje veće konverzije prodaje.
Mogućnost odabira metode plaćanja karticom ili preko bankovnog

74. 62
linka daje mogućnost kupcu da izabere metod koji mu najviše odgovara.
Nesigurni kupci će pre odabrati bankovni link kao metod plaćanja, dok
kupci koji izaberu karticu, jasno će biti vizuelno obavešteni o kom platnom
sistemu se radi.
Ukoliko bi se implementirao platni gejtvej kao servis, Maksekeskus
bi mogao biti primer dobro uraĎenog rešenja na koji bi moglo da se ugleda.
Ovaj platni gejtvej je nastao kao startup u jednoj maloj zemlji i ubrzo
postao najpopularniji servis te vrste u regionu. Da bi opstao u budućnosti,
trebalo bi da se prošire usluge i na mobilna plaćanja pošto je to defintivno
budućnost elektronskog poslovanja koje nameću nova ponašanja korisnika.

75. 63
LITERATURA
[1] ecommerce-platforms.com - http://ecommerce-
platforms.com/ecommerce-selling-advice/what-is-difference-between-a-
payment-gateway-payment-processor-and-a-merchant-account
[2] vanvit.com - https://www.vantiv.com/vantage-point/payments-
basics/what-is-a-payment-processor
[3] bluepay.com - https://www.bluepay.com/blog/payment-gateway-vs-
payment-processor/
[4] unibulmerchantservices.com -
http://blog.unibulmerchantservices.com/what-is-an-independent-sales-
organization-iso/
[5] Mastercard -
https://www.mastercard.com/uk/merchant/en/acquirers/communications
/msp_rules.html
[6] merchantuniversity.org - http://www.merchantuniversity.org/getting-
started/what-is-an-iso-msp.aspx
[7] Comentum 360 | eCommerce Resources -
http://www.comentum.com/comentum-ecommerce/guide-to-merchant-
accounts-payment-gateways.html
[8] paymentsgateway.com.au - http://www.paymentsgateway.com.au
[9] www.netokracija.rs - http://www.netokracija.rs/tomislav-car-
omgcommerce-96366
[10] Klarna - https://www.klarna.com/international
[11] ApplePay - http://www.apple.com/apple-pay/
[12] Nielsen - http://www.nielsen.com/us/en/insights/news/2016/whats-in-
your-customers-digital-wallet-preferences-vary-around-the-globe.html
[13] PayTrail platni system - http://www.paytrail.com/
[14] Unicredit banka - http://eng.unicreditbank.cz/en/web/about-us/press-
centre/press-releases/unicredit-bank-offers-secure-online-payments-to-

76. 64
merchants
[15] Banka Intesa - http://www.bancaintesa.rs/elektronsko-bankarstvo/e-
commerce/e-commerce.1725.html
[16] SecurePay - https://www.allsecure.rs/
[17] Tanjug, novinska agencija Srbije - http://www.tanjug.rs/full-
view.aspx?izb=260788
[18] Maksekeskus platni sistem - https://makecommerce.net/
[19] Estonska pošta - Eesti Post – Omniva -
https://www.omniva.ee/ari/pakk/internetimuuk/lahendused/maksekesku
s
[20] Novinski portal Tarbija24 -
http://tarbija24.postimees.ee/1364892/eesti-post-avas-e-poodide-
teenuseportaali
[21] Maksekeskus lista zahteva - https://makecommerce.net/sign-up-
requirements
[22] Maksekeskus bank link payment -
https://makecommerce.net/service/banklinks/
[23] Maksekeskus credit card payment -
https://makecommerce.net/service/credit-card-payments/
[24] Maksekeskus services - https://makecommerce.net/why-join/?lang=en
[25] Status servera http://status.maksekeskus.ee
[26] Spring framework http://www.springsource.org
[27] JavaScript and JSON essentials, autor: Sai Srinivas Sriparasa ISBN:
9781783286041 1783286040 (2013)
https://books.google.rs/books?id=MZOkAQAAQBAJ
[28] HTTP Pocket Reference: Hypertext Transfer Protocol, autor: Clinton
Wong, ISBN: 1449379605, 9781449379605 (2000)
https://books.google.rs/books?id=dOIlEeG1v4UC
[29] RESTful Web Services O’Reilly – Leonard Richardson & Sam Ruby
ISBN: 978-0-596-52926-0 (2007)
[30] – HTTP: The Definitive Guide – Brian Totty, Marjorie Sayer, Sailu
Reddy, Anshu Aggarwal, David Gourley ISBN: 156-592-50-92 (2002)
https://www.safaribooksonline.com/library/view/http-the-
definitive/1565925092/
[31] – Apiary.io Maksekeskus API http://docs.maksekeskus.apiary.io
[32] HAL - Hypertext Application Language -
https://github.com/mikekelly/hal_specification/blob/master/hal_specificatio
n.md
[33] Laravel PHP Framework - https://laravel.com/
[34] Payment Card Industry Data Security Standard (PCI DSS)
https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf (2013)

77. 65
[35] Composer - https://getcomposer.org/
[36] jQuery - JavaScript library - https://jquery.com/
[37] Bootstrap - HTML, CSS, i JS framework - http://getbootstrap.com/
[38] MaterializeCSS - responsive front-end framework based on Material
Design - http://materializecss.com
[39] Guzzle - http://docs.guzzlephp.org
[40] PSR-7 - https://github.com/php-fig/http-message
[41] REST API Tutorial - http://www.restapitutorial.com/
[42] Apiary - https://apiary.io/
[43] Keylogging - Basic Computer Security/Malware/Spyware/Avoiding
Keyloggers https://en.wikibooks.org/wiki/Basic_Computer_Security/
Malware/Spyware/Avoiding_Keyloggers
[44] CRM - https://en.wikipedia.org
/wiki/Customer_relationship_management