Everything seems half-baked

I'm not really happy with the state that this service is, and I need to talk a little bit about it. I'm sorry if this ends up any mean, I'm really frustrated, had to run this week trying to make some stuff to work, and not getting it right.

First, the dashboard. Why can't I edit the user's currency amount? Why can't I add items to the inventory? Or remove them? Those are basic things that I can't see how to do it in a simple way. Why would I want that you might ask? For support. I can't have a person just for support, that can go into a user's inventory and add a "Ops, we screw this up with you, sorry for that, here, for our mistake!". This can also be said to the Cloud Save, I can't add new entries, but I understand that those might be different teams.

Second, the real money purchase. Do you guys talk with the IAP team? Doesn't seem so. Starting with the documentation.

        /// <summary>
        /// Takes a realMoneyPurchaseId. This is the configuration ID of the purchase to make.
        /// Takes a receipt. This is the receipt data as returned from the Apple App Store.
        /// Takes a localCost. This is the cost of the purchase as an integer in the minor currency format, e.g. $1.99 USD would be 199
        /// Takes a localCurrency. ISO-4217 code of the currency used in the purchase.
        /// </summary>
        /// <param name="realMoneyPurchaseId">Configuration ID of the purchase to be made</param>
        /// <param name="receipt">Receipt data as returned from the Apple App Store</param>
        /// <param name="localCost">Cost of the purchase as an integer in the minor currency format, e.g. $1.99 USD would be 199</param>
        /// <param name="localCurrency">ISO-4217 code of the currency used in the purchase</param>
        public RedeemAppleAppStorePurchaseArgs(string realMoneyPurchaseId, string receipt, int localCost, string localCurrency)

Cool, just take the UnityEngine.Purchasing.Product.receipt and send it, right? Wrong! Its actually the payload. How would you get it? Perhaps with a crystal ball. Or google.

Besides that, the localCost, why is up to the developer to convert it to the right amount? Couldn't you receive the exactly amount reported by the store (double) and convert it internally? You already ask for the currency code, so now everybody has to do a conversion, that the plugin should already do it by itself.

Now, do you know how to properly test it? You have to publish it and make a real purchase! Not even an sandbox account, real money has to be spent! Hurray! If you don't, the payload (from both google and apple) will come empty, and you can't test anything with it. I understand that this is a store limitation (that I had to dig into the IAP forum to find it, nothing was said about this in the documentation), but we need a way to properly test it, especially inside the editor.

Third and final point, god this is a PAID service! The lack of integration inside unity's own tools is astonishing. Sometimes especially the dashboard part, seems that the team is trying to fit the maximum amount of features possible, but not putting too much attention on how those tools will be used day-by-day.


Not very intuitive (and nowhere written), I know, but it doesn’t expect an object of type PurchaseReceipt but a string, and there are three fields in this class that return a string. One is the store, which definitely is the wrong thing, the next is the transaction id (from the store I assume) and then we have the payload. So you could (with quite a bit of fantasy) figure that out, but I agree, testing this is very hard.

The problem is, from version 3.0 (maybe older, but older than that the site breaks) to the most recent version 4.6.0, Product.receipt is a string. So, when the object that comes from purchase, has a receipt, is a string, and the field asks a string AS RETURNED FROM THE STORE, I’m actually discouraged to parse it.


Thanks for sharing your feedback @Hiago_AD , we really value it and appreciate you taking the time to share it with us. I'm sorry that you have found the process so painful.

I totally get where you are coming from. A lot of our UGS systems are brand new, whilst some have existed in one form or another for a while. We are working hard to resolve and simplify a wide range of use cases and interdependencies. But as you have pointed out, we still have a way to go.

With regards, specifically to your experiences with IAP. You are correct. There are quite a few complexities relating to the different stores and we aren't doing a good enough job with end to end documentation and workflows at the moment. I will be sure to raise all the points you have highlighted with my colleagues working across UGS and I'll do what I can to move things forwards.

I know that we've been having disucssions internally about improvements to IAP and receipt validation workflows, your input will help validate and add momentum to our actions.

Thanks again for your feedback :sweat_smile: