1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářské práce Elektronické platební systémy a návrh GUI projektu e...
České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářské práce
Elektronické platební systémy a návrh GUI projektu e-bedynky Barbariyskiy Nikolay
Vedoucí práce: Ing. Komárek Martin
Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 26. května 2011
iv
v
Poděkování Chtěl bych vyjadřit poděkování panu Ing. Martinu Komárkovi za cenné připomínky a odborné rady během vypracování bakalářské práce. Dále děkuji pracovniku banky KB panu Romanu Bartůšku za bezplatné poskytnutí informace. Rovněž patří můj dík rodině za podporu při studiu a tvorbu potřebného zázemí. Děkuji také přítelkyni za její velkou trpělivost se mnou při práci na tomto tématu a její podporu a také jsem moc vděčný Romanu Pivoňkovi, Milanovi Černilu a Ondřeju Davidovi za pomoc při opravování této práce.
vi
vii
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).Celý projekt e-bedynky je šířen pod licensí BSD
Abstract This Bachelor’s dissertation describes the most known payment systems Paypal and PaySec. Contains the analysis of payment by a credit card in the Internet.Also it is devoted to a web service BankParser and includes its analysis and integration into the project e-bedynky. The next part of the work is dealing with integration of the payment system Bankparser into the project e-bedynky and simultaneously includes the graphical user interface.
Abstrakt Bakalářská práce popisuje nejznámější platební systémy, což jsou PayPal a PaySec. Obsahuje analýzu placení platební kartou na internetu. Dále se věnuje webové službě BankParser a zahrnuje její analýzu a integraci do projektu e-bedýnky. Další část práce se zabývá nasazením platebního systému PayPal do projektu e-bedýnky a grafickým uživatelských rozhraním tohoto projektu.
Úvod Cílem mé práce na projektu e-bedynky, jsou elektronické platební systémy a grafické uživatelské rozhraní. Co se týká elektronických platebních systémů, budu se zabývat nasazením webové služby BankParser [1] do projektu e-bedynky. Tato služba je určena ke zpracování bankovních výpisů a umožňuje parsování výpisů z různých bank s použitím filtrů. Byla napsána Jaroslavem Zímou v rámci jeho bakalářské práce. Dále se pokusím nasadit na náš projekt velice populární a v Americe hojně používaný platební systém PayPal, který umožňuje přesuny peněz mezi účty. Tento systém má vysokou úroveň ochrany dat a mnoho hotových řešení pro elektronický obchod. Dále se budu zabývat problémem zpracování plateb pomocí bankovních karet. Platba kartou je celosvětově asi nejpopulárnějším způsobem placení na internetu, má ale nižší úroveň zabezpečení než PayPal. Mým dalším úkolem je navrhnout GUI, které bude příjemné a snadno ovladatelné pro budoucí uživatele systému.
1
2
KAPITOLA 1. ÚVOD
Kapitola 2
Akceptace platebních karet na internetu 2.1
Elektronické peněženky
V této podkapitole se budu zabývat analýzou dvou platebních peněženek- PayPal a PeySec, popíšu nástroje které tyto peněženky poskytují a úroveň jejich bezpečnosti. V závěru podkapitoly porovnám tyto platební systémy a na základě uvedených údajů vysvětlím proč jsem si zvolil peněžní systém PayPal pro práci v rámci mé bakalářské práce.
2.1.1
PayPal
PayPal je internetový platební systém. Umožňuje snadné přesuny peněz mezi účty, které jsou identifikovány emailovými adresami. Každý účet je propojen s jednou nebo více platebními kartami. Platební karta musí mít povolené internetové platby (ale nemusí být embossovaná). Alternativou je platit těmito kartami přímo na internetu (tím je ovšem zvýšeno riziko podvodu, protože je nutno zadat informace o platební kartě přímo cílovému subjektu). Systém PayPal umožňuje mít nastavenu i českou korunu jako primární měnu. Při platbě v jiné měně je částka přepočítána podle aktuálního kurzu. Při aktivaci platební karty je nutno zadat PayPalu potřebné informace o této kartě. PayPal si z karty poté strhne drobnou částku. Tato částka je vrácena jako bonus při prvním převodu peněz přes PayPal. Na výpisu z účtu je u této položky uveden čtyřmístný kód, jehož zadáním na webových stránkách PayPalu je provedena aktivace zmíněné platební karty. Při následných převodech peněz přes Internet je odpovídající částka stržena buď ze zůstatku účtu PayPal nebo přímo z platební karty.[2] 2.1.1.1
Analýza PayPal nástrojů
Systém PayPal obsahuje velké množství různých hotových řešení, což bylo pro mě velmi důležitým faktorem. Ale ve své práci se budu zabývat pouze nejdůležitějšími prostředky pro práci se systémem PayPal.
3
4
KAPITOLA 2. AKCEPTACE PLATEBNÍCH KARET NA INTERNETU
Prvním z nich je Adaptive Payment API. Toto API umožňuje posílat peníze podle různých scénářů, od základních až po velmi robustní. A také poskytuje operace, které umožňují vytvořit aplikaci, která zpracovává platby, předběžné schválení pro platby, náhrady a další operace. Adaptive Payments poskytuje 3 základní scénáře platby: prostý, paralelní a zřetězený. Prosté platby umožňují kupujícímu poslat jednotlivé platby jednomu prodávajícímu. Tento způsob platby je někdy považován za tradiční.
Obrázek 2.1: Prostá platba.Zdroj: [3]
Paralelní platba je platba od odesílatele, která je rozdělena přímo mezi 2 až 6 příjemců. Technicky, paralelní platba je soubor několika plateb provedených v jedné žádosti. Paralelní platby jsou užitečné v případech, kdy kupující má v úmyslu učinit jednotné platby za zboží z prodejců.
Obrázek 2.2: Paralelní platba.Zdroj: [3]
Zřetězena platba je platba od odesílatele, ktera je nepřímo rozdělena mezi více pří-
2.1. ELEKTRONICKÉ PENĚŽENKY
5
jemců. Je to rozšíření typické platby od odesílatele k příjemci, ale od příjemce, známého jako primární příjemce, přechází část platby jiným příjemcům, tzv. sekundárním příjemcům.
Obrázek 2.3: Zřetězena platba.Zdroj: [3]
Obrázek 2.4: vytvoření PayPal účtů.Zdroj: [4]
Dalším nástrojem je Adaptive Accounts. Majitelé účtu tradičně vytvářejí PayPal účty tím, že půjdou přímo na PayPal.com nebo během nákupního procesu. Adaptive Accounts nabízí nový způsob: vytvoření účtů v rámci aplikace nebo webové stránky, mimo nákupní proces. Aplikace odešle požadavek s informací o uživateli, a vytvoří PayPal účet. Na tom
6
KAPITOLA 2. AKCEPTACE PLATEBNÍCH KARET NA INTERNETU
místě je nový uživatel PayPal účtu stručně přesměrován na PayPal.com, kde uvede pouze osobní informace jako je např. heslo a přijme uživatelskou dohodu. Na konci registrace je uživatel přesměrován zpět na náš web. Třetím velíce zajímavým a na první pohled jednoduchým nástrojem je Website Payment Standard. Website Payment Standard dovoluje přidat pomocí HTML přímo do našich stránek tlačítka pro různé typy plateb. A kupujícímu stačí pouze zmáčknout tlačítko pro platbu za produkt nebo službu. Tento nástroj nabízí 4 základní tlačítka, kterými jsou: „Buy Now”, „Donate“, „Add to Card” a „Subscribe”. Tlačítko Buy Now slouží k přijetí plateb za jednotlivé kusy zboží. Pomocí tlačítka Buy Now můžeme koupit jeden nebo více kusů zboží stejného typu. Další tlačítko Donate, se používá pro vložení peněz. Toto tlačítko pomáhá sbírat předem určené částky peněz a vklady od dárců. Tlačítko Subscribe se používá pro
Obrázek 2.5: Princip fungování tlačítka Add to Cart.Zdroj: [5]
opakovaný výběr peněz z účtu uživatele po nějakou určenou dobu např. účtování členských příspěvků. Pomocí PayPal Shopping Cart kupující může si na webové stránce vybrat několik kusů různého zboží a zaplatit za toto zboží najednou. Tlačítko Add to Cart se používá pro přidání zboží na svou PayPal Shopping kartu. Předtím, než zaplátí může prohlédnout své zboží pomocí tlačítka View Cart a pak koupit vše najednou. Následující diagram ukazujie princip fungování tlačítka Add to Cart2.5. Jak už jsem zmínil, na první pohled to vypadá velmi jednoduše, ale tyto 4 tlačítka mají velké množství různých nastavení a víc než 400 stránkovou dokumentaci. Tím pádem je možno navrhnout jednoduchý elektronický obchod pouze pomocí těchto to 4 tlačítek. Tyto tlačítka lze buď vygenerovat přímo na strankách PayPal nebo napsat ručně, jejich funkcionalitu je možno rozšířit pomocí JavaScriptu. Všechna tlačítka kromě Add to cart (popsán výše) mají velice podobný princip práce. Posledním, ale asi nejužitečnějším nástrojem, který nám poskytuje PayPal je SandBox. Je to speciální testovací prostředí určené pro vývojáře. Po registraci na developer.paypal.com,
je možné vytvořit virtuální účty PayPal (přičemž je možné definovat množství peněz, které je na testovacím účtu), navíc toto testovací prostředí obsahuje automatické testy, které lze spustit a otestovat správnost fungování aplikace. 2.1.1.2
Bezpečnost PayPalu
Jak už jsem zmínil, PayPal má vysokou úroveň ochrany dat a transakcí. PayPal používá SSL encripce se 168b klíčem. Základními opatřeními jsou monitoring IP adres, ze kterých se přistupuje na Váš účet. Pokud se jedná o adresu z jiné země, je Váš účet automaticky dočasně zablokován. Samozřejmostí je zabezpečený protokol komunikace HTTPS. Existuje také možnost refundace do výše 250 dolarů. Veškeré transakce v systému se dají vysledovat a dohledat.[6] Avšak PayPal je často kritizován za to, že neexistuje zákaznická linka nebo oficiální poradna PayPalu v češtině, kde by vám okamžitě poradili a poskytli návod na vyřešení problémů. Dokonce velice často uživatelé PayPalu i z jiných zemí kritizují PayPal za špatnou nebo velmi pomalou pomoc při řešení problémů, např. se ztrátou peněz kvůli internetovým podvodům.
2.1.2
PaySec
PaySec je vlastně českou verzí PayPal. PaySec je projektem ČSOB ve spolupráci s Poštovní spořitelnou. PaySec neodečítá peníze za platby přímo z vašeho účtu v bance přes platební kartu, tedy nefunguje jako nějaké prodloužení platební karty jako PayPal. Pro placení přes PaySec si nejdříve musíte své konto u této služby založit (to je otázka několika minut) a nabít penězi podobně třeba jako peněženku eWallet používanou v síti internetových videopůjčoven Kinománia. Způsoby pro nabití konta PaySec jsou dva: klasickým převodem z běžného účtu nebo s pomocí platební karty přes službu PayMuzo. Není přitom nutné mít u ČSOB nebo Poštovní spořitelny běžný účet. Ten můžete mít v kterékoliv bance, ovšem pro klienty dvou zmíněných bank je převod poněkud pohodlnější.[7]
8
KAPITOLA 2. AKCEPTACE PLATEBNÍCH KARET NA INTERNETU
Bohužel založení Konta PaySec pro obchodníky je poněkud komplikovanější. Pro obchodníky je třeba nejperve vyplnit a odeslat několik formulářů. Do druhého pracovního dne od odeslání formuláře žadatele kontaktuje obchodní tým PaySec s konkrétní nabídkou pro požadovaný obchod a dalšími informacemi. Po stanovení výše poplatků je třeba vyplnit Smlouvu a Identifikační formulář. Potom se musí dostavit na kterékoliv Finanční centrum Poštovní spořitelny s těmito dokumenty:[8] 1. Vyplněnou Smlouvou pro majitele Konta pro obchodníky 2. Vyplněným Identifikačním formulářem majitele Konta pro obchodníky 3. Aktuálním výpisem z obchodního rejstříku ( originálem nebo úředně ověřenou kopií a kopií ), nebo z jiné podobné evidence 4. Průkazem totožnosti žadatele, nebo průkazem totožnosti zastupující osoby 5. Plnou mocí pro zástupce - pokud bude zastupován. 2.1.2.1
Analýza PaySec nástrojů
PaySec na rozdíl od PayPal má fakticky pouze dva nástroje: prvním jsou tlačítka (obdoba tlačítek u PayPal) a druhým je formulář. Přičemž používat formulář mohou pouze majitelé konta pro obchodníky.Na obrázku 2.7 je vidět, že PaySec poskytuje pouze 3 tlačítka (3 v češtině 3 v angličtině), funkcionalita kterých je naprosto stejná.
Obrázek 2.7: PaySec tlačítka.Zdroj: [9]
Tlačítka fungují následovně: [9] 1. Plátce klikne na platební tlačítko 2. Platební tlačítko přesměruje internetový prohlížeč plátce na platební bránu a předá jí přednastavené informace o požadované platbě. 3. Plátce na platební bráně potvrdí platbu (vložením přihlašovacího jména a hesla do systému PaySec).Předvyplněná částka je převedena na konto majitele Platebního tlačítka. 4. Internetový prohlížeč uživatele je přesměrován zpět na adresu, která byla předána platební bráně jako jeden z parametrů. Stejně jako u PayPalu tlačítko je možné buď vygenerovat nebo napsat ručně. Formulář je vlastně obyčejný HTML formulář, který ale obsahuje některé speciální parametry. Tento formulář odešle údaje o platbě na platební bránu. Tady na rozdíl od PayPal PaySec má jednu výhodu. Kromě možnosti zaplatit částku pomocí svého PaySec
2.1. ELEKTRONICKÉ PENĚŽENKY
9
účtu, majitelé konta u ČSOB nebo Poštovní spořitelny, mohou zaplatit pomocí elektronického bankovnictví. Pokud uživatel bude chtít zaplatit pomocí PaySec, musí se pouze přihlásit ke svému účtu a potvrdit platbu. Jestliže bude chtít zaplatit pomocí elektronického bankovnictví, musí na platební bráně vybrat platební metodu ČSOB nebo Poštovní spořitelna. Platební brána přesměruje zákazníka do internetového bankovnictví. V rámci přesměrování jsou předány všechny informace k provedení platebního příkazu. Zákazník se přihlásí do internetového bankovnictví a provede platební příkaz na sběrný účet systému PaySec. Do systému PaySec je odesláno avízo o provedení transakce, které umožní okamžité připsání částky na Konto PaySec obchodníka. Internetové bankovnictví přesměruje zákazníka do systému PaySec, kde proběhne ověření po úspěšném připsání částky na Konto PaySec obchodníka. [10] Bohužel PaySec narozdíl od PayPal nemá virtuální testovací účty, poskytuje pouze testovací platební bránu, která umožňuje testovat správnost nasazení platebních prvků 2.1.2.2
Bezpečnost PaySec
Nabíjení konta probíhá prostřednictvím převodu z běžného účtu nebo karty přes 3D Secure platební bránu. Samotné platby jsou zabezpečeny autorizačními SMS. V nastavení svého účtu PaySec si můžete nastavit při jaké sumě je nutné ověření přes SMS. V základním nastavení je to 50 korun, ale může to být až 1000 korun. Zcela vypnout nelze. Komunikace mezi webovou stránkou a systémem PaySec probíhá pomocí zabezpečeného kanálu. Veškerá komunikace je zašifrována tak, aby byla zajištěna integrita (nikdo zprávu nezmění) a důvěrnost (nikdo si zprávu nepřečte) dat. K zašifrování se používají certifikáty. Aby si byl elektronický obchod jistý, že posílá data správnému serveru, musí certifikát ověřit.[7]
2.1.3
Porovnání PayPal a PaySec
PayPal PaySec
Tlačítka API pro platby Ano Ano Ano Ne
API pro registrace Ano Ne
Testovací brána Ano Ano
Testovací účty Ano Ne
Automatické testy Ano Ano
Tabulka 2.1: Porovnání PaySec a PayPal nástrojů Odeslaná platba
Přijatá platba
PayPal
0 Kč
PaySec
1 Kč
1,9–2,9 %+ 0,30 USD 1 Kč
Nabití z bankovního účtu Ne
Nabití platební kartou Ano
0 Kč
2%
Poslání na bankovní účet 0 Kč nad 3 000 Kč, jinak 30 Kč 0 Kč ČSOB, 3 Kč jinam
Tabulka 2.2: Porovnání poplatků za používání konta PaySec a PayPal
10
KAPITOLA 2. AKCEPTACE PLATEBNÍCH KARET NA INTERNETU
Rozhodoval jsem se na základě tří faktorů. Zaprvé, kolik bude stát osobní systém pro elektronické obchodování. Zadruhé, jaké nástroje tento systém poskytuje. Zatřetí, nakolik je systém užitečný pro studijní účely. Jak je vidět v tabulkách 2.2 a 2.1 PayPal je mnohem dražší než PaySec. Avšak PayPal poskutuje mnohem více různých API a nástrojů, ale nejdůležitějším je to, že má naprosto perfektní nástroje na testování a dovoluje vytvářet virtuální účty, což znamená, že při zpracování bakalářské práce nebudu mít žádné právní nebo finanční problémy. Proto jsem si zvolil platební systém PayPal, a v rámci své bakalářské práce se pokusím nasadit ho na projekt e-bedynky.
2.2
Platba platební kartou bez zprostředkovatele
Platba kartou je celosvětově asi nejpopulárnějším způsobem placení na internetu.A je rychlejší, protože uživatel nemusí mít účet v nějaké elektronické peněžence, jako je např. PayPal, ProPay nebo PaySec.K přijetí platby platební kartou na webových stránkách potřebujeme čtyři základní kameny.[11] 1. Elektronický nákupní košík, který umožňuje zákazníkovi nakupovat několik produktů najednou 2. Payment Gateway Service (Platební brána), pro kontrolu platnosti kreditní karty 3. Credit Card Processor , který bude zpracovávat transakce 4. Internet Merchant Account (Konto pro obchodníky) vydané nabývající banky, ve které jsou uloženy zpracování fondů.
2.2.1 2.2.1.1
Základní kameny elektronického obchodování Nákupní košík
Nákupní košík se obvykle skládá ze tří složek: katalog produktů, nákupní vozík, a pokladního/platebního systému. Katalog výrobků je součástí našeho inventáře a zobrazuje položky, které jsou k prodeji na webových stránkách. Pokladní/platební systém je součástí programu, který umožňuje svým zákazníkům "přidat do košíku"a pokladní/platební systém je součást, která umožňuje zákazníkům přístup k pokladně a platbu za zboží. Existuje široký výběr nákupních košíků na trhu a cena je závislá na jejich funkcionalitě. Systémy nákupních košíků se pohybují od jednoduchého formuláře vkládání HTML po robustní systémy, které používají Amazon nebo Dell. 2.2.1.2
Payment Gateway Service
Payment Gateway service, je prostředník v procesu platby. Kdy uživatel dokončí svůj nákup a bude chtít zapaltit, kontrolní systém nákupního košíku odešle informaci o platební kartě do payment gateway service, který přesměruje informaci do procesoru platebních karet (Credit Card Processor). V závislosti na odpovědi od procesoru, Gateway Service vrátí zda karta je schválena nebo není. Tento proces trvá pouze několik sekund.
2.2. PLATBA PLATEBNÍ KARTOU BEZ ZPROSTŘEDKOVATELE
2.2.1.3
11
Credit Card Processor
Credit Card Processor - to je elektronické informačni centrum, které zpracovává transakce provedené kreditní kartou pochazející z brany firmy, zajišťuje, že poplatek je platný, pak vypořádá finanční prostředky na obchodním účtu zakaznika. 2.2.1.4
Internet Merchant Account
Internet Merchant Account. Internetový obchodní účet může mít banka nebo jiná finanční instituce, je určen pro depozity z on-line (přimých) prodejů. Obchodní účty jsou obvykle vydávány bankami, které spolupracují s hlavními poskytovati kreditních karet, což jsou Visa a MasterCard. Existuje velký problém v tom, že mnohé banky nebudou poskytovat obchodní účty internetovým prodejcům, protože takové obchody jsou často považovány za „vysoce rizikové“. Banka sama rozhodne, zda takový internetový podnikatel je riskantní. Pokud rozhodné, že ano - odepře poskytování obchodního účtu. Naštěstí, růst internetových prodejců vyvolal vzestup obchodních institucí - středisek, které poskytnou zákazníkům obchodní účet a vše, co budou potřebovat, aby mohli přijímat on-line platby. Poplatky jsou obvykle vyšší, ale je to lepší než nemít on-line platební systém vůbec.
2.2.2
Proces zpracování kreditní karty
Celkový proces zpracování kreditní karty se dá snadno popsat následovně: zákazník předloží kreditní kartu. Webová stránka odešle tranaskce na bránu. Brána posílá informaci k procesoru. Procesor kontaktuje vydávající banku, ke které patří kreditní karta zákazníka. Pak vydávající banka vrací výsledek k procesoru. Procesor přesměruje výsledek ke bráně. Brána předá výsledek na webovou stránku. Výsledek se objeví na webové stránce.
2.2.3
Analýza nástrojů pro zpracování platebních karet
Nástroje pro akceptaci platebních karet obvykle poskytuje banka, ve které obchodník má svůj obchodní účet (Internet Merchant Account). Proto jsem se v rámci své bakalářské práce pokusil provést drobný výzkum nástrojů, které poskytují banky v České republice. Pro svůj výzkum jsem si vybral 2 banky: ČSOB a KB. Naštěstí, veškeré informace o akceptaci platebních karet ČSOB uvedla na svých webových stránkách na internetu. Abych získal informace o KB musel jsem jít přímo do banky. Na základě informací, které jsem dostal, jsem pochopil, že obě banky (a taky Raiffesen bank, Unicreditbank, Volksbank) spolupracují se společností Global Payments Europe, s.r.o. (dále jen GPE), která je hlavním dodavatelem bezhotovostních plateb pro banky a finanční instituce v České republice. Společnost GPE provozuje systém GP webpay, která umožňuje elektronickým obchodům přijímat platby uskutečněné platebními kartami v prostředí sítě internet. Jedná se o internetovou platební bránu splňující požadavky na nejvyšší bezpečností standard 3D Secure, podporovaný karetními asociacemi VISA a MasterCard. Podle informací, které jsem získal v KB, společnost GPE nabízí Virtuální platební terminál. Virtuální platební terminál je programový modul, který je implementován do provozovaného obchodního serveru. Umožňuje obchodníkovi přijímat a zpracovávat zabezpečené
12
KAPITOLA 2. AKCEPTACE PLATEBNÍCH KARET NA INTERNETU
Obrázek 2.8: Diagram aktivit zpracování kreditní karty
platby prostřednictvím veřejné datové sítě Internet způsobem on-line. Zabezpečení těchto plateb je realizováno šifrováním všech přenášených dat včetně jejich autentifikace za použití jedinečného digitálního podpisu na straně obchodníka i držitele platební karty. Postup při transakci prostřednictvím virtuálního platebního terminálu: 1. obchodní server přijme po Internetu specifikaci zboží a šifrované údaje o platební kartě ze strany zákazníka 2. obchodní server resp. Virtuální platební terminál sestaví autorizační požadavek, který prostřednictvím Internetu odešle do autorizačního centra své banky 3. obchodník i zákazník obdrží zpět informaci, zda autorizace a ověření jedinečných digitálních podpisů proběhlo úspěšně či nikoliv 4. pokud je autorizační požadavek v plném rozsahu schválen, vygeneruje následně virtuální platební terminál požadavek na zaúčtování transakce, který předá prostřednictvím Internetu své bance 5. virtuální terminál vytvoří o provedených operacích datový záznam, který je povinen obchodník vhodným způsobem archivovat
2.2. PLATBA PLATEBNÍ KARTOU BEZ ZPROSTŘEDKOVATELE
13
Školení obsluhy programového modulu virtuálního platebního terminálu provádí vždy dodavatel ( GPE, s.r.o.). Pořízení a technickou implementaci vlastního programového modulu si zajišťuje obchodník na vlastní náklady u společnosti GPE, s.r.o., které si za zpracování a připojení účtuje poplatek ve výši 13.200 Kč, měsíční poplatek 150 Kč a 2 Kč za transakci, tyto dva poplatky jsou společností GPE, s.r.o. fakturovány čtvrtletně Provize pro KB a.s. činí 2,50% z částky, kterou platí klient společnosti přes Internet. Tato provize slouží k úhradě mezibankovních poplatků.
14
KAPITOLA 2. AKCEPTACE PLATEBNÍCH KARET NA INTERNETU
Kapitola 3
BankParser Webová služba BankParser byla napsána panem Jaroslavem Zímou v rámci jeho bakalářské práce. Tato služba je určena ke zpracování elektronického výpisu z účtu. BankParser byl psán v jazyce Java a tím pádem je platformě nezávislý. BankParser používá modulární rozšíření (plugin) a díky tomu, že Java podporuje reflexe (tato vlastnost umožňuje kódu zkoumat sam sebe a zpracovávat kód neznámý v době kompilace programu) není potřeba tento software restartovat, aby si nový plugin mohl zpracovat.[1] BankParser dovoluje podle zvolených filtrů (variabilní číslo, číslo účtu, datum, atd.) vybírat žádané položky ze vstupního dokumentu. Takto vytvořený seznam bude transformován do standardního XML dokumentu. Příklad vstupu a výstupu je uveden na obrázcích 3.1 a 3.2.
Pro projekt e-bedynky jsou důležité dvě vlastnosti této aplikace. 1. BankParser podporuje pluginy, tím pádem je možné napsat plugin pro zpracování výpisu z jakékoliv banky, což dovoluje pro budoucí uživatele být nezávislý na vybané bance, a udržovat takzvaný Internet Merchant Account v jakékoliv bance. Momentálně BankParser obsahuje pluginy pro parsovani bankovních výpisů z KB a Mbank. 2. Výstupem BankParseru je validní XML soubor, tím pádem tento soubor lze parsovat jako XML a ukládat data o všech finančních procesech do databáze, což je naprosto nezbytné pro budouci uživatelé systému.
3.1
Analýza a zprovozňování BankParser
Hlavním problémem při nasazení této webové služby do projektu e-bedynky, pro mne bylo to, že dřív jsem nikdy nepracoval s webovými službami a proto jsem o nich prakticky nic nevěděl, proto jsem musel nastudovat co to je webová služba a jak to funguje. Takže předtím, než jsem začal nasazovat BankParser, jsem potřeboval mít alespoň základní znalosti o webových službách. Při mém samostudiu mi velmi pomohla bakalářská práce pana Zimy a informace, kterou jsem získal na webu včetně wikipedie[12] a stránek w3[13]. Poté co jsem získal dostatek informací o webových službách, jsem začal nasazovat BankParser podle návodu, který napsal pan Zíma. Podle tohoto návodu jsem nejprve musel zkopírovat již zkompilovaný server webové služby (dále jen BP-WS) do složky autodeploy aplikačního serveru GlassFish. Tato složka v GlasFish má speciální význam: jakákoliv webová aplikace (samozřejmě funkční a zkompilována) je automaticky nasazená na server. Tento krok nasazení proběhl úspěšně.
3.1. ANALÝZA A ZPROVOZŇOVÁNÍ BANKPARSER
17
Dalšm krokem podle návodu bylo stejným způsobem deploynout klient webové služby BankParser (dále jen BP-WS-Client) na server, ale tento krok má jednu podmínku. Klient se musí vázat na určitý wsdl soubor a proto pokud nespustíme BP-WS na standardní adrese http://localhost:8080/bp-ws/bpwsService je třeba přizpůsobit anotaci ve třídě bpws.BpwsCLientServlet takto: wsdlLocation = "skutecna lokace wsdl souboru" ... public class BPWSClientServlet extends HttpServlet { @WebServiceRef(wsdlLocation = "http://localhost:8080/bp-ws/bpwsService?wsdl") private BpwsService service; ... Poté je třeba rebuild aplikace a nasazení bpws-web-client.war souboru do AUTODEPLOY adresare GlassFish. Protože jsem chtěl spouštět BankParser na localhostu na portu 8080, rozhodl jsem se, že nepotřebuju dělat žádné změny ve stanovení umístění wsdl souboru. Poté co jsem umístil BP-WS-Client do složky autodeploy, GlassFish automaticky udělal deploy na adrese http://localhost:8080/bp-ws-web -client/. Pomocí jednoduchého uživatelského rozhraní jsem vložil elektronický výpis z banky, který poskytl pan Zima ve své bakalářské práci. Bohužel po zmáčknutí tlačítka parseData mi Glass Fish odpověděl chybou: The requested resource is not available. Tato chyba znamenala, že z nějakých důvodů je wsdl soubor, který potřebuje BP-WS-Client ke správně práci, na jiné adrese než uvedl pan Zima ve svém návodu. Proto jsem pomocí Admin Console nástroje, který je součástí GlassFish a je určen ke správě tohoto serveru, zjistil, že wsdl soubor je umístěn na adrese http://localhost:8080/bpwsService/bpws?wsdl což mě velice překvapilo, protože žádné změny v BP-WS jsem nedělal, a proto jsem spoléhal na to, že wsdl soubor je umístěn na běžné adrese. V návodu od pana Zimy je však naštěstí popsáno jak lze tento vyřešit problém. Musel jsem ve zdrojovém kódu klienta aplikace změnit umístění wsdl soubrou. Poté, co jsem změnil umístění wsdl souboru a pokusil se udělat build aplikace,dostal jsem chybu .../bpwsService/wsdl/localhost_21296/bp-ws does not exist. Bohužel v návodě od Pana Zimy už žádné pokyny jak řešit jiné problémy nebyly, proto jsem od tohoto momentu musel všechny chyby vyhledávat a opravovat samostatně. Chybu, na kterou jsem narazil, jsem odstranil pomocí obyčejného přejmenování složky localhost_ 8080 na localhost_21296. Když jsem se znovu pokusil udělat build, dostal jsem jinou chybu: schema_reference.4: Failed to read schema document ’http://localhost:8080/bp-ws/bpwsService?xsd=1 Tato chyba znamenala, že v nějakých konfiguračních souborech je nastavena stará adresa umístění wsdl souboru. Jediný konfigurační file, který má na to vliv, je vlastně samotný wsdl soubor, proto jsem v něm musel také změnit adresu wsdl souboru na novou. Poté, co
jsem to udělal, se mi konečně podařilo udělat build a během tohoto procesu NetBeans vygenerovaly zbylou část zdrojového kódu BP-WS-Client. Ale v momentě kdy jsem se pokusil zase zparsovat zkušební soubor mi GalssFish nahlásil další chybu (víz Obrázek 3.4). Tato chyba byla jednou z nejsložitějších. Nebylo to z hlediska jejího odstraňování ale získání informací o ní. Čirou náhodou jsem narazil na internetu na článek, ve kterém bylo popsáno, jak vytvořit jednoduchou webovou službu pomocí GlassFish a Eclipse.[14] V tomto článku, naštěstí, byla popsána i tato chyba. Zjistil jsem, že tento problém vzniká kvůli použiti GlassFish updatetool (nástroj pro přidávání nových modulů do GlassFish), který jsme nainstalovali a použili během implementace e-bedynek, protože pořád se nám nedařilo spustit aplikaci a mysleli jsme, že potřebujeme nějaký dodatečný modul pro GlassFish. Bohužel v tomto článku byl popsán pouze jeden způsob, jak se dá této chyby
3.2. ZHODNOCENÍ
19
zbavit, a sice reinstalovat GlassFish. Obával jsem se, že po po reinstalaci aplikačního serveru přestanou fungovat e-bedynky. Nicméně poté, co jsem reinstaloval server, se e-bedýnky podařilo bezproblémově spustit a funkcionalita e-bedynek nebyla poškozená. Když jsem reinstaloval aplikační server, pokusil jsem se znovu spustit aplikaci a zparsovat soubor. Tentokrát dopadlo to mnohem lépe, ale přesto ne ideálně. Dostal jsem na výstup tabulku, která ale obsahovala pouze názvy sloupců a vůbec neukazovala výstup zparsovaného souboru(víz Obrázek 3.5). Ale jak je vidět na obrázku 3.5, aplikace umí hlásit číslo chyby
Obrázek 3.5: Chybová hláška BankParseru
v tagu errorCode.V případě parsovani electronickeho výpisu banky KB mi aplikace hlásila chybu číslo 1. Ve zdrojovém kódu aplikace jsem našel komentáře, které popisují jaké číslo chyby co znamená. Takže chyba číslo 1 znamená, že aplikace neobsahuje modul pro parsovani tohoto souboru, což byl docela překvapující fakt, protože aplikace pravě má 2 moduly: první pro KB, druhý pro mBank. Při pokusu zparsovat výpis z účtu od mBanky jsem dostal jsem chybu číslo 20, což podle dokumentace znamená, že soubor má špatný formát. Tyto 2 chyby mě přivedly na zajímavou myšlenku, že problém může byt v tom, že já mám nainstalovány české Windows, ale regionální nastavení a jazyk pro programy nepodporující Unicode mám nastaveno na ruštinu. Navíc soubory s testovacími výpisy z bank se také zobrazovaly na mém počítači nesprávně - místo písmen, které mají čárky nebo háčky, se mi zobrazovala ruská písmena. Proto jsem změnil nastavení na české, udělal redeploy a znovu se pokusil zparsovat výpis z KB banky pomocí BankParseru. A tetnokrat se mi to podařilo a dostal jsem na výstup tabulku. Ale při pokusu zparsovat soubor mBanky jsem na výstup dostal pouze chybu číslo 0, která bohužel nebyla popsaná v dokumentaci.
3.2
Zhodnocení
Většina problému, které jsem potkal, byla způsobena tím, že jsem nikdy dříve nepracoval s webovou službou. Proto jsem potřeboval nastudovat vše běhěm práce. Z větší části se mi podařilo zprovoznit webovou službu BankParser a pochopit, jakým způsobem tato webová
20
KAPITOLA 3. BANKPARSER
služba funguje. Nezvládl jsem ale zprovoznit parsování bankovních výpisů mBanky, neboť jsem nezvládl odhalit důvod této chyby. Také na základě mé analýzy lze říct, že BankParser je částečně platformové závislý a na systémech, které nepodporují češtinu, nebude pracovat správně.
Kapitola 4
Nasazení platebního systému do projektu e-bedynky. Prvním, a hlavním, bodem při nasazení platebního systému bylo rozhodnout, jak vlastně platba bude probíhat. První myšlenkou bylo implementovat platební systém pomocí centrálního účtu. V takovém případě by byly při platbě peníze nejprve převedeny na centrální účet provozovatele e-bedynek a jednou, například za 10 hodin, by tyto peníze byly hromadně přeposílány na účty dodavatelů. Bohužel tento systém obsahuje více záporů než kladů. Výhodou tohoto systému je možnost nasazení přímé platby kartou bez prostředníků, jako je například systém PayPal nebo PaySec. Ale při takovém způsobu platby by provozovatel systému musel mít tzv. murchant účet v bance a přebrat zodpovědnost za případné poruchy v systému, které by mohly způsobit chybu při posílání peněz a dokonce ztrátu peněz. Proto jsme se rozhodli, že nebudeme používat centrální účet a všechny platby budou probíhat pouze mezi uživateli, tzn. z účtu zákazníku na účet dodavatele. Dále bylo řešeno, zda bude nastaven limit pro částku peněz, která může být zaplacena pomocí PayPal. To znamená, že částku, která je větší než 1000 korun bude muset zákazník zaplatit při odebrání zboží. Výhodou tohoto systému jsou: 1. Snadná implementace 2. Provozovatel nebude mít žádné finanční nebo právní problémy, protože všechny transakce budou probíhat pouze mezi uživateli systému. 3. Menší zatíženost systému Hlavním problémem tohoto systému je nemožnost používání přímé platby kartou, protože takový způsob platby je vázán pouze jeden účet. Ale rozhodli jsme se, že jako náhradu tohoto způsobu platby dodavatel bude mít možnost uvést svůj bankovní účet, na který zákazník bude moci převést peníze pomocí elektronického bankovnictví nebo přímo v bance. Takový způsob používá, například, aukční portál Aukro.cz.
21
22KAPITOLA 4. NASAZENÍ PLATEBNÍHO SYSTÉMU DO PROJEKTU E-BEDYNKY.
4.1
PayPal.
Jak už jsem zmínil, při implementaci platebního systému s přímou platbou mezi zákazníkem a dodavatelem není možné použít platbu bez prostředníka a na základě analýzy jsem se rozhodl používat k těmto účelům PayPal.
4.1.1
Web Payment Standart
Rozhodl jsem se používat Website Payment Standard, což jsou PayPal tlačítka, která jsou snadná a rychlá na implementaci a zároveň mají velké množství různých nastavení, což umožňuje postavit celý e-shop pouze pomocí těchto tlačítek. Proto, aby bylo využito Buy Now tlačítko stačí vložit tento kód: Tento HTML kód je klíčový pro PayPal tlačítko. Přidat další funkcionalitu je možno pomocí proměnných, které jsou uvedené na stránkách PayPal [15]. V uvedeném kódu jsou 3 základní proměnné: 1. business – email, na který je vázán PayPal účet dodavatele 2. amount – částka k zaplacení 3. currency_code – název měny 4.1.1.1
Jak to funguje
Při registraci může dodavatel uvést email, na který je vázán PayPal účet. Na základě tohoto emailu a částky, kterou musí zaplatit zákazník, bude generovat PayPal tlačítko “Buy Now”. Bohužel musel jsem použit tlačítko PayPal bez šifrování a to z toho důvodu, že šifrovací tlačítko vyžaduje certifikát a tento certifikát musí být spojen s PayPal účtem daného uživatele, což může udělat pouze vlastník tohoto účtu. Pro objednání zboží zákazník bude muset postupovat následujícím způsobem: 1. Přihlásit se do systému 2. V menu vybrat Offers - > View all offers
4.1. PAYPAL.
23
3. Z nabídky všech bedýnek vybrat tu, která ho zajímá a zmáčknout na odkaz Detail 4. Vybrat počet bedýnek, které chce objednat 5. Zmáčknout tlačítko Order 6. Po zmáčknuti tlačítka Order, se uživateli zobrazí rekapitulace všech údajů o objednávce a pokud dodavatel uvedl email svého PayPal účtu a není překročena maximální částka pro placení pomocí PayPal, taky se zobrazí tlačítko “Buy Now” 7. Po zmáčknuti tlačítka Buy Now bude uživatel přesměrován na stránku PayPal, kde, pokud tak neučinil dříve, se bude muset přihlásit, potvrdit objednávku a zaplatit. 8. Po ukončení nákupu uživatel bude přesměrován zpět na hlavní stránku aplikace.
Obrázek 4.1: Rekapitulace všech údajů o objednávce
4.1.1.2
Testování Web Payment Standart
Testování Web Payment Standart bylo docela jednoduché. Pro testování PayPal tlačítek jsem použil PayPal sandbox[16], kde jsem po registraci vytvořil 2 účty. Jeden reprezentující kupujícího, druhý prodejce. Pak jsem v systému vytvořil nového prodejce, kterému jsem při registraci uvedl PayPal email vygenerovaný testovacím rozhraním PayPalu. Potom jsem přidal novou nabídku a po přihlášení z účtu zákazníka, ji objednal a zaplatil pomocí paypalu.
4.1.2
PayPal Instant Payment Notification
PayPal dovoluje v naší aplikaci zákazníkům hned při objednání bedynky za ní zaplatit. Pro zákazníka to je velmi pohodlné a komfortní. Zároveň je ale třeba zaručit komfortní
24KAPITOLA 4. NASAZENÍ PLATEBNÍHO SYSTÉMU DO PROJEKTU E-BEDYNKY.
obchodování pomocí paypalu i pro dodavatele, jinak by dodavatel musel evidovat veškeré platby nejenom na stránkách aplikace e-bedynky, ale také v paypalu.Proto je mnohém lépší z hlediska pohodlí centralizovat informace o platbáh v naší aplikaci. Pravě pro evidenci PayPal plateb slouží Instant Payment Notification (dále IPN). 4.1.2.1
Analýza PayPal IPN
IPN je speciální služba, která informuje o událostech souvisejících s PayPal transakcí. Tuto informaci lze využít pro, například, evidence plateb, které byly provedené z vašich webových stránek. Pro příjem zpráv, které nám posílá IPN, je třeba naprogramovat specialní program, který se nazývá posluchač (listener).Tento program musí ihned po přijetí zprávy tuto zprávu zpracovat. Případně provést další operace související s evidencí plateb. Následující graf 4.2 ukazuje autentifikačný protokol IPN.
1. V momentě, kdy bylo zmáčknuté PayPal tlačítko, uživatel bude přesměrován na stránku PayPalu,kde bude pokračovat v nákupu. 2. PayPal IPN odešle posluchači zprávu, která jej upozorní na akce 3. Posluchač musí odeslat v kompletním nezměněném zprávu zpět na PayPal, zpráva musí obsahovat stejné pole ve stejném pořadí a být zakódována stejným způsobem jako původní zpráva, jen do zprávy musí být navíc přidán parametr cmd=_notifyvalidate. 4. PayPal pošle zpátky pouze jedno slovo, a to buď VERIFIED, v případě, že odeslaná posluchačem zpráva souhlasí se zprávou, kterou poslal PayPal, anebo INVALID v opačném případě.
4.1. PAYPAL.
25
V případě, jestli posluchač dostál zprávu INVALID, je třeba tuto platbu buď zahodit,anebo (což je lepší) uložit do logu nebo do databáze pro budoucí vyšetřování.V případě, že posluchač dostal zprávu VERIFIED, je třeba ověřit parametr payment_status, který může nabývat následujících hodnot : • Canceled_Reversal: pokud vrácení peněz bylo zrušené. K tomu může dojít jestli došlo ke sporu mezí kupujícím a dodavatelem, a peníze zpočátku byly vráceny zpátky kupujícímu, ale dodavatel následně vyhrál spor a peníze byly zase vráceny jemu. • Completed: v případě, zda platba proběhla úspěšně • Expired: v případě, že doba platnosti autentifikace byla vyčerpána a plátce neposlal žádné peníze • Failed: v případě, že platba proběhla neúspěšně • Pending: pokud došlo k nějakým dalším potížím a je třeba se podívat do parametru pending_reason pro další vysvětlení • Refunded: jestli platba byla vrácena zpátky kupujícímu • Reversed: jestli došlo k nějakému sporu a peníze z vašeho účtu byly vráceny zpátky kupujícímu • Voided: v případě, že autorizace byla zrušena. • Processed: v případě, ze transakce byla schválena. Jak uz jsem zmínil, pokud hodnota parametru payment_status je Pending, máme ověřit parametr pending_reason, který může nabývat následujících hodnot: • address: jestli došlo k nějakým potížím s adresou doručení • echeck: v případě, že kupující zaplatil pomocí eCheck • withdrawal mechanism: pokud země zákazníka nepodporuje vyzvednutí peněz z PayPalu • multi-currency: jestli došlo ke konvertorování měny, například z amerických dolarů na české koruny • paymentreview: v případě, jestli PayPal rozhodl, že tato platba je riskantní • unilateral: v případě, že platba byla odeslána na email, který ještě není zaregistrovaný nebo schválený v PayPalu • upgrade: pokud platba proběhla pomocí kreditní karty a dodavatel potřebuje upgrejdovat svůj účet na Bussiness nebo Premium, aby dostal tuto platbu, nebo jestli byl překročen měsíční limit transakce • other: v případě, kdy platba má status Pending z jiných důvodů a pro další vysvětlení je třeba kontaktovat centrum podpory uživatelů PayPal
26KAPITOLA 4. NASAZENÍ PLATEBNÍHO SYSTÉMU DO PROJEKTU E-BEDYNKY.
Najít význam, a případně hodnotu jiných proměnných lze na stránkách PayPalu [18]. Taky je třeba dát pozor na to, že IPN je asynchronní, proto pokud IPN nedostane odpověď od posluchače během 30 secund, IPN pošle tuto zprávu ještě jednou, a to znamená, že mohou vzniknout duplicity, které je třeba ošetřit, například pomocí ID transakce [17]. 4.1.2.2
Integrace PayPal INP do projektu e-bedynky
Hlavním problémem při integraci IPN do e-bedynek bylo hledání potřebných informací. Tento krok byl docela problematický z toho důvodu, že veškerou dokumentaci a návody má PayPal velmi špatně strukturované. Navíc informace, kterých se týká používání IPN spolu se springem, na internetu prakticky nejsou, a proto většinu problémů, které jsem potkal při implemetaci, jsem musel řešit samostatně. Prvním krokem který jsem udelal bylo přidání následujících parametrů do kódu PayPal tlačítka : • return: hodnotou tohoto parametru musí být adresa, kam PayPal přesmeřuje uživatele po ukončení nákupu • notify_url: tento parametr je nejdůležitější pro správné fungování IPN, hodnotou parametru musí být adresa na kterou IPN bude posílat zprávy o platbě. • item_number: tento parametr není povinný, hodnotou tohoto paramentru je číslo objednávky. Toto číslo, stejně jako i ostatní atributy, se objeví v IPN zprávě, a díky němu lze dohledat objednávku, které patří tato platba. Dalším krokem bylo naprogramovat servlet a v případě Spring MVC controller, který by přijímal a zpracovával zprávy, které posílá IPN pomocí metody HTTP POST. Tento controller reprezentuje posluchače. K těmto účelům jsem použil kód, který je uveden na stránkách PayPalu a implementuje autentifikace s IPN [19]. Po drobné modifikace jsem přizpůsobil tento kód pro Spring MVC. Dál je třeba zpracovat a uložit platbu do databáze. Zpracování platby probíhá následujícím způsobem: 1. Program ověří zda platba má status VERIFIED, pokud ano, pokračuje dále. Pokud platba má status INVALID nebo došlo k dalším chybám, program platbu zahodí. 2. Pak program ověří, zda hodnota parametru payment_status je Completed, Pending nebo Processed. Pokud ano, program pokračuje dále, pokud ne, program zahodí platbu. 3. Dále program zpracuje následující parametry platby: • item_number: hodnotou tohoto parametru je identifikační číslo objednávky a pomocí tohoto čísla program nalezne příslušnou objednávku v databázi. • mc_currency: hodnotou tohoto paramenru je měna, ve které se provedla transakce. Tuto hodnotu program použije pro nastavení měny platby. • mc_gross: hodnotou tohoto parametru je zaplacená částka. Tuto hodnotu program použije pro nastavení zaplacené částky platby.
4.1. PAYPAL.
27
• txnId: hodnotou tohoto paramtru je identifikační číslo platby. Tuto hodnotu program použije pro nastavení ID platby • payer_email: hodnotou tohoto parametru je email plátce. Tuto hodnotu program používá pro nastavení čísla účtu příchozí platby (v případě PayPalu dá se považovat email plátce, na který je vázán PayPal účet, za číslo účtu). • receiver_email: hodnotou tohoto paramentru je email dodavatele. Tuto hodnotu program použije pro nalezení uživatele, kterému táto platba patří. 4. Program ověří zda pomocí emailu byl nalezen dodavatel. Pokud ano, program pokračuje dál, pokud ne, program nastaví status platby „SupplierNotFound” . 5. Program ověří pomocí čísla objednávky, které jsme dostaly v IPN zprávě, zda taková objednávka existuje.Pokud ano, program pokračuje dál, pokud ne, program nastaví status platby „nezařazená”. 6. Program ověří, zda dodavatel, který býl nalezen pomocí parametru receiver_email v IPN zprávě, souhlasí s dodavatelem objednávky. Pokud ano, program změní status objednávky na „zaplaceno” místo statusu platby „zařazená.” Pokud ne, program nastaví platbu dodavatele a objednávku na null, status platby nastaví na „SupplierError” a do připomínek k platbě napíše hodnotu paramentru receiver_email a hodnotu parametru item_number. 7. V posledním kroku program ověří pomocí identifikačního čísla transakce, zda tato platba není duplicitní. Pokud není, uloží ji do databáze, pokud platba je duplicitní, program ji zahodí.
4.1.2.3
Testování
Testování probíhalo pomocí testovacího prostředí sandbox, které nabízí PayPal a to dvěma způsoby. První pomocí Instant Payment Notification Simulator.Tento nástroj generuje IPN zprávy a odesílá je na uvedenou adresu. Bohužel tento nástroj neumí posílat zprávy na IP adresu, ale posílá pouze na doménové jméno, příčemz port serveru, na kterém běží aplikace musí být nastaven na standardní HTTP port 80. Naštěstí už jsem měl doménové jméno, takže mi zbývalo pouze nastavit aplikační server GlassFish na port 80. V IPN simulátoru jsem uvedl adresu http://azimus.sh.cvut.cz/PayPalNot, kde azimus.sh.cvut.cz je moje doménové jméno a /PayPalNot je adresa, na kterou je mapován kontrolér, který poslouchá IPN zprávy. Druhý způsob testování byl pomocí testovacích účtů, které jsem vytvořil pomocí PayPal sandbox. A to tím způsobem, že jako zákazník jsem objednával bedýnky a platil za ně pomocí PayPal. Jako dodavatel, jsem kontroloval, zda se tyto platby zobrazují na mých stránkách a zda status objednávky se změnil na „zapláceno”. Aby tento způsob správně fungoval, nastavil jsem u PayPal tlačítka parametr notify_url na http://azimus.sh.cvut.cz/PayPalNot a return na http://azimus.sh.cvut.cz/, aby po ukončeni nákupu uživatel byl přesměrován zpátky na hlavní stránku e-bedynek.
28KAPITOLA 4. NASAZENÍ PLATEBNÍHO SYSTÉMU DO PROJEKTU E-BEDYNKY.
4.1.2.4
Analýza budoucího vývoje
Na dané etapě posluchač, který jsem iplementoval, plně podporuje autentifikačný protokol IPN a poskytuje základní funkcionalitu pro zpracování plateb. Ale při nasázení do reálného provozu nebo dalším vývoje je třeba také ošetřit i další chyby, které mohou nastat při zpracování platby, jako například ošetřit všechny varianty payment_status a případně pending_reason. Toto lze například udělat zavedením nové tabulky nebo dokonce několika tabulek v databázi, která bude evidovat problematické platby a program, které tyto problematické platby bude zpracovávat a upozorňovat administrátora systému a případně dodavatele systému. V jakémkoli případě systém zpracování plateb e-bedynek má spíš informační charakter, zaměřený na usnadnění procesu evidence plateb a objednávek pro dodavatele.
4.2
Zpracování elektronických bankovních výpisů
Jak už jsem zmínil, kvůli tomu, že jsme se rozhodli nepoužívat centrální bankovní účet, přes který by probíhaly veškeré transakce, e-bedynky nebudou podporovat přímou platbu kartou. Jako náhradu tohoto způsobu, jsme se rozhodli umožnit dodavateli uvést číslo svého účtu a v takovém případě, že zákazníkovi se po objednání bedýnky zobrazí veškeré potřebné informace pro platbu bankovním převodem. A sice: číslo bankovního účtu dodavatele, specifický symbol, který pro účely testování má hodnotu 2903657 a variabilní symbol - hodnota kterou je číslo objednávky. Postup kterým uživatel může získat tyto informace je úplně stejný jako v případě s platbou za bedýnky pomocí PayPal, jenom namísto PayPal tlačítka BuyNow se zobrazí informace pro platbu bankovním převodem, a v případě, že dodavatel uvede při registraci i PayPal email, tato informace se zobrazí spolu s PayPal tlačítkem a bude zákazníkovi určovat, jakým způsobem je pro něj pohodlnější platit.
4.2.1
BankParser
Jak už jsem zmínil, krom toho, že je třeba udělat použití e-bedynek co nejjednodušší a nejkomfortnější pro zákazníky, v žádném případě nelze zapomenout na dodavatele, a je třeba pro dodavatele se pokusit poskytnout rozhraní, které by jim usnadňovalo praci. To znamená, že pro dodavatele bude nejlépe zajistat, zda bude mít veškeré platby a objednávky na jedněm místě, v případě PayPalu jsem k těmto účelům použil PayPal IPN, a v případě platby bankovním převodem je vhodné použít BankParser. O webové službě BankParser jsem již zmiňoval ve třetí kapitole. V níž jsem podrobně popsal tuto webovou službu a problémy, které jsem potkal při jejím zprovoznění. Zopakuji pouze, že táto webová služba slouží pro parsovani bankovních výpisů do xml. Klient, který byl napsán p. Zimou, samozřejmě neodpovídá funkcionalitě, kterou zde potřebujeme v rámci projektu e-bedynky. Proto je potřeba naimplementovat nového klienta, který by býl integrován do naší aplikace a dovoloval veškeré údaje o provedených platbách ukládat do naší databáze. Nový klient, který jsem napsal, je samozřejmě integrován přímo do projektu a funguje následujícím způsobem:
4.2. ZPRACOVÁNÍ ELEKTRONICKÝCH BANKOVNÍCH VÝPISŮ
29
1. Pokud dodavatel bude chtít přidat nové platby, které dostal pomocí bankovního převodu, musí se přihlásit do systému a v nabídce menu vybrat Payment -> Add payment. Dodavatel bude přesměrován na stránku, kde bude moct odeslat soubor s elektronickým bankovním výpisem. 2. Tento soubor dostane Spring MVC kontrolér, který v daném případě reprezentuje klienta webové služby a odešle ho do BankParseru, přičemž hodnota specifického symbolu 2903657 je hodnota, na základě které se dá rozlišit zda tato platba patří do e-bedynek nebo ne. Proto tuto hodnotu klient taky pošle BankParseru jako jeden z parametrů filtru. 3. BankParser sparsuje tento soubor do xml a pošle zpátky klientovi pouze ty platby, které mají specifický symbol 2903657 ve formě Stringu. 4. Tento string klient pošle do třídy ParseXmlToPayments. Tato třída sparsuje xml do objektu typu Payment pomocí DOM parseru, přičemž s použitím hodnoty variabilného symbolu najde v databázi příslušnou objednávku a nastaví ji jako jeden z parametru platby. Po zavolání metoda getPaymentsList() vrátí klientovi všechny vytvořené objekty Payment ve formě datové struktury List. 5. Každou z těchto plateb klient ověří následujícím způsobem: (a) Pokud k platbě nebyla nalezena příslušná objednávka, klient nastaví status platby na „nazařazena”. (b) Pokud nebyl nalezen dodavatel objednávky, klient nastaví status platby na „SupplierNotFound”. (c) Pokud se momentálně přihlášený dodavatel neshoduje s dodavatelem objednávky, klient nastaví status objednávky na „nezařazená” a do poznámek platby přidá číslo objednávky. (d) Pokud je nalezen v databázi dodavatel, objednávka a momentálně přihlášený uživatel se shoduje s dodavatelem objednávky, klient nastaví status platby na „zařazeno” a změní stav příslušné objednávky na „zapláceno”. 6. Dál klient ověří, na základě identifikačního čísla transakce, zda platba není duplicitní a pokud není, uloží ji do databáze. Pokud je duplicitní zahodí ji. Po parsováni souboru bude uživatel moci prohlédnout všechny transakce včetně PayPal transakce, pokud zvolí v menu Payments - > All Payments.
4.2.2
Testování
Klienta webové služby BankParser testoval jsem pomocí elektronických bankovních výpisů, které poskytnul pan Zima ve své bakalářské práci. K těmto účelům jsem v původním elektronickém výpisu změnil 8 náhodných transakcí, a to následujícím způsobem: Specifický symbol těchto transakcí jsem změnil na 2903657, variabilní symbol byl změněn na hodnotu od 1 do 8, protože, jak už jsem zmínil, variabilní symbol v tomto případě rezprezentuje číslo objednávky.
30KAPITOLA 4. NASAZENÍ PLATEBNÍHO SYSTÉMU DO PROJEKTU E-BEDYNKY.
Obrázek 4.3: Zobrazení transakce v aplikace E-bedynki
4.2.3
Analýza budoucího vývoje
Momentální parsovaní bankovních výpisů v projektu e-bedynky je plně funkční a stabilní, nemá ale dokonalou ochranu proti chybám, které zákazník může udělat při platbě. Například nesprávné napsání specifického symbolu. V tomto případě platba bude vyhozená ještě při parsováni do xml. Tato metoda samozřejmě není ideální, a bylo by mnohém lepší, kdyby se systém rozhodoval zda tato platba může patřit k platbám za objednávky bedýnek na základě více parametrů. Například na základě zaplacení částky a data. Také je třeba dovolit uživateli přidávat ručně nové platby. Například v případě, že platba proběhla v hotovosti při odběru produktu, a povolit uživateli u plateb se statusem „nezařazená” určit, zda tato platba opravdu patří jemu a zda je třeba pouze předefinovat číslo objednávky, nebo tato platba má být zahozená.
Kapitola 5
Grafické uživatelské rozhraní Práce nad uživatelským grafickým rozhraním je spíše mým vedlejším úkolem. Před tím, než jsem začal pracovat nad projektem e-bedynky, jsem už měl pár zkušeností s prací s grafikou (je to vlastně mé hobby) a web designem. Proto jsem chtěl vyzkoušet své znalosti v praxi a pokusit se navrhnout jednoduchý a uživatelsky příjemný GUI pro e-bedynky.
5.1
Aktuální stav
Momentálně jsem vytvořil 2 hlavní verze uživatelského rozhraní. První verze byla spíše zkušební a byla příliš přetížená grafikou a obsahovala pouze jednoduché statické menu,které neodpovídalo funkcionalitě projektu. Nicméně layout, který jsem navrhnoul v první verzi, je používaný i nyní, a pokud nevzniknou nějaké dodatečné požadavky na tento aspekt GUI, layout měnit nebudu. Druhá verze GUI je aktuální a je nasazená na projekt. Tato
Obrázek 5.1: První verze GUI
31
32
KAPITOLA 5. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
verze už má mnohém jednodužší a čistší grafiku. Při vytvoření této verze GUI jsem se inspiroval grafickým rozhraním www.bedynky.cz. Taky podlé požadavků týmu jsem přidal CSS menu,které je implementováno pomocí Free CSS Drop-Down Menu Framework [21] a pomocí Spring-secutrity je závislé na roli uživatele, který je momentálně přihlášen. Tím pádem přihlášený uživatel může vidět pouze tu část menu, na kterou má oprávnění. Poslední verze
Obrázek 5.2: Druhá verze GUI
uživatelského rozhraní je otestovaná a přizpůsobená pro všechny běžné browsery: Opera, Mozilla, Chrome, Internet Explorer (v7, 8). Protože IE v7 nemá plnou podporu CSS pro správně fungování menu v tomto browseru je nutno použít jQuery skript.
5.2
Analýza budoucího vývoje.
Podle vlastní zkušenosti a analýzy webových stránek velkých projektů jsem pochopil několik základních pravidel web designu: Pravidlo, které jsem nazval „as simple as posible“, že vzhled a grafika na webové stránce měla by být jednoduchá a nesmí být přetížená velkým počtem grafickyh elementů. Používání obrázků jako pozadí webové stránky je obvykle považováno za velmi riskantní krok. Složitá grafika se obvykle používá pouze na reklamních a herních webových stránkách, nebo na strankah web-designérů. Pravidlo tří barev, toto pravidlo platí prakticky pro jakékoliv dobré webové stránky. Toto pravidlo znamená, že kromě hlavního banneru webová stránka může obsahovat 2, maximálně 3 další hlavní barvy (ale klidně se mohou použít odstíny těchto barev). Poslední pravidlo, které jsem odvodil z vlastní zkušenosti, se týká barvy hypertextových linků a barvy grafických elementů webové stránky. Studiem webových stránek velkých projektů jako je například Seznam.cz, Facebook, eBay, Yahoo, vk.com, mail.ru, Wikipedia.org lze vzvodit dvě zajímavé vlastnosti:
5.2. ANALÝZA BUDOUCÍHO VÝVOJE.
33
1. nejpoužívanější barvy u velkých projektů jsou: modrá, zelená a červená (žlutá). Ostatní barvy se obvyklé používají u menších projektů 2. barva hypertextových linků je obvyklé závislá na barvě grafických elementů. Toto pravidlo platí i naopak– jestliže je standardní barva pro hypertextové odkazy modrá, pak také velice často webové stránky preferují modrou barvu u grafických elementů
5.2.1
Usability
Jedním z nejdůležitějších aspektů web designu jsou takzvané usability stránky. Pod slovem usability ve web designu se obvyklé rozumí nakolik jsou webové stránky komfortní pro konečného uživatele, nebo nakolik stránky zdržují konečného uživatele při hledání potřebné informace. Je zřejmě, že pokud webová stránka bude mít komplikované ovládání nebo špatně strukturovaný text, uživatel opustí stránku a bude hledat podobnou informaci nebo službu na jiných stránkách. Zajímavý výzkum provedly marketingové firmy Enquiro a Did-it. Tyto firmy zkoumaly na jaké části webové stránky uživatel při vyhledávání informaci dává největší pozor. A těmto firmám se podařilo odhalit takzvané pravidlo zlatého trojúhelníku. A toto pravidlo říká, že nejdůležitější informace pro uživatele musí být umístěná v horním levém rohu stránky. Dalším pravidlem usability je to, že aplikace musí fungovat co nejrychleji, aby uživatel nemusel ztrácet čas čekáním než se stránka stáhne. V našem projektu je tento faktor závislý na třech věcech. První je HW, na kterém bude naše aplikace běžet. Je jasné, že pokud aplikace bude běžet na serveru, který má nedostačující parametry HW, není možné splnit toto pravidlo usability. Druhým faktorem je optimalizace kódu aplikace. Třetí faktor je vlastně důsledkem pravidla web designu, které jsem uvedl na začátku, a sice, že webová stránka nesmí obsahovat příliš mnoho složitých grafických elementů. Je zřejmé, že pokud stránka bude obsahovat např. hodně velkých nebo špatně optimalizovaných obrázků bude fungovat velmi pomalu, zejména pro uživatele, kteří mají pomalý internet. Posledním důležitým pravidlem usability je to, že nelze používat vyhledávání jako náhradu k dobře vytvořeným navigačním složkám. Toto pravidlo je podlé mě velíce důležité pro nás protože při dalším vývoji e-bedynek je zřejmé, že funkcionalita bude narůstat, proto bude potřeba buď dobře strukturalizovat webové stránky nebo použít dodatečné menu nebo použít docela moderní a populární nástroj, který se nazývá megamenu. Je to klasické dynamické menu, které může být implementované pomocí CSS, ale toto menu je větší a může obsahovat obrázky, malé části textu (například abstrakt k nějakému článku) a podmenu.
5.2.2
Ochrana správnosti vstupních dat
Posledním důležitým problémem pro náš projekt je ochrana správnosti vstupních dat. Tento problém se dá vyřešit dvěma způsoby. První je ochrana pomocí JavaScriptu. Avšak toto řešení není dobré, protože uživatel může mít vypnutou podporu Javascriptu a tím pádem uvést vstupní data do formulářů nesprávně. Toto může být uděláno buď náhodně nebo speciálně aby porušil fungování aplikace nebo za účelem krádeže soukromých dat. Proto v našem projektu používáme validace pomocí nástrojů, které poskytuje Hibarnate a Spring MVC. JavaScript je vhodný spíše pro upozornění uživatele při vyplňování formulářů před tím než je uživatel odešle na server.
V Evropské unii žije přes 37 miliónů handicapovaných lidí a jejich počet se, díky stárnoucí populaci, neustále zvyšuje. Základní myšlenkou bezbariérového webu je umožnit těmto handicapovaným uživatelům Internetu používat webové stránky a dokumenty alespoň na takové úrovni, aby mohli využívat jimi zpřístupňované informace, aby se na webových stránkách dokázali orientovat a aby je snáze pochopili a aby nebyli omezováni na základě svých zdravotních omezení, technického vybavení, znalostí nebo dovedností. Cílem přístupnosti je neklást žádnému uživateli překážky v používání webových stránek, dokumentů a aplikací.[22]
5.3.1
Pravidla pro tvorbu přístupného webu.
Pravidla a metodiky přístupného webu, resp. jejich dodržování, jsou právě tím nástrojem, který těmto uživatelům umožní stránky používat když už ne plnohodnotně, pak alespoň bez výrazných omezení. Celosvětově nejznámější je metodika WCAG [23], v aktuální verzi 2.0. V České republice byla v roce 2004 vytvořena Pravidla pro tvorbu přístupného webu.
5.3. ANALÝZA PŘÍSTUPNÉHO WEBU
35
Aktuální verze těchto pravidel pochází z roku 2007 a v nejbližší době se stane součástí prováděcího předpisu Ministerstva vnitra.[22] Tito pravidla jsou rozdělený do 6 oblastí. Navíc je stanovena závaznost pravidel ve dvou úrovních - povinné pravidlo a podmíněně povinné pravidlo.[24] První skupinou pravidel jsou pravidla které popisují obsah webových stránek (povinné pravidla jsou označené tučné): 1. Každý netextový prvek nesoucí významové sdělení musí mít svou textovou alternativu. 2. Multimediální prvky nesoucí významové sdělení musí být doplněny textovými titulky, jestliže nejsou jen alternativou k existujícímu textovému obsahu. 3. Pokud to charakter webových stránek nevylučuje, informace sdělované prostřednictvím skriptů, objektů, appletů, kaskádových stylů, cookies a jiných doplňků na straně uživatele, musí být dostupné i bez kteréhokoli z těchto doplňků a stránky musí být standardně ovladatelné. V opačném případě sdělí orgán veřejné správy tyto informace jiným způsobem. 4. Informace sdělované vizuální podobou webových stránek, tvary jednotlivých prvků, jejich velikostí, pořadím nebo umístěním musí být dostupné i v případě, že uživatel nemůže tyto aspekty vnímat. 5. Informace sdělované barvou musí být dostupné i bez barevného rozlišení. 6. Barvy popředí a pozadí textu (nebo textu v obrázku) musí být vůči sobě dostatečně kontrastní, jestliže text nese významové sdělení. 7. Velikost písma musí být možné zvětšit alespoň na 200 % a zmenšit alespoň na 50 % původní hodnoty pomocí standardních funkcí prohlížeče. Při takové změně velikosti nesmí docházet ke ztrátě obsahu nebo funkcionality. Momentální uživatelské rozhraní e-bedynek odpovídá všem povinným pravidlům této skupiny, a to díky své jednoduchosti. Neodpovídá ale třetímu pravidlu, protože projekt obsahuje menu, které je implementování pomocí CSS a ve starých verzích IE pomocí jQuery. Další skupinou jsou pravidla které definují práci s webovou: 1. Obsah ani kód webové stránky nesmí předpokládat ani vyžadovat konkrétní výstupní či ovládací zařízení. 2. Obsah ani kód webové stránky nesmí předpokládat ani vyžadovat konkrétní způsob použití ani konkrétní programové vybavení. Pokud je předpokládáno či vyžadováno konkrétní programové vybavení, může to být pouze z důvodu technické nerealizovatelnosti přizpůsobení obsahu a kódu webové stránky všem programovým vybavením. 3.
Načtení nové webové stránky či přesměrování musí být možné jen po aktivaci odkazu nebo po odeslání formuláře.
36
KAPITOLA 5. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
4. Načtení nové webové stránky do nového okna prohlížeče musí být možné jen v odůvodněných případech a uživatel na to musí být předem upozorněn. 5. Na webové stránce nesmí docházet rychleji než třikrát za sekundu k výrazným změnám barevnosti, jasu, velikosti nebo umístění prvku. 6. Zvuk, který zní na webové stránce déle než tři sekundy, musí být možné na této webové stránce vypnout nebo upravit jeho hlasitost. 7. Časový limit pro práci s webovou stránkou musí být dostatečný. Pokud to nevylučuje charakter webové stránky, může uživatel časový limit prodloužit nebo vypnout. Uživatelské rozhraní e-bedynek splňuje všechny tyto body a to z důvodu, že neobsahuje ani složitou grafiku a ani jiné multimediální prvky, jako jsou video nebo zvuk. Nová stránka se načítá pouze v momentu, kdy uživatel aktivuje příslušný odkaz, přičemž se stránka otevře ve stejném okně. Další skupinou jsou pravidla které definují ovládání webu: 1. Navigace musí být srozumitelná a konzistentní a na všech webových stránkách orgánu veřejné správy obdobná. Od ostatního obsahu webové stránky musí být zřetelně oddělena. 2. Každá webová stránka (kromě úvodní webové stránky) musí obsahovat odkaz na vyšší úroveň v hierarchii webových stránek a odkaz na úvodní webovou stránku. 3. Pokud se jedná o rozsáhlejší webové stránky, musí být kromě navigace k dispozici rovněž vyhledávání nebo odkaz na mapu webových stránek. Odkaz na mapu webových stránek nebo vyhledávací formulář musí být k dispozici na každé webové stránce. 4. Každá webová stránka musí mít výstižný název odpovídající jejímu obsahu. 5. Pokud uživatel učiní chybu při vyplňování webového formuláře, musí být k dispozici informace o tom, ve které položce je chyba. Pokud to charakter webového formuláře nevylučuje, musí být k dispozici rovněž informace, jak tuto chybu odstranit. 6. Text odkazu nebo jeho přímo související text musí výstižně popisovat cíl odkazu. Jestliže odkaz vede na jiný typ souboru, než je webová stránka, musí být odkaz doplněn sdělením o typu, případně o velikosti tohoto souboru. 7. Každý rám musí mít vhodné jméno či popis vyjadřující jeho smysl a funkčnost. Na dané etapě uživatelské rozhraní e-bedýnek obsahuje menu, které je oddělené od ostatních části webové stránky. Název každé webové stránky odpovídá jejímu obsahu a textu odkazu a vždycky popisuje přesně jeho cíl. Bohužel webové stránky e-bedýnek neobsahují mapu a ve většině případů má stránka pouze hlavní stránku. To je dáno tím, že vývoj projektu ještě není dokončen a na dané etapě jsme dávali spíše přednost funkcionalitě projektu a ne jeho struktuře. Další skupinou jsou pravidla které definují jak musí vypadat kod stránek:
5.3. ANALÝZA PŘÍSTUPNÉHO WEBU
37
1. Sémantické značky, které jsou použity pro formátování obsahu, musí být použity ve zdrojovém kódu tak, aby odpovídaly významu obsahu. 2. Prvky značkovacího jazyka, které jsou párové, musí mít vždy uvedenu počáteční a koncovou značku. Značky musí být správně zanořeny a nesmí docházet k jejich křížení. 3. Ve zdrojovém kódu musí být určen hlavní jazyk obsahu webové stránky. 4. Každá webová stránka musí mít výstižný název odpovídající jejímu obsahu. 5. Prvky tvořící nadpisy a seznamy musí být korektně vyznačeny ve zdrojovém kódu a musí být výstižné. 6. Je-li tabulka použita pro zobrazení tabulkových dat, musí obsahovat značky pro záhlaví řádků nebo sloupců. 7. Obsah všech tabulek musí dávat smysl čtený po řádcích zleva doprava. Sémantických značek, stejně jako textu, projekt ještě obsahuje docela málo, ale tyto všechny značky jsou používány správně. Kód stránek projektu je validní, a to znamená, že párové tagy vždy obsahují počáteční a koncový tag a všechny elementy jsou správným způsobem zabořené. Tato vlastnost byla již při psaní stránek kontrolována pomocí NetBeans. Jako hlavní jazyk stránek je definována angličtina. Veškeré tabulky obsahují element
a jsou určeny pro čtení zleva napravo. Formuláře obsahují tag
Tento HTML kód je klíčový pro PayPal tlačítko. Přidat další funkcionalitu je možno pomocí proměnných, které jsou uvedené na stránkách PayPal [15]. V uvedeném kódu jsou 3 základní proměnné: 1. business – email, na který je vázán PayPal účet dodavatele 2. amount – částka k zaplacení 3. currency_code – název měny 4.1.1.1