Store products are not enough. EVENTY purchase QA needs a real device, a sandbox checkout, and a confirmed entitlement update.
Prove the store product, not only the product ID
A product ID can exist in App Store Connect or Google Play and still fail in the real purchase path. The release check needs to open the paywall on a real phone, show the correct event pack, complete sandbox checkout, and return to the same album setup.
The important signal is continuity. The host should understand which event is being activated, which limit is changing, and what happens immediately after purchase.
Confirm the entitlement where the app actually reads it
RevenueCat is the receipt layer, but the app still needs Supabase to reflect the right event limits. After checkout, verify the event pack, guest count, photo limit, video limit, and retention window from the backend state the app consumes.
If the app only trusts a local purchase callback, the launch is fragile. The backend entitlement should be the durable source of truth.
Test add-ons against an active album
Add-ons are more sensitive than first purchases because they must apply to the selected active event. The QA path should start from the album, choose the limit that needs more capacity, buy the add-on, and re-check the event state.
This is also a conversion moment. The host should see why the upgrade is useful without feeling that the app blocked the event unexpectedly.
Questions fréquentes
Is store catalog presence enough for launch?
No. Catalog presence only proves that a product exists. Launch readiness needs a real sandbox purchase and a backend entitlement update.
What should be checked after buying an add-on?
The selected event should receive the exact guest, photo, video, or retention increase that the paywall promised.
