Entitlement truth

Transaction validation and entitlement checklist

Users do not care which system lost the purchase state. They care whether paid access works predictably.

Quick answer

Define one entitlement source of truth based on verified transactions before launch. Apple documents StoreKit Transaction and AppTransaction APIs. AppReviewReady interpretation: transaction validation should serve product access, support explanation, and privacy minimization at the same time.

01

Choose the entitlement source of truth

Decide whether the app, server, or a combined model grants access. Then document how signed transactions, server notifications, API lookups, local cache, and account state reconcile.

A local unlock can improve offline behavior, but it needs a clear expiration and reconciliation rule if the server later sees refund, revoke, or upgrade events.

02

Validate every access state

  • New purchase, restore, refund, revoke, subscription expiration, grace period, billing retry, upgrade, downgrade, and family share.
  • Multiple devices, multiple app accounts, deleted account, reinstall, and offline launch.
  • Transaction verification failure, server delay, duplicate event, and out-of-order update.
  • Support view and user-facing message for each state.
  • Privacy-safe storage for transaction identifiers and decision summaries.
03

Make entitlement decisions explainable

A paid user who loses access should see a specific path: restore purchase, sign into the correct account, contact support, or wait for billing recovery. Generic errors create refunds and low trust.

AppReviewReady interpretation: transaction validation is a conversion feature. Smooth recovery keeps paid users from turning into support tickets.

04

Run validation tests

  1. Verify signed transactions before granting durable access.
  2. Reconcile app cache with server state after every launch and purchase event.
  3. Test restore from a different device and app account.
  4. Simulate refund, revoke, and expired subscription states.
  5. Confirm support can see the decision without raw sensitive payloads.
05

Entitlement contract

The contract gives engineering and support the same access model.

After launch, compare entitlement support tickets with validation logs. Repeated confusion means the access model or copy needs simplification.

If the app supports anonymous purchase before account creation, define when the entitlement binds to a user account. This edge case often causes lost access during onboarding or device change.

For family sharing or group access, show which person owns the entitlement and which users merely receive access. Support needs that distinction before handling complaints.

When a refund or revoke arrives, design the downgrade experience rather than only removing access. Users should understand what changed and how to resolve legitimate mistakes.

If entitlement state is cached for speed, show when the app will refresh it. A visible restore or sync action can reduce support load when users switch devices.

For paid reports or generated outputs, define whether access survives refund, account deletion, or plan expiration. Digital deliverables need clearer rules than simple feature toggles.

Keep restore actions visible near paid value. Hidden restore paths make valid purchases look lost.

Copy-ready frameworkAdapt every bracketed field
Entitlement contract:
Product: [name]
Source of truth: [app/server]
Grant conditions: [rules]
Revoke conditions: [rules]
Offline behavior: [cache]
Support message: [copy]
Stored fields: [minimal list]
Sources

Primary references checked for this guide

Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.

Put it to work

Check entitlement validation

Review transaction verification, restore behavior, server sync, and support messages.

Open the tool