Verify App Store server notifications before you act on a refund, because anyone can post to your webhook URL

Anyone who learns your webhook URL can send it a refund. That's the uncomfortable fact behind every App Store server notification and every Google Play Real-time developer notification: until you verify it, the message is just an HTTPS POST with some JSON in it. If your server revokes a subscription, claws back credits or bans an account because a request said REFUND, you've handed that power to whoever can write a curl command.

Both stores give you a way to check. Apple signs the notification itself, so you can verify App Store server notifications with nothing but Apple's root certificate. Google Play takes a different route. The message isn't signed, but the Pub/Sub delivery can be, and Google tells you to confirm every change with its API anyway. Here's what each one proves, and what it costs when you get it wrong in either direction.

What each store actually signs

How to verify App Store server notifications

Apple's documentation describes the signedPayload as a string of three Base64URL-encoded components separated by periods: a header, a payload and a signature, signed according to the JSON Web Signature specification. Decoding the payload is easy. Trusting it takes four checks.

• Read the x5c array from the decoded header. Apple documents the order: first the certificate with the signing key, then an Apple intermediate certificate, then an Apple root certificate.
• Validate that chain against an Apple root you downloaded yourself from Apple's PKI site, in practice Apple Root CA - G3. Never trust the root that arrived inside the message, because a forger can put any certificate there.
• Confirm the intermediate carries the Apple Worldwide Developer Relations extension, 1.2.840.113635.100.6.2.1, then verify the JWS signature with the leaf certificate's public key.
• Check the decoded data against your app: bundleId, appAppleId in production, and environment. A valid Apple signature on another developer's app, or on a sandbox purchase hitting your production endpoint, still isn't your refund.

Then do it again for what's inside. The data object holds signedTransactionInfo and signedRenewalInfo, and each is a separate JWS with its own x5c chain. A REFUND handler that verifies the envelope but reads the transaction without verifying it has left a gap in the middle.

Use Apple's library instead of writing it yourself

Apple publishes the App Store Server Library for Swift, Java, Python and Node. Its SignedDataVerifier takes your root certificates, an online-checks flag, the environment, your bundle ID and, for production, your appAppleId. The Node source shows what it enforces: exactly three certificates in the chain, the Apple leaf extension 1.2.840.113635.100.6.11.1 and the intermediate extension, certificate validity dates, and a matching bundle ID, app ID and environment. With online checks on, it also asks the OCSP responder whether the leaf and intermediate certificates were revoked.

Is an IP allow list enough?

No. Apple says that if your server needs an allow list, you should add the 17.0.0.0/8 subnet, and it applies to both sandbox and production. That cuts noise. It doesn't prove a message is genuine, and it breaks the moment Apple's network changes in a way you didn't hear about. Keep the signature check as the real gate.

How to verify Google Play refund notifications

Google Play publishes RTDN messages to a Pub/Sub topic you own, and only the google-play-developer-notifications@system.gserviceaccount.com service account should hold the Pub/Sub Publisher role on it. Your subscription then delivers messages one of two ways, and each has its own proof.

• Pull subscription: your server opens an authenticated connection to Pub/Sub and fetches messages. There's no public endpoint, so there's nothing for a stranger to post to.
• Push subscription with authentication turned on: Pub/Sub signs a JSON Web Token and sends it in the Authorization header as a Bearer token. Google's guide says to validate the token's signature and check that its email and audience claims match the values you configured, and its sample code also requires email_verified to be true. The token can be up to an hour old.
• Push subscription without authentication: anything that can reach the URL can send a message shaped like an RTDN.

Why Google wants you to confirm with the API

Even a perfectly authenticated RTDN doesn't carry the full story. Google's setup guide says plainly that these notifications tell you only that a purchase state changed and that you must call the Google Play Developer API to get the complete status. For a voidedPurchaseNotification, that means finding the purchase in the Voided Purchases API, or fetching its current state, before you revoke anything. The API call is authenticated with your own service account, so its answer is one a forger can't fake.

What a forged or rejected refund costs in money

A forged refund notification that you trust costs you a paying customer. You lock out someone whose money you still have, they open a support ticket, and some will go to the store and ask for the refund your system already pretended to grant. A forged purchase or renewal costs the other way: you deliver GPU compute, paid third-party API calls, storage and creator payouts against revenue that never existed.

The opposite failure is quieter and often bigger. A verifier that rejects genuine messages, because of a wrong appAppleId, a sandbox setting in production or an outdated root certificate, drops the two refund flows where your evidence counts. Apple asks for consumption data within 12 hours of a CONSUMPTION_REQUEST. Google gives you 24 hours to answer a chargeback review through orders.reviewrefund, and for orders placed after August 3, 2026, a lost Google Play chargeback costs you the purchase price less Play's service fee, plus the fee the buyer's bank charges.

Don't let a verification bug eat a deadline

• Store the raw request before you verify it, so a rejected message is never truly lost.
• Alert on every verification failure. One forged message is noise. Every message failing at once is your own bug.
• On Apple, you can replay what you rejected. Get Notification History returns the original signedPayload for the past 180 days, so fix the verifier and run the stored or recovered payloads through it again.
• On Google, a pending chargeback review lives only in its notification, so a misconfigured push audience is a missed review. Test it with Send Test Message in Play Console after every change.

RefundHalt verifies both stores' notifications, confirms refunds with the store APIs before anything changes, and answers CONSUMPTION_REQUEST and chargeback reviews inside their windows, so a fake message can't cost you a customer and a real one can't slip past.