Module disabled due to zone restriction.

[marton_1]

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

[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);

[marton_1]

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

[mc12345678]

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.

[marton_1]

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

[marton_1]

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

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.
When I use the Braintree gateway then Paypal customers are rejected.

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?

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

[marton_1]

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 :)

[DrByte]

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.

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