Receipt validation is the process of confirming that a record of purchase is authentic, unaltered and unused before a business grants something in return: paid content, a rebate or a line in a revenue report. In mobile advertising, where the term is most common, it means checking an in-app purchase with Apple's App Store or Google Play before the revenue is attributed to a campaign. The check exists because the device reporting a purchase cannot be trusted.

A second meaning, covering till receipts sent to rebate programmes, is treated below.

How app store validation works

An in-app purchase produces a signed record. On Apple platforms the historic form is the app receipt, a file Apple creates, signs and stores inside the app bundle. According to Apple's developer documentation, that file is a PKCS #7 container, as defined by RFC 2315, whose payload is encoded in Abstract Syntax Notation One (ASN.1) as a set of attributes, each carrying a type, a version and a value.

Local validation follows a fixed sequence. Apple lists five tests: load the receipt from the bundle, verify that the signature chain traces back to the Apple Inc. Root certificate, confirm the bundle identifier (field type 2), confirm the version string (field type 3), and compute a SHA-1 hash for the device and match it against field type 5. One failure fails the whole receipt. The signature is checked against the receipt creation date, field type 12, rather than the device clock, so that a since-expired certificate does not reject a genuine receipt.

The server route was verifyReceipt. A developer's backend posted the encoded receipt to buy.itunes.apple.com and received JSON containing a status code; 21007, for example, signals a sandbox receipt sent to the production address. Apple now marks that endpoint deprecated. Its successor, the App Store Server API, returns transaction and subscription data signed by Apple as JSON Web Signature (JWS) objects, and the StoreKit 2 framework hands the same signed transactions to the app itself.

Google Play works on tokens rather than files. According to Google's billing security guidance, the app should send the purchaseToken to the developer's backend, confirm that the token has not been seen before, call Purchases.products:get or Purchases.subscriptionsv2:get in the Google Play Developer API, and grant the item only when the state reads PURCHASED rather than PENDING. The orderId field is unsuitable as a key, since promo-code purchases do not generate one. Purchases not acknowledged within three days are refunded automatically and revoked, and for a three-day prepaid plan the window shrinks to a day and a half.

Where the measurement partner sits

For marketers the relevant operator is usually the mobile measurement partner (MMP), the third party that attributes installs and in-app events to advertising networks. Without validation, a purchase event is whatever the software development kit (SDK) inside the app reports. With it, the MMP asks the store.

AppsFlyer's help centre sets out the flow. The store confirms a purchase to the app, the developer calls the SDK method validateAndLogInAppPurchase, the SDK contacts AppsFlyer's validation service, and the event is logged only once the check succeeds. Failures land in a blocked in-app events report, flagged with af_validated set to false. As of June 2026, AppsFlyer splits the function in two: a free product named Receipt validation, which pulls amount and currency from the store, and a premium ROI360 store revenue product adding net revenue, refund handling and deduplication.

Adjust sells the equivalent as Purchase verification. Events are sorted as passed, failed, not verified or verified unknown, and only passed revenue reaches network partners. Validated revenue feeds the bidding systems of platforms such as Meta, which in November 2025 aligned its value optimisation with MMP reattribution windows and reported 29% higher return on ad spend (ROAS) for value-based campaigns than for volume-based ones, a figure supplied by Meta.

Origin and evolution

In-app purchase arrived with iPhone OS 3.0 in 2009, bringing server-side transaction receipts with it. When the Mac App Store opened in January 2011, the OS X 10.6.6 update introduced app receipts that developers could check locally, largely as copy protection.

The weakness surfaced in July 2012. Russian developer Alexey Borodin ran a server impersonating Apple's: users installed a certificate authority and changed their DNS settings, and apps validating receipts directly from the device accepted forged confirmations. Apple's advisory described the attack, named sending receipts to the developer's own server as best practice, and said iOS 6 would close the hole.

iOS 7 gave iOS and OS X a shared receipt format in 2013. At its developer conference in June 2021, Apple presented the App Store Server API as the replacement for verifyReceipt. The endpoint's HTTP header later carried a deprecation date of June 5, 2023. Apple Developer Support said the endpoint and version 1 server notifications would keep working until an end-of-life date was set, with advance notice. As of September 2026, Apple's documentation still lists the endpoint as deprecated without a shutdown date.

Cryptography moved as well. Under technote TN3138, Apple switched the receipt signing intermediate certificate to SHA-256 on June 20, 2023 in the sandbox and on August 16, 2023 for TestFlight and the App Store; the SHA-1 certificate expired on January 24, 2025. Hard-coded checks broke; one developer reported on Apple's forums that a Mac app refused to open for some users.

On Android, mandatory acknowledgement dates from Play Billing Library 2.0. By August 31, 2026, according to Google, new apps and updates had to use version 8 or later, with extensions available until November 1, 2026.

Why it matters for marketers

App revenue is the optimisation target for much of mobile user acquisition. A forged purchase that reaches an MMP inflates ROAS and misleads platform value models. AppsFlyer's State of Fraud for Marketers 2026 found that organic traffic accounted for 52% of fraudulent installs across 106.4 billion installs, with spoofing, which fabricates entire event sequences, the fastest-rising technique. Store-side checks keep purchases the hardest events to fake.

Neutral measurement leans on the same check. Google, Meta, Moloco and Unity bought into AppsFlyer at a $2.7 billion valuation in June 2026, and OpenAI connected ChatGPT Ads to AppsFlyer and Adjust in seven markets the following month, including in-app event postbacks. Revenue passed through those pipes is only as reliable as the verification upstream, which is part of why the MMP's position as arbiter matters.

The shopper receipt meaning

In promotions and commerce data, the term describes checking photographed or digital till receipts. Text is read with optical character recognition (OCR); retailer, date and stock-keeping unit (SKU) are matched against offer rules; duplicates and forgeries are screened out before a rebate is paid. Snipp Interactive lists receipt OCR parsing, SKU-level validation and fraud risk scoring among its capabilities, which it opened to ChatGPT and Claude on September 14, 2026.

Validated receipts also double as advertising data. Fetch processes more than 13 million receipts a day, covering $212 billion in annual gross merchandise value, according to the company, and Media.net routed that data into open web targeting and measurement in April 2026. Perion gained access to Fetch segments through LiveRamp.

Limitations and disputes

Validation proves that a store transaction existed. It does not establish net revenue. Commission, tax and refunds sit outside a basic check, which is why AppsFlyer reserves refund handling for its paid tier and Adjust warns that registering non-passed statuses as revenue events corrupts return and cohort data. Commission rates keep shifting too: Apple fixed its EU rate for in-app purchase at 26% from October 1, 2026.

Coverage is thinning at the edges. After a US contempt ruling removed Apple's commission on external purchases in 2025, more subscriptions can be sold on the web, where no App Store transaction exists. Apple's UK contract extends commission to website purchases within seven days of a link tap, another category store records do not describe. Publishers such as Substack, which adopted Apple's system in August 2025, run two streams with separate verification paths.

Migration has friction. A developer on Apple's forums reported App Store Server API latency above four seconds, against 300 to 400 milliseconds for verifyReceipt; Apple cited an average near 100 milliseconds. MMP validation also means granting a third party credentials that read store transaction records.

Shopper receipts face a different threat. AppZen, an expense auditing firm, found that AI-generated images made up 70.8% of the fake receipts it flagged by mid-May 2026, up from zero in March 2025, according to Forbes. The figures concern corporate expenses, not rebates, but the forging tools are identical.

Not the same as

Purchase verification is Adjust's name for the same function. At Google Play, though, the phrase also labels a consumer setting requiring a password, biometric or screen lock before buying, which authenticates the buyer rather than the transaction.

Postback signature verification in SKAdNetwork and AdAttributionKit confirms that an install attribution message came from Apple. Revenue is not part of it.

Conversion deduplication removes double-counted events, such as pixel and server copies sharing an event ID. A deduplicated purchase can still be fabricated.

Card-linked transaction data comes from payment networks, so cash purchases are missed. Receipt data spans cash, debit, credit and buy-now-pay-later.

Recent developments

Snap confirmed on August 31, 2026 the global rollout of Unified Attribution for app advertisers using AppsFlyer or Adjust, and Google's Billing Library 8 deadline fell on the same day. Apple's verifyReceipt remains reachable three years after deprecation. On the shopper side, Snipp's September 14 connector moved offer discovery into AI assistants while leaving purchase validation where it was: on receipts submitted after the sale.

Timeline

  • 2009: In-app purchase launches with iPhone OS 3.0, with server-side transaction receipts
  • January 2011: The Mac App Store opens; OS X 10.6.6 introduces locally verifiable app receipts
  • July 2012: Alexey Borodin's spoofed App Store server exposes device-side receipt checks; Apple advises server-side validation and promises a fix in iOS 6
  • 2013: iOS 7 unifies the receipt format across iOS and OS X
  • 2019: Play Billing Library 2.0 makes purchase acknowledgement mandatory, with automatic refunds after three days
  • June 2021: Apple presents the App Store Server API as the successor to verifyReceipt
  • June 5, 2023: Deprecation date carried in the verifyReceipt HTTP header
  • June 20, 2023: SHA-256 receipt signing certificate goes live in the sandbox
  • August 16, 2023: SHA-256 certificate reaches TestFlight and the App Store
  • January 24, 2025: SHA-1 receipt signing intermediate certificate expires
  • March 2025: AppZen records no AI-generated fake receipts among its flags
  • November 3, 2025: Meta aligns app value optimisation with MMP reattribution windows
  • April 23, 2026: Media.net announces its Fetch receipt data partnership
  • May 2026: AI-generated images reach 70.8% of fake receipts flagged by AppZen
  • June 2026: AppsFlyer documents separate Receipt validation and ROI360 store revenue products; its State of Fraud report is published on June 10
  • June 23, 2026: Google, Meta, Moloco and Unity agree to invest in AppsFlyer at a $2.7 billion valuation
  • July 2026: ChatGPT Ads goes live with AppsFlyer and Adjust in seven markets
  • August 31, 2026: Play Billing Library 8 requirement takes effect; Snap rolls out Unified Attribution globally
  • September 14, 2026: Snipp Interactive launches ChatGPT and Claude connectors for receipt-validated offers
  • October 1, 2026: Apple's 26% EU in-app purchase rate is scheduled to apply
  • November 1, 2026: End of Google's extension period for Billing Library 8

Summary

Who. Apple and Google issue signed purchase records and run the verification services. App developers call those services from their own servers. Mobile measurement partners including AppsFlyer and Adjust validate purchases before passing revenue to ad platforms, while rebate and rewards operators such as Snipp and Fetch validate shopper receipts.

What. Receipt validation confirms that a purchase record is genuine, unaltered and unused before content, rewards or attributed revenue are granted. In apps it relies on signed receipts, JWS transactions or purchase tokens checked against the store; in retail it relies on OCR, SKU matching and fraud screening.

When. Store receipts date from in-app purchase in 2009 and Mac App Store receipts in January 2011. A July 2012 exploit made server-side checks standard practice. Apple deprecated verifyReceipt in 2023, moved to SHA-256 signing between 2023 and 2025, and Google's Billing Library 8 requirement applied from August 31, 2026.

Where. On devices, on developer servers, inside MMP pipelines feeding ad networks, and in promotion platforms that process photographed receipts across physical and online retail.

Why. Any device can fabricate a purchase message. Validation stops free unlocks, keeps forged revenue out of ROAS reporting and bidding models, and gives receipt-based commerce data enough credibility to be sold as advertising infrastructure.