Geographic area Paypal problem

[bluedye]

PayPal Express Checkout (rev1.3.9h), getting this error on 99% of checkouts, with seemingly random successful orders mixed in:

We are sorry for the inconvenience; however, at the present time we are unable to use PayPal to process orders from the geographic region you selected as your PayPal address. Please continue using normal checkout and select from the available payment methods to complete your order.

My full address is correctly showing in the ...action.log

I swear i have looked and looked through all of the forum and on other sites that mention the same problem, mostly from last year.

I am using v1.3.9h, and every time i see a solution i a post, i get excited. When I go to apply it, it's already been applied in this version.

Fixes I found, but were already there:
- Shipping/payment zones in admin are all set to "none"
- line 1685 or something, in paypalwpp.php: (from http://www.zen-cart.com/forum/showthread.php?t=155664 )

    global $order;
    $order->info['total'] = $response['AMT'];

...and one or two others that i can't find now.


Some of the log, but with details changed:
[payer_lastname] => testerson
[payer_business] =>
[payer_status] => verified
[ship_country_code] => US
[ship_address_status] => Confirmed
[ship_phone] =>
[order_comment] =>
[ship_name] => test testerson
[ship_street_1] => 6111 Testy Circle
[ship_street_2] =>
[ship_city] => Lakeland
[ship_state] => FL
[ship_postal_code] => 33803
[ship_country_name] => United States

This is a new install, straight to v1.3.9h.

I guess that's all i can mention... help?

[DrByte]

That typically happens when you have zone restrictions applied to your PayPal modules, and the customer is attempting to do checkout using an address that's not within the zone assigned to the module.

[bluedye]

Thanks for the reply!

That's what i've read, but i can't figure out why there would be a mismatch. Cart has every country enabled still, including US, and all addresses tested have been US too.

Is there something else it could be? Like the value being dropped somewhere along the line?

[bluedye]

...All shipping/payment zones are set to none, except for tax.

[DrByte]

I would need to see detailed PP debug logs to see what's exactly the cause. Most likely some unacceptable address translation by mixing countries.

Turn on logging as described here: http://www.zen-cart.com/forum/showthread.php?t=61199
Then recreate the problem.
Then download and zip the log files, and upload the zip to someplace on your server, and then PM me with the URL to the file so I can access them.

[malc]

Hi DrByte

Can i send you a link for the same problem, i too have read as many threads as i can, checked and double checked the settings but i do not seem to be getting anywhere.

regards
malc

[chriswillows]

The error: "We are sorry for the inconvenience; however, at the present time we are unable to use PayPal to process orders from the geographic region you selected as your PayPal address. Please continue using normal checkout and select from the available payment methods to complete your order."

comes from /include/payment/paypalwbb.php

line:

$sql = $db->bindVars($sql, ':countryId', $address_question_arr['country']['title'], 'string');

triggering this mySQL query:

SELECT countries_id, address_format_id
FROM zen_countries
WHERE countries_iso_code_2 = 'United Kingdom'
OR countries_name = 'United Kingdom'
LIMIT 1

should be:

$sql = $db->bindVars($sql, ':countryId', $address_question_arr['country']['iso_code_2'], 'string');

It should use the ISO code, a lot safer than a country title!
In our case we were using "England", "Wales", etc as countries into Zen Cart~ not "United Kingdom" as a whole. This prevent flexibility in the countries' management.

A lot of people had this issue over the past few months, as per my post here.

Hoping you will include it in the next release....

[DrByte]

It should use the ISO code, a lot safer than a country title!

I understand what you're saying, and agree. But you should be telling PayPal that. See comments below for further clarification.

In our case we were using "England", "Wales", etc as countries into Zen Cart~ not "United Kingdom" as a whole. This prevent flexibility in the countries' management.

Well, your renamed countries will certainly be a partial cause of problems, and would require your posted code alteration to accommodate that renaming of countries. It's naturally much safer to use official names (ie: "United Kingdom"), not renaming them to something inaccurate like a principality (ie: "Wales").

Zen Cart is simply doing a lookup based on a match of either the ISO code or the country name, in order to accommodate the fact that PayPal sends the data back in multiple ways (ie: PayPal sometimes sends an ISO code, and sometimes sends an (official ISO) country name.) PayPal sends back their responses in different ways depending on which "engine" they're using (US vs UK vs CA/AU, rest of world, etc) and which "product" they're using (Std, EC, Pro, Payflow, etc). The bit of code you quoted is part of a section of lookup code that's attempting those matches.

That said, you've indirectly pointed out an inconsistency in the lookup activity which we'll address in a future version. This may or may not resolve your unique problem of renamed countries.

In looking at your proposed "fix", I can see how it would provide relief for your specific symptoms, especially if you don't have a "United Kingdom" country in your store to match up with PayPal's response.

While one of the others reporting the same error message has stated that they're using a British postcode addon, several are US merchants who are much less likely to have edited the country name "United States" to say something else. So, I would be very surprised if your proposed "fix" would solve their problem at all.

Further, when reviewing wizer's logs I discovered a problem with the $order object's contents which was occurring way before the section of code your proposed "fix" would even fire, so that's not the magic answer either.

A proper complete solution needs to address all these other cases, not just your renamed-country case. That said, if you have eyes to spot the actual real root cause, the input is welcome.


Remember also that an incorrectly defined Zone Definition applied to the payment module will specifically trigger the "geographic area" error, since that's the specific intended purpose of that feature: if the customer's address falls outside the selected zone's definition, the module prevents itself from being used.

[wizer]

I had to pay someone on oDesk to fix it for me in the end. Not sure what he did, but it's working again. V.Frustrating

[DrByte]

As follow-up, according to wizer, the person who fixed his site also saw the problem I mentioned about the $order object, and applied a bandage which appears to be allowing it to work. (They did some other things too, related to zones.) However, the selected bandage doesn't directly fix the specific root cause, and is not a full fix suitable for inclusion in core code.

However, further testing suggests that a little broader approach may be quite reliable. For those interested in experimenting with the idea, read on:

bluedye's first post in this thread mentioned two lines of code at line 1685. If you replace those 2 lines with the following it may provide the symptomatic relief wizer is experiencing:

    global $order, $order_totals;
    if (!isset($order) || !isset($order->info) || !is_array($order->info) || !zen_not_null($order)) {
      $this->zcLog('ec_step2 ', 'Re-instantiating $order object.');
      // init new order object
      if (!class_exists('order')) require(DIR_WS_CLASSES . 'order.php');
      $order = new order;

      // load the selected shipping module so that shipping taxes can be assessed
      if (!class_exists('shipping')) require(DIR_WS_CLASSES . 'shipping.php');
      $shipping_modules = new shipping($_SESSION['shipping']);

      // load OT modules so that discounts and taxes can be assessed
      if (!class_exists('order_total')) require(DIR_WS_CLASSES . 'order_total.php');
      $order_total_modules = new order_total;
      $order_totals = $order_total_modules->pre_confirmation_check();
      $order_totals = $order_total_modules->process();
      $this->zcLog('ec_step2 ', 'Instantiated $order object contents: ' . print_r($order, true));
    }
    $order->info['total'] = $response['AMT'];

I advise that you use caution and be prepared to back it out if your testing (which you should do immediately after you make the change) doesn't produce the desired results.

If you do try it, please send me the debug logs from your testing, via PM. Thanks.