The event PromptProductPurchaseFinished is depreciated, but PromptPurchaseFinished does not fire for Developer products. This means that PromptProductPurchaseFinished must be used to detect products finishing purchase, forcing depreciated code use.
To note, PromptProductPurchaseFinished is deprecated just so that people don’t use it instead of ProcessReceipt. Not saying I agree with it, I don’t, but that’s their reasoning.
Thats not correct, PromptProductPurchaseFinished is not deprecated and is still recommended by intellisense and the wiki. Its PromptPurchaseFinished that is deprecated.
PromptProductPurchaseFinished is deprecated. PromptPurchaseFinished is not deprecated. However on the Wiki it states not to use it as a replacement for ProcessReceipt.
PromptPurchaseFinished was never intended to fire for products, I don’t see why this thread needed to be bumped?
The description of this is “Fires when a purchase is either denied or accepted.”, which either needs to be updated to reflect the fact that this isn’t true for dev products, or the API needs to be fixed.
We’re not using it for a replacement for ProcessReceipt, I want to know when the player clicks off the purchase page, so I can play the purchase animation without having the ugly “Purchase Complete!” UI in the way.
I understand everyone’s use case for the deprecated PromptProductPurchaseFinished event, as I use it myself to know when the purchase dialog has been closed.
But logically speaking, I think the naming of the two methods make sense.
Call PromptPurchase? You can expect the respective event (PromptPurchaseFinished) to fire with whatever the result is of that function.
Call PromptProductPurchase? You can expect the respective event (PromptProductPurchaseFinished) and ProcessReceipt to fire with the results of that function.
This post was originally for a bug that didn’t exist and you bumped it with incorrect information as well. If you want to have the Wiki changed accordingly, a response to a bug report post is not a way to get it shown; I would post it in #platform-feedback:documentation-requests . I agree that the description is confusing though.
Still not working, tested it multiple times with different Developer Product Ids. I’m not certain if it is fixable at this point after all of these years of not working.
Just a reminder, you should be using ProcessReceipt for most developer products. Mostly, ProductPurchaseFinished can only be really used for UI’s and stuff.
The wiki article for PromptPurchaseFinished makes it out to look like both PromptPurchaseFinished and PromptProductPurchaseFinished will fire when a player cancels their purchase… except they it doesn’t work like the wiki article says it does.
This seems to be a bug that should be fixed by making it so PromptPurchaseFinished fires with the third parameter set to false when the player cancels their purchase!
But instead you have a confusing wiki article for the broken event saying you should use the deprecated event, and a wiki article for the deprecated event saying you should use the broken event.
My use case for the deprecated event right now is preventing a player from buying a certain developer product twice, and this needs to be handled by listening to PromptProductPurchaseFinished event on the client.
Can’t you do :PromptProductPurchase on the server instead of the client using a remote, then just check if it was bought or not, and only prompt if it wasn’t, using ProcessReceipt to keep the data about that the purchase was or is being processed? (Also keeping a countdown debounce yourself just to be sure)
Remotes fire in order, but I don’t know if ProcessReceipt is fired in that order.
Regardless of where :PromptProductPurchase is called, AFAIK, PromptProductPurchaseFinished (the simultaneously deprecated and recommended-by-the-wiki method) is the only way to tell when the player cancels their purchase.
Using remotes doesn’t actually change anything, and that’s not what my post was about. Anyways, having this detected client-side makes UI more instantly reactive, allowing the prompt to be shown again immediately after they cancel it.
