topic Re: Other options for transaction data storage? in Integration and Testing

Other options for transaction data storage?

spacysmoke — Mon, 22 Aug 2011 20:02:28 GMT

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.

Re: Other options for transaction data storage?

TJPride — Mon, 22 Aug 2011 23:20:14 GMT

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.

Re: Other options for transaction data storage?

spacysmoke — Mon, 22 Aug 2011 23:51:55 GMT

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?

Re: Other options for transaction data storage?

TJPride — Wed, 24 Aug 2011 02:36:53 GMT

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.

Re: Other options for transaction data storage?

Michelle — Wed, 24 Aug 2011 19:50:44 GMT

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

Re: Other options for transaction data storage?

spacysmoke — Wed, 24 Aug 2011 23:17:59 GMT

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?

Re: Other options for transaction data storage?

TJPride — Thu, 25 Aug 2011 08:14:50 GMT

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.

Re: Other options for transaction data storage?

spacysmoke — Fri, 26 Aug 2011 00:46:03 GMT

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?

Re: Other options for transaction data storage?

TJPride — Fri, 26 Aug 2011 03:15:44 GMT

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.

Re: Other options for transaction data storage?

Michelle — Fri, 26 Aug 2011 18:10:34 GMT

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

Re: Other options for transaction data storage?

spacysmoke — Wed, 31 Aug 2011 23:15:26 GMT

Thank you everyone for you patience and responces; I really appreciate it.

I'm wondering if we're over complicating things though; surely there must be way to issue credits from a custom interface without CIM? The AIM guide says that credits can be done through the Merchant Interface, but if necessary, the API can be used for such transactions in custom applications. Note: We are using a slightly older version of PHP, so we can't use the AIM SDK.

If we are using AIM alone, what would the process be for issuing a credit?

As I understand it, the variables we need for a credit are the transaction ID,and last 4 digits of the CC.

Would we be able to look up the transaction ID from Authorize.net or would we need to store that ourselves?

Can the Transaction Details API to look up the transaction ID or is the TD API only good if we already know the transaction ID?

Would you typically just get the last 4 digits from the cardholder themselves?

Sorry; this is probably really basic stuff, but I'm new to this and our developer doesn't understand English too well so he's not helping me much.

Re: Other options for transaction data storage?

TJPride — Thu, 01 Sep 2011 11:51:06 GMT

Well, there is a function in the AIM SDK for issuing credits, it requires transactiion ID , amount, and the last 4 digits of the credit card number. Transaction ID you can store, but while there's a way to retrieve the last 4 digits of the credit card from a CIM payment profile, I don't think there's a way to do it for an AIM transaction, so you'll probably have to ask the cardholder for that. Voids are different - if the transaction hasn't settled yet, you can just void it, and that only requires transaction ID.

As for applying this knowledge, if you can't use the SDK in your version of PHP and can't upgrade PHP or move to hosting with better PHP, then you'll have to use XML posts and parse things yourself. That will get a LOT more difficult.

Re: Other options for transaction data storage?

Trevor — Tue, 06 Sep 2011 22:39:31 GMT

It is definitely easiest to store the transaction ID if you plan on offering the ability to issue a refund later. As for the last 4 digits of the card number, you can retrieve this using the transaction details API calls or you can ask the customer to enter it. Requiring the customer to enter the last 4 digits of the card number could be viewed as an extra security check to verify their identity.

You are correct that when issuing a refund through AIM, you only need to submit the original transaction ID, the last 4 digits of the card number, and the amount.

Re: Other options for transaction data storage?

spacysmoke — Wed, 07 Sep 2011 19:47:40 GMT

Thank you TJPride and Trevor! I think this is more along the lines of what we are looking for.

So we store the transaction ID on our end and either use CIM to store the last 4 digits or retrieve it from the cardholder.

If we don't use CIM, will we still be able to retrieve the amount charged using the transaction details API?

Re: Other options for transaction data storage?

TJPride — Wed, 07 Sep 2011 22:06:45 GMT

I think Trevor's saying it's possible to retrieve the last 4 digits of the credit card even if it was an AIM transaction, by using the transaction details API and the transaction ID. I would imagine the transaction amount is also included.

Re: Other options for transaction data storage?

Michelle — Fri, 09 Sep 2011 17:44:01 GMT

Hey spacysmoke,

The amount of the transaction is returned when you use the getTransactionDetails call of the Transaction Details API. It should return both the authorized amount and the amount submitted for settlement. For a complete list of what's returned in that call, check out the Transaction Details Guide.

Thanks,

Michelle

Developer Community Manager