How to get app receipt after purchase using test account in iOS - ios

I am working with IAP, I want to get the receipt so that I can validate it.
I have tried this
-(void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions {
for (SKPaymentTransaction *transaction in transactions) {
switch (transaction.transactionState)//Each transaction should be processed by examining transactionState property.
{
case SKPaymentTransactionStatePurchased:
{
if([transaction.payment.productIdentifier isEqualToString:#"TC0001"])
{
}
**NSData *data = [NSData dataWithContentsOfURL:[[NSBundle mainBundle] appStoreReceiptURL]];
NSError *error;
NSDictionary *response = [NSJSONSerialization JSONObjectWithData: data options: 0 error: &error]; //I am using sbjson to parse
NSLog(#"%#",response);**
//Finish transaction deletes the transaction from the default queue
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
}
break;
default:
break;
}
}
}
I hope I am doing right, because this is what mentioned in docs. But I get "null for response. So is that I am missing something.

The receipt is not stored in plain-text JSON.
It's actually in the format of a PKCS7 encoded container which is a binary format based on an old-time telecom encoding format called ASN.1.
I can't point you to any examples because no one has shared their code for decoding the container. Developers are reluctant to share their code because Apple pointed out that if many apps share similar code for handling IAP, a single security exploit would threaten not just one, but many apps.
There's a WWDC presentation: "WWDC 2013: Using Receipts to Protect Your Digital Sales" where they provide some suggestions on how to get started, and there's also a document: "Receipt Validation Programming Guide" in the Xcode docs.
Read those and then Google for pertinent terms, you should find enough bits and pieces to assemble a solution.

Related

iOS receipt does not include repurchased transaction

If I wipe the data in my app, then re-purchase some managed IAP that I know the account already owns, iOS gives me the native "are you sure you wish to repurchase this item you will not be charged" dialog. That's as expected.
When the purchase returns to my app, I get the receipt with [[NSBundle mainBundle] appStoreReceiptURL]. I then attempt to verify the SKPaymentTransaction's transactionIdentifier with the receipt via my server.
However the receipt's transaction ID for this IAP, because I've already purchased it long ago, is not the same as the SKPaymentTransaction.
How should I be verifying that this is a valid repurchase? Can I get a signed receipt for this repurchase somehow?
All the purchases will be in a single receipt. You do have to check all iAPs there and look for the needed ones.
If you want the id of the original iAP transaction, there is Original Transaction Identifier
For a transaction that restores a previous transaction, the transaction identifier of the original transaction. Otherwise, identical to the transaction identifier.
More information about receipt fields is here: https://developer.apple.com/library/prerelease/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html
Anyway, does it really matter whether this is an original purchase or a repurchase? My checks of this are usually the same.
As far as I understand it you should check the originalTransaction to check that this is valid for transactions that are SKPaymentTransactionStateRestored.
[[NSBundle mainBundle] appStoreReceiptURL] is for the receipt of the main application, not the IAP.
You can use RMStore library, and check all purchases:
RMStoreAppReceiptVerificator *verificator = [[RMStoreAppReceiptVerificator alloc] init];
if ([verificator verifyAppReceipt])
{
NSArray *inAppPurchases = [RMAppReceipt bundleReceipt].inAppPurchases;
for (RMAppReceiptIAP *inAppPurchase in inAppPurchases)
{
NSLog(#"productIdentifier %# originalPurchaseDate %#", inAppPurchase.productIdentifier, inAppPurchase.originalPurchaseDate);
}
}
If your receipt is nil you can refresh receipt:
[[RMStore defaultStore] refreshReceiptOnSuccess:^{
//get purchases
} failure:^(NSError *error) {
}];

Apple In-App Purchase Receipt - validation on the server-side

I have a problem with validating an apple receipt on the server-side.
I tried to find a solution in the internet, but haven't succeeded.
So, description:
First of all, application is made for iOS7. Secondly, I have a few items ( type = Non-Renewing Subscription ). So user can buy one or multiple items and then he should manually renew them ( buy again ).
Applications sends a receipt to the server-side, I make a request to the Apple and get the result with a lot of in_app receipts. Something like:
"in_app":[
{
"quantity":"1", "product_id":"...", "transaction_id":"...",
"original_transaction_id":"...", "purchase_date":"...",
"purchase_date_ms":"...", "purchase_date_pst":"...",
"original_purchase_date":"...",
"original_purchase_date_ms":"...", "original_purchase_date_pst":"...",
"is_trial_period":"..."},
{
"quantity":"1", "product_id":"...",
"transaction_id":"...","original_transaction_id":"...",
"purchase_date":"...", "purchase_date_ms":"...",
"purchase_date_pst":"...", "original_purchase_date":"...",
"original_purchase_date_ms":"...", "original_purchase_date_pst":"...",
"is_trial_period":"..."}
]
So, each "receipt" in "in_app" has transaction_id. But how I can identify the transactionId of the current purchase? I would like to validate it as well and make sure that this is unique.
My concern is: if somebody will get one valid receipt, he will be able to hack our server-side API and make unlimited numbers of in-app purchases with the same valid receipt.
Should I somehow decrypt and check for transaction_id the "original" receipt, the one what I send to Apple for verification?
Any help/suggestions would be highly appreciated.
Thank you in advance.
Regards,
Maksim
#Doug Smith
https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html
If you go through the different fields on this page, you will find
Original Transaction Identifier::
For a transaction that restores a previous transaction, the transaction identifier of the original transaction. Otherwise, identical to the transaction identifier.
This value corresponds to the original transaction’s transactionIdentifier property.
All receipts in a chain of renewals for an auto-renewable subscription have the same value for this field.
So for your non-auto renewable subscriptions, you have to keep track of two things on your server side:
The original transaction identifier of the receipt that you are validating with itunes server, associate this with the user Id in your database.
Whether the request that you received from the client side is of a Purchase or of a Restore Purchase.
Once you have these two things with you, you can write your logic on these two parameters like below:
::If a request is of type "Purchase" and you already have the original transaction identifier of that receipt associated with some other user Id, you can block that purchase.
::If a request is of type "Restore Purchase" and request is coming from the same user id against which the original transaction identifier is associated in your DB than allow him otherwise block his restore.
Furthermore, you can derive your own logic based on these things, according to your needs.
Let me know if you have any further doubts.
For each new transaction apple send a new receipt which is unique, encode it so no one can forge data.
Get the transaction receipt from the completed transaction encode it and send it to your server, and on the server side decode it and match with the one apple send to server.
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
_transactionArray = transactions;
for (SKPaymentTransaction * transaction in transactions)
{
switch (transaction.transactionState)
{
case SKPaymentTransactionStatePurchased: {
NSData *receipt = transaction.transactionReceipt;
[self sendReceiptToServer];
} break;
case SKPaymentTransactionStateFailed: {
// finish this transaction
} break;
case SKPaymentTransactionStateRestored:
NSData *receipt = transaction.transactionReceipt;
[self sendReceiptToServer:receipt];
} break;
default:
break;
}
};
}
-(void)sendReceiptToServer:(NSData *)receipt {
// encode receipt
// send receipt to server
// add success and error callback
}
-(void) receiptSuccess {
// finish transaction here
}
-(void) receiptError {
// try again sending receipt to server
}

StoreKit change stores notification?

Is there a way to know when the user has changed stores with the StoreKit framework?
This is for if I have already pulled in a list of products and the user changes stores, so I can refresh the prices for the new store's locale.
I found a solution, a bit of a 'trick', not as obvious as an explicit 'store did change notification'.
You can listen to the errors of each transaction in - paymentQueue:updatedTransactions:
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
for(SKPaymentTransaction* transaction in transactions)
{
NSError* transactionError = transaction.error;
if(transactionError != nil && transactionError.code == SKErrorUnknown)
{
NSLog(#"User potentially switched stores");
[self refreshAllProductInfo];
}
}
}
This may trigger during other errors, but so far I've only seen it to trigger when you change stores.
With this, when the user sees for example, $USD prices and then logs in with a $GBP account, the prices will refresh to their GBP versions.

In-App Purchase Receipt Validation Contradiction

Apple offers two documents about receipt validation, with apparently contradictory statements.
In "Verifying Store Receipts":
Note: On iOS, the contents and format of the store receipt is private
and subject to change. Your application should not attempt to parse
the receipt data directly.
Yet, in "In-App Purchase Receipt Validation on iOS" sample code is provided in which the store receipt is parsed and verified, as part of a "mitigation strategy" for a security vulnerability:
// Check the validity of the receipt. If it checks out then also ensure the transaction is something
// we haven't seen before and then decode and save the purchaseInfo from the receipt for later receipt validation.
- (BOOL)isTransactionAndItsReceiptValid:(SKPaymentTransaction *)transaction
{
if (!(transaction && transaction.transactionReceipt && [transaction.transactionReceipt length] > 0))
{
// Transaction is not valid.
return NO;
}
// Pull the purchase-info out of the transaction receipt, decode it, and save it for later so
// it can be cross checked with the verifyReceipt.
NSDictionary *receiptDict = [self dictionaryFromPlistData:transaction.transactionReceipt];
NSString *transactionPurchaseInfo = [receiptDict objectForKey:#"purchase-info"];
NSString *decodedPurchaseInfo = [self decodeBase64:transactionPurchaseInfo length:nil];
NSDictionary *purchaseInfoDict = [self dictionaryFromPlistData:[decodedPurchaseInfo dataUsingEncoding:NSUTF8StringEncoding]];
NSString *transactionId = [purchaseInfoDict objectForKey:#"transaction-id"];
NSString *purchaseDateString = [purchaseInfoDict objectForKey:#"purchase-date"];
NSString *signature = [receiptDict objectForKey:#"signature"];
// Convert the string into a date
NSDateFormatter *dateFormat = [[NSDateFormatter alloc] init];
[dateFormat setDateFormat:#"yyyy-MM-dd HH:mm:ss z"];
NSDate *purchaseDate = [dateFormat dateFromString:[purchaseDateString stringByReplacingOccurrencesOfString:#"Etc/" withString:#""]];
if (![self isTransactionIdUnique:transactionId])
{
// We've seen this transaction before.
// Had [transactionsReceiptStorageDictionary objectForKey:transactionId]
// Got purchaseInfoDict
return NO;
}
// Check the authenticity of the receipt response/signature etc.
BOOL result = checkReceiptSecurity(transactionPurchaseInfo, signature,
(__bridge CFDateRef)(purchaseDate));
if (!result)
{
return NO;
}
// Ensure the transaction itself is legit
if (![self doTransactionDetailsMatchPurchaseInfo:transaction withPurchaseInfo:purchaseInfoDict])
{
return NO;
}
// Make a note of the fact that we've seen the transaction id already
[self saveTransactionId:transactionId];
// Save the transaction receipt's purchaseInfo in the transactionsReceiptStorageDictionary.
[transactionsReceiptStorageDictionary setObject:purchaseInfoDict forKey:transactionId];
return YES;
}
If I understand correctly, if I verify the receipt my app could stop working when Apple decides to change the format of the receipt.
And if I don't verify the receipt, I'm not following Apple's "mitigation strategy" and my app is vulnerable to attacks.
Damned if I do, damned if I don't. Is there something I'm missing?
They heavily recommend to use your own server as an intermediary for validation, as this will allow a clear and secure passage to the App Store for all versions of iOS. That's really the best route to not be damned either way.
If you must perform validation directly from the device to the App Store, then you utilise their mitigation strategy only when the application is run on 5.1.x and below. For iOS6 and above, use the recommended means provided.
Whilst it was always the case that you shouldn't parse the receipt directly, the discovered vulnerability put Apple between a rock and a hard place in how to address this, and decided that application developers implement a check. It means when a user updates the application, the receipts are now secured again (irrespective of iOS version), thereby providing better fix coverage. As a side effect, it means you have to break from how you should normally do it (but Apple have give you permission to do so).
I agree the documentation isn't wholly clear on this, and could be clarified a bit more (you should give them feedback from the documentation pages at the bottom). Apple have published a mitigation strategy, and they do state it should be used on iOS 5.1.x and below to address the vulnerability. The onus is on them if they change the format/contents of IAP receipts.
Apple is also currently recommending on-device receipt validation. See Validating receipts locally and WWDC 2013 talk Using receipts to protect your digital sales.

Where do you update the server on a consumable in app purchase?

So I have an app that has a consumable purchase and from what I have read a little more work is involved in terms of persisting some info on the server.
What I am not clear on is where does one update the server on a sucessful purchase? Is it
(void)completeTransaction:(SKPaymentTransaction *)transaction;
??
If it is indeed the above mentioned function, is it just a matter of making a web call and updating the server server? I am just trying to understand best practices and would appreciate any help.
much regards
I don't know if this counts as a valid answer, but you should maybe check out this article.
The blog post is from 2010, so one could say it's rather outdated! But i think it's worth a look and the provided example (completeTransaction method implementation) should be valid also.
Getting in app purchases to work is a lot more painful than it should be actually.
I did and do it in
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
...
case SKPaymentTransactionStatePurchased:
case SKPaymentTransactionStateRestored:
[self sendReceiptToServerAndValidateFurther:transaction.receiptData
it is then only a webcall to the server-side script which can validate the receipt with itunes and update its DB/send the data
btw some server php
function itunes_verify2($receiptData,$sandboxed) {
//itunes store url -- sandbox or not :)
$itunes_storeURL = "https://buy.itunes.apple.com/verifyReceipt";
if($sandboxed == true) {
$itunes_storeURL = "https://sandbox.itunes.apple.com/verifyReceipt";
}
log_action('itunes_verify2 using ' . $itunes_storeURL);
$post = array("receipt-data" => $receiptData );
$postData = json_encode($post);
$responseData = post_doRequest( $itunes_storeURL, $postData );
$response = json_decode($responseData);
if($responseArray->status == 0) {
return "YES";
} else {
log_action('failed to get status ok from ' . $reponseData);
return "NO";
}
}
I'll give a vote here for this SO question. Seems to have several examples.
https://stackoverflow.com/questions/4178214/ios-in-app-purchase-sample-code
From what I can tell, consumables do require your own hosting, as mentioned here:
iOS In App Purchases for Subscriptions and Consumables products
I have no personal experience with consumables, only with upgrade-type IAPs, which weren't too painful (relatively speaking).

Resources