Ingo Steinke (openmindculture)

The error happens again (erratically). Solution: switch to Matomo, increase privacy, don’t waste any more time with Google Analytics.

Thanks!
I just checked again and can’t reproduce the error anymore either. It seems that the plugins had been updated after my last comment, so this has probably been fixed, regardless which Google-related plugin wrote that.

As this is still unanswered and unfixed 3 months later, I consider recommending my customers to switch to Matomo.

Thanks, good to know!

Thanks Ernest, that solved our problem!

For everyone who wants to change the setting programmatically, we can also use the WP CLI, e.g.

wp option patch update asl_options maxresults '20'

P.S.

I was able to narrow down the errors. With Impreza + WPBakery, dragging rows in not working (the row event handler is missing). Without Impreza, latest WPBakery + Twenty Twenty-Four Theme works as expected.

As I don’t have a login to Impreza support forums (only my customers have), maybe someone could open the issue on our behalf.

P.S.

I was able to narrow down the errors. With Impreza + WPBakery, dragging rows in not working (the row event handler is missing). Without Impreza, latest WPBakery + Twenty Twenty-Four Theme works as expected.

As I don’t have a login to Impreza support forums (only my customers have), maybe someone could open the issue on our behalf.

Thanks, I will have to evaluate possible solutions.

Still unanswered, if/why/where Sift (fraud detection?) is needed or if it is safe to turn it off?

Hi @gondia123, the plugin is not ready for production yet!

DO NOT USE IT IN PRODUCTION!

But if you want to test, I uploaded a zip file at the (possibily broken) pre-release 1.1.2: https://github.com/openmindculture/wp-contact-form-inbox-report-mailer-plugin/releases/tag/1.1.2

Please see the open issues!

I did not manage to make WP_Cron send mails regularly yet on different testing sites, although some mails have been sent irregularly. If you want to contribute to the plugin, feel free to do so!

After the latest updates to WooCommerce, Germanized, and WooCommerce PayPal payments, are all PayPal payments now supposed to work with WooCommerce block checkout when using the latest plugin versions, including WooCommerce PayPal payments 2.5.4 ?

What’s the current status and planned updates for PayPal vaulting? If I understand the plugin’s changelog correctly, there has been some critical changes that have been rolled back concerning Vaulting? Fix – Can not refund order purchased with Vault v3 Card payment #1997. Does this mean the current plugin version uses PayPal Vault version 3 or not? Is the problem expected to be solved in the current release, WooCommerce PayPal Payments 2.5.4 ? Is there any additional action necessary or recommended to repair existing customers’ database entries or PayPal data?

Thanks!

Thanks so far!

Can the problem be caused by customers who do a single purchase with PayPal payment as guests without a shop customer account and who only create their shop customer account when using the same PayPal account to place a subscription order in the same shop later?

The above scenario is currently possible, as customers can buy as guests as long as they do not place subscription orders. This works well for users who use credit cards instead of PayPal.

Does this plugin store a token or a corresponding reference or key in the shop’s database? Where can we verify if the shop part is working correctly?

Some further details from log files and order history:

Typically, the absence of a payment token is not caused by the plugin.

It looks like the customers do have a token on the PayPal server. Verified from both sides: the user can also see the active recurring payment in their PayPal account.

Log excerpt for problematic payments:

https://api-m.paypal.com/v2/checkout/orders
Request Body: {“intent”:”CAPTURE”,
…
{“user_action”:”CONTINUE”,”shipping_preference”:”GET_FROM_FILE”
…
“return_url”:”[…]?wc-ajax=ppc-return-url”
“payment_method”:{“payee_preferred”:”IMMEDIATE_PAYMENT_REQUIRED”}
Response: Array
(
[code] => 201
[message] => Created
)
…
POST https://api-m.paypal.com/v1/identity/generate-token
Response: Array
(
[code] => 200
[message] => OK
)

vs. log excerpt when generating token for new customer:

POST https://api-m.paypal.com/v1/identity/generate-token
Response: Array
(
[code] => 200
[message] => OK
)
…
POST https://api-m.paypal.com/v1/notifications/verify-webhook-signature
Request Body: …
"event_type":"VAULT.PAYMENT-TOKEN.CREATED","summary":"A payment token has been created."

The explicit token created event seems to be missing when existing customers place their orders and allow subscriptions, while it works when new customers place their order in a seemingly identical way.

When recurring payments fail, I can't find any explicit error in any log file, but WooCommerce order history shows:

"Payment failed. No payment tokens found for customer 8. Status der Bestellung von Zahlung ausstehend auf Fehlgeschlagen ge?ndert."

(German text part translates to: order status changed from pending payment to failed.)

So what is the proper way to deal with "typically" and seemingly situation of the existing customers? Can we find additional logs or meta information somewhere else? Any other helpful ideas?

This is still not working. I will follow-up researching more details when I find time. Helpful suggestions are appreciated, if anyone has been able to solve a similar problem.

• This reply was modified 11 months, 1 week ago by Ingo Steinke (openmindculture).