Collecting Payment Information | MySQL and Perl for the Web

only for RuBoard - do not distribute or recompile

For the doc_shop.pl application, we pretty quickly skipped over the part that showed what to do with credit card information that we obtain from customers. Let s return to the topic of payment and discuss the issue in more detail.

When you sell something, you want to be paid for it, so it s necessary to arrange for collection of information that allows you to assess the proper charges to the customer. Most people who shop online prefer to pay by credit card rather than by some other method, so that s the most common means by which business is transacted over the Internet. It s also the method this section concentrates on, though we ll also survey other payment methods briefly.

Credit Card Processing

If you want to accept credit cards, you need a merchant account with a financial institution such as your bank. This account allows you to engage in credit card transactions, but does not in itself necessarily have anything to do with online ordering. To conduct credit card transactions electronically over the Internet, you ll also need an account with an authorization service. (If you re a large company, you might be able to deal directly with your bank for this, but more typically you ll use a service that handles transactions on behalf of many banks.)

A merchant account isn t free; the cost typically is tied to the volume of business you conduct. As a merchant, you receive only part of the purchase price if the customer pays by credit card, because the bank through which you have your merchant account extracts a percentage of each sale. The merchant account may also involve other costs, such as signup fees or annual fees. Given this obvious disadvantage in terms of revenue loss, do you gain anything by contracting for services that allow you to accept credit card payments? Perhaps. Given that more online consumers prefer to pay by credit card than by any other method, you re likely to lose sales if you don t provide this capability.

The conditions you ll have to meet to obtain a merchant account are something you should discuss with your bank. You ll also need to contact an authorization service that will help you implement online credit transactions; the authorization procedure for this will be specific to the vendor, so make sure the interface software will work with your system. (It s no good for the service vendor to provide software for Windows NT if you re using a UNIX server, or vice versa.)

How Credit Card Transactions Work

When a credit card purchase takes place, it involves the following parties:

The customer making the purchase
The merchant selling the merchandise
The customer s card issuer
The merchant s bank
The bank network

Processing the transaction can involve many steps, several of which take place behind the scenes and require exchanges of information over the bank network to assess the customer s creditworthiness and to obtain permission to make a charge against the customer s account. For our purposes, the process can be boiled down to these essential elements:

The customer gives us a credit card number to pay for an order.
We send to the authorization service a credit authorization request that contains the card number and any other information the service requires.
The authorization service processes the request and sends back either a rejection or an authorization ID for the transaction.

If the request results in a rejection, you inform the customer that the purchase cannot be completed ( sorry, please contact your card issuer ). Otherwise, the authorization ID gives you permission to charge the customer s account. However, actually debiting the account (the capture stage) is in many cases deferred a bit. If you charge immediately for an item that is backordered or that cannot be sent right away, customers tend not to like it. Therefore, it s common to defer capture until you re ready to ship the order.

In practice, authorization request rejections are rare, due to the amount of time that would be necessary to perform more thorough checks on the customer s credit status at the time of the transaction. Apparently the business policy is that more money stands to be lost by making customers wait than by incurring a somewhat higher risk of credit card fraud. Still, authorization failure does occur even for people with good credit, as I ve had occasion to discover. I once went through a period during which I purchased a significant amount of electronic equipment. After several days worth of making multiple purchases, I discovered that my card no longer worked. Attempts to use it to make purchases failed because authorization requests were denied at the store I was visiting. It turned out that the credit card company had noticed the unusual number of electronics purchases. Stolen cards are often used to buy items in that category, and because the pattern of charges arriving for my account didn t fit my usual buying habits, the card company turned my card off until I called to inquire what was happening.Was the card company protecting me as a consumer? I doubt it. Consumers aren t liable for purchases made on stolen cards. The company was attempting to cut its own fraud-related losses through analysis of purchase patterns and identification of unusual events that are likely to be illegitimate. Of course, if you re a merchant, this benefits you by reducing the incidence of fraudulent purchases by customers for which you might otherwise be liable.

Collecting Credit Card Information

When you present a form containing fields for gathering credit card information, you ll typically collect at least the following values:

The name on the card
The card type (Visa, MasterCard, American Express, and so forth)
The card number
The card expiration month and year

Some cards also have a card security code (or card verification number). Visa and MasterCard use a three-digit value on the back of the card; American Express cards have a four-digit number on the front. It s a little more inconvenient for the customer to provide this code in addition to the regular part of the credit card number, but it has the potential to reduce card fraud to some extent, so it s information that you might want to collect. Your authorization service will use the security code if you submit one.

Address verification service (AVS) may be another option available to you. This involves checking whether a street address provided by the customer matches the address listed on file for the account by the card issuer. If your authorization service offers AVS, you may want to ask the customer for an address, even if you don t need it to deliver your product. (For example, we needed no such address for doc_shop.pl to perform order delivery because documents were provided electronically.)

The card type and expiration date can be presented with structured elements, such as pop-up menus, so that the user need not enter any keystrokes. (For example, the expiration date can be represented using one pop-up containing the values 1 to 12 for the month, and another containing year values for the next 10 years or so.) On the other hand, the card number has to be entered manually, which can be a source of error. To lessen this possibility, you can perform a preliminary test that validates the number and helps catch customer typos immediately. This helps you minimize the number of requests to your authorization service (and thus, perhaps the fees you pay).

The validation test is based on the fact that credit card numbers are constructed such that the final digit serves as a check digit that is, a checksum calculated from the card number should yield a result equal to the final digit. This was instituted as a guard against errors made by keystroke operators submitting card numbers into data entry programs, but the same test helps catch mistakes made by customers ordering online. The check digit serves the same purpose as the checksum technique we used in Chapter 9 to encode session and record identifiers: It allows changes to the original data value to be detected. The changes can be inadvertent (as with a keystroke error entering a credit card number) or deliberate (as with a user attempting to hack a form); either way, the checksum or check digit help ensure data integrity.

There s nothing secret about the credit card number check digit algorithm; it s a published standard (ISO 2894). The algorithm is not very complicated and it s relatively easy to write an implementation.^[6] But it s even easier to use a module that can perform the test for you, such as Business::CreditCard. This module has a validate() function that takes a credit card argument and returns true or false to indicate whether the number passes the check digit test:

^[6] For a description of the algorithm, one source is Garfinkel and Spafford (see Appendix B, References and Further Reading ).

 use Business::CreditCard;  if (validate ($card_number))  {     print "It's good\n";  }  else  {     print "It's bad\n";  }

The check digit test is useful for weeding out obvious bad numbers or numbers that customers have entered incorrectly, but it doesn t tell you whether there actually is any card with a particular number. You still must submit the number to an authorization service to find out whether the number is creditworthy. In other words, the preliminary check is useful for reducing the number of requests that you issue to your authorization service, but cannot replace the service. If someone is intent on defrauding you, they ll most certainly know how to generate a card number that passes the check digit test. If you deliver orders based on that number without checking it with the authorization service first, who ll be left holding the bag for the cost? You.

Obtaining Credit Card Authorizations

Authorization requests for credit card transactions can be issued a couple of ways:

With remote mode authorization, you present a link to the authorization service from your ordering page. The customer follows this link, provides credit card information to the service to obtain an authorization ID, and then returns to your site and submits the order along with the ID.
With local mode authorization, the customer presents the card information directly to you, and you contact the authorization service to obtain the authorization ID on the customer s behalf.

The first may be somewhat simpler for you to implement, but the second is more convenient for the customer. In any case, the specific details of the authorization procedure depend on your particular service. Recall that doc_shop.pl used a generic stub routine to generate authorization IDs.You d need to replace it with one that follows your vendor s conventions. Depending on the authorization service you have, you might be able to use one of the Perl modules that facilitate authorization requests, such as the following:

 Apache::iNcom  Apache::iNcom::CartManager  Business::OnlinePayment  Business::OnlinePayment::AuthorizeNet  Business::OnlinePayment::CardStream

In other cases, the vendor may provide a suitable module that you can integrate into your applications.

Protecting Credit Card Information

When you need to perform a transaction that requires a credit card number, observe the following security precautions to protect customer information:

When you reach the point in the ordering process where you need to request sensitive customer information, switch to a secure connection with the client s browser so that the information is not transmitted in the clear.
When you receive the credit card number, don t store it in the database. Connect to your authorization server (over a secure channel, of course) and give them the number. If the transaction is approved, the service will store the card number for you; let them worry about keeping it secure. Refer to the order from that point on using the authorization ID that the service gives you. If you store the credit card number in a database and your site gets hacked, you could compromise your customer data. Store the authorization ID instead and use it for any further dealings involving the order.

Is it Dangerous To Send Credit Card Numbers Over an Insecure Connection?

Credit card information normally is collected over a secure connection, but not always. Just how dangerous is it to send credit card numbers in the clear over the Internet? That s difficult to tell exactly, but it s certainly more likely that a bad guy will try to hack a site that stores thousands of card numbers than to attempt to steal individual numbers with a network sniffer. For this reason, the risks of credit card theft during order submission may be overstated, compared to the risks involved with using your card other ways. Is it really more secure to use your card over the telephone or in person? If you call in an order over a cordless phone, it s possible that your call may be picked up by an outside party. And what s to stop a clerk in a store from using the information on the store copy of your credit slip? Nevertheless, despite these risks (which may mean that sending a card number over the Internet is actually less risky than other means of conducting credit card transactions), many consumers are reluctant to provide a card number online, especially if it s not evident that you re using a secure connection. So take the trouble to set up a secure channel. Then, to address the concerns of customers who are still hesitant, you can provide alternative means of payment. These are surveyed in the next section, Other Payment Options.

Other Payment Options

Credit card payment is convenient for e-commerce because it can be done completely online, and authorization (or rejection) can be obtained immediately. However, other methods can be used, particularly for situations where deferred payment is acceptable. Some of these may help you obtain orders from people who are uneasy about submitting their credit card number over the Internet:

The order page displayed by your application is a convenient means of presenting all the item information together in one place. You can take advantage of this even for customers who don t want to submit the order online. Allow the customer to print the order page and fax it in, to mail it by post, or even to call in the order over the telephone and read off the contents of the order page to your customer service representative. Enabling your site for these options need not involve much more than putting a notice somewhere on the ordering pages pointing out that such options are available and acceptable.
You can allow the customer to submit the order online but pay offline later. To do this, accept the order and provide to the customer in response a confirmation page that displays the order number and the telephone number of your customer service department. The customer calls up later, gives the order number as a reference, and provides payment information over the phone. (This option can be carried out by fax or mail, as well.) Consider putting an expiration period on outstanding orders if you separate order submission and collection of billing information this way. It s not unknown for customers to change their mind about an order or even to forget that they purchased anything!
You can arrange to send the customer an invoice. This is appropriate mainly for business customers with whom you have long-term relationships. Generally, you ll require a customer account number, a purchase order number, and contact information so that you can verify the order before processing it. You might also want to use a login stage so that customers must authenticate to gain access to your ordering system.
If you don t want orders to go directly into your database without being examined first, you can transmit them to your order processing department using email messages. Obviously, with this method, it s best to encrypt the contents of the message.

only for RuBoard - do not distribute or recompile