CoreGUI Product Purchase Success appearing regardless of ProductPurchaseDecision

[Grersh]

While testing MarketPlaceService:PromptProductPurchase and it’s callback ProcessReceipt, I encountered that Regardless of if the ProcessReceipt callback returns NotProcessedYet or PurchaseGranted, on the client the purchase success CoreGUI will appear.

What I want to know is if Players are still being charged regardless of the NotProcessedYet callback being returned, as well as if the success CoreGUI only appears for both options in-studio.

I have no way of testing this online, so a response from a Roblox Administrator with regards to this would be appreciated.

The Callback and the initial ProductPurchase prompt are both being done on the Server.

[Grersh]

After further research, I discovered this post

Enum.ProductPurchaseDecision.NotProcessedYet

It’s specified in the documentation that the callback is fired once again when the player joins the game or purchases another product until PurchaseGranted is returned. I ran some tests and this is true. However, the callback is only fired again if the player joins the same server it made the original purchase in. Same thing applies for the second statement, the callback is only ran again if the product was purchased in the same server the original product was purchased in. No, returning No…

In this post I see conflicting information where some state that it does deduct the robux whilst others state that it doesn’t.

I think the documentation should be more clear for this Enum.

[MysteriousVagabond]

From my understanding, returning PurchaseGranted really only signals to ROBLOX’s backend that the purchase has been handled so it can stop asking about it.

After just testing it now, I created a developer product on another account and set the MarketplaceService.ProcessReceipt function to do nothing except immediately return NotYetProcessed. I purchased the product twice, and ROBUX were subtracted both times.

If you have developer products that are only relevant in particular contexts, an approach to handling out-of-context transactions is to simply apply a credit to the player’s account for that transaction and report it as complete. The next time the player is in the specific context and attempts a purchase, you should consume that credit instead of prompting them to make a purchase. You’ll obviously want to indicate to the user when they receive credit instead of the product they were trying to buy and make it clear when they are in a context to use that credit that they have it.

[Grersh]

@MysteriousVagabond

simply apply a credit to the player’s account for that transaction and report it as complete.

I was afraid this is what I would have to do. I think I’ll implement a “Token” system instead where players can buy and redeem them in-place of the immediate developer product purchase. This was what I was planning from the start to do in the future anyway.

@MysteriousVagabond

After just testing it now, I created a developer product on another account and set the MarketplaceService.ProcessReceipt function to do nothing except immediately return NotYetProcessed. I purchased the product twice, and ROBUX were subtracted both times.

This seems like a HUGE oversight by Roblox admins and I hope that they will revisit both the documentation and how the callback works. Developers could mis-interpret the documentation like myself. Thank you for testing this as well.

Proposed solution for any admins reading this. I think you should add a new EnumItem to ProductPurchaseDecision, one such as PurchaseDenied to go alongside with PurchaseGranted

Unfortunately, given the amount of time it takes for any feature to get implemented I doubt we will see this anytime soon.