Re: Authorize.net?

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 48453
interpreted = N
texte = OK, I had a long talk with authorize.net customer support. I think I have it sorted out now.There are two different versions of AIM. If you log in to your authorize.net merchant interface, and go to Help from there, the AIM documentation is AIM with password. If you go to the authorize.net home page and click on Support Services, then Payment Gateway Implementation Guides, the AIM documentation there is AIM with transaction key. Both methods are supported. I believe they actually took note of the fact that two different versions were posted in two different places, and are going to try to get it corrected.AIM with password actually uses your merchant interface login and password. Early in January when I set mine up, the transaction key method did not exist yet--I complained about having to use the merchant interface login and password on a web site (no matter how well encrypted), and customer service told me an alternative method was coming. Apparently it came shortly thereafter, but I wasn't aware of it.The transaction key method is more desirable, and is not hard to implement. You get the transaction key from the merchant interface, and can change it from time to time, and don't need to use your actual merchant login and password--so even if someone did somehow get at your transaction key from your web site, they could not log in to your authorize.net account and do devastating damage. (Changing it from time to time obviously gets more complicated when its a client's store and you don't have access to the merchant interface. They need to change it and send it to you to encrypt and store on the web site, I guess. There is a permitted 24 hour overlap period which could accommodate this.)However, what I implemented (and what Bob implemented in a more truncated way) is AIM with password. I will definitely change my interface to AIM with trans key now that I know it's there, and will make an updated code sample available at that time. But it may take me a couple of weeks to get to this.The older methods are being phased out in favor of SIM and AIM, which are more secure. Probably eventually SIM and AIM with password with both be phased out in favor of AIM with trans key. So that might be a better thing to implement for the long haul.To complete this outline, remember you cannot use AIM with a version of WebDNA prior to 4.5. (And if anyone has implemented SIM, and is offering a code sample, I haven't heard them say so, but I believe someone at SmithMicro said something about implementing it.)What are the expiration dates of the pre SIM and AIM methods? Maybe I can get to updating my interface sooner for those who are still needing to update their code.Velma At 08:28 PM 3/5/2003, you wrote: >Yeah, I know what you're saying, it is just my understanding that this >x_tran_key will be the feature that is required come April. From the AIM >docs at authorizenet.com >(http://www.authorizenet.com/support/AIM_guide.pdf): > >Minimum Requirements for AIM > >The following is the minimum set of NAME/VALUE pairs that should be >submitted to the gateway when using AIM for a credit card transaction. > >FIELD NAME FIELD VALUE > x_Version 3.1 > x_Delim_Data True > x_Login Your Login ID > x_Tran_Key Transaction key obtained from the Merchant Interface > x_Amount Amount of purchase inclusive of tax > >This version of AIM supports Transaction Key Last revised: 1/16/2003 ΖΙ 2003 >Authorize.Net Corp > >x_Tran_Key Required Varies by merchant 16 Pass the transaction key obtained >from the merchant interface. > >All I know is that my sites are/have been working for years now (with the >once/twice a year changes that would break the code) and now it is going to >drastically change. Bob, you're sending the exact same information that I >am, except via TCPConnect. I've had a couple of support tech's at A/N look >at the code and tell me that it will not fly once the 3.1 required upgrade >to AIM/SIM takes effect. I'm just telling you what I've been told. Again, >I think we're moving on just to avoid the mess altogether. Someone with the >official word please set me straight if I'm incorrect. > >GK > > > > I dunno, I followed their instructions in the aim docs. I didn't dive > > too far into all the documentation. If you know something I don't..... > > > > as far as the password is concerned its not necessary but it doesn't > > fail with it. I am not sure if the client had the required password > > feature turned on. > > > > On Wednesday, March 5, 2003, at 06:00 PM, Gary Krockover wrote: > > > > > Isn't this just a relay response method that is being sent via a > > > TCPConnect? > > > If so, the relay response method is being phased out come April. > > > > > > The new AIM/SIM method will require a x_Tran_Key value (which I don't > > > see on > > > your example) which is a value obtained by the merchant interface and > > > then > > > returned back to the payment processor as a form of authentication. > > > Also, > > > it is my understanding that passing the x_password value will no > > > longer be > > > accepted in AIM/SIM. > > > > > > I very well could be entirely wrong about this, but instead of the > > > nightmare > > > that I forsee this thing causing, I think we've decided to move over to > > > Verisign PayFlowPro. > > > > Robert Minor > > Director of Internet Services---------------------------------------- Velma Kahn Glory Day Software Company 200 Tanager Ln NW, Floyd, Virginia 24091, U.S.A. phone: 540-745-6469 * fax: 651-321-4884 email: vkahn@glorydaysoftware.com http://www.glorydaysoftware.com http://www.communitymade.com http://www.floydcrafts.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Gold on the list ... Was Re: Authorize.net? (marc@kaiwi.com (Marc Kaiwi) 2003)
  2. Re: Authorize.net? (Velma Kahn 2003)
  3. Re: Authorize.net? (Velma Kahn 2003)
  4. Re: Authorize.net? (Clint Davis 2003)
  5. Re: Authorize.net? (Gary Krockover 2003)
  6. Re: Authorize.net? (Bob Minor 2003)
  7. Re: Authorize.net? (Gary Krockover 2003)
  8. Re: Authorize.net? (Bob Minor 2003)
  9. Re: Authorize.net? (Gary Krockover 2003)
  10. Re: Authorize.net? (Bob Minor 2003)
  11. Re: Authorize.net? (Bob Minor 2003)
  12. Re: Authorize.net? (Velma Kahn 2003)
  13. Re: Authorize.net? (Gary Krockover 2003)
  14. Re: Authorize.net? (Bob Minor 2003)
  15. Re: Authorize.net? (marc@kaiwi.com (Marc Kaiwi) 2003)
  16. Re: Authorize.net? (marc@kaiwi.com (Marc Kaiwi) 2003)
  17. Authorize.net? (Stephen Reiss, Ph.D., C.W.E. 2003)
OK, I had a long talk with authorize.net customer support. I think I have it sorted out now.There are two different versions of AIM. If you log in to your authorize.net merchant interface, and go to Help from there, the AIM documentation is AIM with password. If you go to the authorize.net home page and click on Support Services, then Payment Gateway Implementation Guides, the AIM documentation there is AIM with transaction key. Both methods are supported. I believe they actually took note of the fact that two different versions were posted in two different places, and are going to try to get it corrected.AIM with password actually uses your merchant interface login and password. Early in January when I set mine up, the transaction key method did not exist yet--I complained about having to use the merchant interface login and password on a web site (no matter how well encrypted), and customer service told me an alternative method was coming. Apparently it came shortly thereafter, but I wasn't aware of it.The transaction key method is more desirable, and is not hard to implement. You get the transaction key from the merchant interface, and can change it from time to time, and don't need to use your actual merchant login and password--so even if someone did somehow get at your transaction key from your web site, they could not log in to your authorize.net account and do devastating damage. (Changing it from time to time obviously gets more complicated when its a client's store and you don't have access to the merchant interface. They need to change it and send it to you to encrypt and store on the web site, I guess. There is a permitted 24 hour overlap period which could accommodate this.)However, what I implemented (and what Bob implemented in a more truncated way) is AIM with password. I will definitely change my interface to AIM with trans key now that I know it's there, and will make an updated code sample available at that time. But it may take me a couple of weeks to get to this.The older methods are being phased out in favor of SIM and AIM, which are more secure. Probably eventually SIM and AIM with password with both be phased out in favor of AIM with trans key. So that might be a better thing to implement for the long haul.To complete this outline, remember you cannot use AIM with a version of WebDNA prior to 4.5. (And if anyone has implemented SIM, and is offering a code sample, I haven't heard them say so, but I believe someone at SmithMicro said something about implementing it.)What are the expiration dates of the pre SIM and AIM methods? Maybe I can get to updating my interface sooner for those who are still needing to update their code.Velma At 08:28 PM 3/5/2003, you wrote: >Yeah, I know what you're saying, it is just my understanding that this >x_tran_key will be the feature that is required come April. From the AIM >docs at authorizenet.com >(http://www.authorizenet.com/support/AIM_guide.pdf): > >Minimum Requirements for AIM > >The following is the minimum set of NAME/VALUE pairs that should be >submitted to the gateway when using AIM for a credit card transaction. > >FIELD NAME FIELD VALUE > x_Version 3.1 > x_Delim_Data True > x_Login Your Login ID > x_Tran_Key Transaction key obtained from the Merchant Interface > x_Amount Amount of purchase inclusive of tax > >This version of AIM supports Transaction Key Last revised: 1/16/2003 ΖΙ 2003 >Authorize.Net Corp > >x_Tran_Key Required Varies by merchant 16 Pass the transaction key obtained >from the merchant interface. > >All I know is that my sites are/have been working for years now (with the >once/twice a year changes that would break the code) and now it is going to >drastically change. Bob, you're sending the exact same information that I >am, except via TCPConnect. I've had a couple of support tech's at A/N look >at the code and tell me that it will not fly once the 3.1 required upgrade >to AIM/SIM takes effect. I'm just telling you what I've been told. Again, >I think we're moving on just to avoid the mess altogether. Someone with the >official word please set me straight if I'm incorrect. > >GK > > > > I dunno, I followed their instructions in the aim docs. I didn't dive > > too far into all the documentation. If you know something I don't..... > > > > as far as the password is concerned its not necessary but it doesn't > > fail with it. I am not sure if the client had the required password > > feature turned on. > > > > On Wednesday, March 5, 2003, at 06:00 PM, Gary Krockover wrote: > > > > > Isn't this just a relay response method that is being sent via a > > > TCPConnect? > > > If so, the relay response method is being phased out come April. > > > > > > The new AIM/SIM method will require a x_Tran_Key value (which I don't > > > see on > > > your example) which is a value obtained by the merchant interface and > > > then > > > returned back to the payment processor as a form of authentication. > > > Also, > > > it is my understanding that passing the x_password value will no > > > longer be > > > accepted in AIM/SIM. > > > > > > I very well could be entirely wrong about this, but instead of the > > > nightmare > > > that I forsee this thing causing, I think we've decided to move over to > > > Verisign PayFlowPro. > > > > Robert Minor > > Director of Internet Services---------------------------------------- Velma Kahn Glory Day Software Company 200 Tanager Ln NW, Floyd, Virginia 24091, U.S.A. phone: 540-745-6469 * fax: 651-321-4884 email: vkahn@glorydaysoftware.com http://www.glorydaysoftware.com http://www.communitymade.com http://www.floydcrafts.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Velma Kahn

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

[WebDNA] A new popuated field to a DB with 700.000 records (2009) What is WebDNA (1997) Signal Raised (1997) [WebDNA] On click show hidden include (2009) Sorting Numbers (1997) categories (1997) WebCommerce: Folder organization ? (1997) Location of Browser Info.txt file (1997) [WebDNA] Apply discount using a line item (2011) PIXO support (1997) Error: Too many nested [xxx] contexts (1997) WYSIWYG HTML editor for use in browser (2001) RE: WebCat: Access denied, but why? - The solution. (1997) Exclude by date - multiple (1997) PCS Frames (1997) InSecureTextVariables.... (2000) Paths, relative paths, webstar server setup and security (Mac) (1997) PCS Frames (1997) Running 2 two WebCatalog.acgi's (1996) Formulas.db + Users.db (1997)