App Store Server Notifications checklist

Map events to entitlement changes

List subscription renewals, expirations, billing retry, grace, refunds, revocations, upgrades, downgrades, and offer-related changes. For each event, define the user access result and support-facing explanation.

A notification that updates analytics but not access is incomplete if the product depends on paid entitlements.

Design reliable delivery handling

• Verify signed payloads and reject unknown or malformed events.
• Process events idempotently so retries do not duplicate access changes.
• Persist event IDs, transaction IDs, user mapping, and processing outcome.
• Handle out-of-order events by checking current transaction state.
• Alert on delivery failures, processing errors, and entitlement mismatches.

Make notifications supportable

Support should be able to answer why a subscriber lost or gained access without reading raw signed payloads. Store decision summaries and timestamps that explain the entitlement state.

AppReviewReady interpretation: server notifications are part of customer experience. They decide whether paid users trust the product after billing events.

Test event failure paths

1. Simulate duplicate, delayed, missing, invalid, and out-of-order events.
2. Compare notification results with App Store Server API lookups where needed.
3. Test subscription state changes while the user is active in the app.
4. Verify logs avoid unnecessary personal data.
5. Create a manual reconciliation path for incident response.

Notification processing ledger

The ledger connects commerce engineering to user-facing access and support operations.

After launch, reconcile notification volume with Sales and Trends and support tickets. Gaps can reveal missed events, bad mapping, or product confusion.

Create a dead-letter or manual review process for events that cannot be processed. Silently dropping an event can leave a paying user in the wrong access state for days.

When deploying notification handler changes, use a staged rollout and watch idempotency metrics. Commerce webhooks are infrastructure, not ordinary background jobs.

Support should know when notification delays are possible. A clear pending-access message can prevent refunds while the server reconciles state.

For subscription migrations, replay or simulate key notification paths before enabling new entitlement code. A migration that handles new purchases but misses renewals can fail slowly.

Keep alert thresholds tied to business impact. One malformed test event is noise; a sudden drop in renewals processed or spike in revocations needs incident response.

Publish handler changes with rollback notes. Entitlement infrastructure should be reversible under pressure.

Review retry queues daily during launch week.

Document who can replay events and when replay is allowed. Uncontrolled replay can grant or remove access twice.

Notification event:
Event type: [name]
Entitlement result: [grant/revoke/change]
Idempotency key: [field]
Support summary: [message]
Retry behavior: [rule]
Monitoring alert: [signal]
Owner: [team]