I just upgraded to 2.2.5 and now I am getting “AVS verification response: Five-digit ZIP code (no Address)” on several of my orders. With the 2.2.5 upgrade I see that a new AVS error code was added to paypal_pro.php, but I don’t see how that change could affect the AVS response that I am getting.
Is anyone else using PayPal Pro and getting the Five-digit ZIP code error?
Anyone know what I need to do to fix this?
From talking with PayPal, it seems the upgrade changed the information passed to the processor and it is in longer passing the address. It is now only passing the city, state, zip, and country code. Does anyone know how to correct the code to have it also pass the address?
I am getting this problem too so I am sure it is a problem for everyone using Paypal Pro and 2.2.5 …
Have you put in a bug report?
Actually I just seen you did put in a bug report… and the response of 'We see nothing wrong so pay us to fix the problem for you.'.
Did you get this problem fixed Golfcart?
Guys, we are currently running 2.2.5 w/ Paypal Pro & Paypal Express
AVS details from order taken 5 minutes ago = AVS verification response: Address and five-digit ZIP
When you see an AVS response of “Five-digit ZIP code (no Address)” Paypal is telling you that Only the Zip Code matched, the remaining portion of the customers bill to address did not match. This is a common occurence and is not typically an issue to be concerned over unless you sell products with a high level of fraudulent transactions. You can also fine tune your AVS control through your Paypal admin to determine just how precise you want your AVS matching before transactions are declined. 
Had this same issue a few days ago, it occurs because CS-Cart is encoding the data but paypal is not decoding it, which leads to “%20” instead of spaces when the address is sent to PayPal. This leads to AVS failing because the address is not “123%20Any%20Street” it is “123 Any Street”.
If you login to paypal and check the transaction, the shipping address should have the %20 instead of a whitespace.
I was able to fix the issue by modifying the 'paypal_pro.php" under payments:
On line 134, you should see:
“array_walk_recursive($order_info, 'fn_paypal_rawurlencode');”
Change that to:
“array_walk_recursive($order_info);”
I tried that and it worked for me, AVS is back to working like it should be.
I am running CS-Cart 3 ultimate but it should not make a difference.
sarinp04's fix works but needs a slight tweak:
Just comment out the line. Calling [color=#282828][font=arial, verdana, tahoma, sans-serif]array_walk_recursive without a function gives a PHP warning on the temporary checkout page users will see while their card processes.[/font][/color]
I upgraded to 2.2.5 yesterday from 2.2.4, and all my orders processed with Paypal Payflow Pro were poorly encoded. All the addresses, etc have %20 in them (which is an un-encoded string, %20 should be a space)
Additionally, all the buyer's emails are malformed in paypal. Using stamps.com I was able to quickly see since every shipment I imported had “i[color=#000000][font=Arial, Helvetica, sans-serif][size=3]nvalid_email_supplied@PayPal.com” as the email address."[/size][/font][/color]
[color=#000000][font=Arial, Helvetica, sans-serif][size=3]The [/size][/font][/color]fn_paypal_rawurlencode function in cscart is just rawurlencode() the whole order, which is not needed for Paypal Pro.
Everything works on cscarts end, but in Paypal's end AVS will fail, and if you do not import your orders from Paypal into a shipment manager like stamps.com you would never notice.
The only difference between the paypal_pro.php file (from version 2.1.4 and 2.2.5) is:
This function was added:
array_walk_recursive($order_info, 'fn_paypal_rawurlencode');
(Plus the actual function code at the bottom of the file)
And this line was added (under the “$processor_error['avs'] = array(” lines):
“M” => “Address and Postal Code”,
But this has nothing to do with the error.
So it looks like mizzer is right with just comment it out. Then it will never call the function.
-Tim
After one day, commenting out the function works fine…finally and i do not know why I waited so long to fix. I guess I was waiting for CS-Cart to fix the bug but I suppose they are too involved with the 3.x version now.