1 / 11

Integration Between Aleph and External Payment Systems at Developer Meeting Jerusalem, November 2010

Discussing the successful integration of Aleph with external payment systems at a developer meeting in Jerusalem in November 2010, highlighting challenges, usage statistics, interfaces, and more.

farhani
Download Presentation

Integration Between Aleph and External Payment Systems at Developer Meeting Jerusalem, November 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Developer Meets Developer Meeting Jerusalem, November 2010 Jiří Rataj University of Economics, Prague www.vse.cz Integration between Aleph and external payment systems

  2. 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

  3. 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)

  4. 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

  5. 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

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

  7. 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-*

  8. 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)

  9. 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

  10. Questions? • Jiří Rataj • rataj@cuni.cz

More Related