Module disabled due to zone restriction.

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

[marton_1]

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

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?

[mc12345678]

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.

[carlwhat]

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.

[carlwhat]

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/b...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!