Paypal Express checkout and local taxes

[65fastback2+2]

So here is my issue.

I only charge local taxes if the ship location is Kentucky.

If I create an account and use a Texas address then checkout with paypal express, it works perfectly.

If, however, I dont create an account and try to directly use Paypal Express checkout, when it takes me to the paypal screen, it shows taxes even though an address has not been entered for calculating taxes.

Is there a solution for this? I thought about maybe a way to remove the express checkout option and just have create an account or checkout as guest so they have to enter their shipping info before they select paypal as the payment method and then confirm the order where it sends them to paypal. But, I dont know if this is possible or how.

Thanks for the help!

[nootropic]

Dr. Byte, I know you have stated in several threads that there's no way in the current version that PayPal can be displaying tax information unless the customer has provided their shipping address in the Zen Cart store first. But I am having the same problem as others after upgrading from 1.3.9h to 1.5.1. When a customer does not log into my store, but uses the Express Checkout button, the PayPal page does indeed display a sales tax amount. I verified that this amount is transmitted to PayPal in the TAXAMT field. I do NOT have any custom add-ons installed. My paypalwpp.php is the vanilla version from the 1.5.1 distribution.

I have had many inquiries from customers about tax charges, and I wondered why. Then I noticed the display of sales tax!

There are many changes in paypalwpp.php between 1.3.9h and 1.5.1 regarding the handling of TAXAMT. So I really think there is a problem somewhere.
If you don't believe me, please visit my store at http://nootropicdesign.com/store and add something to the cart and choose express checkout. You will see tax information displayed at PayPal.

[DrByte]

I have a fresh new installation of Zen Cart on my site, using demo products.
What do I need to do to my site to make it exactly behave as you describe?

ie: tell me every admin setting you've changed, every zone you've created, every plugin you've installed, every module you've enabled, currencies, languages, everything.

If I can't recreate the problem consistently on-demand, I can't fix it. And thus far I haven't got enough information to help you.

[nootropic]

Admin settings: no changes related to taxes: DISPLAY_PRICES_WITH_TAX = false
Zones: no new zones created. Configuration->My Store->Zone = Minnesota.
All products characterized with Tax Class = Taxable Goods
Tax Rate for Minnesota defined as 6.875% for Tax Class = Taxable Goods
Currencies: US Dollar is only currency used.
Languages: English is only language defined.
Plugins/Add-ons: the only addon is USPS shipping module RateV3 which is now an add-on for 1.5.1
PayPal settings: all shipping and tax options are disabled
Configuration -> My Store -> Basis of Product Tax = Shipping
Configuration -> My Store -> Basis of Shipping Tax = Shipping
Configuration -> My Store -> Zone = Minnesota
USPS Module -> Tax Basis = Shipping
USPS Module -> Shipping Zone = none

I've used Zen Cart for many years and am very familiar with the PayPal integration API. It just seems that some change in paypalwpp.php has altered the way in which the TAXAMT field is set when the customer has not logged in at all to the store. The default behavior I'm seeing in 1.5.1 is to send a TAXAMT based on the zone defined for the store, even though the customer has not logged in or provided any shipping address info to PayPal.

I am very happy to try different configuration settings or to experiment with any code changes you recommend. I'm an experienced developer, so I'm game.

[DrByte]

Just to clarify, it's not actually mischarging them anything, right? It's merely showing them what taxes would be if their delivery address were inside your taxable zone, and then self-corrects when they provide a non-taxable address, right?

[nootropic]

Yes, correct. Once the customer gives their shipping address at PayPal, then the charged amount is completely correct. It's just the initial misrepresentation of the charges that causes customers to ask questions or wander away confused.

[nootropic]

Here is some more info. I have found that the source of the TAXAMT value is from the value of the ot_tax order total. I have a 1.3.9h installation that I can test in, as well as my production 1.5.1 installation, and I can see that the set of order totals being returned from the order_total module is different in the two versions. In 1.3.9h, the ot_tax order total is not returned by the call to order_total_modules->process() in paypalwpp.php. But in 1.5.1, the ot_tax order total is present in the set of order totals returned from process().

For clarity, I'm logging the set of order totals after line 1432 of paypalwpp.php:

    $order_totals = $order_total_modules->process();
    for ($ot=0; $ot<sizeof($order_totals); $ot++) {
      $this->zcLog($order_totals[$ot]['code'] . ' = ' . $order_totals[$ot]['value']);
    }

in 1.3.9h there is no ot_tax total, but in 1.5.1 there is. When the anonymous customer is viewing the shopping cart on my site (before clicking the PayPal Express button), there is NO tax displayed. But when we hand off to the paypal module, there is an ot_tax order total with a calculated tax value.

My tax class, tax rate, and zone definition are identical between the 1.3.9h and 1.5.1 installations. The ot_tax order total module is installed identically between both versions. The actual tax handling in orders works fine in 1.5.1 once we know where the customer is. Tax is correctly assessed for my Minnesota customers, and not otherwise.

[DrByte]

It's not a PayPal thing.

It's caused by this default which was added to prevent errors from being triggered when customers without an account attempt to go through checkout:
line 287 of orders.php class:

    // set default tax calculation for not-logged-in visitors
    $taxCountryId = $taxZoneId = -1;

Changing it from -1 to 0 would prevent the system from using the STORE_ZONE and STORE_COUNTRY as defaults, and instead give nothing back.
But I've no idea what other very bad side effects that could cause as well, everywhere in your store.
USE AT YOUR OWN RISK

[nootropic]

Yes, I found the same thing. I was just running tests with my fix to order.php. The logic for determining the tax address was refactored in 1.5.0. With the default country and zone explicitly set to -1, this will always show tax for the store's location at PayPal. That is not the correct behavior.

My fix is to set the taxCountryId and taxZoneId from the database query result, regardless if there were any records returned. This is how the 1.3.9h version worked.

So I changed order.php:

$tax_address = $db->Execute($tax_address_query);
if ($tax_address->recordCount() > 0) {
   $taxCountryId = $tax_address->fields['entry_country_id'];
   $taxZoneId = $tax_address->fields['entry_zone_id'];
}

to this:

$tax_address = $db->Execute($tax_address_query);
$taxCountryId = $tax_address->fields['entry_country_id'];
$taxZoneId = $tax_address->fields['entry_zone_id'];

This results in the correct behavior for not-logged-in users using the Express button. I tested all the other checkout paths as well.

[DrByte]

The change you just posted will throw errors if nothing comes back from the query if strict error reporting is on, and will set those values to 0. So basically your code is just setting the country and zone to 0, which basically just bypasses normal use period.

Has your fix accounted for the reason why the -1 was used in the refactoring in the first place? Do you know why that was done specifically? If not, are you 100% certain that changing that is absolutely correct for everyone everywhere in the world?