Apple and Google asked
Entitlements come from what the stores say, not from what the device posts.
Solution
Server-side receipt validation for App Store and Google Play subscriptions
Server-side receipt validation means your server asks Apple or Google whether a purchase is real instead of trusting the phone. RevenueDot does this for the RevenueCat SDK: it verifies StoreKit 2 transactions against Apple's root certificate and the App Store Server API, reads Google Play purchase tokens from the Play Developer API, and answers 5xx for its own failures so no purchase is lost.
Free up to $10,000 a month in tracked revenue. Works with the RevenueCat SDK you already ship.
Retry-safe
A 5xx tells the SDK to keep the purchase and try again. A 4xx means it can never succeed.
Notifications confirm it
App Store Server Notifications v2 and Google real-time notifications update state without the app.
Check from your backend
Read active entitlements with a secret key, or receive webhooks.
How it works
How RevenueDot validates a receipt on each store
| App Store | Google Play | |
|---|---|---|
| What the SDK posts | A StoreKit 2 signed transaction (or a StoreKit 1 receipt) | A purchase token |
| How it is checked | JWS verified against Apple's root certificate, then the App Store Server API with your In-App Purchase key | The Play Developer API with your service account |
| Without credentials | StoreKit 2 verified, but no history. StoreKit 1 refused with a retryable 500 | Answers 503 (code 7101), and the SDK retries after you add the service account |
| Later changes | App Store Server Notifications v2 | Real-time developer notifications over Pub/Sub, plus a daily voided-purchase scan |
| Refunds | Recorded from Apple's REFUND notification | Recorded from voided-purchase notifications and the daily scan |
RevenueDot does not call Apple's deprecated verifyReceipt endpoint.
Steps
How to validate App Store and Google Play receipts on your server with RevenueDot
- 01
Create a free project and your store apps
Start free on Cloud and add an App Store app and a Google Play app.
- 02
Add the store credentials
Add the In-App Purchase key and the Play service account, and check both in the dashboard. See App Store and Google Play.
- 03
Set up store notifications
Paste the notification URLs into App Store Connect (Version 2) and a Pub/Sub push subscription. Watch each app's status turn Ready.
- 04
Point the SDK at RevenueDot
Set the proxy URL before
configure. The SDK then posts receipts toPOST /v1/receipts. - 05
Check access from your backend
Read a customer's active entitlements with a secret key, or verify the HMAC on webhooks and deduplicate on the event ID.
Backend
Check a customer's entitlements from your backend
Keep the secret key (sk_) on your server. Never ship it in an app.
Active entitlements for one customerterminal
curl -s -H "Authorization: Bearer $SECRET_KEY" \
"https://api.revenuedot.app/v2/projects/$PROJECT_ID/customers/user_1/active_entitlements"Error rules
Why 4xx and 5xx matter for receipts
- A 4xx means the purchase can never be accepted. The SDK finishes the transaction for good, or on Android stops retrying.
- A 5xx means a temporary problem, so the SDK keeps the transaction open and posts it again later.
- RevenueDot never answers 4xx for its own failures, so a server bug cannot make a paying customer lose a purchase.
- See receipt errors: 4xx vs 5xx for every code.
Honest notes
What has and has not been tested
- The unmodified RevenueCat iOS SDK 5.92 and Android SDK 10.24 pass Test Store purchases against RevenueDot on a simulator and an emulator in its test suite.
- Run an App Store and a Google Play sandbox purchase before you ship, as you would with any backend.
- For development only, an
allow_unsigned_receiptssetting accepts StoreKit 1 receipts without checking them. Anyone could forge one, so never turn it on in production.
FAQ
Receipt validation: questions people ask
How do I validate in-app purchase receipts on my server?
Send the purchase to a server that asks the store. For Apple that means verifying the signed transaction and calling the App Store Server API. For Google it means reading the purchase token with the Play Developer API. RevenueDot does both for the RevenueCat SDK.
Is Apple's verifyReceipt endpoint still the way to validate?
Apple deprecated verifyReceipt. RevenueDot does not call it. It verifies StoreKit 2 signed transactions locally and uses the App Store Server API with your In-App Purchase key.
What happens if validation fails because of a server error?
RevenueDot answers 5xx for its own and temporary store failures, so the SDK keeps the purchase and retries. It answers 4xx only when a purchase can never be valid, so a paying customer does not lose access to a server bug.
How do I verify a Google Play purchase token?
Call the Google Play Developer API with a service account that has View financial data and Manage orders and subscriptions, then acknowledge the purchase within 3 days. RevenueDot does this and re-reads each purchase on every notification.
Can my own backend check who has access?
Yes. Read a customer's active entitlements with the REST API and a secret key, or receive webhooks and verify their HMAC signature. Deduplicate on the event ID.
Get started
Run subscriptions without the revenue share.
Start free on RevenueDot Cloud, free up to $10,000 a month in tracked revenue, or move an existing RevenueCat app with one line of code.
Already have an account? Sign in · Prefer your own servers? Self-host free