Media and Publishing: Verifying Paywall and Subscription Gates Render Correctly

A paywall has exactly two failure modes, and both cost money. Show the full article to a logged-out visitor, and subscribers stop seeing a reason to pay. Block a paying subscriber from content they've already paid for, and they churn without ever filing a support ticket about it — they just leave. Both failures are visual: the page rendered wrong for the account state it was serving. Neither shows up in a server-side uptime check.

Why This Needs a Visual Check, Not Just a Functional Test

A paywall's logic can be entirely correct on the backend — the right entitlement check, the right subscription status — and still render wrong visually because of a CSS regression, an ad blocker interacting badly with the paywall script, or a caching layer serving a logged-out version of a page to a logged-in session. A screenshot of what actually rendered is the only way to catch that class of bug.

Capturing Both States

The logged-out state is a plain capture of the public URL:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example-news-site.com/articles/latest-story",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

The logged-in, subscribed state follows the same pattern as any other authenticated capture — point the request at a URL that's already session-valid for a test subscriber account, the same approach covered in How to Screenshot a Login-Protected SaaS App.

What to Look For in Each Capture

• Logged-out capture: the paywall overlay or truncation should be visible, and the full article body should not be readable below it.
• Logged-in (subscriber) capture: the paywall overlay should be absent, and the full article should render without a truncation cutoff.

If either of those is backwards, that is exactly the kind of regression worth catching before a subscriber notices.

Turning This Into a Standing Check

Capture both states for a small set of representative articles on a recurring schedule, and diff each new pair against a stored baseline with v3/compare:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v3/compare \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "before": {"imageUrl": "https://cdn.example.com/baselines/paywall-loggedout.png"},
    "after": {"url": "https://example-news-site.com/articles/latest-story", "width": 1440, "fullSize": true, "hideCookie": true},
    "threshold": 0.1
  }'

A meaningful mismatch on the logged-out baseline is worth a look — it could mean the paywall stopped rendering, or it could mean a legitimate layout update that just needs a refreshed baseline.

Where to Run This

The natural trigger points are a deploy pipeline (run both captures as part of a release check, alongside any other visual regression gates) and a recurring schedule (to catch a caching or CDN-layer regression that a deploy-time check wouldn't see, since those often surface hours or days after a release).

For publishers running a paywall, Snapshot Site turns "did the paywall actually work today" from an assumption into something checked automatically.