Hi David, following up on this – how can I provide the credentials to you for a test site?
For Stripe, that’s specifically (i.e. only) if one uses the “Express Checkout Element”, is that right?
Yes, that’s correct. And same for WooPayments – the issue is specific to express checkout payment methods like Google Pay/Apple Pay.
For payments where the checkout is ultimately off-site, then in general it’s not likely to be possible to comply with EU VAT regulations…. though *some* of the data can be gathered, since you can’t control the user experience on an off-site checkout, the plugin’s settings generally can’t be enforced
Those methods display a payment sheet on top of the merchant’s site, and they communicate with the merchant’s site to gather shipping rates/prices/etc. via the Store API.
The customer is usually not redirected offsite (with some exceptions – for example, using Google Pay on a non-Chrome browser, or using Apple Pay on a non-Safari browser).
But it’s the customer’s browser that makes the request to the merchant’s site via the Store API, not the payment methods directly.
I.e.: (simplifying) when a Google Pay payment sheet is opened, Google Pay will ask the payment processor (Stripe) to get the shipping rates for a specific shipping address. Stripe will communicate with the customer’s browser to make a Store API call to the merchant’s site to gather shipping rates & prices. The merchant’s store will return the information to Stripe, who will eventually provide it to Google Pay.
So it’ll always be the customer’s browser making the request to the merchant’s site, even when the custoer is redirected to an external site.
I confess that I’ve never tried WooPayments. If you have a dev site that’s using it and things aren’t working, I’m happy to take a look.
Thank you! I can create a test site with your plugin & WooPayments installed in test mode. How can I provide the credentials to you?
Thanks again for your availability!
Hi David,
thank you for getting back to me!
There are a couple of extensions like WooCommerce Stripe ( https://github.com/woocommerce/woocommerce-gateway-stripe/blob/develop/client/api/index.js#L624 ), WooCommerce PayPal, and WooPayments ( https://github.com/Automattic/woocommerce-payments/blob/d8bf8e335f3dca9a604ed7079957ace822a2d2cf/client/express-checkout/cart-api.js#L86 ) that use directly with the Store API to communicate with the merchant’s store to use the express payment buttons like Google Pay/Apple Pay/Amazon Pay/Stripe Link.
Since in those use cases those extensions don’t go through a “normal” checkout flow, because (for example) they allow the customer to checkout the product from the product page or cart, they won’t send parameters like ship_to_different_address, and in the Stripe and WooPayments use cases, the customer’s billing address might not be available until the customer confirms che payment and the POST /checkout endpoint is called.
Thanks again for your time!
Hi @recyborg ,
Thanks for letting us know!
I logged a new issue for the team to look into: https://github.com/Automattic/woocommerce-services/issues/2547
I don’t have a specific timing – but generally speaking, a new version of the plugin will be released in the next few days after the GitHub issue is marked as “Closed”.
I’m going to close this topic for now, you can subscribe to the GitHub issue to stay up to date on its status.
Thanks for your help!
Francesco
Thanks for the follow-up!
In the meantime, we deployed the fix so that the error won’t occur anymore.
Hi @giannis4,
Thanks for the feedback and for your patience!
We’re looking into reverting some changes on the server-side of things, which will resolve the immediate issue.
Have a good rest of your day and have a good weekend!
Francesco
I’m glad that works!
Thanks for your patience with this!
I’m going to mark this thread as resolved for now, but if you desire you can follow the discussion on the ticket.
Once the ticket is marked as “closed”, the fixed will typically be available in one of the next releases of the plugin.
Thanks again, have a great rest of your week!
Francesco
Hi @visibledeals,
Thanks for your patience and for confirming.
I think I was able to reproduce the issue, so I created a ticket for the team to look more into this: https://github.com/Automattic/woocommerce-services/issues/2511
In the meantime, is the “Use address as entered” button visible and clickable for you? If so, you should be able to skip the address validation and try to purchase the label anyways.
Link to image: https://d.pr/i/FubUeH
Let me know if this helps!
Francesco
Hi @visibledeals,
Thanks for reaching out!
The “Name” field is required for both origin and destination addresses.
Can you please confirm whether the “Name” field is filled on the origin address? It is often required by carriers (USPS, DHL Express) in case a shipment needs to be returned to the sender.
Thank you!
Francesco
Hi @rcharbonxx,
USPS is no longer allowing customers to purchase labels to Australia.
More details are available here: https://about.usps.com/newsroom/service-alerts/international/welcome.htm
It should still be possible to purchase the shipment label with DHL Express instead.
Thanks for your patience on this!
Francesco
Hi @dakattack ,
Thanks for reaching out!
The plugin leverages your site’s Jetpack connection in order to determine which account (and credit card) to be used.
In order to change the account connected to your site, go into your site’s wp-admin, then go to Jetpack > Settings.
On that page, you should see a link to “Manage site connection”.
You can now disconnect and re-connect your site with a new account.
Please note that before re-connecting, you might want to log out of your WordPress.com account.
Once the site has been reconnected, you might experience some errors in the UI of order pages for orders that contain existing shipping labels purchased with the older account.
If that’s the case, let us know in a support ticket, so we can re-align your records.
In the support ticket you should provide:
– Your old WordPress account name
– Your new WordPress account name
– A link to this ticket
Let me know if this helps!
Have a good rest of your day!
Francesco
Hi @saqibrajpoot922 ,
Thanks for reaching out, I’m sorry to hear about the issues when printing labels!
Can you please log into your site’s wp-admin, go into WooCommerce > Settings > Shipping > WooCommerce Shipping?
The “Shipping Labels” section should contain some information about the payment methods being used.
Link to image: https://d.pr/i/yt3Qhl
Can you please confirm whether there are payment methods available and selected?
The “master” user connected to Jetpack should have some payment methods available on their profile.
Thanks for your patience!
Have a great rest of your day!
Francesco
Hi @ashf ,
Thanks for reaching out!
The sender’s name (the “origin” name) can be changed in the first step when creating a label.
Once that is verified, it will be used for all new orders to be fulfilled.
Link to image: https://d.pr/i/AooA1K
Let me know if that’s not the case for you or if I misunderstood your question!
In the meantime, have a great rest of your day!
Francesco
Hi @idompharm ,
We have a few steps listed here that can help you troubleshoot possible issues with Apple Pay: https://docs.woocommerce.com/document/stripe/#apple-pay
For some immediate troubleshooting, you can try and go to https://applepaydemo.apple.com/ to see if the button appears or not.
You’ll also need to ensure that you are accessing your site with a valid SSL certificate (via https).
Let me know if this helps!
Francesco
Hello @sleepsong997,
Thanks for looking into this and providing the information!
Unfortunately we don’t provide the automated tax or label printing services to Singapore at this time.
This explains why the connection banner is not displayed.
Your store needs to be based in the EU, UK, US or Canada in order to get automated tax calculation.
In order to get label printing services, your store needs to be in the US with USD currency.
I hope this helps!
I’m going to mark this topic as resolved for now, but feel free to open a new topic if you have any other issues!
Francesco
