Validating StoreKit 2 Subscriptions Server-Side: Granting Access Without Trusting the Device

Verify the signature and grant access on the server

On the server, verify the received JWS against Apple's root certificate chain to confirm it has not been tampered with. Only once verification passes do you save that purchase as the user's entitlement.

import { SignedDataVerifier } from "@apple/app-store-server-library";
 
const verifier = new SignedDataVerifier(
  appleRootCerts,        // Apple root certificates (multiple)
  true,                  // true for production
  "com.example.app",     // bundle id
  appAppleId
);
 
export async function handlePurchase(req, res) {
  const { signedTransaction, userId } = req.body;
  try {
    const payload = await verifier.verifyAndDecodeTransaction(signedTransaction);
    // Trust only the signature-verified contents
    await upsertEntitlement({
      userId,
      productId: payload.productId,
      originalTransactionId: payload.originalTransactionId,
      expiresAt: new Date(payload.expiresDate),
      status: "active",
    });
    res.json({ ok: true, expiresAt: payload.expiresDate });
  } catch (e) {
    // Grant nothing if the signature is invalid
    res.status(400).json({ ok: false });
  }
}

Using originalTransactionId as the entitlement table's primary key was an easy design to work with. The transactionId changes on each renewal, but originalTransactionId stays constant for the subscription's whole life, so keying users to entitlements on it reduces missed renewals.

Keep tracking state with server notifications

Verification at purchase time alone cannot follow the later cancellations, renewals, and refunds. This is where App Store Server Notifications V2 helps: Apple sends subscription state changes as signed notifications to your server's webhook.

The main notification types and how they map to entitlement state break down like this:

1. On DID_RENEW, extend expiresAt to the new expiry and keep the state active.
2. On EXPIRED, set the state to expired and close access.
3. On DID_CHANGE_RENEWAL_STATUS with auto-renew off, keep it active until expiry and only record it as pending cancellation.
4. On REFUND, immediately set the state to revoked and remove access.

export async function handleServerNotification(req, res) {
  const payload = await verifier.verifyAndDecodeNotification(req.body.signedPayload);
  const { notificationType, data } = payload;
  const tx = await verifier.verifyAndDecodeTransaction(data.signedTransactionInfo);
 
  switch (notificationType) {
    case "DID_RENEW":
      await setEntitlement(tx.originalTransactionId, "active", tx.expiresDate);
      break;
    case "EXPIRED":
      await setEntitlement(tx.originalTransactionId, "expired", tx.expiresDate);
      break;
    case "REFUND":
      await setEntitlement(tx.originalTransactionId, "revoked", Date.now());
      break;
  }
  res.sendStatus(200);
}

With this webhook in place, server-side entitlements stay current even when the user never opens the app. Because state changes the instant a cancellation or refund happens, the next time the app asks about access it gets the correct answer.

Let the device only "display the server's answer"

If the source of truth lives on the server, the device's role narrows to "ask the server for current access and branch the UI on the answer." The thinking is the same for an Expo app generated by Rork: leave the purchase flow to native StoreKit, and make the unlock decision from your own API's response.

In my setup I query the server for entitlement at app launch and on returning to the foreground, and cache it on the client for only a short time. Querying on every screen is wasteful, and never caching delays cancellation reflection, so keeping a freshness of a few minutes was the practical middle.

Two gaps that hit revenue and trust

The first is post-cancel freeloading. Back when I unlocked from a device flag alone, some users who turned off auto-renew kept using features afterward by simply not reopening the app. After adding server entitlements and the EXPIRED notification, I could reliably close access the moment expiry arrived.

The second is continued use after a refund. Without handling the REFUND notification, a user who was refunded and no longer holds the charge keeps the entitlement. That is a double loss of revenue, so I designed refunds to flip to revoked at top priority. For protecting a subscription's real LTV, these two points matter.

Where to start

You do not need perfect state sync from day one. The order I recommend is: first add signature verification at purchase and server-side granting; next, receive the webhook for just EXPIRED and REFUND; finally, add the entitlement query at launch. These three stages alone close most of the holes left open by a device-trusting implementation.

A subscription is all about operation after you win the charge. Unlike AdMob, which keeps running once you wire it up, the robustness of your revenue is decided by whether you can track the states of cancellation, refund, and renewal without dropping any. I hope this helps anyone who, like me, started from a device flag and ran into the wall, to raise their design a level.