Partner agency. Store trugrit.com, migrated from WooCommerce, launched Jul 24. During launch week a handful of customers got a blank page containing only the text “Request Forbidden” when clicking Checkout. We have it on video from the merchant’s own Chrome, with the URL visible:
Tru-Grit…&preview_theme_id=183171842350&skip_shop_pay=prompt_allowed
skip_shop_pay=prompt_allowed means the rejected request was the return leg from shop.app, not the first click.
What I’ve established so far:
- Not Cloudflare: DNS-only to 23.227.38.65 on both hostnames (audit log confirms the proxy was on for 2 minutes on launch day, nothing since).
- Not cookie size: 20 KB of cookies passes; 40 KB gets nginx’s “400 Request Header Or Cookie Too Large”, never this page.
- Not the theme: standard cart form POST.
- Not the URL: rebuilt the bare host, preview_theme_id, skip_shop_pay and no-query-string variants in a real browser; all render.
- Not the styled “Access denied” edge page. This is unstyled text, which suggests the checkout app itself (the clone endpoint’s server-timing shows verdict_flag_enabled).
- The store converts 72% of logged checkout clicks into orders, so whatever this is, it’s rare.
Context that may matter: the store served on the bare domain until Sep 21, when the primary was switched to www. Reports were concentrated in launch week while the merchant was doing heavy admin work from the same network.
Questions:
-
Which component emits a bare “Request Forbidden” body on /checkouts/*? Is that the checkout request-screening (verdict) path?
-
Is there any route to get a specific request looked up by cart token and timestamp, short of merchant support? We’ve opened a Partner Support ticket; curious whether anyone has had that succeed.
-
Has anyone seen migrated stores trip this in their first weeks?
Video of issues: