Geographic area Paypal problem

[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.

[DrByte]

What i did also try was a purchase whilst logged in and a purchase whilst not logged in.
When i was not logged it processed the payment at paypal returned to the site then logged me in automatically and i completed the order, but if i logged in and tried it it failed again.

any help?

malc

Did my comment about being logged in or not mean anything to you DrByte?

malc

Somehow I missed replying to this. I do have a question in relation to this. When that happened, was the (primary/selected) address in your store's customer account, while logged in, the same as the address you selected after being redirected to PayPal and then getting the "geographic area" error?
I'd be interested in seeing logs for both the logged-in and not-logged-in scenarios when using the same address in all cases.
(You sent me some logs previously, but I've deleted them ... In the interest of your privacy I don't keep them around very long.)

[DrByte]

Another change which will at least help with some debugging if nothing else is the following very safe change, at line 212 in the same file, replace this:

      if (!$check_flag) {
        $this->enabled = false;
      }

      // module cannot be used for purchase > $10,000 USD
      $order_amount = $this->calc_order_amount($order->info['total'], 'USD');
      if ($order_amount > 10000) $this->enabled = false;
      if ($order->info['total'] == 0) $this->enabled = false;
    }
  }
  /**

with this:

      if (!$check_flag) {
        $this->enabled = false;
        $this->zcLog('update_status', 'Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings.');
      }

      // module cannot be used for purchase > $10,000 USD
      $order_amount = $this->calc_order_amount($order->info['total'], 'USD');
      if ($order_amount > 10000) {
        $this->enabled = false;
        $this->zcLog('update_status', 'Module disabled because purchase price (' . $order_amount . ') exceeds PayPal-imposed maximum limit of 10,000 USD.');
      }
      if ($order->info['total'] == 0) {
        $this->enabled = false;
        $this->zcLog('update_status', 'Module disabled because purchase amount is set to 0.00.' . "\n" . print_r($order, true));
      }
    }
  }
  /**

[malc]

Thank you Dr Byte for your reply.

I will carry out the tasks above but as i have gone live i am bit reluctant to mess with it whilst it works albeit on IPN.

I will at some point want to switch to express do when i get brave enough i will take offline an do some tests.

thank you

[DrByte]

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

Ha! Try changing that line to this:

    $order->info['total'] = urldecode($response['AMT']);

Evidently PayPal's encoding approach is different depending which engine is processing the transaction.
This code change should stop that issue for people who haven't created additional problems by renaming their zones/countries, because there's actually a secondary reason for the "geographic region" message appearing: if the order amount is invalid (either "0" or higher than PayPal's imposed limits) then the module gets disabled (because PayPal won't let you buy 0.00 of something, since that's pointless).

[Mega Moonshine]

We are aware of this logging issue, and have fixed it for the next version.
It is caused by a (relatively rare) server configuration where the lack of certain dependencies causes logging to engage despite it being turned off. We're removing those dependencies in the next version to allow for much broader compatibility.
You can purge those logs yourself using your FTP program.
Or, IIRC there's an option in the Admin->Tools->Store Manager to purge those logs too.

Sorry for the long delay on getting back regarding the above reply... (Surgery sucks! Especially Frontal Labotomies. )

Any chance you can PM me the portion of the fix for this due in the next release (so I can test it for you... ) and/or specify the rare condition so I can take a look at my server to see what I need to change so as to not need the fix?

Thanks!

[Paradave]

DrByte: Thanks! I came here for the same nightmarish issue. Just wanted to confirm that your last fix solved the problem completely.

[jbsaxman]

DrByte,

I tried your fix but it was no go. I'm at a loss as to the root cause of this, but it's effecting a few users who are trying to order.

To give you as much info as i can, here is what the email log is showing me:

(Note: IP address has been modified to protect end user)

paypalwpp
Redirecting to shopping_cart - Stack: shopping_cart
Message: 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.
Session Data: Array
(
    [securityToken] => deeb563cc9a5868327414060b1c4107b
    [customers_host_address] => 70-90-165-x-sfba.hfc.comcastbusiness.net
    [cartID] => 11988
    [cart] => shoppingCart Object
        (
            [contents] => Array
                (
                    [3] => Array
                        (
                            [qty] => 1
                        )

                )

            [total] => 275
            [weight] => 3
            [cartID] => 11988
            [content_type] => physical
            [free_shipping_item] => 0
            [free_shipping_weight] => 0
            [free_shipping_price] => 0
        )

    [navigation] => navigationHistory Object
        (
            [path] => Array
                (
                    [0] => Array
                        (
                            [page] => index
                            [mode] => NONSSL
                            [get] => Array
                                (
                                    [type] => ec
                                    [token] => EC-0C681369SJ709723L
                                    [PayerID] => XUFYWGJ6BXRKW
                                )

                            [post] => Array
                                (
                                )

                        )

                )

            [snapshot] => Array
                (
                )

        )

    [check_valid] => true
    [language] => english
    [languages_id] => 1
    [languages_code] => en
    [currency] => USD
    [today_is] => 2011-08-10
    [updateExpirations] => 1
    [session_counter] => 1
    [customers_ip_address] => 70.90.165.x
    [customer_id] => 15
    [customer_default_address_id] => 22
    [customers_authorization] => 0
    [customer_first_name] => Tom
    [customer_last_name] => Woodruff
    [customer_country_id] => 223
    [customer_zone_id] => 12
    [valid_to_checkout] => 1
    [cart_errors] =>
    [sendto] => 22
    [payment] => paypalwpp
    [shipping] => Array
        (
            [id] => usps_PARCEL
            [title] => United States Postal Service (1 x 3.00lbs) (Parcel
Post (4 - 7 days))
            [cost] => 14.48
        )

    [billto] => 22
    [cot_gv] => 0
    [comments] =>
    [messageToStack] => Array
        (
            [0] => Array
                (
                    [class] => shopping_cart
                    [text] => 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.
                    [type] => error
                )

        )

)

I modified the paypalwpp as follows:

// set total temporarily based on amount returned from PayPal, so validations continue to work properly
    global $order;
    //$order->info['total'] = $response['AMT'];
    $order->info['total'] = urldecode($response['AMT']);
    //$this->zcLog('ec_step2 - processed info', print_r(array_merge($step2_payerinfo, $step2_shipto), true));

What else can I provide you that would be beneficial?