Tutorials » An e-Tailer's Guide to Credit Card Processing
If you are an e-tailer and wish to begin accepting credit card payments over the internet, but are not sure where to begin, this tutorial is for you. We provide an overview of the steps involved in processing an online transaction, an introduction on how to establish a merchant account, how credit card transactions are processed, and how to ensure that your online transactions are secure. We also discuss how you can begin accepting credit card payments directly from your web site without incurring exorbitant processing fees, by using dgCharge: an ActiveX component developed specifically for developers to process credit card transactions easily over the internet.
From start to finish, there are five participants involved in an online transaction: the merchant, merchant bank, consumer, cardholder issuing bank and acquiring processor. The merchant, using a merchant account provided by his merchant bank, sells goods or services through an e-commerce website. The consumer purchases those goods or services using a credit card provided by a cardholder issuing bank. As soon as the consumer enters his credit card information into an e-commerce website, the data is encrypted and transmitted to the acquiring processor. Next, the acquiring processor contacts the cardholder's issuing bank, who either approves or declines the transaction depending on the amount of credit available for the cardholder. If the transaction is approved, the transaction amount is reserved on the cardholder's account, but is not yet deducted. In addition, the approval is transmitted to the merchant's website and to the cardholder. When the merchant delivers the merchandise purchased, the approved transaction amount is gathered in a batch to be settled. At the time of settlement, the merchant transmits the batch of approved transactions to the acquiring processor, who collects the transaction amount from the cardholder's issuing bank and deposits it into the merchant's bank account.
Before you can begin accepting credit cards, you must first establish a merchant account with a credit card transaction processor. The role of the processor is to determine whether or not credit card requests can be satisfied with the credit card issuer, and to oversee the transfer of funds from customer to merchant. Every credit card transaction request initiated by you (the merchant) incurs a small fee from the credit card transaction processor. This is unavoidable, as the transaction processor is a necessary intermediate step. The transaction processor used by dgCharge is NOVA, and if you wish to utilize dgCharge to handle your online credit card processing, you must first set up a merchant account with NOVA.
One of the decisions you will have to make when establishing your merchant account is how you wish to settle your transactions. When a credit card transaction is performed (e.g. a "sale" transaction), funds are not actually exchanged between customer and merchant until the transaction is "settled." As a merchant, you have two choices in how the settlement is to be performed.
The first settlement option is that of "automatic" settlement. As its name implies, under this option all credit card transactions are settled automatically, without any further action on your part. Transactions are settled once per day, at approximately 2:00 A.M. Eastern Standard Time. All pending transactions for the day are settled at the same time. At any time, you may query the results of the most recent settlement, to be sure that all transactions you expect to be settled are indeed settled. Automatic settlement is the easiest method, in that you can be sure your transactions will be settled every day without further intervention on your part. This method does, however, incur slightly higher fees from the transaction processor.
The second settlement option is that of "manual" settlement. In this situation, no automatic settlements are ever performed; instead you must actively settle transactions. This can be done at any time you choose. When you perform a settlement, you can settle all outstanding transactions, or you can settle only selected transactions. Thus manual settlement gives you more control over the settlement process. If, for example, you have processed a sales transaction for an item, but that item is not yet ready to be shipped, you would wait to settle that transaction until the time when the goods are shipped.
Once you have your merchant account, and have decided how you will handle the settlement process, the next step is to decide how to get the transaction information to the transaction processor. We are probably all familiar with the options of dial-up connections and leased lines. However, as e-tailers our interest is primarily in processing transactions over the internet. Many merchants interested in the internet option process their transactions through third-party vendors. This provides the speed and security desired, but at high monthly rates. Other merchants purchase software similar to dgCharge to host the credit card processing locally and avoid high monthly bills. While many of these products indeed do the job, many are also expensive and difficult to use. dgCharge was developed as an affordable alternative that allows you to process credit card transactions by the use of simple, logical object methods (e.g. "Sale") that accept simple, logical arguments (e.g. "amount", "card_nbr", "exp_date", etc.). Please refer to the dgCharge product page for more information.
There are five basic types of credit card transactions: Sale, Credit, Void, Preauth, and Force. We are all probably familiar with Sale and Credit transactions. Void transactions are probably also well understood. As a merchant, you must be aware of the fact that a void transaction can only be done on transactions of type Sale, Credit, and Force. Furthermore, a transaction cannot be voided after it has been settled.
Preauth and Force transactions are probably less well understood. A Preauth is similar to a Sale, except that it only places the funds on reserve in the customer's credit card account. To actually transfer the funds, a Preauth must be followed up with a Force transaction. Funds set aside with a Preauth are only held in reserve for seven business days, after which the Preauth approval code is no longer valid. Merchants may choose to issue a Preauth if they wish to secure funds for sale of an item that is not ready to be shipped. Once the merchandise is ready to be shipped, the charge can be finalized by processing a Force transaction (or a Sale transaction if the Preauth has expired). You should be aware that Preauth/Force transactions incur higher fees from the transaction processor than Sale transactions. Therefore, if you are a merchant who needs this type of capability, you may wish to consider establishing your settlement type as manual. Then, instead of performing Preauths followed by Forces when goods are ready to be shipped, you can simply perform a Sale that is not settled until goods are ready to be shipped.
As a merchant who wishes to enable online credit card transactions, there are a number of security issues of which you should be aware. Security concerns exist both for you and for your customer. There are two mechanisms currently in place in credit card technology that assist you, the merchant, in minimizing credit card fraud. Both of these are of particular benefit when processing credit card transactions "anonymously" as they are done online. These two mechanisms are nicknamed "AVS" and "CVV," and both will be subsequently discussed in more detail. dgCharge provides you with the capability of using both of these security measures, if you choose. For your own protection as a merchant, you are strongly encouraged to require both from your customers.
AVS stands for Address Verification Service. This is a means by which you can determine if the address the customer provides agrees with the address associated with the credit card account. This provides you with some measure of confidence that the person using the credit card is the person who owns it. AVS information is not required for credit card transactions. However, if it is provided, the transaction processor issues back a response indicating how much of the address matches. There are levels of matching: it may be the case that the street address is correct, but the postal code is wrong, etc. It is important to note that a credit card transaction will not usually be denied if the address is wrong. It is up to you to decide what to do if the address does not match, or matches only partially, etc. One course of action would be to void the transaction and deny the sale, but this is entirely at your discretion.
CVV stands for Card Verification Value (sometimes called CVV-2). This is a 3-4 digit code that is found on Visa, MasterCard, and American Express cards. It appears on the card but nowhere else, not even on credit card statements. Its primary purpose is to validate that the user of the credit card actually has the card in hand. On Visa and Mastercard, CVV data consists of the 3-4 digits found after the card number on the signature strip on the back of the card. On American Express, CVV data consists of 3-4 digits on the front of the card, to the upper left of the card number. CVV data provides you, the merchant, a high degree of confidence that the customer actually possesses the credit card that is being used. This prevents fraud that can occur when someone tries to use a credit card number and expiration date found on a discarded receipt, for example. CVV data is not required for most credit card transactions, but some credit card issuers now deny transaction requests that do not supply this information. If the information is provided and is not correct, most credit card issuers will decline the transaction. However, some issuers will approve the transaction, but return a response that indicates the data was wrong. In these situations, it is up to you to decide how to handle it.
Besides protecting yourself from credit card fraud, it is of paramount importance that you guarantee your customers that their credit card information is protected as well. There are at least four different times when customer credit card information is being transferred and must be protected (there may be more depending upon how your business operates):
- When the customer sends his/her credit card information to you. When processing credit card transactions online, this step takes place over the internet, and guaranteeing security at this time is entirely your responsibility as an internet merchant. You must have a secure server, with a valid security certificate, and you must be sure to use the "https" protocol whenever your customers are sending private information.
- When the credit card information is sent to the transaction processor. You do not have direct control over security at this step, but you will need to be sure that the credit card transaction processing software you use is secure. If you choose dgCharge, you can be sure that all credit card information is securely encrypted as it is passed back and forth from your server to the credit card transaction processor.
- When credit card information is being moved into and out of a database. Again, the security measures in place at this step will depend upon the software you are using to handle your transactions and maintain the database. dgCharge encrypts all sensitive credit card information that is stored in the database. Whatever credit card transaction processing software you decide to use, never store unencrypted credit card information in a database.
- When credit card information is being viewed and handled by your staff. Ensuring security at this step is your responsibility. dgCharge includes reporting capability that will be of great use to your accounting personnel. Since these reports include credit card information, you will need to be sure to restrict access to the site that hosts dgCharge, and to run it on your secure server.
