verified — no action The iolo20 default is load-bearing, and it is the platform default

An empty couponCode is not harmless: System Mechanic comes back $54.95 / $54.95, SaveAmount 0. WordPress never sends one because mu-plugins/iolo-varnish-compat.php injects SIC = base64(“iolo20|None”) in memory whenever the cookie is absent — the same default the Varnish VCL used (aW9sbzIwfE5vbmU=). Astro’s hardcoded iolo20 reproduces that edge default rather than inventing one.

What to do: None. Just never let the default fall out — a missing coupon quotes list price.

breaks parity — needs a decision Upgrade-segment visitors are quoted the Purchase tier

The ten UPGRADE segments (030 040 050 060 066 067 073 160 162 163) have no entry in the pricing script’s ownership map, so tier selection falls through to purchase — while CartLinks does know them and sends the same visitor to upgrade.aspx. WordPress derives both from one license_state, so it quotes the Upgrade tier. The two tiers are identical for every product we sampled, so nothing is visibly wrong today, but the logic is inconsistent with our own CTA.

What to do: Decide whether upgrade segments should read the Upgrade tier; if so, mirror <code>CartLinks</code>’ segment list into the pricing script.

breaks parity — needs a decision Tier is chosen per request in WordPress, per product here

WordPress derives one license_state from the segmentid cookie and applies that tier to every price on the page. Astro compares the owned product to each rendered code instead. Concretely, a System Mechanic owner (011) on /products/system-mechanic/ sees Renew pricing on all three editions under WordPress, but Renew on SM and Upgrade on Pro / Ultimate Defense here.

What to do: Confirm the intended commercial behaviour with the commerce team, then align one side. Ours is the more granular model, but it is not what WordPress does.

breaks parity — needs a decision A ?coupon= does not survive navigation

WordPress turns ?coupon= into a 30-day SIC cookie on any page load, so the coupon follows the visitor through the site. Astro only persists a coupon from the /coupon/<code>/<path>/ URL form; a plain ?coupon= applies to the landing page and is then lost on the next click. This is separate from the query-param forwarding that was deliberately removed — WordPress uses a cookie, not URL rewriting.

What to do: Confirm the intent. If coupons should stick, write the SIC cookie from <code>?coupon=</code> (cookie only, no URL changes).

check before shipping The rewritten WP class defaults an unknown visitor to segment 050

class-iolo-pricing.php falls back to SegmentID::NON_SM (050) when no segmentid cookie exists, which resolves to UPGRADE and rewrites every CTA to /purchase/UpgradeHelpStartJump.aspx. Live production does the opposite: an anonymous visitor gets the ordinary secure1 cart (verified on /products/system-mechanic/, where the only UpgradeHelp links are static nav items). Astro follows production — no segmentid cookie means PURCHASE and a normal cart link.

What to do: Flag to whoever owns that rewrite; as written it would push anonymous buyers out of the cart.

intentional Locale & currency are USD-only in practice

The WP class carries full country→locale→currency maps, but a non-USD request to this SOAP service answers Code -1 “PriceItemInfo not found” (verified with locale=en_GB, currency=GBP). Non-USD pricing lives in the PPG path, which prod has switched off (IOLO_USE_PPG=false). Astro therefore sends no locale or currency at all.

What to do: No action. Revisit only if PPG is ever enabled.

do not switch The REST source returns a different (older) catalog

GET api.iolo.com/pricinginfoapi/Pricing/StickyProductProperties/sm answers IOLO_SMSTD_1Y at $49.95/$39.95, while the SOAP service answers IOLO_SMSTD_1Y-V2024 at $54.95/$43.94 — the SOAP numbers are the ones live on iolo.com. Prod runs IOLO_USE_SOAP=true for exactly this reason. The REST host also sends no CORS headers.

What to do: Keep using SOAP. Do not “modernise” to the REST endpoint without a catalog fix on the API side.

behavioural No server-side response cache

WP caches every response in a WordPress transient for 2 hours and can prefetch all products in one parallel curl_multi batch. A static site has no server to cache on: each visitor’s browser makes its own calls (deduplicated per GUID+coupon within a page load).

What to do: Acceptable today. If svc.iolo.com load becomes a concern, add a CDN-cached JSON snapshot endpoint.

no impact Apex domain is not CORS-allowlisted

svc.iolo.com echoes an allow-origin for https://www.iolo.com and https://stage1.iolo.com only — not for https://iolo.com. The apex 301-redirects to www before any page script runs.

What to do: No action.

intentional GeoIP header is not consumed

WP reads nginx’s HTTP_X_COUNTRYNAME to pick a locale server-side. Astro pages are prerendered, so there is no request to read it from.

What to do: No action while pricing is USD-only.