Introduction
A RevenueCat audit checks whether the app, backend and reporting stack agree about a customer's subscription. Start with entitlement behavior, then trace identity, webhook processing and the revenue decisions that rely on them.
Executive summary
Key Takeaways
- Check current entitlements instead of inferring access from a purchase button callback.
- Separate event receipt, durable processing and application of subscription state.
- Reconcile transactions using explicit revenue definitions and mature reporting periods.
1. Define What Each Entitlement Unlocks
Begin with the product contract: which capability is premium, which entitlement authorizes it and which store products can grant that entitlement? Review the mapping with product and engineering together. A monthly and an annual product may unlock the same capability, but an unrelated product must not accidentally unlock everything. Capture the distinction between access to an app screen and authorization for a paid operation performed on your server.
RevenueCat exposes purchase and subscription information through CustomerInfo, including entitlement status, and provides SDK and REST access to subscription information. Use the current state relevant to your implementation when checking access. A successful paywall interaction, a saved local boolean or the presence of an old transaction is not a complete entitlement policy. The audit should identify where the product actually makes its authorization decisions.
2. Test Identity and Account Transitions
Write down the identifier used by your app, the identifier sent to RevenueCat and the key used by the backend. Explain when each becomes available. Then test a customer who starts anonymously and signs in later, a customer restoring on another device, and someone switching accounts on a shared device. Inspect the configured restore and transfer behavior against the product's intended account policy rather than assuming that every project has the same defaults.
Save evidence at each transition: the authenticated app account, current entitlement result, backend access decision and visible premium state. Keep test identifiers separate from real customers. If a mismatch appears, reproduce it before changing identity handling. An account-switching bug can look like a delayed subscription update, and a reporting join that uses the wrong identifier can look like missing revenue. Those problems require different repairs and different owners.
3. Review Refresh, Expiration and Failure Behavior
Subscription state can change while the app is closed. Review what happens on launch, return from background, purchase completion and restore. Document how the client obtains current information and how a server-backed feature checks access. CustomerInfo updates occur through SDK interactions; do not design the interface as though the server will necessarily push every change directly to an idle client. Verify the refresh behavior for the SDK version your app actually ships.
Include expiration, billing problems and refunds in the test matrix. Record the expected policy for each state before running the tests, including any store-supported grace period that applies. A network timeout should have an intentional user experience and retry path. Do not quietly convert an unknown state into a permanent grant, or remove legitimate access merely because a request failed. Test recovery as well as the initial failure.
4. Audit Webhook Delivery and Processing
RevenueCat documents webhook authentication and delivery behavior, including the need to handle retries and possible event ordering differences. Verify your endpoint against the currently configured security mechanism. Keep store sandbox events distinct from production activity. Record the event ID, event type, customer reference, relevant timestamps and processing outcome. Avoid storing unrestricted raw payloads in broadly accessible logs when they contain customer information.
Treat receiving an HTTP request, saving it durably and applying it to subscription state as separate operations. Our recommended checks include delivering the same event twice, receiving older information after a newer update, and restarting a worker during processing. Confirm that a repeated delivery does not create another payment or repeat a customer-facing action. If local state is uncertain, reconcile through the provider's current subscription information instead of trusting arrival order alone.
5. Compare Revenue on the Same Basis
Create a small ledger from known test cases and an appropriately controlled production sample. Identify the store, transaction, currency, amount, environment and lifecycle stage. Separate initial paid purchases, free trials, renewals and refunds. State whether each report uses gross revenue, estimated proceeds or another calculation. Differences in currency conversion, event date or cohort grouping must be understood before two dashboard totals are treated as contradictory.
Follow one transaction from RevenueCat into each destination that consumes it. If a webhook, an SDK event and a native integration all reach the warehouse, establish which represents the authoritative payment record. Multiple useful events can describe one purchase without representing multiple sales. A reconciliation report should expose missing records, duplicates and definition differences separately, because suppressing all discrepancies into one percentage conceals the cause.
6. Create an Audit Handoff the Team Can Maintain
A practical finding contains the customer journey, affected capability, environment, expected state, observed state and supporting evidence. Add the responsible team and a retest condition. Classify a server authorization failure separately from a stale screen or a delayed analytics row. These issues can share a root cause, but their customer impact and urgency differ. Fix the path that threatens paid access or materially distorts commercial decisions first.
Agree on a small monitoring set after remediation: processing failures, unresolved state mismatches, unexpected duplicate payment records and the age of unprocessed events. Thresholds should reflect your actual volume and latency requirements. Grovix's MarTech audit brings the subscription, engineering and growth views together so a working integration remains understandable after the original implementer hands it over. The resulting backlog should be executable without reconstructing the investigation.
Frequently Asked Questions
Can we use webhooks as the only source of client subscription state?
A webhook receiver can maintain backend state, but the client still needs an intentional way to obtain current access information. Audit the complete refresh and authorization path, including delivery interruptions.
What should a RevenueCat audit deliver?
An entitlement and identity map, lifecycle test evidence, webhook-processing findings, a revenue reconciliation sample and a prioritized repair plan with owners and acceptance criteria.
Related Client Evidence
These documented engagements provide practical context. Their observed outcomes are specific to each client and measurement window.
Building a Trustworthy Measurement System for a Fintech App
The engagement established a documented framework for tracing acquisition traffic from source to conversion, giving the team a repeatable way to validate MMP configuration, data handoffs, and campaign traffic.
This NDA-protected case describes the verified scope and operating outcome of the engagement. The report spans more than 200 pages and demonstrates audit depth; it is not presented as a performance-lift claim. No revenue, ROAS, CPA, or incrementality result is attributed to the audit.
Editorial standards
How This Resource Was Prepared
The Grovix Growth Team reviews official platform documentation and the primary sources listed in each resource, then translates that evidence into an operating framework for mobile teams. Platform requirements are cited directly; Grovix recommendations reflect practitioner judgment and should be validated against the app, market, and measurement setup.
Written and reviewed by Grovix Growth Team, senior-led practitioners working across app store optimization, apple ads, mobile measurement, lifecycle, and monetization. The page was published on and last reviewed on .
Grovix, Türkiye. Questions, corrections, or source updates can be sent to hello@grovix.co.Sources and Further Reading
Platform features and measurement conventions change. These primary sources support the platform-specific statements in this resource and should be checked during implementation.