Dave Loodts

To make this issue transparent for everyone; we had reply for the Complaints team of Klarna:

****
This activation is intended to broaden the payment options for your customers and increase your conversion rate by offering consumers flexible and attractive payment methods. However, activating the payment method in Mollie does not make this payment method visible in your Mollie Dashboard, as this needs to be activated from within your organisation in your webshop itself.

According to our User Agreement, article 3.2, Mollie may automatically activate payment methods for your organisation. However, we will always inform you by email for this purpose. Furthermore, you can disable the payment method yourself at any time in your Mollie Dashboard. To do so, click on your company name > Organisation settings > Profiles > Online payment methods.
****

First of all: we can confirm Klarna was visible on the front-end in the checkout. It was forced by Mollie. And we got confirmation from other cases in the WordPress community.

This reply of Mollie is very worrying.
So, Mollie has the right to activate payment methods without any consent.
I must say: this is absolutely a no-go for us.
It’s only up to the owner of the shop and it’s responsible CTO-team to do this.
If Mollie really thinks this is normal, we lose trust and plan to actively switch our customers to another payment provider as our role of technical maintainer can’t monitor this in a good way.

Thanks for the very fast answer.
I never heard of sticky sessions; the site hosted at Siteground.

But i’m surprised this could be the issue, since the site is not that gigantic. It has 9500 orders, and every export we test is around 190 orders. So, that does not seem a giant query.

Hi, we probably found the pain points with the attribution measuring: mainly the Mollie payment gateways: Belfius and KBC.

The Analytics plugin of Sweetcode also has reports on the percentage of buyers that return to the thank-you page per payment gateway. For bancontact and ideal it goes like a breeze: 100% returns to the thank-you page.

But Belfius swings between 30% (!) and 70% (max), KBC between 70% and 90%.; and probably that makes Google Analytics cluessles on what session the traffic is attributed. In most case; in the User Report it connects it to “direct” (obviously).
That one shop with Multisafepay also uses Belfius: the number is 93% (which is rather okay)

So, we asked one shop-owner with Mollie to do a test-run with KBC and Belfius de-activated, buyers can still buy via the bancontact method. So, curious about the outcome of that test.

But overal: i guess there are some issues at the side of Belfius and KBC. I only have one customer with Multisafepay; so too less of data to really compare. And i don’t know how Mollie can influence or impact those issues at the payment gateway side…

• This reply was modified 2 months, 1 week ago by Dave Loodts.

Hi, what’s the status of the new API support?
Since WooCommerce 8.3, there’s now this Legacy API plugin that’s required to use Sendcloud.

Waw, what a fast reply. Thanks, i activated v3 now. Thanks for the other tips!

WooCommerce has a feature request board. It’s a good idea, so worth mentioning over there:?https://woo.com/feature-requests/woocommerce/

• sorry pasted answer of another ticket

• This reply was modified 8 months, 1 week ago by Dave Loodts. Reason: wrong ticket

This is not possible in WooCommerce core, you’ll need a Wholesale plugin or custom coding to add extra pricing fields per role.

In the latest update of WooCommerce, they show these kinds of notifications to display which services on your site still uses the Legacy API. And SendCloud still does.

So, it’s for awereness that -if SendCloud is not adapting- you should install the Legacy API plugin from WooCommerce 9.0 onwards.

It can only be solved when SendCloud is moving over to the new REST API. But besides that: the size of the logfile won’t have any impact on your site performance, and in terms of extra space on your server, it is also not that impactfull.

I do expect SendCloud to follow soon with the new REST API, but we will see.

So 600.000 users have to “opt-out” for a speedy website… waw, just waw…

Thanks!

Thanks for the link.

But I do hope you get my point too that there is right now changelog link from the www.remarpro.com theme profile.

And on the Woo dev blog, the latest Storefront theme release post is from 2021; see category: https://developer.woo.com/category/release-post/storefront-theme-release-notes/

I asked a privacy expert about this new feature. It’s data stored on own server, so that is not an issue. Although for more clearity you can better add it to the privacy policy.
An order on it’s own has already a lot of personal information, WooCommerce also saves the IP-adress, so it’s already a must you should add what data you store in your privacy policy. Although this feature won’t be a big issue in my opinion, as UTM-tags are also mostly sees as save.

I know a few privacy-focussed people that dropped their Analytics tools, and just use it like this way: utm or get origin, save it in a cookie, connects the cookie in a hidden field of a contact form, and now they have a clear overview of the impact of their campaigns. And that is perfectly compliant. And WooCommerce does the same thing now. And as long as this data is stored on the own server, you’re save.

(I know it’s not really allowed to give advice on the matter in this forum, but i really checked an expert in this; he even tracks all the cases/fines in Europe, so that advice is legit: https://www.dailybits.be/item/overzicht-gdpr-boetes-rechtszaken/)

Hi, it looks like it is not a general issue. Sorry about that. We’ll have to dive deeper into that proect.

I’m gonna add the idea to the feature request list.

It’s not only Revolut that’s gonna reply like this. Big or small companies, the majority of it aren’t yet supporting the new cart or checkout block editor. We run +40 shops, none of them use the cart or checkout block. From my current experience as semi-developer; the classic cart and checkout is way more flexible to build out. More documentation and tutorials. Even if a build a new shop now, i’ll still advice the classic way in terms of cart and checkout. For me it’s certainly not a step back, it’s a step for more flexibility right now.

For a typical php developer in WordPress-land, it’s not easy to switch over to javascript. I see a lot of shortcomings in that part at plugin builders. But it’s not easy to follow up: the speed of development, full site editing testing and the HPOS-integration, that all takes a lot of energy and time for plugin builders. There is a lot of pressure and also legacy code to support.

On WooCommerce blocks that is involved with lot’s of other functionality like the checkout or cart, it is certainly not that easy. In fact: that part is thé most important feature of a shop. Other “basic” WooCommerce blocks are okay to use. So, you have to make that difference in blocks. As you said it’s the standard of using blocks, but it depends on the amount of external (plugin) functionality that is added. It will go in that direction for sure, but it will take more time for the majority of plugin builders. We have to be patience and be happy with the ‘classic’ part that is still working great and stable.