The web designer/developer acquires an added responsibility when entering e-commerce, a responsibility to the credit system that makes e-commerce possible. That responsibility is not an elective, any more than safe practices are an elective to a carpenter, plumber, or electrician. As your client's e-commerce provider you acquire the same basic liabilities as any expert craftsman. Whether you think you are an "expert" or not is immaterial; the client, the banks, and the cardholders assume that you are.
Credit card processing from website sales involves 2 distinct subjects: the merchant account and the processing mode.
Merchant Account:
Merchant Accounts (MA) are not an account that you open at the bank. They are granted by a bank and usually involve at least two other entities, an ISO (Independent Service Organization) and the underwriter. An ISO is usually someone from the local debt collection service who certifies the risk involved in granting the MA. They look at the operation itself and the history and assets of the applicant. Frequently the ISO also is the MA administrator, the one who pulls the plug and liquidates the merchant's assets should things go wrong. The underwriter is usually a bank you will not deal with directly. Their responsibility is with the cardholders. They review the website, the operation, and the ISO's report. The underwriter is the entity which actually grants the account. Underwriters frequently request non-negotiable cosmetic and even structural changes to websites to protect the cardholder's interest.
MAs are specific not only to the merchant but to the activity where they are used. Conducting credit card sales in a manner not specified in the MA is illegal and constitutes willful fraud. All revenues from such sales are also illegal and will be refunded to the cardholders, regardless of the cardholder's satisfaction with the sale. As the merchant's expert in e-commerce the web designer/developer can be held liable for those losses to the merchant. Include a clause in your contract that states that the client has the responsibility to approve and accept a website that is not in violation of their MA, and that the MA is in compliance with all State and Federal banking regulations. Such a statement should protect you from civil liability.
There are two basic types of Merchant Accounts, the OTC (over-the-counter) and the MO/TO (money-order/telephone-order). The OTC is used in the brick-n-mortar world, it is illegal to use an OTC for web transactions. A MO/TO account typically has two stages, the amount of the sale is first "authorized" meaning that the amount is removed from the card's open-to-buy limit and put on 30 day hold for the account. The second stage is where you "capture" the amount by actually charging the card. It is illegal to "capture" the transaction until after the product has been physically shipped.
It is not uncommon for storefront merchants to assume that they can get away with processing web sales through "manual entry" on their storefront swipe machine or software without changing their OTC MA. This is not true. The credit card processors have sophisticated filtering software that can easily red flag such a sale when there are no corresponding card charges for fuel, lodging, or airfare that would have transported the cardholder across country to make the purchase at the merchant's store.
Processing Mode:
The credit card processor "call centers" are not online. There is no way that you can connect with the call centers through TCP/IP, the connection must be through regular telephone lines. This situation will probably not change. Netscape's LivePayment, VISA/IBMs S.E.T. protocols, and attempts by Microsoft have all failed to bring TCP/IP connections to the call centers. The problem is in encryption and authentication between the site's web server and the call center's servers.
Offline Authorization:
Most e-commerce sites use offline authorization. In this scenario the details of the orders are recorded on the web server, downloaded as a batch, authorized through offline software as a batch, and then later captured through the offline software in batches. There are many softwares available for this, just search google.com for "credit card processing software". ICVerify and MacAuthorize/PCAuthorize are the standards but are not easily obtained without also purchasing a merchant account from the software vendor. Some banks and online ISOs will attempt to require ICVerify as a condition of their MA since ICVerify has been a standard for many years. Have them call Microsoft's lawyers for an explanation of "tying" and why their attempt is a violation of anti-trust law.
Offline authorization can be a source of added value for the cgi capable web designer. The scenario can include many steps: Securely recording the orders. Downloading a file containing only the authorization information in a format ready for import into the offline software. Uploading an export from the offline software of authorized orders. Generating from the server shipping packing lists in the browser for authorized orders. Presenting a browser checkoff of shipped orders that simultaneously emails the customer that shipping has occurred and downloads a second file for import into the offline software for the capture batch. The checkoff of shipped orders is especially usefull if remote fulfilment is involved. Good shopping cart software already includes most of these backend features.
One of the problems with offline processing is that credit card numbers are stored on the web server. Data can be stored outside the domain path, in files without world readable permissions, in htaccess protected directories, etc. However, data cannot be stored safely against a hack that would open the entire machine to the attacker. If orders are frequently downloaded you can remove the credit card numbers at that time, storing them instead in the offline software. This minimizes the potential for loss. Many sites eliminate the problem by stripping the last 6 characters from the stored number and emailing those characters and the order number to the merchant who must then match the numbers up when they download the orders.
Live-time Authorization:
Live-time authorization should be used for instantly deliverable sales, such as software downloads or access to restricted areas on the website. Live-time authorization for hard goods sales is an expensive option that eliminates the need for offline processing software and accomplishes the authorization stage automatically. Live-time processing does not eliminate the need for a second capture phase after shipment.
Live-time processing on your server will require a way to suspend the submission process, dial out to the call center on a separate modem, match the authorization back up with the submission process, record the order (minus the credit card numbers) and return the results to the browser. RedHat7 has this capability built-in (CCV) and some softwares are available for Win servers (PCAuthorize Hub).
Most live-time processing goes through a third party. Bank of America and many other banks offer this service. Authorize.net also offers this service and franchises the process to online ISOs in one of the web's most successful multi-level marketing schemes. There are also dozens of independent parties that offer this service. Some of these third parties also offer full shopping carts services tied into the process. Basically the scenario is: the checkout phase connects to the third party's secure server presenting a page requesting the credit card information, the third party server authorizes the order, the third party server redirects back to a file or cgi on the merchant's web server. Some of the third parties require that the redirect goes to a perl script or java servlet that they provide and you install on your server to guarantee the authenticity of the success (CyberCash is an example). Most third party processors store the credit card numbers on their servers and offer full backend services for the capture phase of the transaction. If they do not offer a capture phase, or do not offer a capture phase that lets you select which orders to include in the capture batch (which orders were shipped) then run, they do not know what they are doing.
Factoring:
Until recently the credit card industry had a very strict prohibition against one merchant using another merchant's MA. That's called "factoring" and is criminally illegal in 16 States. The last two years there have been a few exceptions allowed where the MA holder is considered the "merchant of record" and the website is considered a merchandising/fulfillment partner. Just because you can run across these companies don't get the idea this is common practice, it's not, these require accounts issued for that purpose only.
PayPal:
PayPal.com has broken all of the credit card Merchant Account rules by treating payments as funds transfers between individuals instead of between merchants and consumers. You can configure your shopping cart to end with a page from PayPal's secure server where the consumer enters their credit card info. Upon success the PayPal server redirects to your server's success cgi where you record the order. The upside of this process for the consumer is that this is as secure as an ATM card purchase since the web merchant does not get to see the credit card number. But, like an ATM card purchase, this is a cash transaction and the consumer has no recourse against a faulty merchant. PayPal does offer to pay chargebacks to consumers but only on "verified merchants". A "verified merchant" is one who has opened their bank account to PayPal so PayPal can retrieve all funds in the account should they receive any consumer complaints. There has been a lot of flack recently on the web about PayPal abusing their access to bank accounts. However, PayPal's record has actually been better than many online ISOs who have the same power to confiscate funds.
If you are in doubt about the legality/ethicality of your e-commerce setup do two things. Look at it from the cardholder's interest and then talk to your bank. Their interests come before your client's because they will outlast your client.
