Using Authorize.net's CIM feature for one merchant with multiple merchant accounts

Question

I'm investigating the use Authorize.net for a client that has N physical locations, each with their own distinct set of goods to sell and each with their own merchant account. I'm thinking about using the CIM feature, which allows me to store sensitive customer data with Authorize rather than holding onto it myself. That's a big win; I'd prefer not to have to deal with the complexities of managing sensitive data.

However, it appears that the CIM feature is storing this information on a per-merchant-account basis. That is, if I store some customer data Z with merchant account A, I can't use that same data with merchant account B, even though A and B both correspond to the same entity and the data represented by Z is identical in each case. That seems silly: the customer will have to re-enter their data once for each store, even though all the stores are part of one chain.

Is there a way I can do this with Authorize.net? If not, is there an alternative which allows me to reuse customer representations across merchant accounts, without storing the sensitive data myself? Are there other more general solutions that would get me what I want, or do I have to resort to holding onto this data myself?

Answer 1

Unfortunately Authorize.Net's CIM service, as well as all of their services, are on a one-to-one relationship with a merchant account. So if you wish to put a profile in multiple CIM accounts you would have to do it for each CIM individually.

Based on your requirements it looks like you may find it easier to store the information yourself.

Answer 2

You can try to centralize connectiivity to Authorize.net and this centralized service will store the mapping within where user entered his sensitive information, and pass it to centralized authorize.net adapter as part of customer identtity,like so "customers/shop12/user12345" over an encrypted connection. THat centralized service will need a Authorize.nwt credentials table, of course (shopid, apiLogin, transactionKey). This is a possible solution if your client accepts storing api credentials outside of "shops"