Closed dreamtooloud closed 2 years ago
I wasn't able to replicate the issue.
I have two shipping methods in UK Zone that I created, then I selected the second one (Express).
When I clicked buy with Apple Pay, consistently the second option was selected. Even after adding my details, the selected shipping method stayed the same:
I used Apple Simulator iPhone X on iOS 12.0
4684886-zen
We are having the same issue on our website as well - www.phyts-usa.com
All orders over $75+, after discount, qualify for Free Shipping. The Free Shipping zone is setup in WooCommerce and displays as the first shipping option in WooCommerce.
But for some reason, when a qualifying order selects Apple Pay, it's defaulting to the $6 Flat Rate Shipping and will now allow the user to select anything but that option. End result, we're charging a qualified customer for shipping when it should be free. Resulting in lots of refunds on our transactions.
I have reached out to Stripe support to review and they gave us the all clear that the problem was not on their side. After contacting WooCommerce support and providing admin credentials, they spent a full day testing and were able to determine it was indeed a bug but did not provide a resolution. They recommended keeping an eye on this thread and disabling Apple Pay for the time being.
Any chance for a resolution soon?
Another case similar to the OP reported in 33846991-hc
Is there an ETA on when this will be fixed? I have multiple clients using Stripe, that want to enable Apple Pay but with it not working correctly with delivery options I can't enable it for them. It's very frustrating. I have been watching this for months now and still no solution. I expect better from Woocommerce.
5250423-zen reported this as well.
5250423 here - spouse-ly.com. We are seeing the same issue with Google Pay as well.
Express Pay (Google Pay and Apple Pay shipping) is not properly syncing with WooCommerce.
You can see this issue live on our staging site.
Select this product, choose any color and size, Add to cart, Checkout Complete the Billing details (you will see 4 shipping options). Note the default - Flat Rate: $5:00, Total: $21.26, select Buy with GPay/ApplePay. The Order summary will be correct: $21.26. Choose a Shipping address. The Order summary will be correct: $21.26. Change the Shipping method to Local Pickup: The Order will be incorrect $21.26 (It should be $16.26)
Close GPay/ApplePay, Select WooCommerce Local Pickup. The Order will be correct: $16.26. Select Buy with GPay/ApplePay. The order will be correct: $16.26. Choose a Shipping address. The Order will be incorrect: $21.26 (It should be $16.26).
Choose any Shipping method and it (shipping) doesn't update (as a side note, tax does update).
Express Pay shipping is not syncing with WooCommerce.
Reported again on #5566563-zen.
@woocommerce/fractal do we have any idea of the priority of this issue?
I'll take a look into this.
@ChrissiePollock The problem is that we do not share the address entered by the user in the checkout form with Apple Pay. It's not sure that the Apple Pay dialog will show the same shipping options in the Apple Pay dialog. To select a shipping method, we'd need to set the addresses shown in Apple Pay, which we can't currently do.
I'm not sure we can fix this. The address Apple Pay uses to get the shipping options is out of our control. We could try to set the initial shipping options shown in the Apple pay dialog, but it will be replaced as soon as a shipping address is selected in the Apple pay dialog (if the user has a saved address, it will be replaced immediately). /cc @diegocurbelo
@asumaran Thanks for the followup and looking into it.
We discussed this issue internally and agreed this issue can't be fixed for now. Unless Apple Pay (and the Stripe JS library) provide a way to set the address on the Apple Pay dialog, there's no reliable way to fix this. I am closing this issue for now.
Any chance this issue can be reopened? As it's still a concern.
Reported in HC-1077282 / ZD 4282395
Describe the bug
"Whenever customers select our express delivery option on our website but they opt to pay with ApplePay, for some reason apple pay is amending the default shipping method to standard. We have already raised this with Stripe who advised this appears to be a Woocommerce issue."
This was originally reported in #755 and a pull request was created and later merged to close the issue in #1191
In a nutshell: When a customer puts an item in their cart, selects a shipping option, and then clicks the Apple Pay button, Apple Pay was reverting the shipping option to the first one on the user's list (in this case, it was free shipping and was 7-10 business days instead of the 2-3 the customer wanted when they selected "express") .
We rectified this by changing the order of the shipping options under WooCommerce-->Settings-->Shipping-->Manager shipping zone. User's site now reflects express delivery first.
However: When we tested using free shipping(the second option in shipping methods hierarchy), Apple Pay was now pulling the Express Shipping option as default. This seems very much related to #755
To Reproduce Steps to reproduce the behavior:
Expected behavior Apple Pay will pull the selected shipping method to the Apple Pay window
Environment (please complete the following information):
Additional context I was not able to test on a clean test site because I don't have Apple Pay set up (my test sites are all on staging/sandbox modes).
I did test the user's website: www.alfredco.com and wasn't able to reproduce since I had a shipping address outside the shipping zone that was created (it defaulted me to a shipping method that was for "all other shipping locations"--So that is actually an expected behavior based on the PR at #1191 . )
You can switch shipping methods in the Apple Pay box but user expressed some concern that their customers would still be making mistakes about shipping if they didn't review the Apple Pay box before clicking submit (again, this is expected after PR #1191 )
This is looking like a fringe case but but it was recommended to open a report since it is very similar to #755