- Shopping Bag ( 0 items )
A full discussion of both the hardware...
Ships from: Hillsboro, OR
Usually ships in 1-2 business days
Ships from: Chatham, NJ
Usually ships in 1-2 business days
A full discussion of both the hardware and software required to run all of the example code in this book is provided in Chapter 1, but as a rough guide you should have a minimum of:
This book explores the most important areas of the Commerce Server 2000 product, taking you through from product installation, and configuring and customizing the ready-made e-commerce solution sites, to low-level application of the component framework, integration with third party components and external systems, and site migration from Site Server 3.0 Commerce Edition.
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:
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.
This is an example of real time credit verification – so what exactly happened? Let's break it down a little:
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.
Such a system would have the following type of layout...
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:
...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.
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....