Models of Fine / Fee Payment in Alma

Owned by Lauren Magnuson (Unlicensed)
Last updated: Jul 08, 2017 by Ian Chan (Unlicensed)
3 min read

Bursar integration

Library "washes its hands" - money is owed to the university, not to the library. Fine/fees are closed in Alma.

  • Developer Network Documentation 
  • Knowledge Center Documentation  
  • Pros:  Easiest possible solution, good solution if library doesn't want to handle payments / track fine and fees, but wants users to pay their fines and fees through the bursar office
  • Cons:  Will require coordination with your campus bursar's office to arrange for the ingestion of the export file via FTP and ensure the format can be parsed by PeopleSoft (the Fines/Fees Task Force can help with this).  Disputes and waiving would have to be coordinated with the bursar's office, payment for anyone not in PeopleSoft (e.g., community borrowers, if those borrowers are not entered in PeopleSoft), will need to be coordinated with your Bursar's Office.

Cashnet eMarkets / Checkout Gateway 

  • $3500/yr (unless unlimited eMarket license - no cost if your campus has unlimited licenses.  See this document for a list.)
  • Pros:  Somewhat easy to set up, minimal custom programming required (unless you want to automate email notifications > fine and fee payment API in Alma), enables payment by community users
  • Cons:  When you go into the CashNet portal, the amount user needs to pay is not specified. Shows as $0 balance due.  User must manually enter the amount they wish to pay.  When payment received, email is sent to circ inbox, and someone has to apply the payment to Alma and release payment in PeopleSoft.  Could potentially automate with script (needs development) to pull data out of email and send data to Alma Fines/Fees API.  Script could likely be ready by go-live.  Blocks / holds in PeopleSoft would have to be removed manually.  Possible cost to the library (up to $3500 / year)
  • Campus could purchase / take advantage of eMarket for year 1, while custom interface (see below) is developed
  • Note:  we are still seeking out more information to the following questions:  
    • More information needed: Accounting / reconciliation fines/fees and payment trails
      • When Sacramento used eCommerce model, daily totals sent to campus financials - entered into CashNet / automatically pushed into PeopleSoft in nightly job (at Sacramento for parking, no longer need receipts as they are sent to PeopleSoft automatically) -
      • Lauren Magnuson (Unlicensed) to ask CashNet rep how this works / gets reconciled w/campus financial systems;
      • Lauren Magnuson (Unlicensed) to ask about consortial deal on cheaper eMarket licenses
    • More information needed: Fines to go general fund, replacement costs are kept by the library - Can CashNet understand which fines go to which fund?
      • With parking T2 - there's an identifier for the type of transaction
      • bill by type of charge - fine/fee vs. replacement
      • Lauren Magnuson (Unlicensed) ask CashNet: Alma differentiates between transaction type (fine vs. replacement) - would CashNet be able to communicate the charge type that was paid back to Alma?
      • Lauren Magnuson (Unlicensed) reach out to Delfin at Stanislaus - student financial services
  • San Marcos 
    1. Form posts user ID and amount to Cashnet Checkout Gateway. 
    2. Cashnet sends HTTPS notification to script on library's server. 
    3. Script posts payment amount to Alma.

Library-specific custom payment portal

    • This would be a custom interface developed by a working group across the CSU.  It would not be ready by go live, but would enable automation of fine/fee payment through the alma API, while Cashnet securely handles credit card transactions.  Users would see a fine/fee payment link in Primo, would login, and upon login, fine/fees would be pulled immediately from Alma, so amount owed would always be up-to-date.  Then they would be directed to a CashNet payment form.  Upon payment, data could be sent to Alma fine/fee payment API.  It is likely that removal of blocks / holds would still be manually removed, at least in early iterations of the app.
    • Pros:  Totally customizable with regard to notifications, enables fine/fee payment from community users, automatically updates fine/fees paid via Alma API
    • Cons:  Would not be complete by go-live.  Estimated timeline looks to Fall 2017 for completion.  Could use any of the other integrations in the meantime (we recommend either Bursar integration or eMarket, see above)

PayPal Integration - San Jose Model

PeopleSoft Integration - Long Beach Model 

Requirements

  • Built with C#, uses IIS, and a MS SQL Server database.  
  • Campus’ PeopleSoft must be configured to allow for credit and debit imports.

Processes

  1. Export of files from Alma (using the Analytics API) and transformation of that data into 2 files (debits and credits) for PeopleSoft consumption.  
  2. Accept the credits from PeopleSoft and use the Alma User API to credit the patrons’ accounts.

Status

  • Not yet in production
  • Worked needed to ensure each Alma fine and fee is in sync with PS.  

More Information

  • Please contact Nadia Vargo <Nadia.Vargo@csulb.edu> for more information.