Associate INITIAL_BUY statusUpdateNotification with a user account

When we receive an `INITIAL_BUY` statusUpdateNotification on our server, I can't see a way to associate that purchase with a user account. So we can't actually do anything with it at all, and have to wait until the app uploads the receipt to make that association. Am I missing a way to set a user identifier somewhere?

Replies

I believe you are correct. The connection will be through original_transaction_id.

Thanks for the response.


That association can only happen after we've uploaded the receipt from the app, which would give us all the same information anyway. The `INITIAL_BUY` notification seems to be pointless since it will likely arrive before our server knows which user matches that original_transaction_id.


It would make a lot sense if the `applicationUsername` attribute on `SKPayment` were passed to our server in this INITIAL_BUY but it's not, as far as I can see.

The initial_buy comes with the receipt that can be used to update the subscription. Yes, you can get that receipt from the device itself. But with this notification all you need do is exchange the transaction_id and the device is linked to the notification.


'applicationUsername' was introduced a few years ago for some weird reason. I do not understand what scam it is trying to prevent and no one has every clearly described the purpose of applicationUsername. As you point out, it would be great to get it back from Apple for many reasons - including security for preventing reuse of receipts. But Apple says it is not for the developer/app but for internal Apple use.

While initial_buy may come with the receipt, that receipt is useless for purposes of matching back to a user in my system until my app notifies me of the transaction and the user together.


Is there some way of passing my user information through with the purchase that I'm missing? Otherwise how would an INITIAL_BUY notification be useful at all?

It provides the receipt to your server without a man-in-the-middle issue.


Yes, "that receipt is useless for purposes of matching back to a user in my system until my app notifies me of the transaction and the user together." But you can replace "useless for purposes of matching....until" with "can be used to match...once". The notification was not meant to do what you want it to.

PBK, I'm not sure what you mean by your earlier comment 'But with this notification all you need do is exchange the transaction_id and the device is linked to the notification.' I suspect that might be key in understanding the purpose of the INITIAL_BUY notification.Would you mind expanding on what you mean there, please?

The INITIAL_BUY notification contains a "latest_receipt" filed. This is the receipt for the transaction. You can decode it using OpenSSL or you can send it to the Apple serbvers and they will decode it. It contains a value for transaction_id. The device that made the purchase got a call to updatedTransactions with a transaction.transactionIdentifier having the same value. That device needs to call your server and announce that it got that transactionIdentifier (i.e. 'exchange the transaction_id and the device is linked to the notification').

Thank you. There's clearly benefit in some cases, depending on how things are implemented. I assume that most folks will still upload the receipt from the client at the same time as the initial buy is detected in updatedTransactions to mitigate the possibility that the server-to-server call was never sent or received successfully.

IMHO the most secure way of handling IAP is to decode on the device itself.