Release Incident Playbook

In-app purchase receipt validation fails: symptoms, cause, and the test that catches it

Store receipts are rejected after a validation or sandbox endpoint change.

In-app purchase receipt validation fails is documented by 2 accepted public reports from 2 organisations, 2 of them published in the last 5 years.

  • Likelihood: low (2 public reports in 5 years)
  • Impact: high (2 of 2 reports: money)

2 public reports · verified 2026-10-21

Symptoms

User-visible

  • After the in-app purchase plugin upgrade, the app's server could not verify new purchases.[1]
  • Customers reported problems with consumable purchases in the Android app store.[2]
  • End users did not see consumable purchases they had paid for, and a purchase restore made them appear.[2]

Monitoring-visible

  • Server receipt parsing threw a TypeError when extracting the transaction id from the app receipt.[1]
  • The serverVerificationData value started with a JWT header instead of the MI prefix of a base64 receipt.[1]
  • About 10 percent of Android non-subscription purchases went unprocessed over a few days.[2]

Root causes

  1. stage: third-party Upgrading the in-app purchase plugin from 3.2.0 to 3.2.3 pulled in a platform package at 0.4.0 that made the newer store framework the default on supported iOS devices. That framework returns a JWT for transaction verification instead of the base64 receipt the server parsed.[1]
  2. stage: release-process The receipt format change shipped in a minor plugin version, and the maintainers said it should have been a major version change.[1]
  3. stage: third-party An app store endpoint that the purchase processor calls to tell subscriptions from other purchases began returning an incorrect error. The processor had no handling for that error, so consumable purchases were not processed.[2]

Public examples

  1. [1]Flutter (Google), 2025-07-04. After a minor in_app_purchase upgrade made StoreKit 2 the default on iOS, serverVerificationData changed from a base64 App Store receipt to a JWT, so unchanged server-side receipt validation code failed for new purchases; maintainers confirmed the behaviour and said it should have been a major version change. primary [in_app_purchase] After upgrade verificationData.serverVerificationData verified in server causes a crash
  2. [2]RevenueCat, 2024-02-19. A change on a Google Play endpoint that RevenueCat calls to tell subscriptions from other purchases began returning an incorrect error, so RevenueCat did not process about 10 percent of Android non-subscription purchases until it deployed handling for the error and replayed the receipts. primary Problem with Consumables using Google Play Store

Test classes that catch it

Test classStageLimitationBasis
Integration testspre-deployA sandbox purchase test runs when the purchase service or plugin changes, so it does not run when a change on the store endpoint starts returning an incorrect error in production.by design analysis
Contract testspre-mergeA contract on serverVerificationData flags the switch from a base64 receipt to a JWT, but an error from the purchase-type endpoint that keeps the expected shape and carries a wrong value passes it.by design analysis
Synthetic monitoringpost-deployA scheduled test purchase that buys only a subscription, or runs only on iOS, stays green while Android consumable purchases fail.by design analysis

Risk

  • Likelihood: low (2 public reports in 5 years)
  • Impact: high (2 of 2 reports: money)
Counts behind the grades
Accepted public reports2
Published in the last 5 years2
Impact stated: money2

How the grades are computed

Pre-release checklist

  • PR-01
  • PR-02
  • PR-03
  • PR-04
  • PR-05
  • PR-06
  • PR-07

First 30 minutes

  • FM-01
  • FM-02
  • FM-03
  • FM-04
  • FM-05
  • FM-06
  • FM-07

Download the checklist

What catches this: catalogue entries

Listed because their own documentation or site names integration tests, contract tests, synthetic monitoring on the verification date. Alphabetical. Not a recommendation.

Tools whose documentation names these test classes

Providers whose site names these test classes

Only on this page

In-app purchase receipt validation fails starts in the third-party stage in report [1] and report [2], not in app code. In report [1], the app developers changed only the plugin version, from 3.2.0 to 3.2.3. The format change arrived in a platform package that switched the default store framework and turned the receipt into a JWT [1].

In report [2], the fault started on the store side, at an endpoint that separates subscriptions from other purchases. That endpoint began returning an incorrect error, and about 10 percent of Android non-subscription purchases went unprocessed [2]. The recovery was a deployed handler for the error plus a replay of every purchase from the previous days that did not go through [2]. A guard on the app's own code path sees neither change, so the check has to sit on the receipt payload and on the store response.

Questions

What causes in-app purchase receipt validation fails?

In report [1], a plugin upgrade switched the default store framework, so the server received a JWT instead of a base64 receipt. In report [2], a store endpoint began returning an incorrect error that the purchase processor did not handle.

What are the symptoms of in-app purchase receipt validation fails?

Server receipt parsing threw a TypeError when extracting the transaction id [1]. End users did not see consumable purchases until they restored purchases [2].

Why did tests not catch in-app purchase receipt validation fails?

Neither report names a test class. The format change shipped in a minor plugin version that maintainers said should have been a major version [1]. The error came from a change on the store endpoint [2].

Which public reports document in-app purchase receipt validation fails?

Two primary reports document it, published on 2025-07-04 [1] and 2024-02-19 [2]. Both classify the impact as money.

What should be checked before a release to prevent in-app purchase receipt validation fails?

PR-01 makes a sandbox purchase on a supported iOS device after every plugin upgrade. PR-04 stubs the store's purchase-type endpoint with an unexpected error and confirms the purchase is retried.

Should a team roll back or fix forward when in-app purchase receipt validation fails happens?

Developers in report [1] downgraded the plugin, and the maintainers pointed to an option that keeps the older store framework. The processor in report [2] fixed forward and replayed the missed purchases. FM-04 covers this decision.

Release Incident Playbook (2026). In-app purchase receipt validation fails: symptoms, cause, and the test that catches it, content version 1.0.0. https://releasefailures.com/incidents/in-app-purchase-receipt-validation-fails/. Accessed 2026-10-21.