Return transaction receipt back to JS about cordova-plugin-purchase

[j3k0]

The way it was done is deprecated in iOS 7. Needs to be updated using appStoreReceiptURL, it's in the pipeline.

Didn't know about the abbStoreReceiptURL changes until now. Makes sense then :)

[antranapp]

+1 for this.

[maxmoore14]

j3k0 - I just e-mailed you about this through the pg directory. Didn't realize you had an open issue for it, sorry.

Don't want to overcomplicate it, but some exposed method that grabs the receipt regardless of OS version would be fantastic.

[maxmoore14]

From what I've read in the docs, best practice is to weakly link to appStoreReceiptURL and fallback to the deprecated method.

This video was helpful: https://developer.apple.com/wwdc/videos/index.php?id=308

[j3k0]

Thanks. I guess we'll have to provide the two methods from javascript too. I don't like that too much but I don't see much other options.

[maxmoore14]

in pseudo-code, since I don't know objective-c...

what if you replaced lines 147 & 161 in InAppPurchase.m with

transactionReceipt = getTransactionReceipt(transaction.receipt)

and add a function like:

getTransactionReceipt(deprecatedReceipt) {
    if (appStoreReceiptURL responds) return getResult(appStoreReceiptURL);
    else return deprecatedReceipt;
}

That would allow you to leave the javascript-facing API alone.

That way you wouldn't know in which way you have to validate.. either deprecated receipt or receipt url method. I think you will need both in order to choose the appropriate validation.

[maxmoore14]

That's a good point. So are you thinking uncomment 147 & 161 to restore the deprecated functionality, then also add a separate function like getAppStoreReceiptFromURL() ? That function could return the receipt data if available or nil.

Then it would be the individual app's responsibility to try the new function first...

function purchase(transactionId, productId, deprecatedReceipt) {
    var receipt = getAppStoreReceiptFromURL();
    if (receipt) {
        // use new
    } else {
        // use old
    }
}

I think it would be great to have something like this on the JS side.

window.storekit.init({
    purchase: function (productId, transaction) {
        console.log('purchased: ' + productId);
        console.log(transaction.id);
        console.log(transaction.transactionReceipt); // false or deprecated receipt
        console.log(transaction.appStoreReceiptURL); // false or receipt url

    },
    restore:  function (productId, transaction) {
        console.log('restored: ' + productId);
        console.log(transaction.originalTransaction);
        console.log(transaction.transactionReceipt); // false or deprecated receipt
        console.log(transaction.appStoreReceiptURL); // false or receipt url
    }
})

That way the signature of the callback would be more flexible and the transactionReceipt property can easily be removed from the transaction object when it is no longer needed.

It would however require users to make a slight modification to their existing implementations when they update.

[maxmoore14]

That would be great too. It is a minor change to the client API, but would be a good/flexible way of handling changes going forward.

[maxmoore14]

If it helps, the related code sample around minute 13 from the video is:

NSURL *receiptURL = nil;
NSBundle *bundle = [NSBundle mainBundle];
if ([bundle respondsToSelector:@selector(appStoreReceiptURL)])
{
    receiptUrl = [bundle performSelector:@selector(appStoreReceiptURL)];
}

I reckon it's up to j3k0 to decide which way to go here.

I could probably spare some time on the weekend and contribute.

[j3k0]

I would prefer to keep things backward compatible, in order not to break silently everyone's projects (as changing purchase and restore signature would do).

Also, there is still a thing. The appReceiptURL may be a file:/// URL or something the iOS SDK will understand but your server or JS code won't. Apple suggests here that we read the receipt then transmit it base64 encoded to the server for validation.

That being said, would something like this make sense to you:

storekit.loadReceipts(function (receipts) {
    receipts.appStoreReceipt(); // null or base64 encoded receipt (iOS >= 7)
    receipts.forTransaction(transactionId); // null or base64 encoded receipt (iOS < 7)
    receipts.forProduct(productId); // null or base64 encoded receipt (iOS < 7)
});

Did not know that. That means the validation process on the server will always be the same. It's just a matter of how do I get to the base64 encoded receipt, which in my mind is the responsibility of the native plugin.

Couldn't we then just leave the signature at:

window.storekit.init({
    purchase: function (transactionId, productId, transactionReceipt) {
        // transactionReceipt is always a base64 encoded receipt
    },
    restore:  function (originalTransactionId, productId, transactionReceipt) {
        // transactionReceipt is always a base64 encoded receipt
    }
})

[j3k0]

Except that the format is not the same in those two case:

• appStoreReceipt is a collection of receipts (including among other things the transactionReceipts).
• transactionReceipt is just a single receipt

I wish things would be simpler, but I guess we need to differentiate them.

Maybe with a good deal of work, it would still be technically possible to decrypt the appStoreReceipt, extract the transactionReceipts, then pass them as a parameter to the purchase and restore callbacks (unencrypted though)... I'm not sure how safe this would be.