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

John Beima interchange-users@interchange.redhat.com
Sat Apr 27 14:40:01 2002


G'Day Kevin,


Given the findings below and your responce, should that also not mean that the
"address" then be updated to "b_address" as well in both the globalsub and the
Payment module???

Also it DOES need to be mentioned that Interchange in NO WAY SHAPE OR FORM,
supports AVS... These fixes don't solve that, then just fix some bad data being
handed to the AuthorizeNet...


John Beima
jbeima@palb.com, support@alocalagent.com, and support@alocalchurch.com

P.A.L.B. Systems - Phone: (780)451-1086 - Fax: (780)447-4760
11639-122 Street, Edmonton, Alberta, Canada, T5M 0B6

Affordable Web Pages - Phone: (888)932-9990 - Fax: (256)351-7297
2713B Spring Place SW, Decatur, Alabama, United States, 35603



Quoting Kevin Walsh <kevin@cursor.biz>:

> > 
> > 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
> _/   _/  _/_/_/_/      _/    _/_/_/  _/    _/
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com
> http://interchange.redhat.com/mailman/listinfo/interchange-users
> 


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/