Håndtering af fejl i betalinger med DIBS-modulet

Mange Ding-biblioteker anvender DIBS-modulet for betalinger via hjemmesiden. Teknikken bag er et kompliceret samspil mellem Ding-hjemmesiden, bibliotekssystemet og DIBS. Afbrydelser af transaktionen, sløvt internet, en browsersession der udløber kan af og til bidrage til at en betaling ikke går helt igennem.

Flere tickets med dibs-problemer er lagt i lighthouse, hvor en ticket med en opsamling er lagt ind.

I Vejle har vi (som flere andre Ding-biblioteker) oplevet problemer med betalinger, som er gået igennem, men som ikke er blevet registreret som betalt i bibliotekssystemet. Nogle gange er der måneder imellem, andre gange er der fejl som perler på en snor i et par dage - men i det store og hele passer det nok meget godt når Steen Larsen siger at ca. 0.5% betalinger fejler.

Det er tilsyneladende umuligt helt at undgå fejlende betalinger, så det er nødvendigt at tjekke betalingerne efter. I Vejle indgår flg. i dagligdagen med Ding og DIBS:

1) Administrationen sammenholder bankudtoget med en udskrift over betalte regninger fra bibliotekssystemet. Langt de fleste gange matcher beløbende hinanden. Når de IKKE gør..

2) Forsøger administrationen af identificere låneren baseret på regningsbeløb + tidspunkt. Tit kan låneren findes, og regningen håndteres manuelt og sættes til betalt i bibliotekssystemet (da låneren typisk HAR betalt og beløbet ER trukket fra lånerens konto). Nogle gange kan låneren IKKE identificeres på denne måde, og..

3) .. administratoren af ding-hjemmesiden må træde til. Vi har et ordrenr., og denne kan slås op i databasen bag drupal i tabellen dibs_transactions. Rækkerne her indeholder bl.a. ordrenr., låners navn og adresse. Grunden til, at ordrenr. kan slås op er at transaktionen/betaling blev startet, men aldrig afsluttet ordentligt, og ding-hjemmesiden har derfor aldrig givet besked til bibliotekssystemet om at sætte regningen til "betalt".

Et databaseopslag der giver lånerens navn baseret på ordrenr. ser sådan ud (udført på databasen til et ding1/drupal6-site):

SELECT `payment_time` , `payment_order_id` , `payment_price` , `payment_transaction_id` , `customer_name` , `customer_address` , `customer_address_2` , `customer_city` , `customer_zipcode` , `customer_country` , `customer_email` , `customer_phone`
FROM `dibs_transactions`
WHERE payment_order_id
IN ( 23835 )

Har man ikke adgang til databasen, er ovenstående selvfølgelig problematisk. Det er oplagt at få lavet et modul, der kan lave opslaget og vise det/sende det pr. mail til administrator.

I Ding2 må det forventes, at problemet stadig er der - da de bagvedliggende problematikker mht. sløvt net, afbrudte browsersessions m.m. er de samme.