[ic] FW: Authorize.net Zip Code Bug Report

[interchange-users@interchange.redhat.com (Kevin Walsh)]

> 
> I've never run across this in my searches through the archives for
> authorize.net issues, so I thought I'd post it.  Maybe it'll prove
> helpful.
> 
> A client of mine was experiencing problems with AVS under Authorize.net
> using the (very handy) globalsub that ships with Interchange.  Orders
> were being sporadically rejected because the address information didn't
> match.  Most often, these orders had different shipping and billing
> addresses, but even in these cases, the orders weren't always rejected.
> (We ran tests with accounts that we knew were good and with address
> information meticulously typed in.)  We finally figured out that the
> issue only arose when the zip codes in the shipping and billing info
> blanks were different.  
> 
> I added some code to the globalsub that logged the query string posted
> to Authorize.net, and sure enough, it was always the billing information
> that was being submitted to the payment gateway.  If the zip codes were
> the same, this wasn't an issue and the transaction would fail.  If the
> zip codes were different, the shipping zip was being passed with the
> billing info and the AVS failed the transaction.  There's code in
> Order.pm that checks for fields starting with "b_" and, if they contain
> values, passes those instead of the shipping fields to Authorize.net.
> It turns out that in the Authorize.net module, the hash that lists which
> field names to pass listed "zip" rather than "b_zip," though it listed
> the other address fields with the preceding "b_."  When I changed this
> hash element appropriately and submitted a test transaction that had
> previously failed, the problem was solved.  My logging also reflected
> the change.
> 
> I checked an unmodified distribution of Interchange, and it looks like
> the globalsub that's shipped with Interchange contains the bad hash
> element.  Maybe I just got a bad distribution.  At any rate, I thought
> I'd mention it in case anybody else was having similar problems.
> 
Thanks for reporting it.  The 'b_zip' is correct in the AuthorizeNet.pm
module but incorrect in the globalsub.  It probably hadn't been noticed
because people are expected to use the payment modules rather than the
globalsubs.

I think the globalsubs are unsupported anyway.  In any case, it's fixed
in CVS now.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin@cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/