question

Correct - as I said, any payment provider would have to be directly integrated for it to work. Unity is not the payment provider in this case - Samsung is.

OpenIAB is also not a payment provider - it is (some would argue was, since active development halted on it quite some time ago) an open source library for doing payment validation with various providers.

Similarly UnityIAP is also not a payment provider. The reason I'm emphasizing this is because for payments to be secure in such a way that we can have confidence that players are only getting items they pay for (but are reliably getting the items they pay for) is if there is a single round-trip on the validation step - the client sends us some information which we validate with the payment provider, and then we add the appropriate item(s) to the player inventory before finally returning the information to the client.

For Samsung specifically, that means integration with the server-to-server verification process described in their FAQ, here: http://developer.samsung.com/iap. Please note that their description above, where the client validates the receipt, then the client gets the item, has the essential flaw that they've made the client authoritative for the decision-making about giving the item to the player. That's specifically what we designed our system to prevent, since it's one of the most commonly hacked features of any game. If you do a search, you'll find many instances of developers talking about a bogus "Cut the Rope 2" receipt that's used in a common hack to get free IAP items in many games that don't use a secure model (no offense to ZeptoLab - their game is fantastic, it's just that someone chose to use one of their receipts in a hack that then spread).

For Q4, no, we recommend having a price in RM in your game catalog, but the actual price things are sold for in receipt-based systems is completely out of our hands - it's the platform that sells the item. That's why the receipt validation API calls take a currency code and price, so that you can specify them there.

For Q5, we do not support client-side receipt validation, for the reasons stated above. It is insecure, and effectively guarantees that you will have people getting in-app purchase items without paying for them.

Hi Brandan,

Just received and update from the Unity team, and they say "Samsung provides receipt information suitable for Remote Validation."

Local Validation would require additional cryptographic data to be included in transactions from Samsung.

Still, I'll call what we receive a "receipt" for convenience's sake: a "purchaseId". We also receive a "paymentId" which is what we map to "transactionId". We pack the "purchaseId" into the Unity IAP receipt field as a trivial JSON string.

You may already know how to access the Unity IAP receipt field, from your earlier work. After successful purchase, in the app's ProcessPurchase(Purchasing.PurchaseEventArgs e) implementation, the receipt will be available in e.purchasedProduct.receipt. This string is packed up by Unity IAP to contain each App Store's various receipt fields. As suggested above, this string should look something like: {"purchaseId":"d215d9abcd17b12578a21c0ea7d8821747b64939732a3243b538d8bcae245590"}.

The Remote Validation server-to-server API for validating this receipt is described in the Samsung IAP Programming Guide "ProgrammingGuide_SamsungInAppPurchaseSDK_v4.0.0.pdf" document: http://developer.samsung.com/iap/guide E.g. call https://iap.samsungapps.com/iap/appsItemVerifyIAPReceipt.as?protocolVersion=2.0&purchaseID=d 215d9abcd17b12578a21c0ea7d8821747b64939732a3243b538d8bcae245590 and parse the response.

It looks like a simple rest call, to the Samsung server. I know that you have mentioned that we are probably the first game team to request Samsung verification, how hard and time consuming would it be to add support for this feature on PlayFab? - This could be used by other games as well, in the future, as clearly Unity has made it official to support Samsung IAP.

Thanks-

Yes, if they didn't provide enough information for it to be used for validation, it wouldn't have any use as a payment system whatsoever. However, for it to be integrated into our service as a payment provider is a very non-trivial amount of work. It's not just the implementation - which is not just a single Web API call, as we must integrate it as part of an end-to-end payment system - it's also all the test time required to ensure that the implementation is correct and has no holes. I'm sorry, but given that we have many other features that have much higher numbers of developers asking for them, we cannot "jump the queue" with this particular feature. If more developers come to us asking for this feature, that could change its priority, but to date, we have had only the one request for it.

Now that said, there's nothing stopping you from implementing receipt validation the way they're recommending - you could call their service to validate the receipt, and then call into our service to grant the items purchased. Because this would not be using our end-to-end purchase system, it would be vulnerable to cheating by a hacked client, as is the case with a large number of games which do client-side receipt validation, but it is at least an option which is available to you.