I would like to make a case for the ability to search CIM Customer Profiles using the XML interface:
We have several applications, each using it's own database, located in remote parts of the world with frequently flakey internet access. Each application has the possibility of creating and using CIM Customer Profiles. Managing the CIM Customer Profile ID's between these applications is a huge hassle. We've had to develop customized synchronization functions to maintain data integrity of our scattered local CIM tables. And still, due to local internet outages and occasional user error, we end up with two different customers accidentally sharing the same CIM Customer Profile ID, or sometimes one customer will have multiple CIM Customer Profiles. This causes customer freak-outs and admin headaches.
It would be so much easier for us if we could search the Authorize CIM database using a call similar to getCustomerProfileIdsRequest, but with search capabilities. If we could use this call, passing a single (or list of) merchantCustomerID, customerProfileID, customerEmail, we would be relieved of the -maintenance overhead of linking our customers to CIM Customer Profiles.
If you consider the Authorize CIM database as part of the greater database application that we (or anyone) have built, the merchantCustomerID in the CIM Customer Profile is THE link between the two. Storing this link locally in our own databases is creating multiple points of truth and adds an extra layer of complexity to our databases and our applications.
Here's what I would love to see as added functionality to the getCustomerProfileIdsRequest:
merchantCustomerID: string of comma-separated ids, OR'd
customerProfileID: string of comma-separated ids, OR'd
customerEmail: string of comma-separated ids, OR'd
Each of the input parameters would be OR'd. The result would be a string of customerProfileIDs that match any of the criteria.
Your response is now more than 6 months old. Please tell me Authorize.net has a solution for this now.
Not being able to search CIM records is a major flaw in the system. It makes a simple query like "Show me all the orders from Texas" a nightmare to accomplish. (Do I really need to pull down every billing profile one-by-one and see if the State is 'TX' ???)
As far as I am aware this is still an issue that has been discussed again and again - and unfortunately for Michelle, she is only the messenger... and we all know what that means...
We overcame this issue by utilizing our own customer profile facility with CIM - and given that you have this info available to you already to make a CIM customerProfile - its not that hard to store identifying subsets of that information on your own DB.
You're right. We could store a sub-set of information locally. I was hoping to avoid that, however. After all, part of the appeal of CIM is the PCI Compliance it provides. In theory we could store no customer information locally, just a unique number for each person. If we now have to step back and store names and addresses, we're essentially back where we started. Why even use CIM?
Worse yet, the information stored locally would need to be unencrypted to be useful. You couldn't search for customers with a last name that starts with 'Mac' if the names were encrypted in the database.
This is really an Achilles Heel for CIM. Can anyone from Authorize.net comment on when Search will be available and what the recommended approach is in the mean time?
from my standpoint, that demographic information Im refering too is what powers the CRM part of our system - I dont want to be relying on a 3rd webservice for that. Now it does become a kicker though when there is a synch issue or some other form of mismatch. In that situation you have no choices other than allowing for a manual lookup or to automatically create a new account.
I have also had exstensive discussions with support about this situation, as its almost as though this functionality was literly just 'not thought of'. and to us developers on the outside it really does seem crazy . It has all the ear-marks of software being developed outside of a live system, IMO. But every developer has been guilty of that in their time.
Unfortunately as TSdotNet already indicated, there still is no way to search CIM profiles using an API. But I have sent the request on to our development teams again, so they are aware of the need. Also, I cannot give any kind of timeline surrounding when such support would be available.
Thanks for the feedback,
Developer Community Manager
Well, I'm back at it again, building another CIM-based solution for a new customer. I'm reviewing all of our current CIM-based projects (which by the way, are working quite well) and the current Authorize.net offerings...
And I'm surprised to see there hasn't been any progress on this issue. Auth-net's system already has search functionality built-in, as we can do it manually in the merchant interface. So my best guess is that the ommission of a CIM search feature in the API is a conscious decision by Auth-net: They want us to track our own relationships between CIM profiles and our various customer/person IDs.
The only reason I can see for this ommission is to conserve Auth-net's resources. Consider this: To find a CIM profile now, we search our own db, get a CIM profile ID, then query Auth-net. If we had the ability search Auth-net, we would skip tracking & searching our own databases and instead query Auth-net directly with an email/person/customer/whatever. That would be a lot of additional queries for Auth-net's servers.
However I'm also guessing that the added complexity of having to maintain & synchronize our own cim_customer_profile tables leads to nearly as many extra hits on the Auth-net servers. If a local table of profile IDs gets out of sync, our only recourse is a manual search in the Merchant interface, or an excruciating traverse thru every CIM profile in our account.
I could be way off the mark here, as it seems a little rediculous to worry about resource requirements of simple xml transactions. But... we don't really know, do we?
Authorize.net, can you give us an official stance/policy on why we don't have search capabilities in the CIM API, and if/when we might get them in the future?