university of central florida’s epay system: online, not in line cumrec 2004 may 16th – 19th...
TRANSCRIPT
University of Central Florida’s ePay System: Online, Not In Line
CUMREC 2004 May 16th – 19th Aaron Streimish
Special Projects Coordinator Computer Services & Telecommunications
University of Central Florida - Orlando, Florida
ePay Project Manager and Functional Administrator
Copyright the University of Central Florida and Aaron Streimish 2004. This work is the intellectual property of the author. Permission is granted for this materialto be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given
that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
Introduction
• About UCF• ePay History 101• A Little About ePay 1.0, 2.0 and 3.0• System Architecture• Backend Processing• Putting It All Together• So What Does It Look Like?
About UCF
• One of 11 state public universities
• Located about 10 miles east of downtown Orlando
• 43,000+ students
• 1,400 acre main campus and 21 regional campuses
ePay History 101
• ePay 1.0 launched as a pilot during Fall 2001
• ePay 2.0 with PeopleSoft integration launched in spring 2002
• ePay with eCheck 3.0 launched in Fall 2003
• Currently working on seamless portal/PS integration for next version
A Little About ePay 1.0
• Pilot project in Fall 2001 (for Spring term)
• Written in JAVA (JSP) with Oracle DB
• Ran from October 2001 to February 2002
• Processed over 6,000 transactions and $4.5 million
• We learned a lot…
A Little About ePay 2.0
• Launched March 2002 (still running)
• Written in JAVA (JSP) with Oracle DB
• Tighter PeopleSoft integration
• Processed over 77,000 transactions and $55 million (and still counting)
• Becomes the official online transaction engine for the entire campus
A Little About ePay 3.0
• Launched December 2003
• Written in JAVA (JSP) with Oracle DB
• Added eCheck (ACH)
• Has processed over 15,000 transactions and $13 million
• New interface (multiple screens), re-branded and even *more* reliable
System Architecture
• Designed as a “black-box” service
• Two Sun machines - One public, one private
B AEnd User VeriSign
DB
B AEnd User
DB ACH
Backend Processing
• All transaction data is collected in Oracle DB.
• Transactions are moved to the PS Financials system once a day
• Tuition payments are applied based on student ID and or Web site ID.
• Project and Department codes determine where the money goes
Backend Processing
• HEPROD - A job (CFSFEPAY) is run in HEPROD each night to extract ePay transactions. This job runs an SQR (Structured Query Report) program by the same name that uses the EPAY_TRANS_LOG, EPAY_PMTITEM_SUM, and the EPAY_PRODUCT tables to find the transactions. Transactions for each department with ePay data are identified by the WEBSITE_ID value (for example, ‘00020001’ is used for Graduate Studies and ‘00040001’ is used for Continuing Education).
• Another table, CF_WEBPAY_FIN_SEQNO, is used to keep track of the last sequence number processed for each type of payment to prevent double processing of transactions.
Backend Processing
• The CSFEPAY program writes out one file for each department (currently eight). After the SQR runs, an FTP control record (CFWEBPAYFIN) is used to then copy these files to the FTP (File Transfer Protocol) server. This server is used to transfer data between the 7.6 environment and the 8.4 Financials environment.
• FIPROD - The eight files placed on the FTP server are copied to a Novell shared drive, using WS-FTP. Then a separate program is run for each department (FXGLEPGS for Graduate Studies, FXGLEPCE for Continuing Education, etc.). These programs generate external journals that can then be imported, examined, and posted by Finance & Accounting personnel on a daily basis.
Backend Processing
Sample PeopleSoft Screen
Backend Processing
Sample PeopleSoft ePay Screen
Putting It All Together
• Information is sent to ePay via HTML Passing Parameters – up to 99 items per transaction.
• The service is “dumb” and does no calculations.
• Transaction data is the responsibility of each department using the system.
Putting It All Together
Sample Passing Parameters
So What Does It Look Like?
• ePay 1.0 and 2.0 used a very simple interface that allowed custom header and footer for departmental branding.
• ePay 3.0 is self-branded and allows only minor departmental branding.
• The interface was broken down to multiple screens instead of one very very long screen.
So What Does It Look Like?
ePay 2.0
So What Does It Look Like?
ePay 3.0 Payment Method Screen
So What Does It Look Like?
ePay 3.0 Fees Due Screen
So What Does It Look Like?
ePay 3.0 Credit Card and eCheck Screens
ePay 3.0 Confirmation Screens
So What Does It Look Like?
So What Does It Look Like?
ePay 3.0 Processing Screen
So What Does It Look Like?
ePay 3.0 Receipt Screen
So What Does It Look Like?
• Live Demo of ePay
• Live Demo of ePay with Campus Card (Web Revalue)
Thank You
Aaron StreimishSpecial Projects CoordinatorUniversity of Central Florida4000 Central Florida Blvd.Orlando, FL 32816-2500
www.ucf.edu [email protected]