Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.6.8

Bug #3792 AuthorizeNet::_handleName()'s dangerous assumption
Submitted: 2005-03-12 16:17 UTC
From: jausions Assigned: jstump
Status: Wont fix Package: Payment_Process
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 36 + 11 = ?

 
 [2005-03-12 16:17 UTC] jausions
Description: ------------ The private method AuthorizeNet::_handleName() assumes the name is set as "firstName lastName" in the "name" property. This will easily break on first names that have spaces in them. I'll look deeper in the code for a better understanding of the "name" property but the assumption above is plain dangerous. I'll post a fix when I have one. -Philippe

Comments

 [2005-03-23 17:40 UTC] jstump
I wouldn't exactly call this "dangerous". How common are two word first names and how would you possibly know which words comprise a first name and which ones make up the last name? eg. How would you decipher the following: Joseph C. Stump Joseph Carl Stump Mary Kate Olsen I think the real problem here is the AN asks for them as two fields instead of one. Have you seen AN fail on names not broken up properly? I guess I always assumed that AN was imploding f/lnames into a single string on their end. Might be worth an inquiry.
 [2005-03-23 18:27 UTC] jausions
I see your point, and I know it's confusing from AuthorizeNet to ask for first and last names, when usually for a credit card, the customer is asked to put the name as printed on the credit card... Yes, probably will have to ask Authorize.Net some clarification on that... -Philippe
 [2005-03-28 17:38 UTC] jausions
I am now using Payment_Process in production... This name split is not that dramatic of a problem with credit cards, but it could be with eCheck. Since we are not accepting eCheck at this moment, I can't tell you if this is a real issue. However, the name split on first space does cause some minor trouble when looking up transaction information on the Authorize.Net control panel. Case in point is people's who have their middle initial in their credit card name: i.e. John B Doe. An invoice administrator would have to look up the last name as "B Doe" which is counter-intuitive. All this being said, I am not sure if there is a 100% good solution to this problem. To be continued... -Philippe
 [2005-07-07 21:20 UTC] jstump
Philippe, I've looked this over and decided that, as of now, there's nothing we can do about this. I've used AuthorizeNet in production since it came out for both eCheck and credit cards and haven't had any complaints from our invoice people here. I can see your point, but as we both agree it's difficult to implement a fix for this (we can thank Authorize.net for this). It's also interesting to note that AN doesn't even require a person's name according to their docs for a "minimum cc transaction via AIM".
 [2006-01-30 07:22 UTC] trav at mac dot com
Most merchants prompt their users for a single text value: "Cardholder name". How do merchants typically split this value into first and last name before submitting to AN?