Documentation
Revenue

Multiple providers (authority and dedupe)

Understand authority and deduplication across revenue providers.

You can connect more than one provider to the same brand. Many founders do: RevenueCat for the apps, Stripe for the web.

Sometimes two connections describe the same purchase. This page explains which one FounderHQ believes, and why your totals do not double.

One purchase, two reporters

RevenueCat is a reporter, not a store. Every purchase it tells you about really happened at Apple, at Google Play, or at Stripe. So if you connect RevenueCat and the underlying provider, both send you the same sale.

FounderHQ picks one source of truth per purchase:

You have connectedWho owns the moneyWhat happens to the other copy
RevenueCat and Stripe, for a Stripe purchaseStripeFounderHQ ignores the RevenueCat event
RevenueCat and Apple, for an App Store purchaseAppleFounderHQ keeps the RevenueCat event as evidence, but it adds no money
RevenueCat and Google Play, for a Play purchaseGoogle PlaySame: kept as evidence, adds no money
RevenueCat onlyRevenueCatIt is the only reporter, so it owns the money
Superwall onlySuperwallIt is the only reporter, so its amounts are the money
Superwall and a store connection, for the same appThe storeSuperwall's copy is kept as evidence and adds no money

The rule is simple: whoever charged the card wins. The closer a source is to the store, the better its amounts, its taxes, and its timing.

When you connect a native store after running on RevenueCat or Superwall, FounderHQ retires the reporter's copy of that subscription's state. MRR does not count twice during the switch.

Adding a store connection is always allowed

You can connect Apple App Store or Google Play for an app that already reports through RevenueCat or Superwall. FounderHQ allows it, hands the money to the store from that moment, and leaves the reporter connected as evidence. That is the migration path off a reporter, and it takes no downtime.

The other direction is refused. Once a store connection owns an app, adding a second reporter for it — or a second store connection — would be two claims on the same purchase with no way to choose. FounderHQ names the connection that holds the app and asks you to disconnect it first.

How FounderHQ knows it is the same purchase

FounderHQ matches on the store's own references, never on the reporter's event ID:

  • Apple: the transaction ID, with the original transaction ID for the subscription.
  • Google Play: the purchase token, with the order ID for each charge.
  • Stripe: the PaymentIntent.

Those references are identical no matter who reports them. A RevenueCat event ID and an Apple notification ID are not, which is why they are never used for matching.

Superwall is a special case

Superwall reports purchases it did not charge. FounderHQ records the amount and currency Superwall reports — Superwall's word, ranked below RevenueCat's and well below a store's. The upgrade is connecting the store itself: the store takes the money over, and Superwall stays connected as evidence.

Superwall's Stripe events are always ignored: they carry no charge reference, so FounderHQ cannot tell them apart from the ones Stripe already sends. Connect Stripe directly.

Superwall's Google Play events are recorded only while no Google Play connection owns the app. Superwall makes up its own reference numbers for Play purchases, so once Google Play is connected there is no way to tell the two copies of a sale apart. Google Play takes the money and Superwall's Play events become evidence.

Two Stripe accounts, or one brand per product

Separate connections stay separate. Each connection carries its own account or business ID, and FounderHQ rejects events from any other one. Connect as many as you sell through.

What to do

  • Selling on the web and in an app? Connect Stripe and RevenueCat. Nothing double-counts.
  • Moving off RevenueCat? Connect Apple or Google Play and leave RevenueCat connected. The native connection takes over.
  • Adding a processor FounderHQ has no connection for? Send it through the generic revenue API and give each payment a stable transaction ID.

AI agent or LLM? Read this page as markdown

On this page