DRAFT
Project Name:
Centralized Credit Card Processing
Project Proposal Originator:
Chris Dempsey, Graduate Division
Project Implementers:
Business Services, Information Systems and Computing (IS&C)
Project Beneficiaries:
This project benefits all campus entities wishing to process credit cards in online web applications.
Problem Statement
Currently, a limited number of campus entities process credit cards through card-swiping terminals; a smaller number handle credit cards online through some sort of e-business web interface. Since a growing number of entities on campus plan to implement credit card processing in their web applications, it is imperative that the process of authorizing, billing, and reconciling of credit card transaction be centralized in a single office, with both the technical ability to establish and maintain a secure credit card processing gateway, and the accounting acumen to manage the increasing volume of transactions.
Additionally, distributed credit card processing implies distributed risk. By centralizing credit card processing, only a single office is required to handle sensitive financial information and is responsible for developing and implementing required controls.
Project Summary
A workgroup made up of Business Services and ISC, and current users of credit cards on campus, will be established to study and establish a plan of action.
There are generally two different methods for electronic processing credit cards: (1) the hosting entity develops the entire process in-house, including the establishment of the dynamic website, shopping cart, firewalls, and databases required; (2) the entity outsources the hosting of the credit card process to either a third-party e-commerce company or the credit card processing company itself. At UCSB, the Graduate Division maintains its own credit card processing in-house. Entities including Parking Services, Engineering, and others have chosen the outsourcing route.
There is a secondary concern regarding the inability to pass along credit card processing charges and fees to student consumers for specific items. It is the author's firm belief that this discussion must happen separately from implementing a transaction gateway, because there are large numbers of transactions that are not affected by these requirements, or where the merchant is able to absorb the processing fees.
UCSB Visionary Requirements
Buy-in from senior campus officers is required. This would represent a nontrivial workload increase for Business Services, though would eliminate a great deal of redundant work in every campus entity requiring credit card processing.
A required sunset period should be established after which decentralized credit card processing would become much more difficult to establish and maintain, encouraging entities to use the central processing gateway.
Costs and Benefits: Initial and Recurring
There is some initial cost required, including hardware, software, and programming time. At minimum, a reliable and secure credit card processing gateway requires load-balanced secure web servers interfacing with databases and credit card processing software. It is the experience of the author that these servers do not necessarily need to be particularly powerful, but must be highly reliable. Depending upon the existing resources available in Business Services, additional services required may include firewall, proxy, etc.
The University and local campus have already established a relationship with Cybersource, a credit card processor. Cybersource provides a number of methods for processing credit cards, including Java, COM, C, and web service interfaces. Programming to a particular interface would require minimum amounts of programming, perhaps 100 hours of programming time. Additionally, the credit card gateway could provide a web interface for department reporting, a HTTP POST interface, or a web service interface for credit card processing. These two programming tasks would perhaps require an additional 100 hours of programming time.
To estimate what type of resources may be required, below is a summary of the current implementation within Graduate Division:
- 1 shared webserver, minimal load from Cybersource Java object and ColdFusion MX 6.1/Windows 2003 environment. 2x1Ghz, 1GB RAM.
- 1 shared database server, minimal load from transaction logging and reporting, SQL 2000 / Windows 2003. 2x667Mhz, .5GB RAM.
- 2 redundant Layer 3 firewalls.
This level of hardware and software processes an average of 31 transactions/day, with a peak of 317 transactions/day. Obviously, many more transactions per day would be expected across the general campus, though this implementation has proven to be reliable and "cheap."
This proposal does not include any additional accounting or clerical resources required. This proposal also does not include any additional programming time required for internal Accounting/Business Services reports and use.
Matching Opportunities
There are matching opportunities in the New Business Architecture proposal, as well as current discussion and upcoming development in Student Affairs and ISC on other credit card processing sites.
Project Timeline
Because of the numbers of campus entities currently investigating the use of web-based processing of credit cards, the author recommends the establishment of the credit card processing workgroup immediately. Delay could mean a more difficult task to transition established online credit card processes back to the centralized gateway.
Project Priority
High. A number of organizations have established or are developing online credit card processing applications.
Back to Proposals Index