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); }

Of course this would be configurable as there are more things you can use for a Field Encapsulation Character besides a pipe...

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

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

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

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.

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); } ?>

Please use: http://www.11abacus.com/cvs/pear/Payment_Process.jausions.patch to correct this bug. -Philippe

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.