Spike: Inconsistent tax behavior when using Express Checkout for virtual products

gpressutto5 commented 8 months ago

Describe the bug

As noted in https://github.com/Automattic/woocommerce-payments/issues/7577#issuecomment-1847967971, we have a fundamental problem calculating taxes for virtual products in Express Checkout. The problem happens because all the payment data is loaded when the page is rendered, so unless the customer is logged in, we have no data about their billing or shipping address. This data is only updated subsequently when we need to calculate the shipping fee, and since virtual products do not require shipping, the tax amount will not be updated. In this issue we must look for a way to resolve this and calculate taxes correctly. One idea I had is to always ask for a shipping address when using Apple Pay or Google Pay, even for products that don't require shipping.

The solution might be affected by #8297

To Reproduce

Go to the taxes settings and create different Taxes zones
On a new window, as a guest, clear all your cookies and local storage and use Apple Pay / Google Pay to pay for a virtual product
Experiment with different settings for "Calculate tax based on" (Customer shipping address / Customer billing address / Shop base address)

Actual behavior

Tax calculation is inconsistent

Screenshots

Apple Pay modal	Price changed after confirmed

From checkout select billing country US	See Apple Pay modal with US tax price	After confirming, it changed to Brazil because of the card

Expected behavior

Tax calculation should be correct

Additional context

7859784-zd-a8c

zmaglica commented 8 months ago

@dwainm this issue affects taxes, so I am moving this issue to the team Sigma. Feel free to reach out to me or ping another team lead if you think that someone else can work on this issue.

pierorocca commented 8 months ago

@zmaglica please go ahead an update the labels accordingly so that the workflow engine will move this out of the Shopper Experience project board. TY.

gpressutto5 commented 7 months ago

@zmaglica This error is tax-related but specific to Apple Pay and Google Pay. It is not the core tax calculation that is wrong, but the logic behind the Payment Request not considering taxes correctly. This issue should be handled by team Heisenberg.

zmaglica commented 7 months ago

Hi @FangedParakeet . Could team Heisenberg work on this issue?

zmaglica commented 7 months ago

@zmaglica please go ahead an update the labels accordingly so that the workflow engine will move this out of the Shopper Experience project board. TY.

I noticed that you have set the label and based on the issue description, the label you set is the correct one. Do I need maybe set something else?

pierorocca commented 7 months ago

I noticed that you have set the label and based on the issue description, the label you set is the correct one. Do I need maybe set something else?

No worries. I had thought based on your comment Sigma was going to take this on. As it is PRB related and staying in Shopper the label as is is perfect. Sorry about that confusion.

gpressutto5 commented 7 months ago

Please add your planning poker estimate with Zenhub @FangedParakeet

gpressutto5 commented 7 months ago

After investigating the Tokenized Carts POC and finding changes to how taxes are calculated (https://github.com/Automattic/woocommerce-payments/pull/8429#issuecomment-2048173799), it is safe to say that this issue will be severely affected by that refactor and perhaps even resolved in the result. It's best to wait until the refactoring project #8525 is finished so we can go back and check if this has been fixed or fix it in case it hasn't.

gpressutto5 commented 7 months ago

I will spend one more day trying to come up with a quick workaround, like always requiring a shipping address when taxes are on, and see if that fixes the issue.

gpressutto5 commented 7 months ago

It did not work quite as well as I anticipated. Although it helped calculate simpler taxes by having a request to the backend, it makes things more confusing in most scenarios. For example, if the tax is calculated based on the billing address and the shipping address selected differs from the card's billing address, the tax displayed in the order review will be incorrect as we only get the billing address in the backend when paying.

Another problem is that even when the product does not need shipping because it is virtual, by pretending it needs shipping, we will display the valid shipping methods for the address, which may include fees. These fees are not charged, but it is misleading.

Notice the tax change because of the card's billing country.

Let's wait for the refactoring project #8525 and give it another try.

frosso commented 4 months ago

I can confirm that a similar behavior is also happening with the tokenized cart PRBs. Stripe provides us the billing address only once the customer finishes interacting with the ApplePay/GooglePay dialog. Similar to the current PRB, if the merchant's store is set to charge taxes based on billing address (which should be the majority of use cases), the tax amount displayed for virtual products might be inaccurate.

I am saying "might" because the customer is geolocated (WC checkout can be set up to geolocate their country/state as a baseline).

If the store is set up with customer geolocation, and the customer is geolocated with their card's country/state, the tax amounts should be accurate.

Stripe allows us to set a pending attribute on each line item. ApplePay/GooglePay then can decide how to interpret/display such amount. I thought that if I put the pending: true only on Tax line item in the scenario where tax is based on billing address, there could be some benefit to the customer. Unfortunately, ApplePay shows the whole amount as "pending", instead of only the Tax line item.

CC @FangedParakeet

Automattic / woocommerce-payments