Have MarketplaceService Finished events return the amount of Robux purchased for easier tracking

As a Roblox developer, it is currently tedious to track accurate purchases (that aren’t developer products) in games that crucially require the amount of Robux that was purchased for, and in all cases, an accurate number for leaderboards and such. People have been modifying their selling items to an absurd price like 99999999 Robux, then set to 1 for them to purchase. We can only do a lot with just remote coming off from local scripts, but there is no way to tell the actual amount of Robux that was purchased since the Finished events fire after the player clicks OK and they could change their price back up beforehand.

Looking at the documentation, MarketplaceService purchase events currently only feature Finished events, but it would be A LOT easier if Requested events are not locked to CoreScripts. I can understand that it would allow games to know if a purchase prompt is up, but what’s really the point when you can easily tell after you fire PromptPurchase in a local script anyways?

The main feature it would benefit most developers including me would be returning the amount of Robux that was PURCHASED for. This way it would not need to call any additional APIs, to prevent being tricked into (like exploits). That being said, developer product functions do return the amount of Robux that was purchased, so it would also make sense to do the same for those functions such as passes or asset prompts, as this would make it easier for us developers.

8 Likes

These events were only meant to be used to detect when the prompt is dismissed for other UI.

For the longest time, and basically forever, Roblox has always advised against using PromptProductPurchaseFinished to detect when the purchase is completed.

Moving forward, Roblox should instead support a new MarketplaceService callback that works for all prompts, not just products.

2 Likes

Unfortunately, this is easier said than done - the server does not know the amount a purchase was made for. All it can currently verify is whether or not a purchase was made. Developer products operate off a completely different system that only really makes sense in the context of transactions where delivery must be guaranteed - the additional information provided by ProcessReceipt is a byproduct of that system, more than anything.
While this would make life easier for a select few use cases, games are very rarely processing transactions so volatile that GetProductInfo won’t do the job. I don’t see this being implemented (at least not any time soon) given the significant strides it would take compared to letting developers create their own, more specialized implementations.

Currently having this issue too. Is there any way to negotiate this issue right now?