Overview of the Payment Processing System

Overview of the Payment Processing System

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.