Integration between Aleph and external payment systems

Developer Meets Developer MeetingJerusalem, November 2010

Jiří RatajUniversity of Economics, Praguewww.vse.cz

University of Economics

Aleph from 2003 130.000 titles, 240.000 items, 3 branches, ~50

staff 13.000 active patrons, >60.000 payment

transactions/year

MULTIDATA Praha – Ex Libris systems support & distributor in Czech Republic and Slovakia, ~20 Aleph customers

Payment systems interfaces

National Technical Library, Prague (STK) Czech University of Life Sciences, Prague

(CZU) University of Economics (UEP, not yet in

production) University of South Bohemia in České

Budějovice (JCU, not yet in production)

STK

GUI has PS as default payment mode Fully automatic payments

Existing z31: sql update, PS “pay” request ↔ response → sql commit (paid) / rollback

Computed fines (not in z31): X Server bor-info, PS “block” request (all fines plus debit balance), PS response not relevant for Aleph (not paid, decreased disposable PS credit)

XML request / response over https, proprietary protocol

CZU

Default GUI payment mode is Cash “External System” payment mode

SmartCard Terminal connected to network (or to staff PC)

GUI ↔ Aleph server (external program) ↔ SmartCard Terminal, patron intervention (PIN enter)

SOAP proprietary protocol

Challenges

Not well documented – all three versions of “Aleph and e-Payments*.pdf” on docportal have the same misleading tab_external_program description

Challenges

External program input Aleph passes too few possible arguments to

an external program, necessary usage of sql for obtaining more data (like card number from z308)

Program parameters are “id”, “sum”, “credit”, “action” and “client-ip-addres”, not z31-*

Challenges

External program output Reply value of “00\n...\n” shall be required

for “payment accepted” result but is not – Aleph accepts empty response (i.e. after external program error or timeout)

External program reply message (transaction no.) goes to Z31_PAYMENT_IDENTIFIER

Only 20 characters accepted for VARCHAR(30)

Can be overriden by GUI “Payment identifier” (30 possible characters from GUI)

USAGE STATISTICS

STK: 99.6% payments through PS, 97% in fully automatic mode without staff or patron intervention

CZU: 1-6% payments through PS, 0% without staff and patron intervention

Questions?

Jiří Rataj

rataj@cuni.cz