Module disabled due to zone restriction.

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

[marton_1]

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.

[DrByte]

My zones ... worked OK for some years.

... or not: https://www.zen-cart.com/showthread....ne-restriction

[marton_1]

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

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

[marton_1]

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?

[carlwhat]

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/bl...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...