Server-side purchase verification: the definitive guide

Every app that sells digital products needs to answer one question: did this user actually pay? If you trust the client to answer that, you are trusting a device potentially controlled by an attacker. Server-side purchase verification is the only way to be certain — and it is easier than most teams think.

This guide covers how verification works on both Google Play and the App Store, the common pitfalls teams hit when building it themselves, and why a managed verification layer can save months of engineering time.

Why client-side verification is not enough

Client-side verification — where your app calls the store SDK and trusts the response — is vulnerable to several attack vectors:

• Replay attacks: A recorded successful purchase response can be injected back into the app to unlock features indefinitely.
• Modified clients: On jailbroken or rooted devices, the verification logic can be patched to always return "verified".
• API key extraction: If you ship your Google Play Developer API key in the app, it can be extracted and abused.

Server-side verification eliminates all three. The client sends a purchase token to your backend; your backend calls the store's API independently; the server decides whether the purchase is valid. The client never sees the verification result until your server returns it.

How Google Play verification works

Google Play purchase verification uses the Android Publisher API (purchases.subscriptions.get or purchases.products.get). You send the package name, product ID, and purchase token. The API returns the purchase state, expiry time, and whether the subscription is active.

GET https://androidpublisher.googleapis.com/androidpublisher/v3/
  applications/{packageName}/purchases/subscriptions/
  {productId}/tokens/{purchaseToken}

Response:
{
  "startTimeMillis": "1719446400000",
  "expiryTimeMillis": "1722038400000",
  "autoRenewing": true,
  "paymentState": 1,
  "acknowledgementState": 1
}

The key challenge is not the API call itself — it is handling subscription lifecycle changes. A purchase verified today might be cancelled tomorrow. You need RTDN webhooks to keep entitlement state current.

How Apple verification works

With StoreKit 2, Apple signs each transaction with a JSON Web Signature (JWS). Your server verifies the signature against Apple's root certificate — no shared secret needed. The decoded payload contains the transaction ID, product ID, purchase date, and expiry date.

For App Store Server Notifications V2, Apple pushes signed JWS payloads to your server for subscription lifecycle events — the same pattern as RTDN on Google Play.

Common pitfalls when building it yourself

1. Token storage: Raw purchase tokens should never be persisted to disk. Hash them for deduplication; encrypt only what is needed for refresh operations.
2. Platform divergence: Google Play and Apple return different response shapes. Normalize them into a consistent entitlement model before exposing to your application logic.
3. Webhook handling: Both stores push lifecycle events via webhooks (RTDN / App Store Server Notifications). Missing a webhook means stale entitlement state and either over-granting or under-granting access.
4. Idempotency: A purchase token might be submitted multiple times. Your verification endpoint must handle duplicates without double-granting entitlements.

When to use a managed verification layer

Building purchase verification yourself is ~2-4 weeks of engineering for a basic implementation, plus ongoing maintenance for store API changes. If you are a team of fewer than 5 engineers, or if billing is not your core competency, a managed layer like Tierux can save months.

Tierux handles verification, token hashing/encryption, webhook processing, and entitlement normalization behind one REST endpoint. Your backend calls POST /verify and gets back a simple { active: true, entitlement: "pro" } — no platform-specific code, no token vault, no webhook plumbing.