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?
In a word, security. The primary benefit in providing the Customer Information Manager as a Web service is that it acts as an abstraction, and a fairly limited one at that.
What I mean is, if you had the ability to run any old UPDATE or DELETE query you wanted to run on the Customer Information Manager, you’d be able to do some serious damage, even if you only messed up your own records. (Everyone who has worked with SQL queries for more than a week has totally annihilated database tables with ill-considered UPDATE or DELETE queries.)
The Customer Information Manager APIs (application programming interfaces) allow authorize.net to restrict your activities to some basic tasks; namely, creating new customer database entries (“profiles”), deleting them one at a time; updating them one at a time; or getting a list of profile IDs.
The other benefit to the CIM Web service approach is, by only accepting XML requests and sending back XML in response, authorize.net can impose several levels of protection between the database and you. We don’t know, for example, what database holds our information; we can’t try to hack root; authorize.net is able to insert several layers of intrusion detection / firewall / load balancing between the XML we see and the database we can’t see.
Why Bother With CIM?
The primary reason to work with the Customer Information Manager is that it fully complies with the Payment Card Industry (PCI) Data Security Standard (DSS). Having a secure payment gateway to process online credit cards is one thing; being able to protect the credit card numbers you collect, as well as personally identifiable information about cardholders, is another.
Page 1 of 3 | Next page
