BibPay MIKROBETALING. Udvikling af løsning til mikrobetaling via mobile enheder. Projekt udviklet i et samarbejde mellem:

Transkript

1 MIKROBETALING BibPay Udvikling af løsning til mikrobetaling via mobile enheder Projekt udviklet i et samarbejde mellem: Herning Bibliotekerne Silkeborg Bibliotekerne Cordura - med støtte fra Kulturstyrelsen Silkeborg / september

2 Indholdsfortegnelse Introduktion... 3 Formål... 4 Proces / historik... 5 Aftalepartnere... 6 Axiell... 6 NETS... 6 EPay... 6 SafeCom... 6 Datatilsyn... 6 BibPay intro... 7 BibPay, DANTEK og NCIP... 7 Andre systemer... 7 Køb og aftaler... 7 BibPay snitflader... 8 Front end API... 8 Betalings gateway Rapport og bogholderi BibPay og bibliotekssystem Login Betaling Kontooversigt Opsamling af beløb - inden transaktion Udfordringer Mulighed for delbetaling Differentiering af mellemværender SafeCom - testcase Integration med BibPay Andre mobile betalingsløsninger MobilePay fra Danske Bank Swipp SMS NFC Betaling Andre løsninger Konklusion

3 Introduktion Silkeborg og Herning Bibliotekerne fik via Kulturstyrelsens Overbygningspulje mulighed for at udvikle en løsning til mikrobetaling via mobiltelefon. Løsningen er tilpasset projektbibliotekernes nuværende bibliotekssystem, samtidig med, der er etableret en open source snitflade i en backend - kaldet BibPay - som Cordura har programmeret til løsningen. Løsningen vil kunne tilpasses i forbindelse med nyt bibliotekssystem eller løsninger som måtte opstå i forlængelse af Danskernes Digitale Biliotek (DDB), herunder det nye fælles nationale bibliotekssystem, som leveres af DANTEK A/S. Løsningen er ved projektets afslutning udviklet, så den efter en overvåget drift vil kunne implementeres på andre biblioteker fra årsskiftet. Projektet opererer med en løsning, som består af en webgrænseflade tilpasset præsentation på mobiltelefoner, tablets og PC. Denne webgrænseflade kan uden problemer skaleres til almindelig PC med browseradgang. Bibliotekets brugere vil således med produktet fra dette projekt, kunne betale i samme type grænseflade fra både mobiltelefon, tablet og almindelig PC. Dette øger produktets anvendelighed, da nogle af bibliotekets brugere måske endnu ikke er helt fortrolige med betaling via mobiltelefon, men er vant til betaling via internet. Brugerne kan: betale ydelser - delvist eller helt - fra bibliotekssystemets kontosystem, for eksempel gebyr i forbindelse med aflevering og erstatninger betale differentierede beløb for konkrete ydelser købt på biblioteket Betalinger håndteres af BibPay via gateway (epay) til NETS, som håndterer og validerer betalingen. Hvert bibliotek har i projektet oprettet indløsningsaftale med NETS. Omkostningen pr. transaktion er minimal, da gebyret fra NETS bliver som ved en standard webbutik. For at sikre understøttelse af så mange 3.parts programmerer som muligt, er der i projektet udviklet en open source API til BibPay. Tanken er at eksisterende systemer - til håndtering af print/kopi, billetsalg osv. - kan tilkobles via den åbne API. Biblioteker - eller andre - vil således selv kunne bygge tillægsmoduler eller integrere 3. parts systemer i BibPay. Under projektforløbet er SafeCom - som bruges på Herning Bibliotekerne - integreret som eksempel på denne funktionalitet. SafeCom er Herning Bibliotekernes leverandør af system til styring af print, fax og fotokopiering. I projektet er indgået vurdering af krav ved Datatilsyn med henblik på eventuel brug af personfølsomme data i BibPay. Projektets arbejdsgruppe: Sara Jørgensen og Birthe Mark Bornæs, Herning Bibliotekerne / bibsaj@herning.dk Karen Thomsen, Silkeborg Bibliotekerne / kath@silkeborgbib.dk Lis Wagner, Silkeborg Bibliotekerne / lisw@silkeborgbib.dk Tove Bitsch Andersen, Silkeborg Bibliotekerne / tba@silkeborgbib.dk Torben Olsen, Herning Bibliotekerne / bibtol@herning.dk Mogens Larsen, Silkeborg Bibliotekerne / mllar@silkeborgbib.dk Lau Rasmussen, Cordura / lau@cordura.dk Projektgruppen kan kontaktes ved interesse i at bruge BibPay - eller for yderligere information om projektets løsning. Projektets tovholder har været Mogens Larsen, Silkeborg Bibliotekerne. 3

4 Formål Modtagning af kontanter er en relativ dyr måde at håndtere betalinger på. Derfor har Kulturstyrelsen med Overbygningspuljen ønsket at sætte fokus på netbaseret betaling via mobile enheder. Formålet med dette projekt har således været at bidrage til afskaffelse af kontant betalinger på biblioteket. Kontantbetalinger er ressourcetungt arbejde for bibliotekspersonalet, og udvikling af en løsning til digital betaling ét sted for både gebyrer, regninger, kopi og print vil lette denne arbejdsbyrde betydeligt, samt gøre det nemmere for brugerne at foretage betalinger. Projektet skal således danne baggrund for at etablere en national løsning til betaling af biblioteksydelser og gebyrer via mobile enheder med henblik på at hæve graden af selvbetjening. En væsentlig del af projektet har været, at udvikle integration med projektdeltagernes bibliotekssystem (DDELibra), så betalinger foretages direkte på brugerens konto i bibliotekssystemet direkte fra brugerens bankkonto via en gateway til NETS. I projektet er desuden taget kontakt til firmaerne Lyngsoe Systems A/S og TagVision A/S. Disse firmaer leverer løsninger til selvbetjening. Denne kontakt er sket for at undersøge muligheden for integration af BibPay løsningen i firmaernes udlånsautomater. Desuden er firmaet SafeCom kontaktet med henblik på at integrere betaling via BibPay i firmaets løsning til print styring på Herning Bibliotekerne. Lyngsoe Systems A/S og TagVision A/S er interesseret i at integrere løsningen i firmaernes udlånsautomater. SafeCom er valgt som testcase, og dette firmas løsning er derfor i projektperioden integreret i den open source snitflade, som er udviklet i BibPay systemet. BibPay er bygget så systemuafhængigt som muligt bl.a. ved brug af NCIP protokollen. Ved udvidelser i denne eller andre API indgange vil systemet kunne integreres med andre systemer. I projektet er indgået estimat fra Cordura vedrørende pris på disse ydelser. 4

5 Proces / historik Da Silkeborg og Herning Bibliotekerne fik bevilget tilskud fra Overbygningspuljen begyndte en langvarig proces, som indebar kontakt med flere af de parter, det var nødvendigt at indgå aftaler med for at skabe den unikke betalingsløsning, som BibPay indeholder. Bibliotekernes systemleverandør - Axiell - havde ved projektets start allerede startet en proces med centrale kunder om at få udviklet en betalingsløsning via mobil. Men Axiell manglede en leverandør, som kunne løfte den tekniske del i forhold til slutbrugerne. Projektet deltog i et afklarende møde hos Axiell, hvor også CSC og Teller deltog. Teller var med, fordi de som part for bankerne var på vej til at introducere begrebet mobilpenge - et projekt som dog efterfølgende blev overhalet af andre løsninger med udgangspunkt i bankverdenen (MobilePay og Swipp). CSC udgik senere af processen, da den ydelse de kunne bidrage med allerede var indtænkt i BibPay. Da det stod klart, at Silkeborg og Herning Bibliotekerne fik bevilget penge til indeværende projekt, erklærede Axiell sig parat til at samarbejde om en løsning med Cordura som leverandør. Senere blev der afholdt møde med Teller om Mobilpenge, og der blev også underskrevet en aftale om at modtage mobilpenge. Men som nævnt har dette system ikke slået igennem. Ved start af projektet indgik også overvejelser om andre teknologier: NFC (Near Field Communication): er en netværksteknologi som virker trådløst på korte afstande. Teknologien er baseret på RFID-teknologien, og er kompatibel med eksisterende elektroniske betalingsmetoder. Eksempelvis kan en mobiltelefon med indbygget NFC anvendes som betalingsmiddel i forretninger og ved køb af billet til offentlig transport. NFC er dog endnu ikke introduceret i Danmark som åben betalingsløsning tilknyttet de nuværende betalingsteknologier, ligesom det stadig ikke er integreret i smartphones fra Apple. SMS: brug af overtakserede SMS er udgik også ret hurtigt af overvejelser om mobil betaling, ikke alene på grund af prisen, men også fordi en kontooversigt via telefonregning ville være et mindre fleksibelt redskab til håndtering af overskuelighed fremfor direkte træk på brugerens bankkonto, som de fleste ser via netbank på PC og mobile enheder. Sigtet med dette projekt har været at kunne overføre betalinger direkte fra brugerens bankkonto via et system (BibPay) direkte til bibliotekets lokale administrative system. Derved imødekommes brugernes behov for at kunne udføre en hurtig og sikker betaling direkte til biblioteket, samtidig med at betalinger kan overskues på en nem og sikker måde via BibPay miljøet, men også direkte i brugerne kontooversigt på Netbank. Undervejs i projektet har der været afholdt 2 workshops mellem projektets parter. Den første workshop klarlagde de udfordringer som bibliotekerne ønskede tilgodeset i løsningen, mens den 2. workshop vurderede Corduras foreløbige løsning og de eventuelle funktionaliteter, som blev integreret i projektets sidste del. I starten af projektet var der endvidere møde med repræsentanter fra Gladsaxe Bibliotek og Københavns Kommune. Mødet bidrog med ønsker til systemets udformning. Webgrænsefladen er som browserbaseret løsning lavet i HTML5. Løsningen tilgås via webadressen: Ved oprettelse af brugerkonto kræves, at brugeren er kendt i det lokale bibliotekssystem. Herefter oprettes passord til BibPay. Desuden tilknyttes bankkonto, som ønskes anvendt i BibPay. 5

6 Aftalepartnere Aftaleparter og interessenter - der har været inddraget i projektet - er: Axiell Axiell er Silkeborg og Herning Bibliotekernes nuværende systemleverandør. Systemet DDE- Libra håndterer bl.a. administrative brugerdata vedrørende betalinger for ydelser oprettet i bibliotekssystemet. De primære ydelser er betaling af gebyr ved for sent aflevere materialer samt erstatninger af bortkommet materiale. NETS NETS er nordisk udbyder af betalings-, kort- og informationsservices. Kunderne er bl.a. pengeinstitutter, som får håndteret (indløst) betalingsløsninger tilknyttet betalingstjenester i detailhandel og på nettet. NETS står bl.a. for betalingsløsninger tilknyttet VISA/Dankort og Masterkort. EPay EPay er en gateway, som via krypteret forbindelse overfører betalinger fra BibPay til NETS. Løsningen har form af en webshop på hjemmesiden. EPay håndterer programmering af gateway samt de høje sikkerhedskrav, der foreligger ved pengetransaktioner. Der findes andre firmaer som håndterer gateways. I dette projekt er valgt epay som gateway. SafeCom SafeCom er i projektet valgt til test af den åbne grænseflade i BibPay. SafeCom systemet er indført for at forenkle brugernes betaling for print, kopi og fax på Herning Bibliotekerne. Desuden har biblioteket selv udviklet et publikums logon system med navn UsePC med integration til bibliotekssystem og SafeCom. Datatilsyn Efter kig på 7 og 8 i persondataloven er Silkeborg Kommunes juridiske konsulent af den opfattelse, at det ikke er nødvendigt at anmelde brugen af Bibpay til Datatilsynet, da anvendelsen af data i BibPay som udgangspunkt ikke kategoriseres som brug af personfølsomme oplysninger. Bibliotekssystemer er i forvejen undtaget for anmeldelser, jf. 12 i Bekendtgørelsen om undtagelse fra pligten til anmeldelse m.v. 6

7 BibPay intro Udvikling af betalingsløsning via mobile enheder har været udgangspunkt for at lave projektet BibPay : mikrobetaling via mobile enheder. Ikke alene udbredelsen af smartphones, men også kravet om et tidssvarende bibliotekssystem fordrer, at denne form for service indtænkes i måden brugerne tilgår biblioteket på. En stor del af landets biblioteker er tilmeldt Danskernes Digitale Bibliotek, herunder udvikling af nyt CMS, hvilket betyder ny strategi og struktur for bibliotekernes hjemmesider. Dette påvirker ikke BibPay, da systemet er lavet som særskilt hjemmeside uafhængig af bibliotekernes eksisterende hjemmesider. Desuden er BibPay allerede nu tilpasset kommende brug via smartphones, tablets og PC. BibPay, DANTEK og NCIP BibPay er udviklet med sammenhæng til Herning og Silkeborg Bibliotekernes eksisterende bibliotekssystem (DDELibra), men vil kunne implementeres i det kommende nationale system, som er lagt i hænderne på DANTEK A/S. Det skyldes bl.a. at systemerne snakker sammen via NCIP-protokollen 1, som også indgår i kravene til det nye bibliotekssystem. Eventuelle ændringer i snitfladerne - efter skift til nyt bibliotekssystem - vil kunne laves i samarbejde med Cordura, som har udviklet BibPay s tekniske funktionaliteter. Endvidere kan ændringer i NCIP protokollen hos DANTEK A/S betyde flere muligheder for dataforespørgsler baseret på DANTEKs erfaringer fra skolebiblioteksområdet. I DDELibra har BibPay været underlagt de dataformater og protokoller for kommunikation, som systemet anvender i dag. Derfor har det i DDELibra kun været muligt at anvende en delmængde af de mulige forespørgsler i NCIP-protokollen. Denne mulighed har været bestemt af Kulturstyrelsens minimumskrav for kommunikation mellem bibliotekssystemer. Dataformater er bl.a. betinget af den struktur brugerregister og mellemværender har i bibliotekssystemets database. Andre systemer Tilkobling af selvbetjeningsautomater (udlånsstationer) vil kunne implementeres i BibPay. Dette begrundes i de tilbagemeldinger, som Lyngsoe Systems A/S og TagVision A/S har afleveret efter de har gennemgået BibPay projektets open source API. Køber et bibliotek Bibpay-systemet af Cordura, kan man endvidere vælge selv at udvikle services, der benytter funktionaliteten i Bibpay. Det kan være alt fra kantinekort, kaffemaskiner, billetsalg til parkering. Cordura kan også udvikle denne tilknytning for biblioteket. I projektet er SafeCom integreret i BibPays som testcase. Køb og aftaler BibPay systemet skal købes af det enkelte bibliotek. Desuden skal der laves indløsningsaftale med NETS samt etableres abonnement ved en gateway, som overfører betalinger fra BibPay til NETS. I nuværende projekt er anvendt epay som gateway. NETS er bankernes system, som henter penge på brugernes konto i det pengeinstitut, de selv har valgt. BibPay overfører pengene sikkert til bibliotekets administrative system og skaber de nødvendige rapporter for at kunne håndtere overvågning og opfølgning på indbetalinger fra brugerne til bibliotekets system. 1 en protokol er en aktuel indpakning af data mellem afsender og modtager, som sikrer at data når frem og kan tolkes korrekt. NCIP protokollen anvendes bl.a. i bibliotekssektoren. 7

8 BibPay snitflader Bibpay indeholder snitflader til andre systemer end bibliotekssystemet. Disse API er (FRONT END og BETALING) er lavet som open source. Dvs. metoderne kan eksponeres til 3. part så man selv kan kode op mod disse. Det er ingen forudsætning for BibPay, men en mulighed. Som eksempel på hvordan andre systemer tilkobles, er der udviklet en webservice til Herning Bibliotekerne, som benytter BibPays API. Denne webservice kører på Hernings SafeCom server. Der er ingen ekstra driftsudgifter forbundet med denne funktionalitet. Køber et bibliotek Bibpay-systemet af Cordura, kan man selv vælge at udvikle services tilknyttet 3.parts systemer, der vil benytte funktionaliteten i Bibpay. Det kan være alt fra kantinekort, kaffemaskiner, billetsalg til parkering. Biblioteket er selvfølgelig også velkommen til at kontakte Cordura for at løse denne opgave, som kan medføre øgede driftsudgifter. Front end API Front end API'en tillader eksterne systemer at interagere med BibPay systemet på vegne af brugerne, således at disse kan foretage betalinger til services brugeren er associeret med, med de betalingsmidler brugeren har tilføjet. Desuden skal gives en autentifikation af at brugeren reelt har accepteret den pågældende ordre på servicen. I projektet benyttes denne API bl.a. til at lade brugerne betale fra en eventuel selvbetjenings udlånsstation. Har brugeren gæld er det nu muligt at give brugeren mulighed for at betale med det samme. Lyngsoe Systems A/S og TagVision A/S vil kunne koble sig på denne løsning med deres selvbetjente udlånsstationer. Sikkerheden er baseret på at der bliver sendt en sms til brugerens mobiltelefon med en kode, som skal tastes på udlånsstationen inden betalingen reelt gennemføres. Frontend API en er udviklet så den kan bruges af andre systemer, som ønsker at modtage betalinger via biblioteket. 8

9 API en er skitseret i følgende diagram: 9

10 Betalings gateway Ud over en API adgang til BibPay, er der også udviklet en betalings gateway som kan initiere betalinger. Modsat Frontend API en aktiveres betalingen fra Bibpay brugergrænsefladen og sendes til et eksternt system. Formålet er f.eks. at tillade optankning af eksisterende printkonti eller at tilgå andre systemer, hvor brugerne allerede har en konto, men ingen smart indbetalingsmulighed. I dette projekt er denne løsning anvendt for at integrere testcasen SafeCom under projektets open source del. Brugerens pengene hæves således via Bibpay og sendes direkte til bibliotekets bankkonto. 3. parts systemet (her SafeCom) får med det samme besked om, at der er indsat penge på brugerens konto. Se afsnittet om SafeCom for detaljer. Bibpay er designet så kun det øverste lag Integration til BibPay API er specialudviklet til SafeCom. Opbygningen sikrer, at det kun er det midterste lag der skal udvikles, hvis andre systemer skal integreres op mod Bibpay. 3. part system SafeCom database Specielt udviklet WebService Integration til SafeCom API Integration til Bibpay API BibPay API via WebService Rapport og bogholderi BibPay sørger for at holde styr på alle transaktioner og har en rapportgenerator, der kan lave udtræk til bibliotekets administration. Rapporterne kan eksporteres til regnskabssystemer så efterfølgende administration holdes på et minimum. Det er muligt at se omsætning for enkelte services, brugere eller betalingsteknologier. Penge der betales via Bibpay flyttes direkte fra brugerens bank til bibliotekets konto. Hvor hurtigt pengene når frem til bibliotekets konto, afhænger af betalingsteknologien, men BibPay sørger for rapporter, der gør det nemt at afstemme og tjekke bogholderiet. Se eksempel på næste side: 10

11 11

12 BibPay og bibliotekssystem Kommunikationen mellem BibPay og bibliotekssystemet, DDELibra, sker med brug af NCIP 2 som protokol 3 og interface-modulet ALMA (API). Dette i henhold til vejledning for samarbejde mellem bibliotekssystemer og andre parter, Collaboration between Danish libraries and other agencies 4. Der er 3 funktionaliteter, hvor BibPay via NCIP og ALMA sender forespørgsler til bibliotekssystemet og får NCIP svar tilbage: Login Betaling Kontooversigt Login Nedenfor er vist håndteringen i integrationen mellem BibPay og bibliotekssystemet generelt

13 De enkelte trin i figuren er: Brugeren logger altid ind (trin 1) på med lånernummer fra bibliotekssystemet. Herefter tjekker BibPay, om brugeren er tilmeldt en BibPay-konto (trin 2). Herefter får brugeren vist sin aktuelle status for BibPay (trin 3 til 8). Er brugeren ikke tilmeldt BibPay, bliver brugeren oprettet. Når en bruger oprettes i BibPay indtastes cpr/lånernummer og pinkode fra bibliotekssystemet. Disse oplysninger knyttes til Bibpay brugeren. Samtidig skal brugeren vælge, hvilke af de mulige betalingstjenester, der skal tilknyttes brugerens BibPay-konto. Ved oprettelse i BibPay, registreres brugeren i en intern database i BibPay, hvor kobling mellem brugerens bruger-identifikation i bibliotekssystemet, mobilnummer, betalingskonto og samlede betalingsstatus opbevares sammen med et passord til BibPay, som skal bruges, når man frem over logger ind på BibPay. Er brugeren tilmeldt vil brugerinformationerne fra bibliotekssystemet findes i BibPay databasen. Derfor sender BibPay forespørgsel til bibliotekssystemet for at få hente BibPaybrugerens eventuelle aktuelle mellemværender og dermed sikre, at BibPay databasen er opdateret med status. 13

14 Betaling Nedenfor er vist håndteringen i integrationen mellem BibPay og bibliotekssystemet. De enkelte trin i figuren er: Brugeren vil betale mellemværende (trin 1) hos BibPay. BibPay sender forespørgsel til bibliotekssystemet om aktuel status på mellemværender som bibliotekssystemet har registreret for brugeren. (trin 2 og 3). Dette for at tjekke om der er kommet nye mellemværender siden brugeren sidst brugte BibPay. BibPay genererer og sender en transaktion via epay gateway til NETS omkring betaling (trin 4 og 5) og modtager svar om resultat fra NETS via epay gateway (trin 6). BibPay registrerer i den interne database betalingen og sender en opdatering til bibliotekets brugerregister med hensyn til ændret mellemværende (trin 7). Ny status sendes til bibliotekssystemet, der kvitterer (trin 8 og 9). Derefter sendes en kontooversigt med mail til brugerens enhed (trin 10). Her er et par specielle situationer omkring delbetaling at tage hensyn til: Hvis biblioteket har valgt, at delbetaling af mellemværender IKKE kan ske, vil opdatering kun kunne ske, når der er tale om betaling af hele mellemværendet. Brugeren har i denne situation ikke mulighed for at vælge Delbetaling i systemet. Ved delbetalinger har brugeren mulighed for at indbetale beløb under en vis grænse (grænsen sættes i den administrative grænseflade for det enkelte bibliotek). Det registreres i BibPay databasen og i bibliotekssystemet som betalt. 14

15 Når sådanne små beløb tilsammen summer op til en valgt nedre grænse sendes én transaktion til NETS på det samlede beløb, der så hæves på brugerens konto. Det fremgår tydeligt af kontooversigten, hvorvidt beløb er hævet på kontoen, eller blot registreret som betalt i BibPay og i bibliotekssystemet. 15

16 Kontooversigt Nedenfor er vist håndteringen i integrationen mellem BibPay og bibliotekssystemet. De enkelte trin i figuren beskrives herunder: Brugeren vil se kontooversigt i BibPay (trin1) BibPay sender forespørgsel til bibliotekssystemets brugerregistrering om aktuel status på mellemværender, som bibliotekssystemet har registreret for brugeren. (trin 2 og 3). Dette for at sikre, om der er kommet nye mellemværender siden brugeren sidst brugte BibPay. Bibpay bruger denne status til at opdatere databasen og til at generere en samlet kontooversigt sammen med status for andre tjenester, brugeren anvender sin BibPay-konto til. (trin 4 og 5). Opsamling af beløb - inden transaktion Biblioteket har valgt at differentiere mellem hævede og ikke-hævede beløb, da NETS kræver gebyr pr. transaktion. Ved små beløb (f.eks. 1 fotokopi) vil gebyret overstige den reelle pris for ydelsen, og derfor har biblioteket en mulighed for i den administrative adgang til BibPay at konfigurere en sum, som skal nås før beløbet reelt overføres via NETS fra brugerens bankkonto. En kontooversigt indbefatter begge typer beløb. Beløbene registreres i bibliotekssystemet som betalte, men der skelnes i præsentationen af kontooversigten mellem beløb hævet på bankkonto, kaldet Gennemførte - og beløb, der ikke er hævet på brugerens BibPay-bankkonto. Sidstnævnte benævnes Godkendt i oversigten. Bemærk, at der i kontooversigten på næste side kun optræder et beløb, der er Godkendt det vil sige registreret som betalt i bibliotekssystemet, men som endnu ikke er hævet på brugerens bankkonto. I afsnittet om Rapport og bogholderi, ses en kontooversigt, hvor flere beløb er hævet på brugerens bankkonto. 16

17 Udfordringer Undervejs i projektet har der været udfordringer i muligheder for brugerne i forhold til de informationer BibPay kan få fra bibliotekssystemet gennem NCIP. Mulighed for delbetaling Umiddelbart var ikke muligt gennem bibliotekssystemets API (ALMA) at foretage delbetaling af mellemværender til biblioteket. Projektet betalte for, at Axiell implementerede en sådan funktionalitet i bibliotekssystemet med adgang via ALMA. NETS stillede ved delbetaling krav om, at brugerne ikke måtte indtaste, men kun vælge mellem faste beløb, fx 25, 100, 175,. ved betaling. Dette blev implementeret gennem mulighed for at vælge delbetalingsbeløbet i en drop-down menu i brugergrænsefladen. Differentiering af mellemværender Det er ikke muligt i bibliotekssystemet i den aktuelle implementation af NCIP for biblioteket, at skelne mellem de forskellige typer af mellemværender: f.eks. gebyr og erstatning. Det kan derfor ikke i BibPay specificeres hvilken type mellemværende brugeren har, men kun ses beløb på de enkelte ydelser. Projektet har ikke anset det for væsentligt med differentiering, så derfor blev den beskrevne model implementeret i projektet. 17

18 SafeCom - testcase I det følgende beskrives hvordan BibPay som Front end API håndterer integrationen af SafeCom gennem den open source snitflade, som er integreret i løsningen: Når publikum benytter Publikums Print systemet indsættes et beløb på egen print konto, som der bliver trukket på under anvendelsen af services til print, kopiering og afsendelse af fax. SafeCom har ikke oprindeligt udviklet integration til bibliotekssystemet. Derfor håndteres to forskellige databaser og to forskellige brugerkonti (som dog typisk har navne sammenfald). Sammenhængen mellem disse to systemer skjules dog af UsePC, således at brugerne ser systemet som et hele i det øjeblik, det anvendes. SafeCom print systemet er et FollowMe print system, hvor alle print jobs sendes til den samme Print Pool (kø) og derefter kan udskrives af brugerne fra en valgfri Printing Device (fysisk printer). Se principskitsen herunder: Print pool Implementering af SafeCom baserer sig i høj grad på Herning Bibliotekernes egenudviklede logonsystem UsePC. Formålet med UsePC er at styre adgangen til Herning Bibliotekernes publikums pc'er, samt definere hvor lang tid hver bruger har adgang til at benytte en aktuel PC. UsePC giver også en stribe administrative muligheder som fx tildeling af ekstra tid, udelukkelse (karantæne), distribution af annoncering, WakeOnLan og Shutdown. Ved logon på UsePC undersøges om brugeren har en tilknyttet print konto. Hvis det ikke er tilfældet, oprettes automatisk en sådan via SafeCom API'et. Funktionen er vist i diagram på næste side. 18

19 UsePC validerer om bruger er oprettet i bibliotekssystemet? JA NEJ Via SafeCom API et tjekkes om bruger har en print konto Bruger kan IKKE benytte en pub pc og skal oprettes af personalet JA NEJ Logon OK SafeCom print konto oprettes og der indsættes 1 kr. på kontoen Bruger identifikation gemmes under anvendelse af pc Der kan indsættes penge på print kontoen på 2 måder: Med Credit card eller betalingskort via SafeCom WEB interface Med kontanter (sedler og mønter) i SafeCom Money Loader automat De væsentligste indvendinger/ulemper ved det nuværende system er, at publikum skal benytte forskellige grafiske interfaces til deponering af beløb på print konto og i afviklingen af gebyrer og erstatninger i bibliotekssystemet. Integration med BibPay BibPay tilbyder muligheden for et fælles interface til betaling af erstatninger og gebyrer i bibliotekssystemet samt betaling for print. Print betalingsdelen i BibPay er opbygget på baggrund af SafeCom API'et således at deponering af et beløb på SafeCom print konto sker transparent for brugerne. Princippet er illustreret på skitse - næste side. 19

20 BibPay betalings Gateway Herning Bibliotek Web opkobling mod BibPay Gateway Web Service SafeCom Server SafeCom API SafeCom database BibPay kontaktes via web-opkobling og brugeren vælger at indsætte (deponere) et beløb på sin print konto. Brugeren vælger et beløb som ønskes indsat. Som tidligere nævnt kan der kun vælges forud definerede beløb fra drop-down menu på grund af krav fra NETS. BibPay kommunikerer med den af Cordura udviklede web service, som er installeret på SafeCom print serveren. Fordelen ved denne løsning er, at eventuelle ændringer i webservicen ikke påvirker Herning Bibliotekernes UsePC system, som kommunikerer med API'et ved hjælp af sin egen webservice. Alle ændringer sendes fra Web servicen til SafeCom API'et som står for den praktiske opdatering af SafeCom databasen. Ovenstående modulopbyggede design sikrer at BibPay kan udbygges til at fungere sammen med andre print systemer, som tilbyder et entydigt interface som Web servicen kan kommunikere med. 20

21 Andre mobile betalingsløsninger Bibpay er forberedt til integration med andre betalingsløsninger. Nogle af de løsninger, der har været diskuteret undervejs i projektet er: MobilePay fra Danske Bank På få måneder har Danske Bank fået over private brugere af deres mobile betalingsløsning. Det vil være oplagt at integrere denne betalingsteknologi, men i dag er der følgende udfordringer: Swipp Der kan kun sendes penge til et mobilnummer Det er uklart hvilke vilkår en fremtidig kommerciel løsning vil være baseret på Konkurrent til MobilePay, men kræver tilknytning i netbank. Er mindre udbredt end MobilePay men kunne også blive interessant. Swipp er endnu ikke åbnet op for kommerciel brug og løsningen er kun til privatpersoner, der overfører penge privat. SMS De overtakserede sms er er udbredte men har følgende begrænsninger i forhold til BibPay: Generelt meget højt gebyr pr. transaktion Låneren opkræves via telefonregning NFC Betaling Fremtidens betaling med mobiltelefoner inkluderer sandsynligvis den trådløse RFID teknologi så man sikkert og trådløst kan overføre betalingsoplysninger (kortoplysninger) ved at vifte med mobiltelefonen. Der er eksempler på lukkede miljøer hvor NFC plastikkort eller armbånd bruges som identifikation, men de åbne løsninger som inkluderer udbredte betalingsteknologier (Dankort, Visa og MasterCard) er endnu ikke set i Danmark. Derfor kendes gebyrer og teknologi i forhold til BibPay endnu ikke. NFC er integreret i nyere Android smartphones, mens Apple endnu ikke har valgt løsningen i deres produkter. Andre løsninger Der pågår meget aktivitet med at designe fremtidens mobile betalinger. Pengeinstitutter og teleselskaber har konkurreret intenst de sidste 2-3 år, mens festivaler og events ligeledes udvikler deres egne interne (lukkede) systemer. Pay4it, BigEWallet og izettle er nogle af navnene på de markedsførte systemer. Sidstnævnte er en speciel løsning, hvor kortlæser kobles direkte på mobiltelefonen. Flere løsninger er på vej, da forretningsområdet rummer et stort potentiale - både for teleselskaber og banker, men også for udviklere af hard- og software til smartphones. 21