Betala förseningsavgifter i Voyager på webben med hjälp av Umbraco, TeaCommerce och DIBS

2015-02-11

Jag såg just att ExLibris tagit fram ett sätt att betala förseningsavgifter som skapats i ALMA genom PayPal och det slog mig att jag inte skrivit om Stockholms universitetsbiblioteks lösning här.

ExLibris har lagt upp ett blogginlägg där de visar hur de fått till betalning av förseningsavgifter på webben med hjälp av Almas API:er, PayPal och lite C#. De har också skrivit en port till Ruby on Rails.

Ända sedan vi tog fram vår bokhandel i Umbraco har vi haft på dagordningen att ta fram en lösning för att låta våra användare betala sina förseningsavgifter på webben. Våren 2014 slog vi till och smygöppnade en tjänst som bygger på samma teknik som bokhandeln med den skillnaden att den enda produkt man kan köpa är en förseningsavgift, och att priset varierar från person till person.

Vi har fått det att fungera bra om jag förstår det rätt. Användarupplevelsen kunde vara bättre på sina ställen och lösningen lider av att bokhandeln är del av samma tjänst.

Hur det fungerar

När låntagaren loggar in på bibliotekets webbplats sker ett anrop till Voyager via ett REST-API som returnerar eventuella avgifter för låntagaren. Har låntagaren avgifter så presenteras dessa för låntagaren som kan välja vilka avgifter som ska betalas.

Fines1

I bilden ovan syns inte titlarna på de försenade böckerna, men det gör de för en riktigt låntagare.

I och med valet skapas en orderrad och en order i Umbraco/TeaCommerce.

Låntagaren klickar på Betala och tas till en sida där villkoren godkänns och där låntagaren kan se att alla uppgifter stämmer:

Fines2

Väljer låntagaren att gå vidare med betalningen skickas denne vidare till DIBS, och om betalningen går igenom anropas Voyager och böterna stryks.

Fines3

Låntagaren når sedan en bekräftelsesida där resultat av betalning och strykningen av avgifterna visas.

En stor oro inför lanseringen var att kommunikationen mellan Voyager och Umbraco skulle fela och att böterna inte skulle strykas. Jag skrev in en del felhantering för detta så att det skulle gå snabbt att hitta felande ordrar, men som det verkar har det inträffat en gång. Synd för det skulle vara en fin anledning till att få implementera en kö.

Användning

Jag samlade lite statistik från betalningarna och här är de. Vi har gjort väldigt lite reklam för tjänsten, användarna har i princip fått upptäcka den själv.

En betalning kan innehålla strykning av flera avgifter, men det är nog mest rättvist som mått för tjänstens popularitet.

Sales _month

Ovanstående diagram visar antalet betalningar som vi haft sedan starten. Som synes är sommaren ingen höjdarmånad för att samla in förseningsavgifter, och platån mot slutet antyder att tjänsten har en ganska jämn tillströmning.

Sales _user

I bilden ovan kan man se att de flesta användarna är nya, men att det finns några som använt tjänsten ett antal gånger.

Sales _day

Ett viktigt argument för att få till lösningen var att vi ville låta använare som låsts ute från våra tjänster betala sina avgifter när som helst på dygnet för att på så vis få åtkomst till elektroniska resurser och annat de hindras från att använda. Som diagrammet visar sker den största andelen (i %) transaktioner under bibliotekets öppettider, men det finns också en stor andel som utnyttnjar tjänsten på andra delar av dygnet.

Jag ska försöka få redan på hur stor del webbetalningarna står för av den totala mängden avgiftsbetalningar.

/Bibliotekarien - The Librarian