Working With The Authorize.net Customer Information Manager (CIM), Part 1: Overview
I’m going to spend several posts discussing authorize.net’s Customer Information Manager, a Web service for storing and retrieving personally identifiable information about the people who place credit card orders on your Web site.
Today, I’m focusing solely on an overview of CIM: What it is, how it works, why it works that way, and approaches to integrating CIM into your custom storefront / ordering systems. In future posts, I will discuss actual implementation via PHP and MySQL; my intent is to use 2-3 posts to cover the process, but it may take more or less. My intent is to post every day, but there may be a delay of a day or two between posts.
(I’m uncertain on the number and timing of posts on this topic because I’ll be blogging about implementation as I implement CIM for the first time. And lest that gives you pause, I’ve extensively reviewed the documentation, tested the basics of using the service, and have over 10 years’ experience with PHP / XML / MySQL. And because I’m doing the actual implementation for pay, I will have extensively tested the solution for elegance, reliability and security.)
What Is A Web Service?
The Customer Information Manager is a Web service. In its most common implementation on the World Wide Web, you send a Web service an XML document describing information you want, and the service responds with an XML document that contains the information you requested. (Not all Web services work this way; there are many kinds of Web services out there. But rather than bog down the point, let’s stick with this basic description.)
We can therefore think of a Web service as a remote database; the Customer Information Manager Web service is, in fact, a way to get data into and out of a remote database.
In the case of a Web service, rather than connecting to a local database, writing a SQL query and asking it to send us a result set (or Boolean false on failure), such as we would do in PHP / MySQL, we instead write an XML document that provides our authentication credentials and describes the data we want, send that to the CIM Web service via cUrl (or, if your server allows it, fopen), and get back from the CIM an XML document that contains the records we want (or an error code describing any problems encountered).
In other words, for most intents and purposes, the CIM Web service works exactly like a database, only different. So why in the world does authorize.net bother with a Web service, rather than simply giving you access to their database directly?
