andrisp
Forum Replies Created
-
Hi @mrclayton ,
In none of the problematic scenarios my expectation is that wallet would load address data from the checkout form. The problem is the opposite – if there has been any prefilled data (country or full address), address from the wallet is not handled properly.
In the example #2 (where full address was prefilled in the form and shipping options were calculated on checkout form load), wallet dialog is always showing shipping for the address in checkout form not the address which was default in the wallet. And even changing the address in the wallet does not update the shipping. It always shows the shipping for the address which was calculated in the checkout form. This is the opposite of what you are saying.
In the example #3 (only country ir preselected in checkout form), the wallet just fails to load shipping options for the default address. It seems that backend call still tries to calculate shipping for the (partial) address in the checkout form, not the address in the wallet. Again – opposite of your last post’s point #2.
I’m in fact am using Checkout Field Editor by themehigh. Will try to disable and see if anything changes.
You should see a notice showing the address is not valid.
Yes, notice is there.
Is that the case when the checkout form submts? You should see that when you complete the payment in the wallet, the wallet closes and the checkout page HTML updates with the address info from the wallet. The checkout form then submits.
Yes, submitting the incorrect Express Checkout payment triggers the address update in checkout form and if that address has shipping options available – first shipping option is automatically selected and the charge is made without user consent about the shipping option and cost (because Express Checkout was showing the wrong shipping options / cost without any errors).
I’ll try to illustrate the scenarios with some screenshots and captions
- Scenario where standard checkout form is empty, and Express Checkout works as expected: https://imgur.com/a/E6uFsHT
- Scenario where address is prefilled (see comments below each image): https://imgur.com/a/4vwNtpg. In this case, user can submit the payment, and he will be charged the actual shipping cost on checkout form submit, not the cost he was shown in the Express Checkout which is misleading.
- Scenario where address is just partly filled. Country is selected, but no shipping options were calculated before opening Express Checkout: https://imgur.com/a/ByuohKH
While debugging the backend call, I noticed that
WC_Customer->set_shipping_location()inRest/Routes/CartShipping.phphas no effect in scenarios #2 and #3: https://imgur.com/a/6HwZCFQ- This reply was modified 1 month ago by andrisp.
- Ok, I find this strange behavior, because at the same time Google Express Checkout is not discarding the address which caused the error. It seams that user can simply submit the payment with the previous shipping cost, but with the updated address.
- I cannot provide it publicly (it’s behind VPN).
request is made to your wordpress backend where the chosen shipping method WooCommerce session variable is updated. You won’t see the checkout page UI update until after the payment sheet closes.
Yes, I was debugging this request, and noticed that session variables are never updated. Shipping address always stays the same, regardless of what address I fill in the Express Checkout dialog. And I noticed this happens only when standard checkout form had fields prefilled before I opened Express Checkout.
Thanks for the prompt reply!
- I mentioned the bad data just in case to highlight that the implementation does not handle invalid responses. The scenario which I really care about is when address does not have shipping options available. In this case that ajax call returns 404 code with message “‘There are no shipping options available for the provided address.”, but this does not reset shipping options in the Express Checkout dialog (it still shows old shipping options and cost from the previous address). My assumption is that in this case shipping options and the cost should be removed, and if possible, continuing with the payment should not be possible.
- The problem is that for some reason, backend code is not updating shipping options for the address which is provided by the wallet. When testing different scenarios, I found out that this happens if country field has been already filled out in the standard checkout field (for example, automatically from user session) . If I open incognito window, and start with empty checkout form (no country selected), then Express Checkout works as expected. I’m not saying that I’m expecting Express Checkout to use address from standard form.
- This reply was modified 1 month ago by andrisp.
Hello @diegoversiani ,
It seems that this issue was not resolved in the latest 3.2.6 version.
PHP Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, null given in /var/www/html/wp-content/plugins/fluid-checkout/inc/compat/plugins/compat-plugin-woocommerce-subscriptions.php:535
Stack trace:
#0 /var/www/html/wp-content/plugins/fluid-checkout/inc/compat/plugins/compat-plugin-woocommerce-subscriptions.php(535): array_merge()
#1 /var/www/html/wp-includes/class-wp-hook.php(324): FluidCheckout_WooCommerceSubscriptions->add_substep_text_lines_shipping_method()
#2 /var/www/html/wp-includes/plugin.php(205): WP_Hook->apply_filters()get_packages_review_text_linesstill does not properly initialize return variable ($package_review_text_lines). It should be initialized before foreach block.Forum: Plugins
In reply to: [WooCommerce Stripe Payment Gateway] return_url missing – Stripe notifiedReceived the same email from Stripe.
Plugin was updated to latest version (v8.5.1) yesterday.
Reconfigured the webhooks as asked, although not sure how the actual problem is related to webhooks. Don’t know if that helped or not.