Forum Replies Created

Viewing 15 replies - 1 through 15 (of 31 total)
  • Thread Starter robertrosanke

    (@robertrosanke)

    Thanks for the info.
    We’ll stick with the manual solution for now and hope for a fix soon.

    Thread Starter robertrosanke

    (@robertrosanke)

    Thank you for the new update. We are happy about this news and are eagerly awaiting the corresponding entry in the plugin changelog.

    We appreciate that you have discussed the whole issue internally again and are ready to make this change.
    Thank you for your help.

    Thread Starter robertrosanke

    (@robertrosanke)

    Quick question: Will the issue be resolved in the next plugin update?

    Note: wp_enqueue_script() now also natively supports async behavior via $args['startegy'=>'async']. It is no longer necessary to manipulate the tag before output.

    Thread Starter robertrosanke

    (@robertrosanke)

    Thanks for the info.
    I really appreciate that you have created a feature request.

    I’m just wondering if it’s worth spending hours studying the Klaviyo documentation and developing my own script to send events, or if I’d rather wait for a plugin update from you and solve the issue without much effort.

    I would like to wait for the plugin update, as long as it doesn’t take too long. That should be the most economically efficient.

    How long should it take until you have integrated a php filter and rolled it out via a plugin update?

    Thread Starter robertrosanke

    (@robertrosanke)

    Thank you!

    Thread Starter robertrosanke

    (@robertrosanke)

    Hello.

    Thank you for contacting the developer.
    We appreciate the positive feedback and will keep an eye on the plugin changelogs.

    Our support will be happy if failed orders are also handled automatically for orders via Klarna, leaving more time for the really important tasks.

    Thank you!

    If no more input is required from our side, you are welcome to close the ticket.

    Regards
    Robert

    Thread Starter robertrosanke

    (@robertrosanke)

    I would like to point out once again that the other payment service providers, as far as we are aware, automatically set the order to “failed”. I think it would be a great thing if the plugins of the major payment providers all handled such a case in a similar way. This should make it easier for store operators because a kind of standard behavior is expected and understood.

    Thread Starter robertrosanke

    (@robertrosanke)

    Thank you for your feedback, we have given it some more thought.

    It is WooCommerce standard behavior to create a Pending Payment order in the background when the payment process starts, […].

    That in itself is perfectly fine. It would just be good if Klarna adjusted the status of the created order accordingly after Klarna recognizes that the payment has failed.

    We have analyzed the code of the Klarna plugin. We noticed that Klarna recognizes errors. E.g. in KP_AJAX::kp_wc_auth_failed(), the plugin sets the error message that we have for some failed payments.
    However, there are also other methods that Klarna uses to communicate errors via $order->add_order_note().

    As I said: It would be good if Klarna could automatically change the order status to “failed” if there are problems with the payment.
    If you don’t want to do this, then it would be good if there was an action hook for an individual reaction to errors or a filter, or perhaps simply a plugin setting that can be used to optionally define the order status that failed Klarna orders should have.

    Examples:

    • do_action(‘kp_wc_order_payment_failed’, $order): Fire in any situation where Klarna plugin has set the order_note and completed the handling of a failed payment. Third parties can then react according to their own wishes.
    • apply_filter(‘kp_wc_order_payment_failed_status’, null): Instead of an action hook, you can also change the WooCommerce status automatically if a developer specifies this via the filter and the filtered value is not null.

    If you set an amount of time in the WooCommerce Hold stock feature (minutes) you do not have to worry about the Pending Payment orders. They will be automatically set to cancelled if they have not been paid for within the set minutes.

    We don’t want that.
    It’s not about people not wanting to buy. It’s about the fact that something sometimes doesn’t work when paying via Klarna.
    The customer doesn’t seem to notice. Neither do we. The customer doesn’t want to cancel. So the “hold stock” setting does not correspond to our objective.

    Conclusion:

    It would be good if you could help us to integrate your plugin in a meaningful way.

    To be honest, there is no point in automatically canceling orders that may not be paid due to a technical error. Nor does it do us any good to leave them on “Pending payment”.

    Payment services should clearly and simply indicate when something fails. There is a failed status for this purpose, which other payment providers also use.

    The official plugins from Stripe and PayPal solve this much better. We would be delighted if Klarna were to follow their example.

    If you don’t want to implement this, then I respect that. Nevertheless, it would be nice if you could help us and other plugin users to implement such a status change behavior when a Klarna order has payment problems.

    The best way to do this is via an action hook that you ALWAYS fire after you have registered and handled a payment error. Third parties can then intervene and adapt the behavior to their needs.

    Alternatively, a plugin setting could also be sufficient and you can change the order status yourself if a user has set the setting and a payment has failed. I assume that other Klarna customers will also benefit from this. If you want to automate processes, you won’t get very far with the current approach of the Klarna plugin.

    Thread Starter robertrosanke

    (@robertrosanke)

    Thanks for the clarification.

    I believe that several inaccuracies lead to the problem.

    Firstly, Klarna seems to be storing orders in the WooCommerce system that a customer (maybe) does not want to make (with Klarna).

    Secondly, Klarna does not communicate failed orders via the order status.

    Now one after the other.

    Problem 1: Orders are saved when a customer cancels the process in the Klarna popup

    “As soon as the customer clicks on Pay order button and Klarna modal opens a Pending Payment order is created in WooCommerce and if the customer do not pay the order the status remains as Pending Payment on the WooCommerce order.”

    As far as I observed it, the official PayPal plugin, for example, only creates an order once the customer has completed the payment process. If I want to buy with PayPal and cancel the process in the PayPal popup, the order is not even created and the user ends up back in the WooCommerce checkout.

    This is logical for me and expected behavior.

    Regardless of whether the customer wants to cancel the order completely or spontaneously decide on a different payment method: the checkout is the right place for the customer to help themselves.

    In the checkout, they can simply close the tab and end the order process. However, they can also simply change the payment method and continue.

    Klarna should proceed in the same way instead of creating an order that is “pending” and leaving the customer and the shop operator in the lurch.

    Problem 2: Failed payments are not communicated via the order status

    “We can not set the order status to failed because we do not know why the order was not paid for.”

    In case of doubt, it doesn’t matter.
    If it didn’t work, it didn’t work.
    And that should be communicated via the order status, I think.

    “We can not set the order status to failed because we do not know why the order was not paid for. If the customer just did not have enough money and wants to pay for the order later, if the customer choose not to pay for the order or if an issue appeared in the checkout.”

    The chosen Klarna method has nothing to do with the order status in WooCommerce.
    If a customer agrees to “pay later” with Klarna, the order will still be set to “in process” in order to be shipped directly.
    The actual payment from the customer to Klarna has nothing to do with the WooCommerce status.

    This applies to all well known payment services that offer customers their own options for more convenient, later payments, or am I wrong?

    So it would be good – if an order fails – to also set the status to failed.
    Then we get the error and can take action.

    At the moment, we should apparently look at every order with “Payment pending” manually and then act manually, depending on what the order notes say?
    Who is supposed to manage this in a store with many orders?

    We have an email template with the order payment link.
    We would like to send this automatically if an order fails.
    No matter which payment method was used.

    Currently it works with all payment methods except Klarna.

    How should we act automatically if Klarna does not inform us via the status change that the order has failed?

    As I said, other payment methods set the status to “failed” in such a case and the issue is resolved.
    We expect the same from Klarna.

    What solution do you suggest?

    Thread Starter robertrosanke

    (@robertrosanke)

    I’m not sure what the billing address/country has to do with the users’ language.
    But good.
    Apparently we can’t change it.
    If it cannot be changed, then the ticket can be closed.

    Thanks for the support.

    Thread Starter robertrosanke

    (@robertrosanke)

    Thanks for the support. Excellent.

    Thread Starter robertrosanke

    (@robertrosanke)

    Thank you.

    robertrosanke

    (@robertrosanke)

    It is not absolutely necessary to send the data via the data layer.

    Depending on the WPML setting, you can read the language from the URL. Or from a cookie called “wp-wpml_current_language”.

    To do this, you can create a variable in GTM that reads the data.

    For example, custom JavaScript can be used as a variable configuration.

    For example, we have the following URL structure

    • /en/… => EN
    • /fr/… => FR
    • /… => DE (original language in WordPress, does not have its own folder on our wpml setup.)

    The following JS is a GTM variable and checks if the URL path starts with one of the active WPML language codes. If yes, then it will be returned. On the other hand, the original language DE is returned.

    function() {
      var path = window.location.pathname;
      
      var allowed = ['de','en','fr'];
      var parts = path.split('/');
      var firstFolder = parts[1];
      if(!allowed.includes(firstFolder))
        return 'de';
      
      return firstFolder;
    }

    Maybe this will help. You may have to search around on Google to find out how to write the appropriate JS for your GTM variable and how to debug its value with the GTM preview.

    Thread Starter robertrosanke

    (@robertrosanke)

    Important: The problem here only exists if events are processed on the server side tagging container. If you don’t use SST, you shouldn’t have any problems in this regard.

    Thread Starter robertrosanke

    (@robertrosanke)

    Hello.
    Do you have an update on this topic?

Viewing 15 replies - 1 through 15 (of 31 total)