Washington State University’s Credit Card Payment Service

John Chapman
Washington State University
Pullman, Washington

• Introduction
• Credit Card Terms
• Overview of the Credit Card Process
• Components of the Credit Card Payment Service
• Security Issues
• Current Applications
• Adding New Applications
• Project Cost
• Conclusion
• Appendix 1 Credit Card System Diagram
• Appendix 2 Receipt from Credit Card Application

Many students find it convenient to pay for University goods and services with a credit card. When credit card payments can be made from the Web, a valuable service for the customer is provided and a significant savings of staff time for the University is realized. Thanks to high quality vendor software, implementing an enterprise credit card payment service is less expensive and difficult than you might think.

WSU’s credit card payment service was developed using software purchased from PaylinX, a St. Louis, Missouri vendor of electronic commerce software. The primary

components of the PaylinX software are the PaylinX Server and the PaylinX Client API, or simply, the PaylinX Client. The PaylinX Client resides on the Web server and is called by the Web application for credit card authorizations. The PaylinX Server accepts requests from the PaylinX Client and sends it via a POS (Point-Of-Sale) device to the Financial Network and ultimately to the consumer’s bank for approval or denial.

Before examining WSU’s credit card payment service in more detail, it is helpful to review some terminology and the steps involved in all credit card purchases.

Acquiring Bank – A bank that has a business relationship with a merchant and receives any credit card transactions from that merchant. The acquiring bank acts as a broker between the merchant’s bank and the issuing bank.

Authorization – Approval of a credit card transaction for a merchant by the card-issuing bank.

Authorization Code – A code assigned by the card-issuing bank to a credit card sale to show that the transaction is authorized.

Issuing Bank – The bank which issued the credit card to the consumer.

Merchant Bank – The bank that authorizes a business to accept credit cards.

Sales Draft – A document showing an obligation on the cardholder’s part to pay money, to the card issuer. This is the piece of paper that you sign when making a purchase with your credit card. Sales draft data can be ‘captured’ electronically and sent over the financial networks to be processed.

The credit card process involves three parties: the consumer or credit card holder, the merchant who is offering products or services for sale, and the financial institution that processes credit card payments, known as the Acquirer. Indirectly, there are two other parties involved, the bank that has issued the consumer's bankcard and the merchant bank where the merchant's account resides. The best way to get a full understanding is to walk through the process of a credit card authorization step by step. After doing this it will be shown how each step is implemented from a Web application using the PaylinX software.

Step 1. Consumer browses merchant’s store and decides to make a purchase.

Step 2. Merchant totals purchase amount and seeks payment from consumer.

Step 3. Consumer presents merchant with a credit card.

Step 4. Merchant transmits the credit card data and sales amount with a request for authorization of the sale to their acquiring bank through a POS (Point of sale) device.

Step 5. The acquiring bank that processes the transaction routes the authorization request to the card-issuing bank. The credit card number identifies type of card, issuing bank, and the cardholder's account.

Step 6. If the cardholder has enough credit in their account to cover the sale, the issuing bank authorizes the transaction and generates an authorization code. This code is sent back to the acquiring bank.

Step 7. The acquiring bank processes the transaction, and then sends the approval or denial code to the merchant's point of sale unit.

Step 8. A sales draft, or slip, is printed by the point of sale unit or cash register. The merchant asks the buyer to sign the sales draft, which obligates the buyer to pay for the amount of the sale.

Step 9. At a later time, usually that night when the store is closing, the merchant reviews all the authorizations stored in the point of sale unit and transmits the authorizations to the acquiring bank for deposit. We will call this process ‘batch settlement’. This is done in lieu of depositing the actual signed paper drafts with the bank.

Step 10. The acquiring bank performs what is called an interchange for each sales draft, with the appropriate card-issuing bank. The card-issuing bank transfers the amount of the sales draft, minus an interchange fee to the acquiring bank.

Step 11. The acquiring bank then deposits the amount of all the sales drafts submitted by the merchant, less a discount fee, into the merchant's bank account.

Let’s go through the steps again and see how each step is implemented when the purchase is done from a Web application using the PaylinX software. It may be helpful to refer to the Credit Card System Diagram (Appendix 1).

Step 1. Consumer browses merchant’s store and decides to make a purchase.

A Web application is developed that presents the goods and services available to the consumer. The Web application can be written in a variety of languages. The only requirement is that it be able to access the PaylinX Client. At WSU, students can pay tuition through a Web application that was written in C and runs under Digital Unix. Other credit card applications are being written using Active Server Pages on Windows NT platforms. If the goods and services being offered are large in number and varied, packaged software may be acquired to help develop the Web application.

Step 2. Merchant totals purchase amount and seeks payment from consumer.

After the consumer decides on the items they would like to purchase, the Web application presents them with a form that includes input fields for the credit card number and expiration date.

Step 3. Consumer presents merchant with a credit card.

The consumer inputs their credit card number and expiration date into the form and clicks on a ‘submit’ button. The ‘action’ on the submit button connects to the Web server using the HTTPS (HyperText Transport Protocol Secure) protocol so that the credit card number is encrypted between the consumer’s browser and the Web server.

Step 4. Merchant processes credit card through POS (Point of sale) device.

When the Web application receives the credit card number and expiration date, it formats and sends a transaction through the PaylinX Client that resides on the Web server. This connects to the PaylinX Server and issues a credit card authorization request. The PaylinX Server formats the request and sends it to a POS device that is attached to the PaylinX Server by a serial connection. The POS device, which contains an internal modem, dials the number to the Visa Processing Network and issues an authorization request to the acquiring bank.

Steps 5 and 6 occur as above.

Step 7. The acquiring bank processes the transaction and then sends the approval or denial status to the merchant's point of sale unit.

When the PaylinX Server receives the results of the credit card authorization request from the POS device, it writes a record in its database to record the transaction. The record contains the credit card number, expiration date, amount, date and time stamps, approval or denial status, authorization code and various other information. It then sends the results to the Web application.

Step 8. A sales draft, or slip, is printed by the point of sale unit or cash register. The merchant asks the buyer to sign the sales draft, which obligates the buyer to pay for the amount of the sale.

The Web application receives the results of the credit card authorization request and sends the results back to the consumer. If the request for authorization was approved, the application should provide the consumer with a ‘receipt’ that includes the date, time, description of the goods or services purchased, the amount charged and the authorization code (Appendix 2). The application is also responsible for informing the consumer if the credit card authorization was denied. The Web application also writes a transaction that documents the goods or services to be delivered to the consumer.

Step 9. At a later time, usually that night when the store is closing, the merchant reviews all the authorizations stored in the point of sale unit and transmits the authorizations to the acquiring bank for deposit. We will call this process ‘batch settlement’. This is done in lieu of depositing the actual signed paper drafts with the bank.

At the end of the day, the PaylinX server reads all of the approved credit card authorizations in its database, and sends them via the POS device to the acquiring bank for settlement and deposit into the merchant’s account.

Steps 10 and 11 occur as above.

The reader should now have a basic understanding of the credit card payment service. Let’s now look in more detail at the function and requirements of each component.

The credit card transaction is initiated by a consumer who browses the merchant’s Web site. Because we want to make goods and services available to as many consumers as possible, the requirements for the consumer workstation are few. The consumer only needs connectivity to the Web site and a browser that supports SSL (Secure Sockets Layer) encryption.

The Web server hosts the Web application, the Web server software and the PaylinX Client. The Web server must support SSL to allow for the encryption of the credit card number. Additionally, the Web server must run on one of the PaylinX Client supported platforms. This currently includes Windows NT and 95 and most common flavors of Unix. At WSU, Web applications that use the credit card server run on a Digital Unix computer with the Apache Stronghold Web server and also on Windows NT with the Internet Information Server.

The credit card server hosts the PaylinX Server and the ODBC-compliant database that is required by the PaylinX Server. For security and performance reasons it is recommended that these are the only applications on the credit card server. The credit card server is Windows NT based, as that is the only platform supported by the PaylinX Server.

The PaylinX Server runs as an NT service on the credit card server. Its responsibility is to accept requests from PaylinX Clients, format, and send those requests to the POS device. It also returns the results of the request to the PaylinX Client and logs the transaction to its database. According to the vendor’s documentation, a PaylinX server can process over 10,000 transactions per hour while maintaining typical transaction speeds of 3 to 7 seconds. The PaylinX Server performs another very important task. It performs the batch settlement with the bank. Batch settlement is usually done once per day. It is the transmission of the day’s credit card authorizations to the acquiring bank for deposit to the merchant’s account.

The POS device transmits credit card authorizations and settlements to the Visa Processing Network. The POS device is attached to the credit card server by a serial connection and to the Visa Processing Network by its internal modem and a standard business phone line. The POS device is supplied by VisaNet, but must be ordered by your merchant bank on your behalf. It is leased for a flat fee that is currently $35.00 per month.

The PaylinX Server logs all credit card authorization requests to a database using ODBC calls. At a specified time at the end of the day, the PaylinX Server reads all of the days approved transactions and transmits them to the acquiring bank for settlement and deposit into the merchant bank account. WSU, uses Microsoft SQL Server version 6.5.

The PaylinX Administrator software is a management tool used to monitor, configure, and control the PaylinX Server. It runs under Windows NT/ 95 and is connected to the PaylinX server through the network. It allows the credit card administrator to remotely start and stop the PaylinX Server, set user and database passwords, set logging parameters, check on the server status and other functions as well.

WSU has firewall software installed on the credit card server. Its purpose is to deny connections that do not originate from a WSU credit card application or the PaylinX Administrator. For security reasons, details of the firewall software will not be presented in this paper.

Credit card charges represent revenue that must be posted to the University accounting system. A number of departments across campus manually accept credit cards, in person or over the phone, for payment of various goods and services. The department will periodically total the sales and produce an accounting journal voucher to be posted to our batch oriented legacy accounting system.

An advantage of our Web-based credit card payment service is the automated posting of credit card charges to our legacy accounting system which eliminates the existing manual, paper-based process. Automating the transmittal of credit card transactions to our accounting system is very simple. Since all transactions are recorded in the PaylinX Server database, it is only necessary to read all of the day’s credit card charges and create an accounting transaction for each approved charge, which is then sent to the accounting system. This program also e-mails a summary report of the day’s activity to the WSU Revenue manager. This report can then be compared to the bank deposits for reconciliation purposes.

Consumers, application developers, and business managers all have security concerns about Web-based credit card applications. Although no application will ever be completely secure, a number of measures can be taken to provide a high level of security.

An SSL connection should be established from the Web server to the customer’s browser so that the credit card number is not viewable as it travels across the Internet. An SSL connection ensures that all information exchanged between the Web server and the browser is encrypted.

The credit card server that contains the PaylinX Server should reside behind a firewall. The firewall should be configured so that only the Web server applications and the PaylinX Administrator have access to the credit card server. This will insure that credit card transactions are only issued from authorized Web applications.

At WSU, we keep the credit card server in a locked cabinet in our dispatch area that is staffed twenty-four hours per day, 365 days per year. Only the credit card administrator and backup personnel have keys to the cabinet that houses the credit card server. Also, restrict the usage of the credit card server. Don’t run other applications on it.

Make sure that your Web server is configured for maximum security. Disable services that can be hacked into if they are not needed such as: FTP daemons, public logons, NFS (Network File System), Server Side includes, telnet and Sendmail.

Don’t store important information in HTML hidden fields. Hidden fields are useful for maintaining state information in your application, but they can also be changed by users. By storing the purchase amount field on an HTML page, a malicious user can change the amount they are to pay for an item.

Since WSU implemented the credit card service last spring, three applications have been developed and are in production. Three other applications are currently in development.

This application allows students to make payments on amounts they owe the University. Payments can be made to their general student account, housing and dining, WSU child care, Cougar telephone, or student loan. Parents can also make payments on behalf of their student. After making a payment, the student’s account is updated in the evening and they can see the credit the next day.

This application allows prospective graduate students, including those from overseas, to simultaneously complete an application form and pay their application fee. This is especially valuable for international students who often fall victim to deadlines. A series of deadlines must be satisfied for an international student to be eligible to study here. Sometimes an international applicant is eligible for admission but, because of the time required to receive the application and fee through the mail, the application can’t be processed in time to get a visa to enter the country.

WSU’s Undergraduate Admission Application has just recently been completed and made available on the Web. The primary benefit is that students can complete the application and pay the $35.00 fee, all at once, electronically. This speeds up the application process and saves staff members from having to process the application fee.

The credit card payment service was paid for by the WSU central administration. It was expected that it would be a University resource used to collect payments for central (e.g. collection of tuition, student loans, admission application fees) and departmental (e.g. publications, parking permits, Cougar Cheese) goods and services. Since the credit card payment service was implemented last spring, three departments are developing Web-based applications that will use it. We expect the number of Web-based credit card payment applications to steadily increase and have made the requirements for using it as simple as possible to facilitate its usage. The requirements for a WSU department to use the credit card payment service are listed below.

The department is responsible for developing the Web application. They are required to follow appropriate business practices, such as ensuring that the customer is provided a receipt with a description of the goods or services purchased, the amount that was charged and the authorization code. The department is also responsible for doing any refunds should the goods not be available and need to be backordered. The department is provided with training and support on the usage of the PaylinX Client, including understanding the appropriate credit card transaction types, the calling sequences, and error handling.

Departments wishing to develop credit card payment applications may do so on a centrally maintained secure Web server. However, many departments maintain their own Web site on Web servers that they have purchased and maintain. If the department wants to use their own Web server, it is required that their Web server support the SSL protocol. Also, the Web server must run on a platform that is supported by the PaylinX Client. This currently includes Windows NT and 95, and most flavors of Unix.

The department is also responsible for working with the Revenue manager to determine how credit card charges will be reflected in the University’s central accounting system. Typically, all of the revenue for a department’s credit card sales will go into a single account credited to the department. It’s the department’s responsibility to keep track of amounts collected for third parties (e.g., sales tax) or as required for the department’s internal business purposes.

The project cost was a little under $50,000 which includes two copies of all components. The second copy of each component was acquired for development and testing purposes. The additional copy also provides us with redundancy which can be used in the event of a hardware failure. Of the $50,000, software costs account for about $17,000 and hardware about $30,000. Most of the software costs were for the purchase of the two copies of the PaylinX software, but the figure also includes costs for the purchase of MS SQL Server and a firewall product. Most of the hardware cost were for the purchase of two credit card servers ($13,000 each). Other hardware costs included a server cabinet and modems. Included in the $50,000 are miscellaneous costs, such as the installation of phone lines and network connections.

Annual recurring costs are less than $6000. Most of this is for the PaylinX software maintenance, but also included are phone line and POS device charges.

It took approximately three person-months to implement the credit card payment service. This included the time required to acquire and install the credit card servers and related components as well as developing, Student Payments, the first application to use the service.

Many University customers enjoy the option of being able to pay for goods and services with a credit card. In fact, credit card payments of goods and services at WSU has been steadily increasing. Manually accepting credit card payments is a time consuming task for University staff. Our Point of Sale manager estimates that it takes a clerk about five minutes to process a credit card sale. It is often inconvenient for the customer as well. It requires them to sometimes walk to a building on campus or phone during business hours. The phone call sometimes results in a busy signal or being placed on hold.

WSU’s credit card payment service benefits both University customers and staff. Customers benefit from the convenience of being able to purchase University goods and services twenty-four hours a day, 365 days per year. Staff benefit by not having to take credit card orders manually. Staff also benefit from the automated feed into the central accounting system which eliminates the manual totaling and reporting of credit card sales.

It is easy for University departments to incorporate the credit card payment service into Web applications. The PaylinX Client runs on many platforms and SSL support is the only other requirement for the Web server. This allows most departments to write applications on existing platforms in their language of choice.

We expect six applications to be completed in the credit card payment service’s first year. Additional applications are expected in subsequent years. New applications are being encouraged. Each new application results in increased service to our customers and saves staff time. Also, because there is no incremental cost, each new application increases the return on WSU’s investment. For a relatively low cost and a modest time investment, you can bring the benefits of a credit card payment service to your institution.

Appendix 1

Appendix 2