Server Notifications

Purchases change outside the app: renewals, cancellations, refunds, grace periods, billing retry, voided purchases, and store-side recovery can all happen while the customer is not using your app. AppActor uses store notifications to keep entitlement state, integrations, analytics, and dashboard history fresh.

​

Store notifications vs AppActor webhooks

Use store notifications to keep AppActor current. Use Outbound Webhooks or integrations when your own backend needs to react to the processed lifecycle event.

​

Runtime flow

​

Apple App Store Server Notifications

Apple notifications are configured per iOS app.

​

What you need

• iOS app created in AppActor
• Bundle ID configured on that app
• Apple App ID when production App Store Server API checks need it
• Apple credential connected
• AppActor Apple notification URL from the app detail page

​

Setup path

1. Open the iOS app in AppActor.
2. Copy the Apple notification URL shown in the app detail page.
3. Open App Store Connect and select the matching app.
4. Paste the URL into App Store Server Notifications for both production and sandbox where applicable.
5. Send a test notification from AppActor.
6. Confirm the AppActor app detail page shows a verified state, environment, and test result.

​

Apple details to watch

• Use the notification URL for the matching AppActor iOS app, Bundle ID, and environment.
• Apple sends signed notification payloads. AppActor verifies and normalizes them before updating entitlement state.
• AppActor uses Apple transaction timing such as signedDate, purchase dates, expiration dates, revocation dates, and renewal info to classify renewals, refunds, billing issues, grace, and expiry.
• If Apple test notification is not healthy, check the App Store Connect app, Bundle ID, credential, and environment before changing SDK code.

​

Google Real-time Developer Notifications

Google RTDN is configured per Android app and delivered through Google Cloud Pub/Sub.

​

What you need

• Android app created in AppActor
• Package name configured on that app
• Google Play service account credential connected
• service account invited to the app in Play Console
• required Play Console permissions granted
• AppActor-generated Topic ID

​

Setup path

1. Open the Android app in AppActor.
2. Make sure the package name and Google credential are connected.
3. Let AppActor provision or refresh the Google notification resources.
4. Copy the generated Topic ID.
5. In Play Console, go to Monetize > Monetization setup > Real-time developer notifications.
6. Paste the Topic ID.
7. Select the notification content shown by AppActor.
8. Send Google’s test notification.
9. Wait for AppActor to receive and process a notification for the current topic.

​

Google details to watch

• Use the Topic ID for the matching AppActor Android app and Play Console package.
• The Google service account must have access to the target Play app.
• AppActor treats RTDN as a wake-up signal and then verifies subscription or one-time purchase state with Google.
• Google event timing such as eventTimeMillis is used when available for voided purchases, refunds, and notification ordering.
• If the RTDN test is not healthy, check package binding, service account permissions, Pub/Sub setup, and Play Console notification content before changing SDK code.

​

Health states to understand

​

Healthy evidence

Before launch, capture these dashboard facts for each platform app:

​

Before go-live

• Apple notification URL is configured for the correct app and environment.
• Apple test notification succeeds.
• Google Topic ID is pasted into the correct Play Console app.
• Google test notification is received and processed.
• AppActor products, entitlements, and offerings are connected.
• Your own backend uses Outbound Webhooks or server-side access checks instead of raw store notifications for app access decisions.