In App Purchase: What's the security benefit of 2 server receipt verification?

Question

Created Apr ’17

Replies 2

Boosts 0

Participants 3

The developer documentation for In App Purchasing talks about a method to use a server validation. In this case, My app will send a reciept from IAP to my server. I will then send that to Apple's server.

AppleProductionUrl = "https://buy.itunes.apple.com/verifyReceipt";

AppleTestUrl = "https://sandbox.itunes.apple.com/verifyReceipt";

What exactly does the Apple Server verify? Can I skip this and verify only on my server?

What analysis of the reciept must I do?

- Inspect bundle ID, check.

- Make sure the reciept instance isn't a replay (somehow)

Boost

Answer 1

PBK OP

Apr ’17

Accepted Answer

The receipt is encoded using OpenSSL techniques. You can decode it on your server, in the app or use the Apple servers to decode the receipt. The encoded receipt protects you from scams in which the user injects a 'purchased' command into updatedTransactions and tries to fool the device into thinking it purchased an IAP. Such a purchase would not have a valid, encoded receipt.

There is another feature that the Apple servers seem to provide - they will convert an old autorenewable subscription receipt into the latest autorenewable receipt thereby telling your server that the user's subscription has been renewed without requiring action by the user.

0

Answer 2

KMT OP

Apr ’17

>What exactly does the Apple Server verify?

Valid user vs. spoofed purchase.

>Can I skip this and verify only on my server?

Yes. Better yet, do both, that way you gain legacy support and the user has a better experience without having to take additional action vis-à-vis autorenew, as an example.

0