Revenue and subscription data, with its source intact

Stripe: payments and recurring subscriptions

Connect Stripe and assign its products to your projects. Naarva reads products, prices, subscriptions, payments and refunds, with verified events and periodic synchronization keeping the imported data current.

Successful one-time and subscription payments contribute to revenue; failed payments and test-mode transactions do not. Paid recurring subscriptions contribute to MRR when their recurring amount can be established. Refunds affect revenue rather than being subtracted from the recurring subscription amount.

Read the Stripe connection and reporting guide for product assignment, source history and the difference between collected revenue and MRR.

Paddle Billing: transaction and subscription reporting

The Paddle Billing connection uses a read-only API key to import products, prices, subscriptions, transactions and adjustments. It is for Paddle Billing; Paddle Classic uses a different API and is not supported by this connection.

Your Paddle account needs at least one product before it can be connected. An Owner or Admin enters the key in the workspace’s integration settings. Optional verified webhooks help refresh changed records, and periodic reconciliation checks the source again.

Revenue is based on the relevant transaction data, with refunds and tax treatment kept explicit. A merchant-of-record payout is not the same measure as revenue. Add the operating costs you want to track separately and consult the source’s accounting records for settlement details.

RevenueCat: daily full mobile-store exports

RevenueCat reporting requires a daily full Transactions CSV export delivered to AWS S3, together with the RevenueCat project connection. Incremental-only exports are insufficient: Naarva needs the full snapshot to identify corrected or removed records.

The connection covers supported App Store, Google Play and Amazon store records. RevenueCat records for Stripe, Paddle, web, promotional and sandbox sources are excluded so those sales are not counted again alongside their direct integrations.

The export is a periodic observation, not a live feed. Revenue history, current subscription coverage and source freshness are distinct. Historical MRR starts with observed snapshots; today’s price is not used to invent earlier MRR. Individual failed payment attempts are unavailable from this export.

Some source data cannot establish exact tax amounts or a complete history of separate partial refunds. Those limitations remain visible. A missing or stale export does not silently replace the last published data with zeros.

Check a connection before relying on its totals

1. Use a verified Owner or Admin account and follow the setup instructions for the selected provider.
2. Complete the first synchronization and review the resulting status.
3. Assign source products to the intended projects and review anything left unassigned.
4. Check currency, available history and any warnings before comparing businesses.

A connected account alone does not prove that every historical period or metric is complete. The metric methodology describes how missing coverage, trial subscriptions and tax limitations are represented.

Keep access and pricing straightforward

Credentials are entered in authenticated integration settings and are not part of public reports. Disconnecting a source removes its stored credentials and stops future synchronization while retaining previously published business history. You can also revoke access directly at the provider.

Supported integrations are included in Naarva’s project-based price. A source connection does not create a separate integration fee, and importing more revenue does not raise the subscription price.