robertrosanke

Hello @mosesmedh ,

We tested the update to 9.9.2 today and it fixes the display issues. Thank you very much for your quick response and the speedy update by the plugin developers.

Have a great week!

Hello Sai,

Thank you for your response and patience!

We have reconnected Stripe and there do not appear to be any issues at first glance.

The communication in the UI was somewhat misleading. When I disconnect an account, the plugin tells me that I need a new Stripe account if I want to reconnect. Perhaps you could improve the wording for the disconnect/reconnect process to better support users during this procedure.

The ticket can be closed. Thanks for your help.

Hello @klarna ,

thanks for the update.

A cronjob could probably help us, yes.
But I don’t understand why every store owner who wants to use Klarna via your plugin has to program it manually.

An out of the box solution should be much more efficient and valuable for your customers.

For example, you could add a function in the plugin settings: Automatically set orders to “failed” after x hours. Anyone who activates this option already knows why they are doing so, and that’s the end of the matter.
You could also create an entry in the order notes that informs the shop operator that the order has automatically been set to failed because Klarna has not given the green light for x hours.

That’s the end of the matter, without adding manual effort for every store operator.

@louisekrokedil :

To be honest, I was confused about the link you showed (https://docs.krokedil.com/krokedil-general-support-info/pending-payment-orders-and-held-stock/).

I don’t like what the “Changed pending payment orders” section says about creating multiple orders for just one customer.

Earlier in this thread I described how PayPal, for example, simply sends the user back to the checkout if you cancel in the PayPal popup and there are not multiple orders in the system for this one customer.
Especially if you want to automate processes, in this case e.g. the payment reminder in case of problems, it worries me that a customer with one checkout process may have two orders in the WooComerce system.

The “second order” may go through as paid, while the “first”, pending order is then set to failed by the cronjob and the customer receives a message that the payment has failed and they should pay again.

I can hardly tell my customer, for whom I’m writing this thread, about this behavior without him thinking I’m joking.

It’s not meant to be malicious. It’s more like honest feedback so that we can initiate improvements together.

I also have customers who wouldn’t care about the behavior because they only have a few orders and process them manually.

However, anyone who relies on reliable automation is probably not satisfied with the current situation. It seems immature compared to other payment solutions for WooCommerce (PayPal, Stripe).

Hello @doublezed2 ,

Unfortunately, even with rollbacks up to version 9.4.0, I couldn’t find out when the problem started.
It may have existed for some time, and we only noticed it recently.

Perhaps we can relabel the topic from “Error” to “Suggestion for improvement”.

Proposal

It would be good if there were a PHP filter that allows developers to choose between a server-side and a client-side preselection of a product variant for product pages of variable products with attribute_pa_* properties in the query parameters.

Use case

The use case clearly relates to online stores that send users directly to product pages that preselect properties via URL.
This is common for Google Shopping Ads, for example. Performance is important there, so we as store operators are very interested in delivering such specific variant page views via cache (e.g. via WP Rocket).
We therefore cache a product page without preselection and deliver this cached version, regardless of which query parameters are in the URL.
To ensure that the whole process runs smoothly, the product variant should then be selected on the client side via JavaScript after the cached product page has been delivered.

Implementation

By default, it can remain as it is.
On the server side in wc_dropdown_variation_attribute_options(), select the variants that can be read in the URL.

If the filter described above is used by a developer to perform the preselection on the client side, the following should happen:

1.) The function wc_dropdown_variation_attribute_options() or its caller ensures that only the product variation defined as the preferred variant in the backend is marked as “selected” in the HTML on the server side and delivered. (Or no variation if no preferred variation has been defined by the store operator). The query parameters in the URL are therefore ignored during server-side HTML generation.
2.) On the client side, i.e. via JavaScript, the possibly existing query parameters in the URL of a product page should be synchronized with the selectable product properties. This means: If, for example, ?attribute_pa_color=red is in the URL, then the WooCommerce JavaScript should automatically select the red product variant, if possible.

Here is an example of JavaScript code that only refers to the color example.
If you were to implement it ready for production, you would probably first go through all the properties in the add to cart form in a loop, then check the query parameters associated with the individual select fields and set any values found accordingly via JavaScript.

function initSingleProductPageVariationsForm() {
	const searchParams = new URLSearchParams(window.location.search);
	const COLOR_ATTR = "attribute_pa_color";
	const queriedValue = searchParams.has(COLOR_ATTR) ? searchParams.get(COLOR_ATTR) : '';

	const selectField = document.querySelector('form.variations_form.cart select[name="' + COLOR_ATTR + '"]');
	if (!selectField) return;

	let isQueriedValueAvailable = false;
	const selectedIndex = selectField.selectedIndex;
	for (let i = 0; i < selectField.length; i++) {
		const option = selectField.options[i];
		isQueriedValueAvailable = queriedValue === option.value;

		if (isQueriedValueAvailable) break;
	}

	selectField.value = queriedValue && isQueriedValueAvailable ? queriedValue : "";

	selectField.dispatchEvent(new Event("input", {
		bubbles: true
	}));
	selectField.dispatchEvent(new Event("change", {
		bubbles: true
	}));

	console.log({
		isQueriedValueAvailable,
		queriedValue,
		selectField
	})
}

jQuery(function() {
  initSingleProductPageVariationsForm()
});

We, and presumably many other online store operators, would be happy to see an improvement in WooCommerce in the future.

If the proposed improvement lands, then caching plugins, such as WP Rocket, can automatically and safely ignore URL parameters in the style of attribute_pa_* on product pages, so that many stores should generally benefit from this improvement in terms of loading time and thus also conversion rate.

Hello @louisekrokedil ,

Thank you very much for keeping your word and publishing the long-awaited update at the beginning of the year.

Regarding the error rate for orders with Klarna: To be honest, I don’t think the problem is just ours either.

@janez33 also wrote, see above, that almost 20% of their Klarna orders don’t go through. So the problem with the inexplicable cancellations doesn’t just seem to affect us.

Klarna was by far our biggest problem with payment service providers in 2024 and we want to see an improvement now before we invest any more time.

We will therefore first check to what extent the new update runs smoothly and supports our automatic processes. Then we can still take care of the error rate.

@louisekrokedil Regarding the order note: I would like to agree with @janez33 here. I cannot confirm that customers cancel an order and that this is the reason for the order note.
We have the note on many failed orders. According to their own statements, customers have not canceled and even ask us why the order has not yet arrived. So they definitely don’t want to cancel on purpose. There may be a technical error along the way that none of us or the customers are currently aware of.

None of us or our customers can explain it.

It is WooCommerce standard behavior to create a Pending Payment order in WooCommerce when the payment process starts.

At this point I would like to give some inspiration on how PayPal solves the issue in Woocommerce. Just a different perspective.

If the customer clicks on “Buy” in the checkout, the PayPal popup opens.
If canceled within the PayPal popup, the user returns to the checkout and the order does not exist in the WooCommerce backend.

This “PayPal approach” has worked for us in our store for years without any problems.
We have had no problems with PayPal orders and everything runs smoothly.

We are currently working on a new workflow to use the failed order status in WooCommerce and the release is planned for early next year. Thanks for giving us all details on this!

We would like to thank you for taking this issue seriously and optimizing it. This will help us and many other store operators to use Klarna. And that will certainly help Klarna too.