• Resolved anabsw

    (@anabsw)


    Hello everyone,

    I am experiencing a fatal UI error that completely blocks the Transactions / Payments screen in WooPayments, showing the message “Oops, something went wrong… error retrieving account tags / disputes”.

    The website went through a period of being outdated with plugin incompatibilities, but everything is currently updated to the latest versions. The error occurs on version 10.8.0 and persists even after downgrading to 10.7.1. Interestingly, the plugin’s Settings page works perfectly fine; the crash only occurs when attempting to load the transaction list/dashboard.

    Steps already taken that did not resolve the issue:

    1. Disabled the multi-currency option (to rule out currency mapping conflicts).
    2. Forced a full re-import of historical data under Analytics > Settings (completed successfully, 0 errors).
    3. Cleared WooCommerce analytics cache, updated the database, and verified core DB tables via WooCommerce > Status > Tools.
    4. Cleared the server Varnish cache (Hosting: Webempresa) and tested using a clean incognito window.
    5. Ran the hosting provider’s automated security diagnostic tool (Stephan) to ensure there are no ModSecurity or firewall IP blocks blocking external API requests.

    Upon loading the page, quick toast notifications appear stating an error retrieving disputes/tags, and immediately after, the screen crashes with the following console trace:

    TypeError: Cannot read properties of undefined (reading 'filter')
    at pf (https://productosjessica.es/wp-content/plugins/woocommerce-payments/dist/index.js?ver=10.7.1:2:607792)
    at Suspense
    at Oe (https://productosjessica.es/wp-content/plugins/woocommerce/assets/client/admin/app/index.js?ver=b1c24d63aa250816182c:2:185538)
    at div
    at div
    at me (https://productosjessica.es/wp-content/plugins/woocommerce/assets/client/admin/app/index.js?ver=b1c24d63aa250816182c:2:179884)
    at div
    at Rac (https://productosjessica.es/wp-includes/js/dist/components.min.js?ver=5dedfe13f08880193a28:9:124282)
    at FC (https://productosjessica.es/wp-includes/js/dist/components.min.js?ver=5dedfe13f08880193a28:9:125036)
    at w (https://productosjessica.es/wp-content/plugins/woocommerce/assets/client/admin/admin-layout/index.js?ver=70ee5a6ed50d37f62db2:1:1981)

    Here is the latest woocommerce-payments API log trace requested:

    2026-06-22T10:12:14+00:00 API REQUEST: GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/disputes?test_mode=0&page=1&pagesize=50&sort=created&direction=desc&limit=100&search%5B0%5D=needs_response&search%5B1%5D=warning_needs_response
    2026-06-22T10:12:14+00:00 API REQUEST: GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/deposits/overview-all?test_mode=0
    2026-06-22T10:12:14+00:00 API RESPONSE: GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/disputes?…
    2026-06-22T10:12:15+00:00 API REQUEST: GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/deposits?test_mode=0&page=1&pagesize=3&sort=date&direction=desc&limit=100&store_currency_is=eur
    2026-06-22T10:12:15+00:00 API RESPONSE: GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/deposits/overview-all?test_mode=0
    2026-06-22T10:12:16+00:00 API RESPONSE: GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/deposits?…

    Current Active Version during this log: 10.8.1

    It seems the React component expects an array from the API response (account tags, features, or disputes) but receives undefined instead, causing the .filter() method to break. This is likely due to stale data/transients left over from the incompatibility period or a synchronization desync with the central WooPayments server.

    Is there a way to completely flush the connection tokens/account cache or safely reset the integration data from the database to force a clean re-fetch of these tags?

    Any guidance would be highly appreciated.

    Thank you!
    Ana

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Hi @anabsw,

    Thanks for the incredibly detailed report. The API log and console trace are genuinely helpful.

    The crash is happening because the React component that renders the Transactions screen calls .filter() on data it expects to be an array (account tags or disputes), but is receiving undefined instead. Your API logs confirm the requests are going out and getting responses, so it’s not a connectivity issue; something in the response structure is malformed or null where the component expects an array.

    Before we dig deeper, one concrete step worth trying: go to WooCommerce → Status → Tools, scroll down to “Clear WooPayments account cache,” and click Clear. This is separate from the general WooCommerce cache you’ve already cleared. It specifically forces a fresh fetch of your account details directly from the WooPayments server, which may resolve the desync you’re describing.

    If that doesn’t help, could you share your full System Status Report (WooCommerce → Status → Get system report) via https://gist.github.com/? That’ll let us identify your account and escalate this to the right team to look at what the API is actually returning for your account on the server side.

    I hope that helps. Let us know how it goes!

    Thread Starter anabsw

    (@anabsw)

    Hi Frank,

    As requested, I’ve created and shared the full WooCommerce system status report via Gist. You can access it here:

    https://gist.github.com/anabsw26/370953b63784e9d9823995dc8583aeee

    Please let me know if you need anything else or if I should take any additional steps.

    Thank you,
    Ana

    Hi @anabsw,

    Thanks for the thorough writeup and for sharing the system report, both are really helpful.

    Could you confirm whether clearing the WooPayments account cache made any difference?

    That said, something in your setup stands out as a stronger candidate: NinjaFirewall is running both as a regular active plugin and as a must-use plugin, which means it’s applying two layers of firewall inspection to every request. Your API log shows the disputes and deposits responses are arriving, but if NinjaFirewall is sanitizing or modifying the response bodies from public-api.wordpress.com before they reach the React component, the component would receive undefined instead of the expected array, exactly what triggers the .filter() crash. This is worth testing directly: temporarily deactivate NinjaFirewall (both the plugin and if possible the mu-plugin version) and reload the Transactions screen to see if the crash clears. Do the same for all other plugin except WooCommerce and WooPayments

    If it does, you’d need to add public-api.wordpress.com to NinjaFirewall’s whitelist or exclusion rules rather than leaving it permanently disabled.

    If it doesn’t, please let us know.

    Thread Starter anabsw

    (@anabsw)

    Hi Frank, 🙂

    Thank you very much for your detailed response and for taking the time to analyse the issue so thoroughly.

    I really appreciate your guidance regarding NinjaFirewall and the suggestion to test with a fully clean plugin environment. I followed those steps carefully:

    • I completely deactivated NinjaFirewall from the WordPress dashboard.
    • I also confirmed that there was no active MU-plugin version running.
    • I tested the site with only WooCommerce and WooPayments active.
    • I cleared the WooPayments account cache as suggested.

    However, the issue persisted even under those conditions, with the same behavior in the Transactions screen.

    After continuing the investigation on my side and reviewing server behavior and logs, I found that the root cause was actually related to server-side PHP execution limits rather than plugin-level interference.

    In particular, the environment had relatively low execution constraints:

    PHP

    • max_execution_time was set to 30 seconds
    • max_input_time was 60 seconds
    • memory and related limits were also quite restrictive for WooCommerce Admin workloads

    After increasing these limits (especially raising max_execution_time to 300 and adjusting memory/input limits accordingly), the issue with the Transactions screen and the invalid_json errors was fully resolved. Final conclusion

    From what I was able to observe, the root cause was not related to NinjaFirewall or any manipulation of responses from public-api.wordpress.com, but rather to PHP requests timing out before completing, which led to:

    • Interrupted REST API responses
    • Incomplete JSON being returned to WooCommerce Admin
    • The React component receiving undefined instead of expected arrays, causing the .filter() crash

    Even so, I truly appreciate your suggestion regarding NinjaFirewall, as it helped me rule out a potential layer of interference early in the process. It was a very helpful direction to explore.

    I hope this summary can also be useful for other users who might encounter similar symptoms, since from the outside it can easily look like a plugin/API issue when in reality it may be related to server execution limits under WooCommerce Admin workloads.

    Thank you again for your time and support.

    Kind regards,
    Ana 🙂

    Plugin Support shahzeen(woo-hc)

    (@shahzeenfarooq)

    Hi @anabsw!

    Thank you for taking the time to investigate this issue so thoroughly and for sharing your findings with us.

    I’m glad to hear that you were able to identify the root cause and resolve the issue by increasing the PHP execution limits. Your explanation makes a lot of sense, and it’s helpful to know that the invalid_json errors and the Transactions screen issue were ultimately caused by PHP requests timing out before completing, resulting in incomplete REST API responses.

    Before you go, If you found Woopayment plugin helpful for your store, we would really appreciate it if you could leave a five-star review here: https://wordpress.org/support/plugin/woocommerce-payments/reviews/#new-post. Your feedback helps us improve and lets other users know how WooCommerce can support their business.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.