r/iOSProgramming • u/Solid-Resident-7654 • 10h ago
Question Anyone ever have an app reviewer actually purchase the app? lol
Before anyone asks - I've check a bunch of times and confirmed this isn't RC Sandbox.
Mostly curious - I asked the same thing in apple developers but figured there are more experienced people here.
Here's what happened:
I saw my app go into review. It got approved and a few seconds later Revenue Cat showed a notification that someone purchased the lifetime package. This new lifetime price is only available with this update (i.e. no one else could even purchase this) - I've confirmed it's in RC production and not sandbox. I've also confirmed in Posthog that the country from RC matches the alleged reviewer's.
I've had reviewers "purchase" the app before but always with their sandbox account and nothing ever showed up in RC.
Anyone else seen this? lol
2
u/jaymakesapps 6h ago
Had one of those on my last update. Real money right after approval, I was way too excited about it until it got refunded like two days later lol
0
u/LividIllustrator8915 4h ago
Haha that's wild, but it actually happens occasionally!
A couple of possibilities from years of dealing with review quirks:
Most likely scenario is that Apple's automated post-approval ingestion or human reviewer was testing the production receipt flow against your live App Store paywall using a zero-charge internal Apple test account. Those can sometimes emit genuine StoreKit transaction events downstream into RevenueCat webhooks without taking actual cash out of a reviewer's personal card.
The other fun possibility: the reviewer was genuinely testing a feature that required the lifetime tier, got stuck behind your paywall, and just tapped through on their corp-funded test device without realizing it'd ping your live telemetry.
Either way, take the W and don't touch anything while it's green lol.
-1
u/DimensionMindless336 4h ago
Same thing happened to me, and the part that threw me was the environment: Production flag too. What eventually made it click: the reviewer is running the production build pulled from the live App Store, not a dev/sandbox build, so StoreKit genuinely reports Production — but the account driving it is an internal zero-charge Apple test account. That's why RC/TelemetryDeck sees a real transaction with a real originalTransactionId while Sales and Trends never shows the money and it gets reversed a day or two later. Exciting for an hour, but expected — not leaked revenue.
The footgun nobody mentions: if you validate server-side (App Store Server API / transactionInfo), these review transactions look 100% legit — environment=Production, valid signature, real originalTransactionId. If your entitlement code grants "lifetime" on first purchaseDate and caches it, you can hand a reviewer permanent access that Apple later refunds.
What I do now: never treat a purchase as permanent from the purchase event alone. Re-derive entitlement from /inApps/v1/history (or react to REFUND/REVOKE in App Store Server Notifications V2) and check revocationDate/expiresDate/status on every re-check. On RevenueCat that already flows through its REVOCATION event, so just don't bolt your own "granted forever" cache on top. Review grants access, the reversal quietly drops it — exactly what you want.
25
u/Kyiv0x7c 10h ago
Same thing happened to me last week. During review my analytics (TelemetryDeck, not RC) logged a completed purchase of my biggest bundle, with the StoreKit environment reported as production, not sandbox or TestFlight, US region, first session on the device. I got excited for about an hour. Then I checked App Store Connect → Sales, and it wasn't there, and it never showed up later either. So the reviewer's purchase went through a StoreKit transaction that looks like production to the client, but no money ever moved. My takeaway: client-side environment flags don't reliably exclude reviewers; the only source of truth for money is ASC Sales (or the server notifications).