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

UNIVERZITET U NOVOM SADU FAKULTET TEHNIĈKIH NAUKA

2 1 0 0 0 N O V I S A D , T r g D o s i t e j a O b r a d o v i ć a 6

Broj:

ZADATAK ZA MASTER 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.

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

VI

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/graphs/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

VIII

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

X

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

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ć

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

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

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

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

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

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

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.

8

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

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

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.).

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

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.

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

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

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.

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

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.

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

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

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)

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].

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)

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.

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"

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

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].

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-

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"

},

{

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-

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": {

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.

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

34

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

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

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

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).

39

Slika 4.3. Dijagram toka aktivnosti

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.

41

Slika 4.4. Dijagram sekvence za naplatu karticom

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.

43

Slika 4.5. Dijagram sekvence za naplatu bankovnim linkom

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.

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.

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.

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

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.

49

Slika 5.4. - prikaz računa ako je odabran metog plaćanja bankovni link

Slika 5.5. - primer stranice SEB banke

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

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

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;

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, [

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.

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"

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,

]);

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')) {

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

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.

60

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

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.

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-

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/maksekeskus

[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_specification.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)

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