Read-only transaction key for Transaction Details API?

[BenDunlap]

Hi, I suspect this is a long shot but I'm wondering if there's some way that I missed for me to generate a separate, read-only transaction key that I can use to make Transaction Details API calls.

I am writing some code to run unattended once a day and do a bookkeeping reconciliation between our Authorize.net transactions and our sales-tracking system. So far it's looking like this code I'm writing -- which only needs to be able to view past transaction details -- is going to have to store and use the same key that our live ecommerce sites are using.

I'd just as soon minimize the number of places where that fully-featured key is used and stored -- is this possible, or is there just one key per merchant account, always with full access?

[TJPride · Accepted solution]

Only one login ID and transaction key as far as I know. Practically speaking, it doesn't make any difference, since you can't get credit card data out of the system using the login ID and transaction key. The worst someone could do is charge some of your CIM profiles, if you're using CIM, but then the money would end up at you and not them - there would be no motivation to do that. The login ID and transaction key do NOT give you full access, that's why there's a second login for the control panel.

[BenDunlap]

Thanks -- I guess I had assumed that our login-id/transaction-key pair could be used to issue refunds via one of the APIs. Is that not actually the case?

[TJPride]

I suppose that could be done, but it would have to be linked to an existing transaction, within 120 days of the transaction date, and the refund would have to be equal to or less than the amount charged. That would be a little damaging, but chances are that anyone who managed to gain access would have no transactions of their own on your site, therefore again no motivation to do this. You don't have unlinked credit turned on, do you?

Practically speaking, anyone who gains access to your hosting can do much worse things to you than just use your Authorize.net account. They can, for instance, modify your ordering process so credit card details are collected on your site and mirrored to their site. Security starts and ends with your hosting, worrying about the Authorize.net login ID and transaction key is kind of trying to close the barn door after the cows have already escaped.

[BenDunlap]

No, ECC is not enabled -- and the server where this reconciliation is going to run is completely distinct from anything to do with our ecommerce. So it sounds like we're in reasonably good shape. Thanks for the tips.