TollGate

1. One-liner

Files your web-checkout sales to Apple and Google on time, and proves the commission you paid was right.

2. Trend signal — why now?

Two years of antitrust rulings finally handed app developers the thing they’d been demanding: the right to link users out to their own web checkout. Then both stores quietly attached an invoice to the gift, and made the developer responsible for writing it.

Apple. Developers using the External Purchase Link Entitlement must file a report through the External Purchase Server API within 15 days after the end of each calendar month. The report must contain all tokens, regardless of whether they resulted in a completed transaction, including refunds, corrections, renewals, one-time purchases, and transactions that didn’t lead to a purchase (Apple, App Store Connect Help). Commission is 12% under the Small Business Program, 27% otherwise, on purchases made within a seven-day attribution window from the link tap. Miss the filings and, per implementation guides, “missed reports are the most common reason entitlements get revoked… if your reporting is late or incomplete, your entitlement can be revoked and the app can be pulled” (Stora, 16 May 2026). Apple retains audit rights: on discrepancy it can terminate the developer account or withhold the amount from App Store payments, with interest at 1% per month on missed payments (Superwall).

Google. On 22 July 2026 Google notified developers that those enrolled in the external content links and alternative billing programs in the US “will need to report transactions and successful downloads and pay the relevant service fees starting on October 1, 2026” (Play Console Help). That ends the zero-fee link-out era US developers have enjoyed since the Epic injunction. Fees: 10% on auto-renewing subscriptions, 20% on other digital content, plus fixed per-install fees of $2.85 for apps and $3.65 for games when a link-out leads to a download. In the EEA the reporting window is not 15 days — it’s within 24 hours of the external transaction. The externaltransactions API demands per-transaction pre-tax amount, tax amount, transaction time, and a user tax address (for India, down to the state) with separate refund calls per occurrence (Android Developers).

And the population is enormous and just doubled. 82% of top-grossing App Store apps now use some form of web monetisation — nearly double the share from a year ago — with web funnel launches up 77% in 2025 (Business of Apps, State of web-to-app 2026).

The third leg: chargebacks became the developer’s money. For orders placed after 3 August 2026, Google Play shifted chargeback cost responsibility to developers — the purchase price less Play’s service fee, plus the bank’s chargeback fees (Play Console Help). Every chargeback is now a line item that must flow back through the filing as a correction, or the developer overpays commission on money it never kept.

So: a filing duty, on a fortnightly-to-24-hour clock, denominated in money, with account termination as the penalty and audit as the enforcement — landing on a population that doubled in twelve months and has never filed anything like it before.

Provenance:

• Signal 1 (demand): 82% of top-grossing App Store apps now use web monetisation, nearly double a year ago; web funnel launches +77% in 2025 — businessofapps.com — 2026
• Signal 2 (feasibility): Apple External Purchase Server API and Google externaltransactions API both became the mandatory machine-readable filing path in 2026, replacing manual reports — developer.apple.com / developer.android.com — 2026
• Signal 3 (economic): Google begins charging and requiring reports on link-out transactions 1 October 2026 (10–20% + $2.85/$3.65 per install); Apple charges 12–27%; chargeback costs shifted to developers 3 August 2026 — support.google.com — 22 July 2026 Category: Platform shift

3. The opportunity

The app monetisation stack is crowded and well funded — RevenueCat, Adapty, Superwall, Paddle, Purchasely. Every one of them sells the same half of the problem: getting the user to the web checkout and taking their money. RevenueCat Web does “synced web checkout, attribution, and compliant app-to-web subscription purchases.” Paddle handles the merchant-of-record and the sales tax. Superwall does the paywall.

None of them files the report to the store.

This isn’t my inference. Asked directly in RevenueCat’s own community whether Apple’s External Purchase API could be used through RevenueCat, the answer was that they will consider supporting it if Apple broadens its support (RevenueCat Community). The category leader has publicly declined to build it. The reason is structural, not lazy: RevenueCat’s business is subscription infrastructure sold to developers. Filing a developer’s commission return to Apple means computing how much money that developer owes Apple, standing behind the number in an audit, and being the party that says “you underpaid.” That is an adversarial, liability-bearing posture toward the exact platform your SDK depends on. Growth-tooling companies do not volunteer for it.

The gap is precisely the one this catalog has learned to hunt: vendors sell generating the artifact; nobody sells delivering it before the meter starts. Here it’s sharper than usual, because the artifact is a reconciliation, not a document. Apple demands every issued token be accounted for — including the ones that never converted. That means the developer must diff Apple’s token ledger against Stripe/Paddle settlements, classify each unmatched token as abandonment vs. late conversion vs. out-of-window, handle refunds and chargebacks as corrections, and defend the classification under audit. Google demands a different shape entirely, on a different clock, in a different currency-and-tax format.

A studio running both stores in both regions maintains four incompatible reporting pipelines against APIs that are less than a year old, on penalty of losing its entitlement.

The 10× isn’t a better UI. It’s that the thing does not currently exist as a product, the deadline is six weeks out, and the alternative is a backend engineer’s month plus permanent maintenance.

4. Target market

Primary customer: Head of Growth, or the founder-CTO, at an independent subscription app studio — 5 to 60 people, $500K to $20M in annual consumer subscription revenue, running iOS and Android with a web checkout funnel already live. Health & fitness, dating, language learning, photo/video editing, utilities, mid-size mobile games with webshops. Concentrated in the US, UK, EU, plus the large Eastern European and Israeli mobile studio clusters.

Secondary: the mobile growth agencies and fractional-CTO shops that run monetisation for 10–40 such apps and would rather buy this once than build it per client.

Why they buy, in their words: the recurring complaint in the implementation literature is that the money side looked like the easy part and wasn’t. “The work splits into two halves: the on-device flow… and the off-device flow (web checkout, attribution reporting, receipt round-trip). The off-device half is where teams fall behind, and where Apple revokes entitlements” (Stora). And on the economics that make it worth caring about: “Paying Google 25% for alternative billing (or 20% for external links) plus your alternative payment provider’s fee (generally around 5%) puts you at or above the 30% you were trying to avoid” (Neon Commerce). When the whole point of the exercise is arbitraging a few percentage points, being wrong about which transactions are commissionable eats the entire margin.

The 7-day attribution window is its own quiet disaster. An analysis of 194,730 retail transactions found that install-tuned attribution windows miss nearly half of purchases, with nearly half of retail purchases occurring more than 7 days after the click (Apptrove, 2026). Which means roughly half of a studio’s post-link revenue sits in a grey zone where the difference between “commissionable” and “not” is a timestamp nobody is carefully keeping. Over-report and you hand Apple 27% of money you didn’t owe. Under-report and you’re the audit case.

Rough TAM reasoning: Apple has publicly cited well over a million App Store developers, but the relevant slice is narrow: studios with meaningful consumer subscription revenue and a live web funnel. Working from the 82% web-monetisation figure among top-grossing apps and the size of the RevenueCat customer base (public marketing claims tens of thousands of apps), a realistic serviceable base is 8,000–25,000 studios worldwide that will be enrolled in at least one external-purchase program within 18 months. At a $400/mo blended ACV, a 3% share is ~$3.5M ARR. This is a bootstrap-sized market, not a venture one — which is exactly why the funded incumbents will keep deprioritising it.

Why now for them: Google’s fee-and-reporting switch flips 1 October 2026. Studios that enrolled in the link-out program during the free period now have a filing duty and a bill arriving in the same month. Apple’s clock is already running. Nobody gets to defer this to next year.

5. Product sketch (MVP)

• Token reconciliation. Pulls Apple’s issued external-purchase tokens and diffs them against your Stripe / Paddle / Chargebee settlements. Every token lands in one of four buckets: matched, expired-unconverted, converted-outside-window, or unexplained. The unexplained pile is the only thing you have to look at.
• The filing itself. Assembles and submits the Apple monthly report through the External Purchase Server API by day 15, and Google’s per-transaction reports through the externaltransactions API on the right clock for each region — 24 hours in the EEA, per-program in the US. Files the zero-transaction month too, which is the one everyone forgets.
• Attribution-window adjudicator. For every purchase, decides whether the 7-day Apple window or Google’s rules make it commissionable, and records why — timestamp, token, link-tap source. This is the audit defence.
• Commission pre-check. Before you file, shows what you’re about to owe: Apple 12% vs 27% depending on Small Business Program status, Google 10%/20% plus the $2.85/$3.65 per-install fees, alongside your payment processor’s cut. Flags when the “savings” have gone negative versus just using store billing.
• Refund and chargeback flow-back. Google shifted chargeback costs to developers on 3 August 2026. Every refund and chargeback is filed as a correction against the right original transaction, per-occurrence for subscriptions, so you stop paying commission on money you refunded.
• Filing calendar with a real countdown. Days remaining until each store’s deadline per region, and the one thing blocking each filing.
• Audit binder. One export per period: what was filed, what it was computed from, which tokens were excluded and on what evidence. The thing you hand over when Apple asks.

6. AI angle — what’s load-bearing

Remove the AI and about 70% of this product survives — the API plumbing and the calendar are deterministic. So I’ll be honest about where it’s genuinely load-bearing and where it isn’t, because a fake AI angle is worse than none.

Where it earns its keep: the unexplained-token pile. Reconciliation between a store’s token ledger and a payment processor’s settlement file is never clean. Currencies differ, timestamps sit in different zones, a user pays with a different email than the one that tapped the link, a subscription renews under an ID that doesn’t obviously trace to an original token, Paddle’s merchant-of-record record looks nothing like Stripe’s. The matching is fuzzy, high-volume, and exactly the kind of judgement that a human analyst does well and regex does badly. An LLM-plus-heuristics matcher that proposes a classification for each orphan token with a stated reason — and escalates only genuine ambiguity — is what turns a two-day monthly grind into a twenty-minute review. That’s the product.

Second place it matters: both stores’ policies have changed materially four times in the last eighteen months, across at least six documents per store, differently per region. Keeping the rule engine current is a document-monitoring problem — diffing Apple and Google policy pages, surfacing what changed and which customers it affects. That’s a real ongoing AI-assisted workflow, and it’s also the moat.

I’m not going to pretend the filing submission needs a model. It doesn’t.

7. Localization angle (if any)

N/A as a market wedge — this is a global play sold in English to studios that already operate internationally. But region is the core product complexity, which is different and worth being precise about.

The same transaction is reportable on a 24-hour clock in the EEA and a 15-day-after-month-end clock under Apple’s US entitlement. Google requires a user tax address down to state level for India. Apple currently requires manual reports for transactions on iOS 26.2/26.3 in Japan and on OS versions before 26.4 in the EU — a genuinely nasty edge case, because it means part of your filing can’t be automated at all and a studio that automates the rest will silently drop the Japanese slice. Fee schedules differ by region and by install cohort (Google charges 20% non-recurring on new installs, 25% on installs predating the regional launch date).

A studio selling in fifteen countries cannot hold this in its head. Encoding it per-region is the work, and it’s why this doesn’t get cloned in a weekend.

8. Business model — path to $1M–$5M ARR

Pricing — three tiers, priced against the cost of the engineer they’d otherwise assign:

• Solo — $149/mo. One store, one region, under $50K/mo external revenue. Indie and small studios.
• Studio — $449/mo. Both stores, all regions, unlimited apps under one developer account, audit binder, chargeback flow-back.
• Portfolio — $1,200–$2,500/mo. Agencies and multi-account studios, 10+ apps, per-client filing separation and white-labelled binders.

Deliberately flat, not a percentage of transactions. Two reasons. Taking a cut of the money someone is already paying two other parties a cut of is a bad look and invites a race to zero. And a fixed fee makes the pitch trivially arithmetic: $449/mo against a backend engineer’s month plus permanent on-call for an API that changes quarterly.

ACV: ~$5,400 blended.

To $1M ARR: 185 customers at blended ACV. Concretely: 120 Studio at $449 + 40 Solo at $149 + 20 Portfolio at $1,500 ≈ $1.07M. That’s 185 studios out of a serviceable base I’ve put at 8,000–25,000 — a 1–2% share.

To $5M ARR: needs roughly 800–900 customers, which needs two things to be true. First, that the agency/portfolio tier lands — 100 agencies at $1,800/mo is $2.2M on its own and is a far shorter list to work than 900 individual studios. Second, that external purchase links become the default rather than a minority strategy. The 82%-of-top-grossing-apps-use-web-monetisation figure says the trend is going that way hard, but “uses a web funnel” and “enrolled in a store’s external purchase program with a filing duty” are not yet the same set. This is the number I’d most want to be wrong about in my favour.

Expansion path: starts as filing, grows into money-recovery. Once you hold every studio’s token ledger, settlement data and commission history, the next products are obvious: over-payment detection (commission paid on out-of-window or refunded transactions — a refund claim against the store), Small Business Program threshold monitoring (the $1M cliff where your rate doubles from 12% to 27%), and per-cohort fee optimisation. Recovered-money products price at a share of what they recover and lift ACV without a new sale.

9. Go-to-market wedge — first 100 customers

The customer list here is unusually enumerable, which is most of why I like this idea.

1. The enrolment lists are semi-public and the deadline is the pitch. Apps that have shipped an external purchase link are visible — the disclosure sheet appears in the purchase flow, and app-intelligence tools (Appfigures, Sensor Tower, data.ai) let you filter top-grossing subscription apps by category and publisher size. Build a list of 1,500 studios with live web funnels in health/fitness, dating, language, and photo/video. Email subject line is a date: “Your first Google Play link-out filing is due after 1 October.” Send a 90-second Loom showing their own store, their own fee schedule, and the four filings they now owe. This is a deadline-driven cold email against a fear of account termination — expect 8–12% reply, 2–3% to trial. 1,500 → ~35 customers.

2. Go where the incumbents publicly said no. RevenueCat’s community thread declining to support Apple’s External Purchase API is a live, indexed, high-intent page — as are the Apple Developer Forums threads on External Purchase Server API integration (e.g. thread/781101), and the equivalent questions on Stack Overflow and r/iOSProgramming. Every person asking “how do I report this to Apple” is a qualified lead who has already tried to build it. Answer the question properly and completely — post the actual reconciliation logic, the edge cases, the Japan manual-report trap — and mention the product once at the end. This is 20–30 customers over six months and it compounds, because these pages rank for exactly the query a panicking developer types on day 13.

3. Agencies and monetisation consultancies, sold once, deployed forty times. There is a small, well-known set of mobile growth agencies and fractional-CTO shops running monetisation for portfolios of subscription apps — they congregate at App Promotion Summit, MAU, and in the paid growth communities. Twenty conversations gets 4–6 Portfolio deals, and each one drags 10–40 studios onto the platform. Highest-leverage channel by a distance; also the one that most credibly gets to $5M.

4. Be the reference document. The definitive, continuously-updated public comparison of Apple vs Google external-purchase reporting requirements — both clocks, all regions, every fee tier, the manual-report exceptions — does not currently exist. Every law-firm alert and vendor blog covers one store or one region. Publish it, keep it current, and it becomes the page linked whenever this comes up. Slow channel, but it’s the one that makes the cold email in channel 1 land warm.

5. Pre-sell before building. The Google deadline is 1 October 2026. Take 30 discovery calls in September, offer founding-customer pricing at $249/mo locked for two years in exchange for filing their first period manually as a service. Ten of those pays for the build and tells you exactly what the reconciliation actually has to handle before you write it.

10. Build complexity — justification

Medium. Two well-documented REST APIs (Apple’s External Purchase Server API, Google’s externaltransactions), plus read integrations against Stripe, Paddle and Chargebee — all off-the-shelf, all with good docs. Standard web stack, no infrastructure novelty.

The real work is threefold. First, the reconciliation engine: fuzzy-matching token ledgers against settlement files across currencies, timezones and identity mismatches, with an audit trail behind every classification. Second, encoding the region-and-cohort fee matrix correctly — Apple 12/27%, Google 10/20/25% split by install cohort, per-install fees, the EEA 24-hour clock, the Japan and pre-26.4 EU manual-report exceptions. Third, the correction paths for refunds and chargebacks, which must reference the specific original transaction, per-occurrence for subscriptions.

Two engineers, 12–16 weeks to a v1 that files real periods for real customers. A narrower v1 — Apple only, US only, Stripe only — ships in 7–8 weeks and is genuinely sellable, because Apple’s filing is already overdue for anyone enrolled.

Bumped from Low because getting the numbers wrong here costs the customer their developer account, so the correctness bar is high and the test surface is wide.

11. Gating checklist

Gate	Pass?	Note
Legal in target market	✅	Helping developers comply with published store policies using the stores’ own official reporting APIs. Nothing adversarial to the platforms — this makes them get paid accurately and on time.
Ethical — no harm / dark patterns	✅	Product’s purpose is filing accurately, not underpaying. Over-payment detection is a factual claim against the store, not evasion.
Market exists (evidence above)	✅	82% of top-grossing apps use web monetisation; both stores impose mandatory filings with financial and account-termination penalties.
1–5 person team can build this	✅	Two engineers, 12–16 weeks. Two REST APIs and three payment-processor integrations.
Launchable with <$50K / ₹40L	✅	Founder time, a few hundred a month of infrastructure, app-intelligence data subscription for prospecting.

All five pass.

12. Feasibility score

Axis	Weight	Score	Notes
Problem intensity	20	17/20	Money and account survival, on a fortnightly-to-24-hour clock. Late or incomplete reporting is cited as the most common cause of entitlement revocation; Apple can terminate the developer account on audit discrepancy. Not 18+ because a studio can dodge it entirely by reverting to store billing — painful, but an exit exists.
Demand evidence	15	12/15	Strong structural evidence: 82% web-monetisation among top-grossing apps (doubled YoY), two mandatory filing regimes, a hard 1 Oct 2026 fee date, RevenueCat publicly declining to build it. Held below 13 because I could not find volume verbatim complaints from developers who have actually filed — the Google duty hasn’t started yet. The pain is well-evidenced as predicted, less so as lived.
Build feasibility	15	11/15	Documented APIs and standard stack, but the reconciliation engine and multi-region fee matrix are real engineering, and the correctness bar is unforgiving. 12–16 weeks for a pair.
Distribution clarity	15	13/15	Enumerable customer list via app-intelligence filters, a dated deadline as the subject line, high-intent forum threads where incumbents said no, and an agency tier that multiplies. Not 14+ because cold email to developers converts worse than to operators.
Revenue mechanics	15	12/15	Flat pricing benchmarked against an engineer-month, clean $1M math at 185 customers. $5M requires the agency tier to land and the enrolled population to keep expanding — one real assumption.
Time to first revenue	10	8/10	Pre-sellable now against the 1 Oct deadline; Apple-only v1 in 7–8 weeks. Founding customers plausible inside 6 weeks, though these are considered purchases, not impulse ones.
Defensibility	10	5/10	Honest score. No network effect, no proprietary data at start. The moat is accumulated regulatory-operational knowledge — a per-region fee-and-clock matrix kept current across two platforms that change policy quarterly — plus the filing history lock-in once you hold a customer’s audit trail. Real, but a funded incumbent could decide to build it. The reason they haven’t is strategic reluctance, not difficulty, and strategy changes.
Total	100	78/100

13. Qualitative modifiers

Founder-fit tags

technical-heavy · domain-expertise-required

Needs someone who can read platform policy documents like contracts and hold four reporting regimes in their head, paired with an engineer comfortable in payments reconciliation. A mobile-monetisation background is close to a cheat code here — the customer list is your existing network.

Key assumptions to validate (3–5)

1. Assumption: Studios treat this as a buy, not a build — they’ll pay $449/mo rather than assign a backend engineer for a month. How to test: 30 discovery calls with studios in the $1M–$20M subscription band before 1 October. Ask what they’ve already scoped internally and what they budgeted. If more than two-thirds say “our platform engineer has it handled,” the price ceiling is much lower than modelled.

2. Assumption: The enrolled population is big enough — that “uses a web funnel” converts into “enrolled in an external-purchase program with a filing duty” at a meaningful rate. How to test: sample 200 top-grossing subscription apps and check how many actually surface an external purchase disclosure sheet in the live purchase flow. If under 15% are genuinely enrolled, the serviceable base is a fraction of my estimate and $5M is off the table.

3. Assumption: The reconciliation is genuinely hard — that a real studio’s token ledger vs. settlement diff produces enough orphans to be worth paying to resolve. How to test: get two friendly studios to share one month of Apple tokens and Stripe settlements under NDA and reconcile by hand. If the match rate is 98%+ clean, the AI-matching value evaporates and this is a thin API wrapper.

4. Assumption: RevenueCat and Adapty stay out. How to test: watch their changelogs and community threads monthly; talk to their partner teams. A shipped RevenueCat external-purchase filing feature is close to a kill shot for the standalone version.

Risk flags

1. Platform dependency — total, and on two hostile-ish platforms. The entire product exists because Apple and Google impose these filings. Either could build first-party reconciliation tooling, simplify the regime, or change the APIs. Google already changed the terms twice in 2026 alone. Mitigation is being the layer across both, which neither will ever build.

2. Regulatory/legal volatility — this is the big one. These fees are actively litigated. Whether the link-out fees survive is genuinely unsettled — the court’s economist flagged the question and Epic has fought Google over exactly this kind of fee before (Strataigize). If a court strikes the link-out commission, the fee disappears — though note the reporting duty and the attribution accounting plausibly survive as long as any commission does. Still, a large adverse ruling shrinks the product materially.

3. Incumbent entry. RevenueCat has the customers, the SDK and the data. They’ve publicly declined so far for good structural reasons — but “we’ll consider it if Apple broadens support” is a stated intention to revisit, not a permanent no.

4. Correctness liability. You are computing what your customer owes a platform that can terminate their account. A systematic error in your favour is an audit finding for every customer at once. This needs conservative defaults, clear terms of service, and probably E&O insurance before the first enterprise-ish deal.

5. Market timing on the early side. Google’s duty starts 1 October 2026. Sell too early and studios haven’t felt it; too late and someone else owns the search results. The window is roughly August 2026 through Q1 2027.

14. Structured verdict

Score:                  78/100
Verdict:                GO
Confidence:             Medium
Best-fit builder:       Technical founder from mobile monetisation or payments
                        reconciliation, paired with one backend engineer.
                        Existing studio network is a major accelerant.
Time to revenue:        6–10 weeks (pre-sell against the 1 October Google deadline;
                        Apple-only v1 fileable in 7–8 weeks)
Capital to launch:      $8–15K (₹7–13L) — infrastructure plus app-intelligence
                        data subscription for prospecting
Top 3 assumptions to validate first:
  1. Buy-not-build at $449/mo — 30 discovery calls with $1M–$20M studios before 1 Oct
  2. Enrolled population size — sample 200 top-grossing apps for a live external
     purchase disclosure sheet; need >15% genuinely enrolled
  3. Reconciliation is genuinely messy — hand-reconcile one month of real token
     ledger vs. Stripe settlements for two studios; need a material orphan rate
Kill criteria:
  - Abandon if fewer than 15% of a 200-app sample are actually enrolled in an
    external purchase program by Q4 2026 — the market is a rounding error
  - Abandon if RevenueCat or Adapty ships store-filing support before your v1
  - Abandon if a court vacates the Google link-out fee AND Apple's commission,
    removing the money that makes accuracy matter
  - Abandon if fewer than 8 of 30 discovery calls will pre-pay $249/mo

15. Next step — 1-week validation sprint

• Day 1–2: Build the enrolled-app census. Pull 200 top-grossing subscription apps across health/fitness, dating, language and photo/video from app-intelligence data. Check each for a live external purchase disclosure sheet or a documented web-checkout funnel. This produces the single number the whole business rests on: what fraction of the addressable base actually has a filing duty today.
• Day 3–4: Thirty outbound conversations. Founders and growth leads at studios from that census, plus five mobile growth agencies. One question set: have you enrolled, who’s building the reporting, what did they scope it at, what happens if you file late. Offer founding pricing at $249/mo for two years in exchange for pre-payment.
• Day 5: Get one real dataset. Persuade two studios to share one month of Apple external-purchase tokens plus the matching Stripe or Paddle settlement file under NDA. Reconcile it by hand and count the orphans.

Falsifiable go/no-go: Proceed only if (a) ≥30 of 200 sampled apps show a live external purchase enrolment, (b) ≥8 of 30 conversations convert to a signed pre-payment at $249/mo, and (c) the hand reconciliation produces ≥3% orphan tokens requiring judgement to classify. Fail any one and the idea is either too small, not urgent enough, or a thin wrapper — stop.