Troubleshooting
This article covers the most common issues with Super Speedy AJAX Prices and how to fix them.
Prices on a draft, private, or scheduled product are not loading via AJAX
This is expected behaviour. Super Speedy AJAX Prices only “ajaxifies” products whose status is Published. Draft, Pending Review, Private, and Scheduled (future-dated) products are deliberately left alone:
- On the page, their price is rendered normally by WooCommerce — it is not replaced with an AJAX placeholder.
- The public AJAX endpoint (
ssap_get_prices) will not return price or stock data for them either.
So when you preview an unpublished product as an administrator, you still see the correct price — it just won’t be swapped in via AJAX. As soon as the product is published, AJAX pricing applies automatically.
Why it works this way. The AJAX endpoint is public (it has to be, so it can run on fully-cached pages for logged-out visitors). If it returned data for unpublished products, anyone could enumerate product IDs and read the prices and stock levels of products you haven’t launched yet — for example an upcoming product, or an embargoed sale price. Gating on Published status closes that information-disclosure gap. The same gate is applied in two places (when the price placeholder is inserted, and again inside the AJAX handler) so the two halves can never disagree, and so admins can always preview real prices on unpublished products.
Prices not swapping on a draft, private or scheduled product is not a bug – unpublished products are deliberately skipped so the public endpoint can never leak the price or stock of an unlaunched product. Publish the product and AJAX pricing applies automatically.
If you genuinely need AJAX pricing on a product, make sure it is Published (not Draft/Private/Scheduled).
Prices show “cached” values briefly before updating
This is by design and is what makes the plugin compatible with full-page caching. The cached page shows the price that was rendered when the page was cached; a fraction of a second later the AJAX request replaces it with the price calculated for the current visitor (their geolocation, tax location, dynamic pricing, etc.). The cached price is kept visible while the request is in flight specifically to avoid layout shift.
If prices never update from the cached value:
If prices never move off the cached value, the usual causes are a JavaScript error from another plugin or the theme blocking the script, or admin-ajax.php being cached so every visitor gets the same response. Check the browser console, and confirm the endpoint is excluded from your cache.
Check your browser console for JavaScript errors. A theme or another plugin throwing a JS error before our script runs will stop the AJAX request firing.
Check the AJAX request is not being cached. Configure your caching/CDN layer to not cache admin-ajax.php requests. If the ssap_get_prices response is cached, every visitor receives the same prices.
Check the product is published (see the section above).
Only some products on an archive page update
The plugin caps how many products are refreshed in a single AJAX request (default 200) to stop a single request from forcing thousands of product loads. On a normal shop or category page you will never hit this limit. If you run unusually large grids (e.g. a single page showing more than 200 products) and need a higher ceiling, a developer can raise it with the ssap_max_products_per_request filter – see the Developer Reference KB article.
Check the setting is enabled. Stock refresh is opt-in: go to Super Speedy > AJAX Prices and tick Refresh stock via AJAX.
Check the same exclusions. Stock refresh follows the same rules as prices — it is skipped for logged-in users and when the cart has items if you have enabled those options, and it only applies to Published products.
Prices are wrong for tax-exempt / VAT-exempt countries
If you entered prices inclusive of tax and you sell into regions with no VAT, add a zero-rate row that matches every other country. In WooCommerce > Settings > Tax > Standard rates, insert a row with the country code left blank (the * wildcard), the rate set to 0.0000, and give it a name such as Zero rate. Put it below your real VAT row.
The row has to be in Standard rates. A wildcard row on the “Zero rate” rates tab looks like the same thing but is a separate tax class, and it does nothing for a product that is not assigned to that class.
Then check the products themselves. If only some products are wrong, look at the Tax class on a wrong one (Product data > General). A product set to Zero rate is telling WooCommerce its price already contains no tax, so nothing is ever taken off and the price displays exactly as you typed it, VAT and all. No amount of rate-table editing fixes that: the product needs its tax class set back to Standard.
That combination is what both stores that reported this to us actually had, and it produces a distinctive symptom – one product on the page correct and the rest carrying the VAT, with no obvious pattern until you check the tax classes.
The underlying reason is that “no matching tax rate” and “a tax rate of zero” are not the same thing to WooCommerce. It needs a rate row to match before it will treat a location as zero-rated. Simple products cope without one, but a variable product’s displayed range does not, which is why a store can look correct everywhere except its variable products.
You can confirm the fix without leaving wp-admin: on Super Speedy > AJAX Prices, use See what each customer sees, pick By country, and compare your base country against one with no VAT. Every row in the zero-tax column should be the base price divided by your VAT multiplier, so a 20% rate turns £49.99 into £41.66. Any row still showing the full price is a product to check the tax class on; if it is only the variable products, it is the wildcard row that is missing.
Comments