Reply
Member
Posts: 6
Registered: ‎08-22-2011

Other options for transaction data storage?

Hi all,

 

My company is looking into using the AIM method but it looks like it requires us to store the transaction data (CC#, billing address, etc.)  on our own servers. Our servers are in Japan and apparently there are laws there against storing sensitive personal info on our own servers. Is there a service option or some other method we should be using if we don't want to store the transaction data on our own servers?

 

Hope that makes sense. I myself am not the developer but since he doesn't speak English, I'm asking for him.

 

Thanks for any help.

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Other options for transaction data storage?

If you need to do ongoing billing, use CIM (Customer Information Manager). You create profiles and blling profiles that you can then charge by just passing ID's - Authorize.net stores the credit card info for you.

Member
Posts: 6
Registered: ‎08-22-2011

Re: Other options for transaction data storage?

Thanks for the reply.

 

We won't be doing ongoing/subscription billing; I think our developer is talking about a database of orders and payment info. Basically, if we needed to do a refund and we had to look up the order by the credit card # used, where would that database be stored? Is that something Authorize.net can host?

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Other options for transaction data storage?

Well... you could store a one-way hash of the last x digits of the credit card number in your database and then match against the hash to find transactions. Then when you found the right transaction in your database, void it (as long as it isn't settled yet, anyway). That would be mostly secure. But I don't think you can search Authorize.net using credit card numbers.

All Star
Posts: 1,072
Registered: ‎08-17-2009

Re: Other options for transaction data storage?

Hey guys,

 

Many people use CIM just for the secure storage and repeat customer aspects it offers. You don't actually have to do any recurring billing with CIM, you just can if you want to. With CIM, you store profiles on our servers for your customers and their info. So if you used it and needed to refund a customer, all you would need would be the payment profile ID that they used to pay with.

 

And you can actually search by credit card number from within the secure Merchant Interface. Just in case you need to.

 

Thanks,

 

Michelle

Developer Community Manager

Member
Posts: 6
Registered: ‎08-22-2011

Re: Other options for transaction data storage?

Thanks for the additonal responses.

 

@Michelle, so with CIM, it will store all cardholder information regardless of whether or not the customer creates a profile?

We would also need to be able to issue refunds through our own backoffice on our server (and not through the Merchant Interface); would that be possible with an AIM and CIM combo?

 

If not, is the Direct Post Method an alternative solution?

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Other options for transaction data storage?

CIM is called internally, so the customer doesn't know whether you charged them and then immediately forgot their info (AIM), or whether you created a customer and billing profile (CIM) and then did an immediate single charge against it. If there's any chance of having to bill the same person again, you definitely want to use CIM; otherwise, you should probably just use AIM. It's generally a bad idea to rely on any third-party service to store your customer info, since you then can't query it directly yourself (for instance, if you wanted to generate a report on your site of how many customers are in which zip codes), so I always store non-billing info on my end and just mirror it on Authorize.net when a transaction goes through so it also shows up in the merchant login area.

Member
Posts: 6
Registered: ‎08-22-2011

Re: Other options for transaction data storage?

So basically if we use CIM, we wouldn't be able to connect to or query the data within CIM from our own custom interface?

If we want to access that data, we'd have to use the Authorize.net merchant interface?

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Other options for transaction data storage?

You can access the customer info one record at a time, and also get a list of customer ID's, I'm just saying that if you don't store the info on your end as well, you can't query against all of the records simultaneously. So if you have several thousand profiles, for instance, you couldn't generate statistics on your best areas to sell to (or whatever) without querying Authorize.net several thousand times. Also, if Authorize.net happens to be lagging or having some sort of other technical problem (hopefully rare), anything on your site that relies on loading and displaying customer data would lag as well. It's better - at least in my opinion - to store everything except credit card and other billing info on your end as well.

 

Short version - you can, but whether you -should- is another issue.

All Star
Posts: 1,072
Registered: ‎08-17-2009

Re: Other options for transaction data storage?

Hey spacysmoke,

 

To answer the questions directed at me above, yes, when using CIM you create a profile, even if the customer doesn't necessarily think they are creating one. But as TJPride indicated, the process is behind the scenes and just makes handling repeat customers and follow-up transactions easier to manage. 

 

You can also use CIM to issue refunds. You would use the API call createCustomerProfileTransactionRequest and submit profileTransRefund for the transaction type. You'd also need the payment profile ID and the original transaction ID. You can check out the CIM guide for more info.

 

Hope that helps.

 

Thanks,

 

Michelle

Developer Community Manager