Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Maksekeskus sistem za online plaćanje

209 views

Published on

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Maksekeskus sistem za online plaćanje

  1. 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
  2. 2. 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.
  3. 3. 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
  4. 4. VI
  5. 5. 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
  6. 6. VIII
  7. 7. 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
  8. 8. X
  9. 9. 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
  10. 10. 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ć
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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.
  18. 18. 8
  19. 19. 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
  20. 20. 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
  21. 21. 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.).
  22. 22. 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
  23. 23. 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.
  24. 24. 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
  25. 25. 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
  26. 26. 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.
  27. 27. 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
  28. 28. 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.
  29. 29. 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
  30. 30. 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
  31. 31. 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)
  32. 32. 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].
  33. 33. 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)
  34. 34. 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.
  35. 35. 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"
  36. 36. 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
  37. 37. 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].
  38. 38. 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-
  39. 39. 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" }, {
  40. 40. 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-
  41. 41. 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": {
  42. 42. 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.
  43. 43. 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
  44. 44. 34
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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).
  49. 49. 39 Slika 4.3. Dijagram toka aktivnosti
  50. 50. 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.
  51. 51. 41 Slika 4.4. Dijagram sekvence za naplatu karticom
  52. 52. 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.
  53. 53. 43 Slika 4.5. Dijagram sekvence za naplatu bankovnim linkom
  54. 54. 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.
  55. 55. 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.
  56. 56. 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.
  57. 57. 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
  58. 58. 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.
  59. 59. 49 Slika 5.4. - prikaz računa ako je odabran metog plaćanja bankovni link Slika 5.5. - primer stranice SEB banke
  60. 60. 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
  61. 61. 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
  62. 62. 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;
  63. 63. 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, [
  64. 64. 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.
  65. 65. 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"
  66. 66. 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, ]);
  67. 67. 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')) {
  68. 68. 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
  69. 69. 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.
  70. 70. 60
  71. 71. 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
  72. 72. 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.
  73. 73. 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-
  74. 74. 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)
  75. 75. 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

×