Paywall Parity/Guidelines
Run a free audit

Start here

  • Overview
  • Quickstart
  • Safety model

Concepts

  • Store baselines
  • Parity targets
  • Strategies
  • Confidence
  • Drift
  • Protected markets

Workflows

  • Connect a store
  • Review recommendations
  • Stage and publish

Reference

  • Formulas
  • Error codes

Integrations

  • Google Play
  • Apple App Store
  • Revenue signals

Trust and operations

  • Credential custody
  • Methodology

Start here

What Paywall Parity does

The closed pricing loop, what each stage is responsible for, and which stages are live today.

Shipped2 min readReviewed 2026-09-21Markdown

On this page

  • The loop
  • What it reads, and what it changes
  • Who it is for
  • Where the product actually is
  • Where to go next

Paywall Parity turns one question into a repeatable process: what should this subscription cost in each country, and can you defend the answer?

It is not a pricing table generator. It reads the live state of your store, derives a regional target from published economic data, shows the evidence behind every number, and refuses to act when the evidence is weak.

The loop

Each stage hands the next one something specific. Nothing skips ahead.

  1. Import the exact live store state — products, base plans, offers, regional prices, availability.
  2. Calculate a regional target from purchasing-power data, dampened by a strategy you choose.
  3. Explain the target: its inputs, its arithmetic, and its confidence.
  4. Stage a change as an exact diff, checked against the store as it is right now.
  5. Verify what the store actually accepted by reading it back.
  6. Observe what happened afterwards, by product and market.

Stages 1 through 4 are live. Stage 5 exists and is gated behind a release check. Stage 6 is specified but not built — see Where the product actually is.

What it reads, and what it changes

Import and analysis are read-only. Connecting a store, importing a catalogue, calculating targets, and previewing an entire 170-market matrix all happen without a single write to your store.

Writing is a separate, explicitly approved path. It is default-off, it never triggers on a schedule, and an exchange-rate movement can never authorize one on its own. See The safety model.

Who it is for

Developers and studios who sell subscriptions through an app store in more than a handful of countries, and who have noticed that a single USD price converted at spot rate is either unaffordable in half the world or leaving money on the table in the other half.

It assumes you own the store account and can grant API access to it.

Where the product actually is

This documentation labels every page with a status, and the label is not decoration:

  • Shipped — working in production today.
  • Controlled beta — built, tested, and gated behind a release check. Not generally enabled.
  • Planned — specified and agreed, not yet implemented.

A page marked Planned describes something that does not exist yet. That is deliberate: the alternative is discovering the gap after you have committed to a workflow around it.

Today: Google Play is the only supported store. Apple is planned. Revenue-outcome measurement is planned. Store write-back is in controlled beta and rollback is not built.

Where to go next

  • New here? Connect a store and get your first matrix.
  • Want to know what it will never do without asking? The safety model.
  • Trying to read a specific number on a screen? Start with Store baselines and Parity targets.
NextYour first pricing matrix

On this page

  • The loop
  • What it reads, and what it changes
  • Who it is for
  • Where the product actually is
  • Where to go next