IT DevWorks specializing in ecommerce sites and Authorize.net integration.

Page 4—How to Build Your Own Shopping Cart

On the previous pages, we discussed how to create the infrastructure for your shopping cart. Finally, we’re ready to tackle the code.

Checkout Pages

Obviously, ecommerce sites can be very complex. If you’re selling a lot of products and/or your products include a lot of complex ordering options, you’ll probably find it easiest to purchase a shopping cart. On the other hand, if you’re building a basic shopping cart to sell a limited number of products or simply billing monthly for services, you can easily build your own shopping cart.

Ease of use is critical. You can find plenty of articles about website design, and it’s worth taking the time to read them. A few key things to keep in mind:


For more information about designing checkout pages, see what usability expert Jakob Nielsen had to say in this article.

API or Third-Party Component

One basic decision you will need to make is whether to use the payment gateways’ default access method or use a third-party component. The APIs of even the largest and most popular gateways leave something to be desired. They provide limited formats for transmission and response. They often don’t provide explicit error messages. Most of the default access methods require that you build complicated submit strings and do a lot of parsing of responses, as well as write code to handle all the possible input cases, response cases, and errors.

On the other hand, a well-built, third-party library will allow you to work in the language you’re comfortable with, will perform the majority of error-handling for you, and may offer added features similar to the ones shopping carts offer, like line item totaling.

Where to Store the Product Data

Ideally, you should store your product data in a single location. It adds a level of complexity, but it provides a place from which to dynamically update your pages. If you design your site so that all references to product data are done dynamically, when changes occur, you can make the change once and all of your pages are updated.

You can store the information as hard-coded constants, in a database, in an XML file or some other format. If you have a lot of products, the products have a lot of options, or the product information changes a lot, a true database may be the best choice.

Payment Processing Pages

The checkout system for even a basic ecommerce site should have the following checkout pages:


One of the decisions you’ll have to make for the payment information page is what kinds of payments you will accept. For instance, most payment gateways accept echecks, as well as the standard credit cards. Will you? Some credit cards have higher fees. Will you accept them?

You’ll populate the order review and confirmation pages using a combination of your stored product data, the information the user entered on the payment information page, and the calculations performed by your code or the payment processing component you’re using.

Security

Obviously, security is critical, but it is a fairly big topic—too big to do it justice here. Again, there are a variety of good resources on the web, such as OWASP’s Top 10 2007 (Web Application Vulnerabilities).

One very important thing to know, though, is to not store customer credit card data unless you absolutely need to. If you must do so, make sure that any personally identifiable information you do store is encrypted and that you never transfer such personal information between the customer's browser and your server without being encrypted (using https:// and an SSL certificate).

State and Error Management

Good state management is important to usability and helps prevent the kind of errors that could lose you customers. Keep in mind that people will use the Back button in their browser to make changes to their order. Normally that will bring them back to a cached version of the page. You’ll need to handle that. Make sure you preserve state between pages during the user’s session. If you have a registration and log-in system, use it to save the user’s order information when the user ends the session.

Errors will occur. If nothing else, users will make typos. Make sure you are trapping errors on every page, and before leaving the page, reporting them to the user in a clear and visible manner. Make it as easy as possible for the user to identify and correct any missing or wrong information.

Don’t pass errors through to the user. Doing so may give hackers valuable information about your site, making it easier for them to attack you.

IBillIt

Now that you know how to build an online shopping cart, we hope you'll consider using the IBillItcomponent for Authorize.Net. IBillItis not just a thin veneer that passes through calls to the payment gateway. It includes several bonus features to make it faster and easier for you to create a custom shopping cart, including:


And that's not all. We hope you'll check out our FAQ for more information.


Back to articles


1       2         3         4