Friday, November 13, 2009

Overview of the Payment Processing System





Overview of the
Payment Processing System



lang=EN-GB style='color:#003399'>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
lang=EN-GB style='color:#003399'>Figure 3-9.



lang=EN-GB style='font-size:10.5pt;font-family:Arial'>Figure 3-8. Use of the
Discover one-time credit card to pay for purchases




style='font-size:10.5pt;font-family:Arial'>Figure 3-9. Payment
System�technology perspective




style='width:90.0%'>




lang=EN-GB style='font-size:16.5pt;font-family:Arial'>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 lang=EN-GB>. style='color:#003399'>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.



 





No comments: