Module disabled due to zone restriction.

This question was on the zen cart Braintree Payment Gateway support thread because it showed up after I started using the Braintree Payment gateway some weeks ago but I moved the question here because I asked Braintree and they claim it is not their problem!

I am using ZC155d, green classic responsive template

I had three Swiss customers rejected by PayPal during the payment process "due to zone restriction".

I tried ordering myself via PayPal on my live site using my Swiss details and it worked OK.

I have selected the same payment zone for Braintree as I used successfully for several years with the built in Paypal express module, the payment zone includes Switzerland and all the West Europe countries

Here is a typical zen cart log message;

Sep-02-2017 23:20:54 (1504387254)
update_status
Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings.

Anybody know where does this 150xxxx number come from? Is it a PayPal number and can I trace it somehow?

First time today I saw a PHP warning

[05-Sep-2017 15:54:05 Europe/Zurich] Request URI: /catalog/[admin]/orders.php?page=1&oID=1238&action=edit, IP address: xx.xx.xx.xx
#1  braintree_api->update_status() called at [/home/httpd/vhosts/simmar.ch/httpdocs/catalog/includes/modules/payment/braintree_api.php:83]
#2  braintree_api->braintree_api() called at [/home/httpd/vhosts/simmar.ch/httpdocs/catalog/[admin]/orders.php:427]

[05-Sep-2017 15:54:05 Europe/Zurich] PHP Warning:  Illegal string offset 'id' in /home/httpd/vhosts/simmar.ch/httpdocs/catalog/includes/modules/payment/braintree_api.php on line 132

The PHP code around line 132 is

  $sql = $db->bindVars($sql, ':zoneId', $this->zone, 'integer');
            $sql = $db->bindVars($sql, ':countryId', $order->billing['country']['id'], 'integer');
            $check = $db->Execute($sql);

Thanks for any ideas

The number: 1504387254 is the Unix timestamp value of the record. It doesn't provide any real further information other than that the server's date is 9 hours ahead of that date value (returns Sep-02-2017 14:20:54) when using:

echo date("M-d-Y G:i:s", 1504387254);

mc12345678:

The number: 1504387254 is the Unix timestamp value of the record. It doesn't provide any real further information other than that the server's date is 9 hours ahead of that date value (returns Sep-02-2017 14:20:54) when using:

echo date("M-d-Y G:i:s", 1504387254);

Thanks, there goes my wish of tracking the error somehow :(

I thought "Illegal string offset 'id'" was fixed in V155d :(

I am using PHP5.6.31

marton_1:

Thanks, there goes my wish of tracking the error somehow :(

I thought "Illegal string offset 'id'" was fixed in V155d :(

I am using PHP5.6.31

That error can occur anywhere for any expected array. The question becomes how is the $billing variable declared/incorporated in this plugin and further what does the order class code look like/how has it been modified from a stock install?

Besides that, even if there was an issue fixed in the core code, that doesn't mean that something like this plugin was also fixed.

Sorry for that news though about the time stamp. I would guess that if you could get access to your server logs, you might be able to figure something out.

Another PayPal customer rejected today with the log message
"Sep-07-2017 16:01:09 (1504792869)
update_status
Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings."

I have PayPal Express set as
"Debug Mode
Log and Email"

There were no PayPal log messages or emails after the log message about the zone.

Then I tried a test ordering myself with my test user and it worked correctly even though there was the log message
"Sep-07-2017 20:25:17 (1504808717)
update_status
Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings."

After that update_status there was a whole string of PayPal log messages and finally "PayPal Debug log - DoExpressCheckoutPayment".

As the test user I did not see anything different or unusual; no user visible message about zones.

Then I tried a test by creating a new test user and it worked correctly even though again there was the log message
"Sep-07-2017 21:26:48 (1504812408)
update_status
Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings."

After that update_status there was a whole string of usual PayPal log messages.

As I posted at the start the customer error message was logged at Sep-07-2017 16:01:09

I attach a picture of a spreadsheet with the server logs around that date/time, there was nothing in the server error log!

Any help appreciated; this is driving me nuts :(

Another PayPal customer rejected today with the log message

Sep-08-2017 11:11:14 (1504861874)
update_status
Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings.

The zone setting in the Braintree Gateway I am using looks like this.


The zone setting in the zen cart built in Paypal Express Gateway I have been happily using for years looks like this.


I am in a catch 22, when I use the Paypal Express Gateway I lose credit card customers who do not want to open a Paypal account. :cry:
When I use the Braintree gateway then Paypal customers are rejected. :cry:

I have Braintree Gateway and Paypal express running in debug mode but not helping me to research the problem.
Is there any other tool I could use?

I haven't looked at the braintree module to know the below:

So the braintree module... it accepts other methods of payment AND paypal?

The issue appears to be with the braintree module specifically if I understand the operation(s) as discussed above that paypal functions fine, but paypal through braintree does not and that the issue occurs in the update_status function where it appears that there is insufficient information for the module to address zones when that function is called.

Perhaps providing the content of the braintree version of the update_status function may shed some light, but also would want to look at where in the code that same function is called to verify that the data needed/sought has been made available for it to work on it.

Then again, perhaps this should all be taken to a thread intended for discussion of the braintree module...

mc12345678:

I haven't looked at the braintree module to know the below:

So the braintree module... it accepts other methods of payment AND paypal?

The issue appears to be with the braintree module specifically if I understand the operation(s) as discussed above that paypal functions fine, but paypal through braintree does not and that the issue occurs in the update_status function where it appears that there is insufficient information for the module to address zones when that function is called.

Perhaps providing the content of the braintree version of the update_status function may shed some light, but also would want to look at where in the code that same function is called to verify that the data needed/sought has been made available for it to work on it.

Then again, perhaps this should all be taken to a thread intended for discussion of the braintree module...

Thanks for your time, I appreciate it.

I did originally post this on the Braintree module support thread here but nobody ever replied :(

Possibly my bad but desperate times call for desperate measures :)

The message "Module disabled due to zone restriction. Billing address is not within the Payment Zone selected in the module settings." could be coming from many places:
- PayPal Express Checkout
- PayPal Payments Pro
- Braintree plugin

You said "after seeing that in the log, there were a bunch of paypal logs, ending with DoExpressCheckoutPayment".

That basically means:
- one of the modules disabled itself due to zone restrictions
- and then one of the remaining available modules was PayPal Express Checkout, which the customer finally used for payment.

That's quite normal. Especially if the shopper's payment address was indeed outside the configured zone.

I don't have a Braintree account let alone a site set up with the module.

But, it would be helpful to know exactly how to recreate your exact situation on a new store:
- how to create the zone configuration affecting these transactions
- an actual billing address that would trigger the problem

Perhaps there's a combination in there that will expose a solution. Often zone-mismatches are a result of unexpected assumptions.

DrByte:

I don't have a Braintree account let alone a site set up with the module.

But, it would be helpful to know exactly how to recreate your exact situation on a new store:
- how to create the zone configuration affecting these transactions
- an actual billing address that would trigger the problem

Perhaps there's a combination in there that will expose a solution. Often zone-mismatches are a result of unexpected assumptions.

"how to create the zone configuration affecting these transactions" My zones were already set up in my zen cart in Admin/Location/Taxes/ZoneDefinitions and worked OK for some years.
In Braintree you see a drop down list of these zone definitions and simply click the one you want to use.

I went into my database and the "billing country" is shown correctly for these cases.

marton_1:

My zones ... worked OK for some years.

... or not: https://www.zen-cart.com/showthread.php?219120-paypalwpp-Module-disabled-due-to-zone-restriction

When I compare the zone checking Paypalwpp code against the Braintree code it is almost identical except for the first line that has some extra code and the last line has an extra }.

Zen Cart paypalwpp.ch Line 207

if ($this->enabled && (int)$this->zone > 0 && isset($order->billing['country']['id'])) { 
$check_flag = false;
      $sql = "SELECT zone_id
              FROM " . TABLE_ZONES_TO_GEO_ZONES . "
              WHERE geo_zone_id = :zoneId
              AND zone_country_id = :countryId
              ORDER BY zone_id";
      $sql = $db->bindVars($sql, ':zoneId', $this->zone, 'integer');
      $sql = $db->bindVars($sql, ':countryId', $order->billing['country']['id'], 'integer');
      $check = $db->Execute($sql);
      while (!$check->EOF) {
        if ($check->fields['zone_id'] < 1) {
          $check_flag = true;
          break;
        } elseif ($check->fields['zone_id'] == $order->billing['zone_id']) {
          $check_flag = true;
          break;
        }
        $check->MoveNext();
      }

      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.');
      }
    }

Braintree braintree_api.ch Line 121

 if ($this->enabled && (int) $this->zone > 0) { 

            $check_flag = false;

            $sql = "SELECT zone_id
                FROM " . TABLE_ZONES_TO_GEO_ZONES . "
                WHERE geo_zone_id = :zoneId
                AND zone_country_id = :countryId
                ORDER BY zone_id";

            $sql = $db->bindVars($sql, ':zoneId', $this->zone, 'integer');
            $sql = $db->bindVars($sql, ':countryId', $order->billing['country']['id'], 'integer');
            $check = $db->Execute($sql);

            while (!$check->EOF) {

                if ($check->fields['zone_id'] < 1) {
                    $check_flag = true;
                    break;
                } else if ($check->fields['zone_id'] == $order->billing['zone_id']) {
                    $check_flag = true;
                    break;
                }

                $check->MoveNext();
            }

            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.');
            }

Have some major differences there I would say. The braintree version doesn't check for the $order related data before attempting to match to a zone and further the content that exists at and after the "missing" right squiggly parenthesis (}) is important as well. Code operates in balanced pairs... the presented code is missing a closing }.
Advising about whether or where to put a check of the order data depends on what follows. Currently it looks like, oh yeah will turn this off for now because we don't have all the necessary/desired data, but the next line may well turn it back on based on some other condition and/or have logic to again turn it off based on some other characteristic...

But yes, as written/presented so far, if $order->billing['country']['id'] was not set, then the query would not work properly and the zone would be disabled and the message would get recorded... should it be possible for it to get into that condition? Well, seems one program has the check to prevent it and works fine, the other doesn't have the check and an "zone error" is logged. So... it seems that something about that piece of information is important to the process flow... may just need to go around the logging of the error message or as a sub-set of the zone check operation, I don't know without at least the remainder of the code within the opening/closing of that particular code group, possibly the entire update_status function.

mc12345678:

Have some major differences there I would say. The braintree version doesn't check for the $order related data before attempting to match to a zone and further the content that exists at and after the "missing" right squiggly parenthesis (}) is important as well. Code operates in balanced pairs... the presented code is missing a closing }.
Advising about whether or where to put a check of the order data depends on what follows. Currently it looks like, oh yeah will turn this off for now because we don't have all the necessary/desired data, but the next line may well turn it back on based on some other condition and/or have logic to again turn it off based on some other characteristic...

But yes, as written/presented so far, if $order->billing['country']['id'] was not set, then the query would not work properly and the zone would be disabled and the message would get recorded... should it be possible for it to get into that condition? Well, seems one program has the check to prevent it and works fine, the other doesn't have the check and an "zone error" is logged. So... it seems that something about that piece of information is important to the process flow... may just need to go around the logging of the error message or as a sub-set of the zone check operation, I don't know without at least the remainder of the code within the opening/closing of that particular code group, possibly the entire update_status function.

Decided to abandon this Braintree gateway and return to Paypal Express, problem here is credit card customers are sometime asked to open a PayPal account and then I lose the sale

Anyway looks like the Braintree gateway is not updated for MasterCard 2-series BIN.

I tried payeez, I filled in the new customer form on their local web site some two months ago but they never did reply.

Square does not offer credit card service in Switzerland.

Anybody have good experience of a Zen Cart credit card gateway in Switzerland?

marton_1:

Decided to abandon this Braintree gateway and return to Paypal Express, problem here is credit card customers are sometime asked to open a PayPal account and then I lose the sale

Anyway looks like the Braintree gateway is not updated for MasterCard 2-series BIN.

from:
https://www.braintreepayments.com/blog/supporting-new-mastercard-2-series-bins/

"Braintree is ready for the new Mastercard 2-series BINs. The good news is that, as a merchant, you will not see any change to your day-to-day processing. If you want to test the new 2-series BINs in the sandbox environment, please refer to these Mastercard test card numbers."

i really find it hard to believe that any processor is not ready for the MC 2-series.

odds are much greater that the problem is with the ZC code (and possibly not having the latest version...) just my opinion...

carlwhat:

from:
https://www.braintreepayments.com/blog/supporting-new-mastercard-2-series-bins/

"Braintree is ready for the new Mastercard 2-series BINs. The good news is that, as a merchant, you will not see any change to your day-to-day processing. If you want to test the new 2-series BINs in the sandbox environment, please refer to these Mastercard test card numbers."

i really find it hard to believe that any processor is not ready for the MC 2-series.

odds are much greater that the problem is with the ZC code (and possibly not having the latest version...) just my opinion...

I meant the ZC plug in when I spoke about "ready for the new Mastercard 2-series BINs".

I could not see anything in the latest plug in dated last June which mentions specifically allowing the new Mastercard 2-series BINs but maybe it does not carry out such a detailed check? It just states "Fix for incorrect plugin removal code."

I do not see the point of a ZC plugin duplicating the same checks that the credit card company does anyway; maybe there is a good reason?

marton_1:

I meant the ZC plug in when I spoke about "ready for the new Mastercard 2-series BINs".

I could not see anything in the latest plug in dated last June which mentions specifically allowing the new Mastercard 2-series BINs but maybe it does not carry out such a detailed check? It just states "Fix for incorrect plugin removal code."

I do not see the point of a ZC plugin duplicating the same checks that the credit card company does anyway; maybe there is a good reason?

There is, as far as I have seen, which is to sanitize the content that is provided to the maximum extent but to still be within the operational parameters that are expected. It is undesirable to take just *any* content provided and try to feed it to the processor as that content could contain something that would be undesirable for either party. Also, that way the content entered can be provided a response prior to being processed and when handled can support a better user experience. The numbers rarely change or are added so things can be consistently controlled.

marton_1:

I meant the ZC plug in when I spoke about "ready for the new Mastercard 2-series BINs".

I could not see anything in the latest plug in dated last June which mentions specifically allowing the new Mastercard 2-series BINs but maybe it does not carry out such a detailed check? It just states "Fix for incorrect plugin removal code."

I do not see the point of a ZC plugin duplicating the same checks that the credit card company does anyway; maybe there is a good reason?

client side validation (through javascript/jquery) provides a much better user experience. sending all of the data to the processor when the card number (or any other data) is invalid never makes sense. it just slows the user experience down.

best.

marton_1:

I meant the ZC plug in when I spoke about "ready for the new Mastercard 2-series BINs".

I could not see anything in the latest plug in dated last June which mentions specifically allowing the new Mastercard 2-series BINs but maybe it does not carry out such a detailed check? It just states "Fix for incorrect plugin removal code."

I do not see the point of a ZC plugin duplicating the same checks that the credit card company does anyway; maybe there is a good reason?

marton,
if you want to focus on getting braintree working, i can certainly make an attempt.

in answer to your question with regards to MC 2-series BINs, braintree does NOT check the validity of the MC number. it relies on ZC to ensure that it is valid. which is why you would not see an update in the braintree plugin.

it looks like ZC updated this plugin a year ago to accommodate the 2-series BINs (i remember drByte giving me a shout out on it...) the relevant script is:

includes/classes/cc_validation.php

and you can see it here:

https://github.com/zencart/zencart/blob/v155/includes/classes/cc_validation.php

and specifically line 34 is the modified code that checks for those 2-series BINs.

i would compare your file to that one. if they are the same, what would make you think that 2-series BINs are getting rejected by ZC? none of the previous posted errors in the thread would suggest that to me.

with regards to MC and your statements on a missing }, that is CLEARLY not the case. if the } was missing, there would be debug logs and the code would not work.

i have downloaded the code and am looking at it; i see NO reason why you could not change the initial if statement to the one in paypaywpp. in this way, ZC will NOT disable the module prior to sending the data, and we can then see how braintree processes the transaction as you previously suggested.

your zones were fine for paypal because paypal did NOT check the zone if none was entered, and therefore the module stayed enabled.

i hope that makes sense!

so on the braintree_api.php code, change line 120 from:

       if ($this->enabled && (int) $this->zone > 0) {

to:

if ($this->enabled && (int)$this->zone > 0 && isset($order->billing['country']['id'])) { 

double check the cc_validation class referenced above; don't mess with ANY of the ending squiggly brackets, and let us know how it goes.

ggod luck!