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

Request #2756 Field Encapsulation Character Support
Submitted: 2004-11-15 10:38 UTC Modified: 2005-07-07 17:57 UTC
From: josh at trutwins dot homeip dot net Assigned: jstump
Status: Closed Package: Payment_Process
PHP Version: 4.3.9 OS: Linux Debian Stable
Roadmaps: (Not assigned)    
Subscription  


 [2004-11-15 10:38 UTC] josh at trutwins dot homeip dot net
Description: ------------ Authorize.NET recommends that a user enable a Field Encapsulation Character so the response is not only delmitted by commas, but in the event of a comma being in one of the return fields it is encapsulted, for example: [_rawResponse] => |2|,|2|,|45|,|This transaction has been declined.|,|005191|,|A|,|710881561|,|1123451458|,||,|1.00|,|CC|,|auth_only|,|1461264151|,|Joshua|,|D Trutwin|,||,|4342 Fake St N|,|Metropolis|,|NY|,|10101|,|US|,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,|E508DF8E048CC23DD95AA1E629A21708|,|N|,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,||,|"x_delim_data" I was able to add support for this by modifying the Payment_Process_AuthorizeNet parse method: function parse() { $responseArray = explode(',',$this->_rawResponse); for($i = 0; $i < count($responseArray); $i++) { $responseArray[$i] = preg_replace("/^\|(.*)\|$/","\\1",$responseArray[$i]); } $this->_mapFields($responseArray); }

Comments

 [2004-11-15 10:45 UTC] josh at trutwins dot homeip dot net
Of course this would be configurable as there are more things you can use for a Field Encapsulation Character besides a pipe...
 [2005-03-12 11:35 UTC] jausions
Josh, Your fix is not quite right... you would first need to explode('|,|') and not simply explode(',') which doesn't resolve the problem of field containing a comma. I'll look more in detail in the AuthorizeNet about the encapsulation character and possibly submit a patch... -Philippe
 [2005-03-15 12:34 UTC] josh at trutwins dot homeip dot net
I'm not sure why but for some reason explode("|,|", $this->_rawResponse) caused odd behavior. I'm leaving it alone for now, if you implement a patch I'd be more than happy to test it out. Josh
 [2005-03-16 03:26 UTC] jausions
Here's the fix for Payment_Process_Response_AuthorizeNet::parse() <?php function parse() { $delim = $this->_request->getOption('x_delim_char'); $encap = $this->_request->getOption('x_encap_char'); $responseArray = explode($encap . $delim . $encap, $this->_rawResponse); $count = count($responseArray) - 1; $responseArray[0] = ltrim($responseArray[0], $encap); $responseArray[$count] = rtrim($responseArray[$count], $encap); $this->_mapFields($responseArray); } ?> This assumes that x_encap_char and x_delim_char have been set in the options. furthermore, this also assumes that x_encap_char doesn't appear in any of the data sent to the payment gateway (because it is echoed back) If you dynamically assign the x_encap_char there may be a problem when the payment gateway does an asynchronous POST notification (for instance after a review of an order.) It will probably format the "raw" response using settings set in the account control panel. But even if the response is formatted using the x_encap_char set during the initial call, your script at that time will not remember which one was used. In that case, the parse() method will need to do some guessing on the x_delim_char and x_encap_char... -Philippe
 [2005-03-23 13:06 UTC] jstump
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. I've used Phillipe's patch and set default options to ',' and '' for x_delim_char and x_encap_char respectively.
 [2005-03-24 00:04 UTC] jausions
Joe, For peace of mind, and robustess, you shouldn't default x_encap_char to blank. This was the reason why the bug was opened in the first place. By the way, I spotted a potential problem with rtrim() and ltrim(). So here's a corrected version. Note that due to the reported bug #3815 about MD5 support and bug #3936 about DUPLICATE/FRAUD result code this is not the definitive parse() method. I also have some other code for _prepareQueryStrin() to find an appropriate x_encap_char in case the one set in the options is present in the values. This way the raw response will always be properly parsed. <?php /** * Parses the data received from the payment gateway * * @access public * @author Philippe Jausions <Philippe.Jausions@11abacus.com> */ function parse() { $delim = $this->_request->getOption('x_delim_char'); $encap = $this->_request->getOption('x_encap_char'); $responseArray = explode($encap . $delim . $encap, $this->_rawResponse); if ($responseArray === false) { return array(); } $count = count($responseArray) - 1; if ($responseArray[0]{0} == $encap) { $responseArray[0] = substr($responseArray[0], 1); } if (substr($responseArray[$count], -1) == $encap) { $responseArray[$count] = substr($responseArray[$count], 0, -1); } $this->_mapFields($responseArray); } ?>
 [2005-06-23 09:24 UTC] jausions
Please use: http://www.11abacus.com/cvs/pear/Payment_Process.jausions.patch to correct this bug. -Philippe
 [2005-07-07 17:57 UTC] jstump
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better.