paypalwpp.php inserts a shipping address outside the zone definition, no tax applied

Current Settings:
Express Checkout Shortcut Button= Off
Express Checkout: Require Confirmed Address= No
Express Checkout: Skip Payment Page= No
Express Checkout: Automatic Account Creation=Yes
And I have tax based on shipping address not billing.

So, it transpires that the customer is registering in the shop as normal with a single address and buys the product via paypal.
He should be paying tax as the province in his address is in a defined zone.

However, what I find is that a second address is added during the payment process and used as the shipping address (it’s written slightly differently from that used to register in the shop) which does not get caught by the zone definition and so the order does not have tax applied to it.

Now, this has occurred only three times (in five years). I figured out the problem was the second address but could not get coherent answers out of the two customers as to how they purchased the product: I may as well have asked the cat.

So I altered every sql that inserted into the address_ book to add an extra column detailing the page responsible and a timestamp to get more clues as to how this extra address was being created.
On occasion 3 I find this inserted in address_book
“2014-01-31 11:58:55 paypalwpp 2638” (2638 is the line number of my file=2467 in a vanilla version of paypalwpp.php)

And the order record at my Paypal account is 11:58:59.

The timestamp on the order is
“2014-01-31 11:59:01”

So, looking at the paypalwpp code, it is indeed inserting a new record in the database at order completion.

But, I don’t get the step-by-step details of this particular payment process.

If the insert of the Paypal address is only done at order-completion time, the amount carried to the Paypal page prior to this should have tax applied as usual. It changes dynamically?
Here the new address insert is shown 6 seconds before order completion.

I have now changed Express Checkout: Automatic Account Creation to No, but am unsure if that will have an effect.

Can someone please explain the communication steps of this payment method…or even offer some thoughts on this issue?

Happened again. I am guessing that these customers created their paypal account when paypal did not force a drop-down selection of spanish provinces, so they could write what they wanted in that field. It doesn't match with their ZC default province so the address gets added and used. So, in the absence of any help here, a hacking I will go...

I know it's a bit late, but the area within paypalwpp.php that you'll want to modify is the function ec_step2, which is called after the customer has entered his/her information on PayPal and come back to your site to verify/confirm the order. You could start by making a small change to force the payment module's debug logs when the delivery and billing addresses don't match:

 /**
   * Debug Logging support
   */
  function zcLog($stage, $message) {
    global $order;
    static $tokenHash;
    if ($tokenHash == '') $tokenHash = '_' . zen_create_random_value(4);
    $force_debug = (isset($order) && isset($order->billing) && isset($order->delivery) && sizeof (array_diff_assoc ($order->billing, $order->delivery)) > 0);
    if (MODULE_PAYMENT_PAYPALWPP_DEBUGGING == 'Log and Email' || MODULE_PAYMENT_PAYPALWPP_DEBUGGING == 'Log File' || $force_debug) {
      $token = (isset($_SESSION['paypal_ec_token'])) ? $_SESSION['paypal_ec_token'] : preg_replace('/[^0-9.A-Z\-]/', '', $_GET['token']);
      $token = ($token == '') ? date('m-d-Y-H-i') : $token; // or time()
      $token .= $tokenHash;
      $file = $this->_logDir . '/' . $this->code . '_Paypal_Action_' . $token . '.log';
      if (defined('PAYPAL_DEV_MODE') && PAYPAL_DEV_MODE == 'true') $file = $this->_logDir . '/' . $this->code . '_Paypal_Debug_' . $token . '.log';
      $fp = @fopen($file, 'a');
      @fwrite($fp, date('M-d-Y H:i:s') . ' (' . time() . ')' . "\n" . $stage . "\n" . $message . "\n=================================\n\n");
      @fclose($fp);
    }
    $this->_doDebug($stage, $message, false);
  }
  /**

Thanks for the reply, I started looking at the whys and wherefores and decided to do this:

function addAddressBookEntry($customer_id, $address_question_arr, $make_default = false) {
global $db;
//bof steve to stop address matching
return false;
//eof

which is the same as if the user has no address details in Paypal at all.

I have yet to see any ill effects...

I'm not versed enough in Paypal lore to know better, but maybe this should be switched in the admin if you always wanted the store address to be used.

The customer to whom this just occurred has (after I asked him) found about 20 similar addresses in his Paypal account, he's assuming they have been automatically added from shops he has visited. I was not aware of such functionality. The whole process seems flawed to me.

For the record, the offending bit of code that was setting the zone to 0 because there was no match:

if (!$zone->EOF) {// grab the id
   $zone_id = $zone->fields['zone_id'];
   } else {
      $zone_id = 0;
   }

I could have defaulted this to be the customers shipping address zone but since I make everyone register in my shop I'll stick with the above sledgehammer approach for now, why should I allow Paypal to create addresses willy nilly?
I'm suprised no-one else has had this issue before...?