Accepting Credit Card Numbers on Your Website
A common problem facing website designers is how to accept and manage credit card information from their website. As e-commerce sites proliferate and traditional bricks-and-mortor companies take up shop on the Internet, this issue is becoming critical for more and more developers.
This document discusses issues faced by developers or website owners who are considering accepting credit cards on their site.
- Introduction
- Setting up a Merchant Account
- Designing Your Application
- Developing Your Application
- Implementing Your Application
- Conclusions
Introduction
Third Party Payment Gateway .
A third party payment processing solution will take the burden off you to do any of the card processing yourself. Most gateways are set up so that your site contains all shopping and ordering screens, but at payment time, the processing gateway does all the work, including the SSL encrytion, card validation, cash collection and subsequent funds transfer to your bank account.
For most developers, the basic technical aspects of accepting credit card information are not difficult to overcome. Many programmers now have experience designing and coding web applications that use forms and back end database technology and virtually all professional programmers are at least aware of the basic principles behind data gathering, validation, processing and storage. These tasks are normally not very difficult and usually require medium to advanced skills in order to produce a good quality web application.
The real challenge to accepting credit cards from a website are to find a credit vendor with whom you can set up an account and also to implement methods that meet or exceed the security requirements of the credit vendor. Typically this involves setting up a credit merchant account with a bank or other financial institute. Once your account is set up, you then need to implement a secure, reliable application on your website.
Before reading any further, you should be aware that instead of collecting the credit card information directly at your site you may be able to use a
For many sites, using a third party gateway is the best solution when all costs are considered. If you have not looked into this option and budget or time constraints are a consideration, it may be a good idea to see what is available. The remainder of this document is dedicated to issues faced when implementing credit card processing on your website and within your business.
Setting Up a Merchant Account
Developing Your Application
Developing your application includes the coding and testing activities necessary to create software. A high quality application is well designed, well coded and rigorously tested. Good software comes from good programmers, and to create applications that work well, you will need medium to high programming skills.
Generally, you will want to develop your application off-line and only publish it once its working. To do this you usually to be concerned with:
- Development Software
- Application Source Code
- Web Server
- Database Server
- Development Workstation
- Networking Infrastructure
Development Software
The development software you choose should match the environment on the server hosting the live site. You should try to keep things as generic as possible and try to avoid non-standard hardware or webserver requirements.
Web Server
Your web server should be set up similar to the server that will host your live site. Any server components or other specific conditions found in production should be approximated as closely as possible.
A common problem is encountering permission errors when software code is moved from your local development environment to the live production website. Windows2000 and IIS use a variety of permission settings to provide security. You may need to become familiar with the specific settings on the production webserver in order to create similar conditions for proper testing.
Application Source Code
The application source code should be maintained on a development server, and not on the production webserver. The production server should only run a copy of tested and debugged code.
The source code itself should be kept in a secure place and should be backed up regularily. You may also wish to use some type of code management software such as Microsoft's Visual SourceSave, or the public domain RSC package. Formal source management particularily helpful if you have a team development environment.
You should avoid hard-coded directory or URL references. If you have hard references to directory or to specific URL's, you may run into problems when you migrate code to a production server.
The application should be able to run under SSL. If you are using COM components, you should verify all components support the HTTPS protocol. Many components support HTTP only and cannot be used in a secure environment.
Database Server
Your database server should be set up similar to the server that will host your live site. Any server components or other specific conditions found in production should be approximated as closely as possible.
If you are using one of our database servers for production, you should set up your local database as follows:
- One database user account that owns and manages the data.
- The owner account is a separate login from "sa" or "system".
- The owner account should be assigned "dbo" privileges to the database.
You may also have additional database accounts for other operations such as searching or other read-only applications.
Development Workstation
Your development workstation should contain all necessary components to build your application with.
Networking Infrastructure
Ideally, you will have a number of machines to develop your application with. To develop in a networked environment, obviously you need equipment such as network hub or switch, cabling, NIC's and you may also need advanced equipment such as routers and gateways if your developers are geographically distributed.
A full infrastructure normally contains one or more of the following:
- Web servers
- Database servers
- Workstations
- Firewall
- DNS servers
- Mail servers
Depending on the complexity of your application (and the size of your budget) you may need all or some of these machines. For a small, simple system often a single workstation with web server software loaded will do. For a large team project, the actual requirements can often exceed the list above.
Implementing Your Application
In order to handle credit card transactions, your application usually requires a number of configuration settings and other changes to the servers in order to meet your vendors security specifications.
Generally, you need to:
- Secure the network
- Secure the website
- Secure the database
- Secure any off-site data transmissions
- Install and test your application
As you can see, most of the implementation involves securing the physical infrastructure that is handling your credit card transactions. Only when the site is secure should you begin working with your application in a live environment.
Secure the Network
A common requirement from the credit vendor is that the webserver and any database servers are protected behind a firewall. Some credit vendors may have requirements regarding port usage and other issues regarding network security.
On the Alentus network, all web and database servers on our network are behind firewalls. The firewalls are used to monitor, filter and prevent unauthorized traffic on our network. Note that we do not guarantee that auauthorized traffic will never get past our firewalls, however we do take active measures to prevent it from occuring.
Secure the Website
Your website is secured by using the SSL protocol along with a certificate that ensures the identity of the server. The certificate may be your own, or may be shared among a number of users. Usually you will require at minimum a 40 bit certificate to meet your credit vendors requirement. Some vendors require 128 bit, so you should check. A 40 bit certificate may be insufficient for some vendors.
If you are hosting on one of our shared servers, note that there are other sites using the same physical computer for their websites as well. These other customers have accounts on the system and there is always a possibility the someone could circumvent the security measures and gain access to your site by the virtue of being hosted on the same server. For this reason, many credit vendors will not certify sites running on a shared webserver. In this case, you will require a dedicated web server to meet your vendor's requirements.
Secure the database
Securing the database involves setting up your schema so that only the users who need access to the data can get it. In a complex system, this can involve roles, database triggers and other mechanisms to ensure that only valid user account can read the credit card information. At minimum, you should have a secure password on any user accounts that can access the data.
Some vendors require that the card data is encrypted within the database. Doing this may require installation of security components such as certificates or COM encryption components. Another approach is to fully encrypt the database. For example, it is possible to encrypt an Access .MDB file and also set a database password. Your scripts can use the password to access the file via ODBC or a DSN-less connection. Note that this method is only as secure as your source code and .MDB file. If someone can download your scripts and your .MDB, they can access the data. You should test your site for any such security holes before implementing your production code.
If you are hosting your database on one of our shared database servers, note that there are other customer databases on the same physical database server. These other customers have database accounts on the system and there is always a possibility the someone could circumvent the security measures and gain access to your data. For this reason, many credit vendors will not certify sites storing data on a shared database server. In this case, you may require a dedicated database server to meet your vendor's requirements.
Secure any off-site data transmissions
If you need to send credit card data off-site for processing, you will require a secure mechanism to perform the transmission. Doing this may involve a number of different steps such as encrypting the data, using special processes to transmit and receive data and restricting transmissions to specific servers.
If you are using email to send orders from your site to an email account outside the network hosting the web and database servers, you must encrypt the message before sending it. This will protect the message during both the sending and retrieval phases of an email transaction. If the message stays inside the network, some credit vendors may still require that you encrypt the data.
Typically, you can use commercial COM components, PGP or custom code to encrypt any messages. Before deciding on a specific method, you should check that both the credit card vendor approves and that your live production environment can support it.
Some vendors use other means such as dial-up lines or alternate data networks to accept data from their merchants. If this is the case, you may need to install modems, phone lines or special data circuits to communicate to the credit vendor. In a shared hosting environment, this sort of requirement is usually not supported.
Install and test your application
You should take the time to test all functions of your your application. Any bugs or security holes can cause significant problems, particularily if they expose card numbers to the public. Also, consumer confidence can be quite shaken if your application generates an error during a credit card transaction.
Conclusions
Accepting credit card data on your website can be a considerable undertaking and will take significant resources to implement properly. If you have a small site with low traffic, or you do not expect significant transaction volumes in the near future, you should seriously consider a payment gateway instead.
If you are prepared to invest the necessary resources to accept credit card information online, you will have the advantage of a complete in-house solution. Often it becomes possible to fully integrate your credit card system into your other business data which can greatly help your sales and marketing functions. Given enough volume, you may be also able to achieve significant reductions in your per-transaction cost as compared to using a third party gateway.
The companies who implement the card handling themselves usually fall into one of these categories:
- High volume retailers with significant available resources
- Specialized sites where gateways cannot provide needed functionality
- Internet-only businesss whose sole revenue is based on credit card billing
The companies who fall into these categories usually have either the money or the expertise (or both) to implement an in-house credit card handling system. At Alentus Corporation, we ourselves do much of what is discussed above for our own billing system. In our case, we have the in-house programming, database, networking and administrative expertise to do this and as an on-line hosting provider we believe that it is a basic requirement for our business. There are many companies where the in-house approach does not make sense, once the all of the actual costs are considered. You should look at all the aspects involved before making the decision for your business.
Disclaimer: In no way does Alentus Corporation guarantee that credit card information, or any other information or data that is stored, processed or otherwise handled by our servers is 100% secure. We take many precautions to provide security for usage by our customers and by public users of our equipment, but we do not accept any responsibility for any loss of data, loss of business, any other damages or claims of losses due to use or misuse of servers, our network or other resources provided by Alentus Corporation. Specifically, we disclaim any guarantee of security or usability with regards to email, web site content, database content, network traffic or any other resources provided by Alentus Corporation or that our network is attached to, or can otherwise interact with regardless of whether it is owned by Alentus Corporation or not. Persons who accept, process or otherwise handle credit card information or other sensitive or private information using our servers do so at their own risk. Those persons also assume any and all liability that may result from such actions. For more information, please see our
Terms and Conditions.
Setting up a merchant account can be time-consuming and will usually not provide you with all the tools you require to begin taking credit card information over the Internet. However, it is the first step towards that goal, and since it is an absolute requirement that you have a Merchant Account, you should probably start work towards this as soon as possible.
Typically, you will need to apply for credit status with your local bank or other financial institute. There are also a number of companies that specialize in Internet-based store-front credit accounts as well as various trust companies, co-operatives and other groups that can offer merchant credit. Like any business decision, its probably a good idea to investigate a number of alternatives before selecting a particular credit vendor.
Before you apply to any particular vendor, you may wish to obtain their specific technical requirements for handling transactions on the Internet. The regulations vary and you should ensure that you will be able to meet a vendor's regulations before applying for an account.
If you are unsure if you can meet a particular requirement, you can contact our Customer Service people, however please be very specific when you ask about any requirements. There are a number of issues that wholly depend on how you implement your application and we can only respond to questions that relate directly to our servers and hosting plans.
Designing Your Application
Designing your application includes making the decisions as to exactly how your site will work with regards to handling card information. Usually most of the basic site design is completed by the time you get to the details regarding the credit processing part. Often the site is already running and the credit card handling section is being added later. The sections below look at the specific design issues involved in the credit card processing section.
The credit card processing function can range from fairly simple to very complex, depending on the requirements of your organisation. However, there are many common elements that will affect nearly all sites doing credit card processing. These elements are:
- Pre-Transaction Processing
- Collect Card Information
- Validate Card Information
- Save the transaction
- Generate a receipt
- Process the transaction for payment
Pre-Transaction Processing
This is where the ordering information is usually gathered. Often it is a shopping cart system, or it may be custom system that gathers orders for a service or specialized type of product.
Often the shopping cart portion is unsecured, however once an order is ready for completion, there is a need for secure communications to gether the customer specific information. This usually includes data fields including such as name, phone numbers and shipping information. Most customer prefer to have this information kept private and it should be done in a secure environment.
Collect Card Information
Collecting card information must be done securely. Usually, you will need to gather:
- Card Type
- Name on Card
- Card Number
- Expiry Date
Some credit vendors may also require other data found on the card or information that is known only to the card holder. The specifications from your credit vendor should include all required fields as well as special formatting information.
Validate Card Information
Validating cards can include:
- Verify the card type is one you have an account for
- The name should resemble readable text
- The number should be a valid number for the given card type
- The expiry date should be in the future, but not too far in the future.
The specifications from your credit vendor should include any field validation rules and any other specific validation requirements.
Save the transaction
The transaction can be saved locally or to a remote server. If saving it locally, ensure that the firewall and other network security specifications are met. If you need to transfer the transaction to a remote server, you must encrypt the data prior to transmission.
The means of transmission can include email, FTP, HTTP, HTTPS and custom solutions. Generally, all are acceptable providing that the data is encrypted and appropriate measure are in place elsewhere on the network. As always, you should check your vendors specifications just in case your preferred method is disallowed or has special requirements for compliance.
If you are saving the transaction to a database, you may need to encrypt the card number field and possibly the type and expiry date fields as well. This is to prevent casual users from accessing the data. Usually, your application will have security measures to only display the decrypted values to users who require access to the actual card number such as accounts receivable clerks and management.
Access to the card data within the database is normally restricted only to persons who have a valid reason to view the data as part of their job duties. Even if you don't encrypt the data within the database, you should still use security measures to prevent casual users from reading the card numbers. Internal application security can be accomplished through various means including database roles, embedded application passwords and user name or role checking in forms and reports.
Generate a receipt
All credit card transactions should generate a receipt and send it to the cardholder. The receipt should usually include:
- Details regarding the order
- All prices including shipping and taxes
- Any applicable tax registration numbers
- Exact time and date
- Your company information including: name, phone numbers, and addresses
- Type of card used
Usually you will not include the full card number, particularily if you are sending the receipt via email. A common practice is to mask out part of the card number, for example: "53** **** **** **21". Doing this will let the customer know that their card was the one used and prevents others from learning the actual card number.
Process the transaction for payment
The transaction can be processed in a number of ways. The simplest method is to process it offline from a report generated by the database. Transactions can be manually keyed in from a local Point-of-Sale terminal or printed on credit card slips and send to the credit vendor.
The manual methods mentioned above are good for small shops or companies with low volumes. However, if you have large volumes of transactions or need to process regular recurring transactions, you usually need an automated system to handle the transaction processing functions.
An automated process is one that will generate data that is compatible with your credit vendor's software and transfer the data electonically to the their system. This can include batched or real-time transactions. You will need a means of connecting to the vendor and software that performs the transfer. The credit vendor should supply you with all the details you need in order to connect to their systems.
You may also need to collect data from your credit vendor. This is information regarding customer chargebacks, declined cards or other transactions introduced at the vendor. Your system will need to collect these incoming transactions and enter them into your database. At minimum, you will need to collect the data and find some method, possibily manually, to deal with transactions from your vendor.
Regardless of the processing method, it must be secured. Any printouts should normally be kept in a secure place or disposed of by shredding or other means. Data transfers should be encrypted, particularily if it arrives at, or leaves your network.