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

Bug #3854 Payment_Process_Result_AuthorizeNet doesn't map echoed fields
Submitted: 2005-03-16 23:22 UTC
From: jausions Assigned: jstump
Status: Bogus 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 - 1 = ?

 
 [2005-03-16 23:22 UTC] jausions
Description: ------------ The Payment_Process_Result_AuthorizeNet doesn't map the echoed fields into class members. Why is this important? It allows to do an integrity check on the response from the gateway. Also, in case of an asynchronous push notification from the payment gateway it allows the script receiving the call to have the data it may not have available anywhere else otherwise. Also see bug #3815. Reproduce code: --------------- In Payment_Process_Result_AuthorizeNet: <?php var $_fieldMap = array('0' => 'code', '2' => 'messageCode', '3' => 'message', '4' => 'approvalCode', '5' => 'avsCode', '6' => 'transactionId', '7' => 'invoiceNumber', '8' => 'description', '9' => 'amount', '11' => 'action', '12' => 'customerId', '13' => 'firstName', '14' => 'lastName', '15' => 'company', '16' => 'address', '17' => 'city', '18' => 'state', '19' => 'postalCode', '20' => 'country', '21' => 'phone', '23' => 'email', '37' => 'md5Hash', '38' => 'cvvCode' ); ?> This is not all of it, but it's a start... -Philippe

Comments

 [2005-03-23 17:54 UTC] jstump
I agree these fields should be returned, but we need to be careful to keep the API "clean". Possibly we should create an array in Payment_Process_Result to store an array of "extra" variables. The reason I say this is because we are trying *very* hard to keep the API the same across all gateways. What you're asking for here is for us to implement a gateway specific field. I'm not opposed, I just think we need to take a step back and figure out how to best approach this. I'm thinking a private array $_extra and then in the Payment_Process_Result class have a get('md5Hash') or something like that. Thoughts?
 [2005-03-23 18:46 UTC] jausions
This is the usual problem of abstraction and making things common across all backends... leveling by the bottom... Normally the information contained in the response should be stored somewhere else by the application... so I don't have a problem dumping some fields. However for the Authorize.Net we need to retrieve the MD5 hash value to check the legitimacy of the response. Maybe the solution is simply to keep the parsed result into a private member of the Payment_Process_Result object and then the extra info can be accessed this way. We could even simply keep a $this->_parsed['md5Hash'] only instead of the whole parsed thing to save some memory. I would also suggest to keep $this->_parsed['amount'] to make sure the formatting of the value is the one actually used during the computation of the MD5 hash. I used "_fieldMap" since it gave me instant registration of the md5Hash member. But again not need to be public members either... I think this would indeed be a cleaner solution. -Philippe
 [2005-03-23 19:15 UTC] jstump
Thank you for taking the time to write to us, but this is not a bug. Again, our framework isn't meant to "do it all", but rather compromise on a static set of features available to all of the gateways we support. We do, however, agree that "non-standardized" data in result sets should be made available to the user code. If you have a patch that cleanly allows developers to access the _rawResponse in an appropriate way that doesn't negatively impact other drivers we're all ears. For now you could simply grab $result->_rawResponse.