Figure 3-8 shows a diagram of a typical e-business payment processing system. The three functional elements of the electronic storefront’s payment processing system are order confirmation, payment gateway interface, and transaction database interface, as illustrated in Figure 3-9.

Figure 3-8. Use of the Discover one-time credit card to pay for purchases

Figure 3-9. Payment System—technology perspective

Innovative Ways to Combat Credit Card Fraud

One of the most popular topics of e-business discussion is credit card fraud. Incidents of credit card fraud are reported in the news media almost every day. Many more incidents are swept under the rug and never reported. Today’s marketing jargon has established a myth that credit card security hinges entirely on SSL. In fact, SSL has very little to do with most cases of credit card fraud. However, an SSL session does prevent an eavesdropper from snooping on network traffic and recovering sensitive financial information being sent from the customer to the electronic storefront. To date, we haven’t heard of a single case of an attacker perpetuating a credit card fraud by cracking a “weak” 40-bit SSL encrypted session and stealing customer credentials from it. Rather, the number one cause of e-business credit card fraud is when an attacker breaks into an electronic storefront and steals the transaction database.

A few years ago, the Secure Electronic Transaction (SET) protocol was designed so that the merchant didn’t receive the actual credit card information. The system involved three parties to the transaction participating simultaneously—namely, the customer, the merchant, and the financial institution. When a customer decides to pay for a purchase, the SET system on the customer’s computer sends a message to the merchant providing the transaction details and a copy of the customer’s digital certificate. No credit card details are sent. The merchant then sends a request to the merchant’s financial institution, which in turn asks for authorization from the customer’s financial institution based on the certificate provided by the customer. Once everything has been approved, payment is completed. Thus the merchant never gets the actual credit card details, and theft of information from the merchant’s system can’t result in fraud. However, the SET protocol didn’t catch on. It was based on an idealized model, requiring heavy software and PKI support by all three participants.

An innovative way to achieve a similar result is used by some credit card companies. It calls for a “one-time-use credit card.” A “virtual” credit card is issued by the credit card company whenever a customer wants to make an online payment. The customer accesses the credit card company’s Web site and signs in. The customer then enters parameters such as the amount to be paid and validity of payment. In return, the credit card company generates a “virtual” credit card number, which is valid for one transaction only. This credit card number is internally linked to the customer’s actual credit card, and it is also stored by the credit card company during the period for which it is valid.

The customer then uses the virtual credit card number, instead of the actual credit card number. To the merchant, the virtual credit card is processed exactly the same as a normal credit card. The merchant’s financial institution sends a verification and settlement message to the customer’s credit card company. The credit card company determines whether the virtual credit card is valid and whether the amount of payment falls within the limits of the amount requested by the customer—and approved when the virtual credit card was issued. The rest of the payment process goes through normally.

Once used, the virtual credit card is automatically destroyed by the credit card company. The credit card number will never work again. In the event of a fraud where credit card information gets stolen from the merchant’s Web site, and an attacker reuses the virtual credit card, the fraud will be detected and, in addition to denial of the transaction, a fraud investigation can be initiated.

Discover Financial Services, the issuers of the Discover credit card, uses such a scheme, which it calls Single-Use Credit Card number. Discover also provides customers with software called Discover DeskShop, which can be integrated with browsers to facilitate quick issuing of single-use credit cards from Discover.com. More details on Discover’s single-use credit card approach can be found at http://www2.discovercard.com/shopcenter/deskshop/main.shtml. Figure 3-8 summarizes the use of one-time credit cards.

Order Confirmation Page
After deciding to purchase the items that were placed in the shopping cart, the customer is guided to an order confirmation page, which captures information such as credit card number, customer name, shipment address, billing address, and mode of shipment.

Payment Gateway Interface
Every electronic storefront has an interface to a payment gateway operated by a financial institution. The interface is provided by the financial institution as a software component. For example, Verisign’s PayFlow Pro payment gateway provides a variety of PFPro components, including a Java object, a Microsoft COM DLL, and a Unix shared module.

The payment gateway interface component is invoked by the electronic storefront application. This component transmits the payment information to the payment gateway system over an encrypted channel such as SSL. This component also returns a response code to the electronic storefront application, indicating the status of the transaction. The response code indicates whether the transaction succeeded or failed and gives various other details about the transaction. Based on the response code, the electronic storefront application decides what to do with the order.

Transaction Database Interface
Once a transaction is passed to the payment gateway, the transaction details, along with the response code, are written into a back-end transaction database for future use. The transaction database interface must be carefully designed so it does not allow attackers to retrieve or tamper with the transaction data.

Interfacing with a Payment Gateway—An Example

A popular payment gateway service called PayFlow Pro is provided by VeriSign. PayFlow Pro’s client-side component resides in the electronic storefront application. The client component interfaces with PayFlow Pro’s servers owned by VeriSign. The PayFlow Pro client communicates with the PayFlow Pro servers, using HTTP requests sent via SSL. The HTTP request contains various parameters for processing the transaction.

Figure 3-10. Sample HTML page that interfaces with PayFlow Pro

This example features a PayFlow Pro interface implemented with Java Servlets. On the client side, the PayFlow Pro Java object is wrapped into a Java Servlet. Figure 3-10 shows what the page looks like in the Web browser.

The following HTML code is from a sample HTML page that interfaces with the PayFlow Pro payment processing system and invokes the payment processing component:

<H1>Payment Gateway Interface</H1>

<p>

<form name=pfpro_form method=GET

 action="https://payment.example.com/servlet/PFServlet/">

<table border=0>

<tr><td>Cart code</td><td><input type=text name=SHOPCART size=6></td></tr>

<tr><td>Credit Card number</td><td><input type=text name=CARDNUM size=16></td>

</tr>

<tr><td>Expiration date<br>(month/year)</td>

 <td><input type=text name=EXPMONTH size=2>

 <input type=text name=EXPYEAR size=2></td></tr>

</table>

<p><input type=submit value="Process payment">

</form>

The HTML page contains a form that invokes https://payment.example.com/servlet/PFServlet/. PFServlet invokes the PFPro Java object, which interfaces with the PayFlow Pro payment gateway. The HTML form accepts the following parameters:

Each customer’s shopping cart has a unique code associated with it. The PFServlet uses that code to process all the items in the shopping cart. Ideally, the shopping cart code is passed automatically to the payment processing system by the shopping cart session management system. The following is the code for the Java PFServlet.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import com.Signio.PFProAPI;

public class PFServlet extends HttpServlet {

public void doGet (HttpServletRequest req, HttpServletResponse res) throws

ServletException, IOException

{

 PrintWrite            rout;

 PFProAPI pfObject = new PFProAPI();

 String ver = pfObject.PNVersion();

 // get HTML form parameters

 String EXPMONTH = req.getParameter("EXPMONTH");

 String EXPYEAR = req.getParameter("EXPYEAR");

 String CARDNUM = req.getParameter("CARDNUM");

 String SHOPCART = req.getParameter("SHOPCART");

 String EXPDATE = EXPMONTH + EXPYEAR;

 // calculate total amount from the shopping cart contents

 String AMOUNT = CalculateTotalAmount(SHOPCART);

 // Receive PayFlow Pro username and password credentials from

 // a stored repository

 String username = PFCredentials.getUserName();

 String password = PFCredentials.getPassword();

 // Server hosting PayFlowPro payment gateway

 String HostAddress   = "test.signio.com";

 String HostPort      = "443";

 // Construct the parameter string to be passed to PayFlow Pro

 String ParmList      =

 "TRXTYPE=S&TENDER=C&USER=" + username + "&PWD=" + password +

 "&ACCT=" + CARDNUM + "&EXPDATE=" + EXPDATE + "&AMT=" + AMOUNT +

 "&COMMENT1[10]=TestPay&INVNUM=1234567890&STREET=120+WIGGINS+ST

 &ZIP=47907";

 String Timeout       = "30";

 // Send request to process payment and receive a response

 int rc = pfObject.ProcessTransaction( HostAddress, HostPort,

 "", "", "", "", ParmList, Timeout);

 // Write the result

 res.setContentType("text/html");

 out = res.getWriter();

 // Customer response and receipt generation code goes here.

 // At the very end, the transaction is written out to the database.

}

The com.signio.PFProAPI package provides the PayFlow Pro Java object API calls. This package is imported and placed within the PFServlet code. Next pfObject is instantiated from the PFProAPI class. The pfObject is used to communicate with the PayFlow Pro servers.

Then the form parameters, described previously, passed to the PFServlet are processed. Once the parameters are received, the function CalculateTotalAmount() is used to process the contents of the customer’s shopping cart and generate the total purchase amount to be passed for payment processing.

The next part of the code deals with setting up connection parameters for the payment gateway. First, the payment gateway credentials issued by PayFlow Pro to the merchant are retrieved from an internal repository. These credentials also can be hard-coded but doing so isn’t good programming practice. Next the server’s IP address and port numbers are set up. Finally, the string ParmList, containing a list of parameters to be passed as an HTTP request to the PayFlow Pro server, is created. These parameters indicate the transaction type (in this case a “Sale” indicated by an “S”) and the payment method (a “C” for “Credit Card”). In addition, they provide the PayFlow Pro user name and password, the credit card number and expiration date, the amount to be debited, some comments regarding the transaction, the customer’s invoice number, and the customer’s address. Full details of these parameters are found in the PayFlow Pro’s developer guide document available from VeriSign.

The request for payment processing is then issued by the pfObject.ProcessTransaction() method. The variable “rc” stores the response code received from the PayFlow Pro’s payment gateway server. Typically, all the processing—from the request to the response—occurs within a few seconds.

The rest of the servlet code generates the appropriate results based on the response code. If the payment is accepted, the servlet generates an order confirmation and a receipt and initiates the order fulfillment process. If the payment is denied, the servlet generates an appropriate response to the customer. In the end, the transaction is recorded in the transactions database.

Payment System Implementation Issues

Implementing a payment system and integrating it with a payment gateway raises certain issues that must be addressed.

Integration
Integrating the payment processing system of the electronic storefront with the payment gateway interface object requires that no sensitive parameters be derived from data passed from the client side. For example, the total price of the items selected should always be calculated by looking up the shopping cart contents and price lists from tables on the server side and never depending on any client-side data.

Temporary Information
If any temporary information needs to be stored on the server side, it should be stored outside the Web document root directory in a separate temporary file area. This way, attackers can’t retrieve intermediate or temporary files by requesting them over a Web browser. All temporary information stored should be destroyed as soon as it is no longer needed. Care should be also taken to ensure that temporary information stored from two concurrent sessions do not overwrite one another.

SSL
Although SSL doesn’t imply server-side security, it is essential that SSL be used between the customer and the electronic storefront Web site and between the storefront application and the payment gateway so that eavesdroppers can’t lay their hands on sensitive data traveling across the Internet.

Storing User Profiles
Many electronic retail storefronts allow users to create a profile and store it on the businesses’ system. In many cases, the stored profile also contains payment information, including credit card information. In such cases, extreme care should be taken to ensure that stored user profiles not be compromised in any way.

Vulnerabilities Caused by Poor Integration of Shopping Cart and Payment Gateway
A vulnerability was reported on January 4, 2002, concerning the Miva Merchant shopping cart (versions 3.x) and VeriSign’s PayFlow link payment system. The vulnerability causes the shopping cart to accept invalid credit card transactions as valid. In essence, the bug isn’t in the payment processing system but in the way the shopping cart application is integrated with the payment gateway.

There are two ways to exploit the Miva Merchant shopping cart. The first method is to edit the HTML code by saving the HTML contents of the final checkout page so that, instead of the payment form invoking the PayFlow URL, it directly invokes the final payment acceptance URL within the shopping cart, thus entirely skipping the validation stage. The second way of exploiting the system is to sign up for a free test merchant account with VeriSign’s PayFlow system. The test merchant account will validate certain credit card numbers that have been designated as test numbers for developers who want to test their applications. Again, the way to exploit the shopping cart is to edit the HTML code on the checkout page, and instead of the HTML form invoking the PayFlow URL, the form invokes the test account validation URL. Then a fake “testing” credit card number can be used to validate the purchases. Full details of the exploitations are available at http://securitytracker.com/alerts/2002/Jan/1003102.html.

PayPal—Enabling Individuals to Accept Electronic Payments

Payment processing systems such as PayPal (http://www.paypal.com) have enabled individuals to accept electronic payments over the Web. This capability has led to a dramatic increase in individuals, including small-scale entrepreneurs, and small businesses doing business over the Internet.

PayPal’s transactions are performed via credit card. Every user is allowed to sign up for a PayPal account at no cost. The account binds users’ identities with their credit cards. Users simply use their e-mail addresses to refer to their PayPal accounts. Assume that a user named Mallory wants to make a payment to a user named Jill who has a PayPal account. Jill’s PayPal account is simply referred to by her e-mail address, jill@example.com. If Mallory wants to make a payment to Jill, Mallory first has to sign up for a PayPal account. To do so he creates a PayPal account and assigns his credit card to the account. To make the payment, Mallory signs onto PayPal and initiates a payment to the jill@example.com account. PayPal uses Mallory’s credit card to credit Jill’s account with the specified amount. An e-mail is automatically sent to Jill stating that she has received money from Mallory.

PayPal offers three types of accounts: personal, premium, and business with different features and facilities customized for individual users, individual users with high volumes of payment receipts, and small businesses, respectively. Facilities such as receiving direct credit card payments, using an ATM or a debit card connected to the PayPal account, handling mass payments, and the like are provided by PayPal.

Some fifteen million individuals and small businesses currently use PayPal, enabling them to carry on business online. PayPal is the number one method of accepting payments on auction sites such as eBay. PayPal also encourages the “shareware” software market. Shareware is based on the concept of “try before buy.” Software developers distribute their software at no cost and give customers an option to purchase copies if they like it and want to continue using it. PayPal allows individual software developers to accept payments via credit cards from such customers who use their software. Interestingly, PayPal is also used extensively by the Internet pornography industry, which has now enabled individuals to accept payments for pornographic content.

Summary

Shopping carts and payment gateways are the heart of any e-commerce application that serves customers over the Internet. These parts of the application exchange confidential and essential information between customers and businesses over the Internet. Hence it needs serious attention with respect to security. Each component should be tightly coupled with other parts of the application. Any loophole in implementation can cause serious information leakage from the server. The several products available should be thoroughly tested with regard to security before purchase, not after installation.