jackshao1981

Because the same setup works on staging but fails on production, I would first test whether the production server can fetch Revolut’s Apple Pay domain association file at all.

Useful checks:

1. From the production server, test a direct request to the Revolut URL that appears in the error.
2. Compare the result with the same request from staging.
3. Check whether production has a firewall, security plugin, outbound HTTP restriction, DNS difference, IPv6 issue, or SSL/CA bundle issue that could block assets.revolut.com.
4. Check WooCommerce / WordPress logs at the exact onboarding timestamp for the HTTP status or cURL error returned by the fetch.

If staging can read the file and production cannot, the likely next step is to identify the production-only network/security difference rather than re-running onboarding repeatedly.

For the plugin author, the most useful evidence would be: production HTTP status/cURL error for that URL, staging result for the same URL, and whether other outbound HTTPS requests from production work normally.

Hi, one useful next step may be to continue this in the WooCommerce PayPal Payments support forum too, since the plugin support reply above says the current site appears to be using that plugin rather than this one.

Before reposting or continuing there, I would try to make the reproduction case narrower so the PayPal/WooCommerce side has something concrete to compare:

1. Run one Android test with WP Rocket JavaScript delay/defer fully disabled, not only with the PayPal SDK excluded. That helps rule out a delayed checkout fragment or shipping recalculation script.
2. Record whether the WooCommerce customer/session country is still DE immediately before opening PayPal and whether it changes after returning from the PayPal mobile flow.
3. Test with one simple physical product, no custom shipping class, and only one Germany free-shipping method enabled.
4. Include the exact woocommerce_rest_invalid_address_country log entry, Android browser/user agent, and whether the flow opens PayPal in browser or through an app handoff.

The most useful clue seems to be whether WooCommerce has the correct country before PayPal and then receives or recalculates with US after the Android PayPal return. If that is reproducible, it should make the issue easier to route to the correct plugin/support team.

Since the duplicate reminders are sent at exactly the same time, I would try to separate two possibilities:

1. The reminder job is being triggered twice.
2. The reminder job is triggered once, but the SMTP layer sends the same message twice.

A few low-risk checks may help narrow that down:

1. Check whether both duplicate emails have the same subject, recipient, timestamp, and message ID. If your SMTP plugin logs outgoing emails, compare the two log rows. If there are two different SMTP log rows, the duplicate likely happens before or inside WordPress. If there is one SMTP log row but the customer receives two emails, the issue may be downstream from WordPress.

2. Check WooCommerce > Status > Scheduled Actions and search for CusRev/review reminder related actions around the exact time the duplicate emails were sent. If there are two matching scheduled actions with the same order/customer/time, that points to duplicated scheduling.

3. In the Customer Reviews settings, confirm there is only one active reminder rule/campaign for the same order status and timing. Also check whether both an automatic reminder and a separate follow-up/reminder option could match the same completed order.

4. If possible, test with one internal test order and one internal email address. Move the order through the same status path once, then record whether one or two reminder actions are created before the email is actually sent.

5. Since you mentioned WP SMTP, I would not assume it is the cause yet, but I would keep its email log enabled during the test. The key evidence is whether WordPress creates two outgoing email events or only one.

If you can share a redacted screenshot of the relevant reminder settings and the matching Scheduled Actions rows around the duplicate send time, it should be easier to tell whether this is duplicated scheduling, duplicated order-status triggering, or duplicated SMTP sending.

This looks like an Analytics import / Action Scheduler queue issue rather than a normal report-filter issue, especially because both Analytics and old reports show 0 and the import gets stuck.

I would check it in this order:

1. In WooCommerce > Status > Scheduled Actions, filter for failed / pending / past-due actions and look for analytics/import-related actions around the time the import was started. If there are many actions older than a day, that can point to a WP-Cron or queue runner issue.
2. In WooCommerce > Status > Tools, run Clear Analytics Cache, then go back to Analytics > Settings and try importing only a very small date range first instead of all history.
3. If the small range also gets stuck, check WooCommerce > Status > Logs for fatal errors at the same timestamp as the stuck import. The useful clue is usually the first fatal/error before the import stops, not the repeated stuck-action entries afterward.
4. If the small range works, import historical data in smaller windows, for example by year or quarter, with “skip previously imported customers and orders” enabled for overlapping ranges.
5. Before deleting/reimporting analytics data, confirm you are only deleting imported analytics/reporting data, not orders/products/customers. WooCommerce’s Analytics docs say deleting previously imported data is for analytics data only, but I would still take a backup first.

If you can share the exact failed action hook name and the first related fatal log line, it should be possible to narrow this down further.