Showing results for 
Search instead for 
Did you mean: 

Multiple API Login IDs

This has probably been asked before. I did search, but didn't find anything, although I may not have searched for the right terms.  I do apologize if this has been asked before.


Is it possible to have multiple API login IDs?  One with lesser privileges?  Specifically for the CIM API method, but I guess this would be beneficial for any of the API methods.


For example, have one API login that links to your account, but it does not have the privilege to use the CustomerProfileTransactionRequest.  So you could use this API login ID on a public web server, without risking that server being hacked into and the hacker being able to run charges on the information stored in your CIM.


I know every effort should be made to protect this API login so that that doesn't happen.  But I just thought it would be more secure having this extra layer of protection.


Then you could have another API login ID that is linked to the same account that has all privileges, privileges to run transactions.


Is this possible to do?





This layer of protection does not currently exist but it sounds like an interesting idea. Maybe the team at Authnet will consider adding this to their to do list?

John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post

Hey there,


I will definitely pass that on to our development teams for consideration. Thanks for the suggestion!





Developer Community Manager

Michelle, what is the status of this development request?



Michelle wrote:

Hey there,


I will definitely pass that on to our development teams for consideration. Thanks for the suggestion!





Developer Community Manager


Hey there,


No updates that I'm aware of. But the developers are aware of the request.





Developer Community Manager

Practically speaking, if a hacker gains access to your FTP, you're screwed. Period. Even if you don't store credit card info locally (and I'm sure you don't, since you're using, all the hacker has to do is insert 3-4 lines of code into your form and have it log the credit card info to a file. Same with customer data. Surface "hacks", on the other hand, are generally limited to inserting Javascript that forwards people to an infected site, unless you're a really moronic programmer and don't escape your data before putting it into a database query.


Short version - this might be an interesting idea for to implement, but I don't really think it'll enhance security that much. Just don't leave your password lying around.

That is correct.  If you're account is hacked into, you are screwed, and every effort should be made to protect this login information.

But, in order for a web facing script (a publicly accessible webpage, an order form for example) it has to be public and on a server that has a connection to the Internet.  This means it can be hacked.


Perhaps a script becomes vulnerable and a hacker gains access to the script through that vulnerability (always keep your script up-to-date, but what about the event of a 0-day exploit?).  Perhaps your FTP username and password information leaks out, again this is the fault of the end-user for not protecting it better, but it could still happen.

The point I'm trying to make with this feature request, is that by having a more "write-only" login on your public facing application, then if your webhosting account gets hacked into, for any reason, the hacker conceivably would not be able to run charges on the cards that already exist in your CIM account.


I know I would feel safer with this.


Have a public facing script, that reads an Authorize.Net login, connects to the CIM database, writes the credit card information to the Authorize.Net servers and that is all it is capable of doing.

If I want to charge a card in the CIM database, I use a separate login, on my own personal local area network, behind a firewall which does not allow incoming web connections, to make that charge.


Yes, if you're public facing website is hacked, you are screwed.  Nothing will stop a hacker from injecting code into the scripts to email them the credit card information or write the credit card information somewhere else.  But at least they wouldn't be able to make charges on the cards already in the CIM database.


Look at the current situation.  On the public facing web server, you have to have your Authorize.Net information stored somewhere on the server. Somewhere where the webhosting account in question can read it.  If a hacker or malicious user can read that information, then they instantly have access to charge the cards in your CIM database for whatever amount they want, whenever they want.


Unless I'm missing something somewhere, which I won't say that I'm not.

You need the payment profile ID to do any charging, however, so as long as you don't allow the public database user to access that information, you're still fine.

I have to admit, I haven't looked at any of this since I opened this thread last fall.


From the code I have, there is a vars.php file.  In it, it lists your login name ($g_loginname) and transaction key ($g_transactionkey).


Can't anyone that has this information use the API to call getCustomerProfileIdsRequest to get a list of the Customer Profiles and charge a profile with that?


I really don't know, that's why I'm asking these questions.  It still just seems to me that if there was a login name and a transacation key that you could put on a public facing server and the only thing it could do, the only api functions it could call, are functions that write items to the CIM database.  This eliminates any potential malicious actions that can come about with this information.

Hmm. I guess that would be a security flaw, if we assume for the sake of argument that your hosting has been compromised. However, the worst they'd be able to do is charge the credit cards and have the money go to you, so you could easily identify that someone's in your account, reverse the charges, and change your passwords. It would be much worse if they just added a credit card sniffer, as I said before, and then charged the credit cards somewhere else. If your hosting has been compromised, then having ANY part of ANY merchant system on your account is real bad. Having some of it locked off just delays the damage and/or forces the hacker to be slightly more creative.