Read an Excerpt
Chapter 12: Third-Party Solutions for Payment, Tax & ShippingOne of the great benefits of using Commerce Server 2000 is that it enables us to integrate third party components into our pipeline architecture with relative ease. By now, we should be quite familiar with the plug-in functionality of components for Commerce Server. In this chapter, we will discuss extending the pipeline architecture for additional payment processing, tax calculation, and shipping calculation functionality through the use of third party components, in conjunction functionality exposed by a service provider.
Why do we need to extend the pipeline for payment, tax and shipping functionality? The out of the box components were never designed for production use in these areas. The Default Payment Component in Commerce Server only sets values that are needed by some of the other components to complete transactions. It never connects to a banking institution; therefore a live authorization does not take place. Tax components are similar. These components calculate tax rates based on values set, but they do not take tax calculation to the appropriate level of 'precision' that is needed by most businesses. The same goes for shipping calculation. The cost of shipping can vary between carriers, weight, the type of products shipped, the size of the packaging and the shipping method used; therefore the components included with Commerce Server only scratch the surface. These may work fine in certain instances, but when calculation need to be very precise, and may be quite complex, it is best to look into third party components and services.
We will look at a few of the companies that provide these services, and see how to incorporate their components into a Commerce Server 2000 solution site. We will see the ease of setting up this type of functionality with Commerce Server, and will gain an understanding of how these components and services differ from each other. By the end of this chapter, we should have a good understanding of how to implement each one of the components. We will discuss the following services:
- Credit Card Payment – considering CyberSource and CyberCash solutions
- Tax Calculation – considering CyberSource and ClearCommerce solutions
- Shipping Calculation – considering the ClearCommerce solution
Credit Card Payment SolutionsYou've created an e-commerce site with Commerce Server 2000, and you have a large product catalog that you're sure will attract a lot of customers. Now there's just one catch: right now, you don't have any way to take their money. Commerce Server 2000 ships with a default 'out of the box' payment component that really does nothing more than fill a place in the pipeline until you choose to add a more functional component. The default payment component writes to the
order._payment_auth_codename/value pair so that the required payment component will not fail. This component doesn't actually implement any credit card pre-authorization; there is no true billing of a customer's credit card, and no type of fraud screening taking place. The reason this component lacks this functionality is because there are so many different credit card providers available with many different rates, connections, banks and services. It would be impossible for Microsoft to supply a component to fit everyone's needs; therefore they provide us with a starting point and enable us to expand and move forward choosing exactly what you need from other service providers. If you want to process live transactions you must select a payment service that handles these things for you.
However, before we look at the implementation of services and components, it's important to understand just how these services work, the different types of services, and what we need to have already in place.
How Payment Processing Solutions WorkThere are three types of payment processing solutions available today. There are many other solutions that can be customized to be integrated with existing payment solutions, but we will focus on those readily available for Commerce Server 2000.
- Real-time payment via the Internet
- Real-time/batched payment with in-house systems
- Redirection based payment solutions
Real-Time Payment Via the InternetOkay, let's imagine this scenario: a customer is sitting at their computer with a full shopping cart, looking at the total cost of their order. They click the Purchase button after entering their credit card information, and a few seconds later get a message on the screen informing them that the specified credit card is over its limit.
This is an example of real time credit verification – so what exactly happened? Let's break it down a little:
- First, the user clicked the Purchase button, sending credit card information to the e-commerce
- The e-commerce web server then opened a connection across the Internet to a payment
service provider and sent the customer's credit card information (and, very probably,
their billing address information as well).
- The payment service provider (which is connected to the banking network) sent that
information on to the bank where the e-commerce business holds its merchant account.
- The bank ran a pre-authorization on the card number, along with an AVS (Address
Verification Service) check, to make sure the billing address given matched that of the
card being used.
- Once this was complete, the banking processor sent back 'card over its limit' information to the payment service. This in turn handed the information back to the e-commerce site's web server, which used it to generate a message for display on the customer's browser.
- Ease of implementation.
- Low maintenance, because the payment system is a service and another company's responsibility.
- Low cost....
- In most cases there must be a constant Internet connection between the payment provider and
the web server. If this connection fails, it will result in lost sales. Some providers do offer a
dial up link or leased line into their external systems to alleviate that possibility.
- We must deal with latency over the Internet service provider's server and the service's network – response times can increase and decrease depending on congestion levels; ultimately, we have no control over the speed of the connections. Remember, this is also a service – check into the uptimes of the services, because if they go down, so does your website if you do not have another form of payment or telephone ordering system in place.
Real-time/Batched Payment with In-house SystemsThere are some types of systems that that do not send information via the Internet to process payments. Some of the third party solutions available are sold as packages that handle all of the processing in-house. With these systems, the communication is much faster because the system is running on the same network as the web server.
What might be another benefit to a system that runs in-house? The payment processors that transmit data on the Internet usually charge a fee per transaction. For a large enterprise that processes many transactions it will be more cost effective to pay a larger initial fee and bring the payment processing inside the company. Also, with in-house systems, it is potentially easier to tie in customer service call centers, phone operators who take orders, the e-commerce site, and point of purchase systems. Many of the Internet based payment solutions are designed for server use only and for integration with e-commerce applications. In-house systems have a more open architecture, allowing them to be used within custom applications.
- When an order is placed on an e-commerce site, the site's web server will contact the
- This payment server is connected to a banking network (via a leased line) and makes a call directly to the banking institution.
Such a system would have the following type of layout...
Redirection Services...Some companies offer services that allow us to post data or link to their page for payment services. They then handle all the payment processing, and can even return a success/failure message to the customer. This type of service is usually cheaper on per-transaction rates, monthly fees and development time. However, one of the drawbacks is that the user may get a sense of leaving the website, which will make some users feel the transaction is not secure.
This type of service requires no direct component integration with Commerce Server, so we're not going to go into detail here on how to implement the service. However, it is important for developers to know that this type of service exists and how it works in order to make informed design decisions.
Using the same scenario given in the previous two payment type solutions, we can begin to understand where this type of service would come into play:
- While the customer is looking at the total for their order, they click the Purchase button
- At this stage, the site would post information pertaining to the order to the service provider's website, which would generate pages for the submission of credit card information. In many cases, the external pages can be customized to match the look of the original e-commerce site, leaving the user with the sense that they are just accessing one system. The service provider processes the transaction and places the money in the e-commerce company's merchant account....
...A very important concern with this type of service, as with all payment services, is security. If the system is designed poorly, a person could potentially manipulate URL strings and trick the merchant's site into thinking that the payment was successful.
Commerce Server 2000 Payment IntegrationAt this point, we will cover the implementation of two major payment service providers that supply components that easily integrate into Commerce Server 2000. There is very little development involved with these components, as the implementations are fairly straightforward.
The first component we will start with is a component developed by the CyberSource Corporation. This component is simple to implement and provides a wide range of services....