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

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

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

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

6. 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…

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

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

9. System Architecture Designed as a “black-box” service Two Sun machines - One public, one private BAEnd UserVeriSign DB BAEnd User DB ACH

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

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

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

13. Backend Processing Sample PeopleSoft Screen

14. Backend Processing Sample PeopleSoft ePay Screen

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

16. Putting It All Together Sample Passing Parameters

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

18. So What Does It Look Like? ePay 2.0

19. So What Does It Look Like? ePay 3.0 Payment Method Screen

20. So What Does It Look Like? ePay 3.0 Fees Due Screen

21. So What Does It Look Like? ePay 3.0 Credit Card and eCheck Screens

22. ePay 3.0 Confirmation Screens So What Does It Look Like?

23. ePay 3.0 Processing Screen

24. So What Does It Look Like? ePay 3.0 Receipt Screen

25. So What Does It Look Like? Live Demo of ePay Live Demo of ePay with Campus Card (Web Revalue)

26. Thank You Aaron Streimish Special Projects Coordinator University of Central Florida 4000 Central Florida Blvd. Orlando, FL 32816-2500 www.ucf.edu aarons@mail.ucf.edu