Receipt Validation in Swift
The aim of this guide is to help you take a look inside the PKCS #7 container, and verify the presence and authenticity of the signature on the receipt.
The aim of this guide is to help you parse a receipt and decode it so that you have readable pieces of metadata to inspect and finalize all of the receipt validation steps.
[…]
In-app purchase receipts are encoded as ASN.1 Sets (with ASN.1 Sequences within) inside the primary ASN.1 Set receipt payload. In other words, they’re nested ASN.1 Sets within the overall ASN.1 Set that encodes the whole receipt. The nested Set contains the in-app purchase receipt attributes.
Update (2017-07-31): Andrew Bancroft:
The aim of this guide is to help you finalize the receipt validation process by computing the GUID hash for your app, and comparing it to the hash that’s stored within your receipt itself.
Update (2023-08-09): Felix Schwarz:
Two days ago I finally got annoyed enough with the OpenSSL dependency for App Store receipt parsing and validation that I had another shot at an ASN.1 parser.
Today I have ObjC parsers for ASN.1 and PKCS#7, signature validation through Security.framework and can drop OpenSSL from my App Store project(s). 🥳
In retrospect I wish I had found that courage earlier instead of spending a lot more time than this on getting OpenSSL to build for all the various Apple platforms and CPUs.
So much time and storage space have been collectively been wasted on this. Why couldn’t Apple have just used a plist or JSON?
Previously:
