Currently, MarketplaceService.ProcessReceipt is a callback to handle developer product purchase logic for our games.

However, the current approach makes it harder to add purchase logic per developer product, leading to several nested if-statements or lots of elseifs.

I suggest that MarketplaceService:SetProcessReceiptCallback(int productId, function callback) is added, as it makes code cleaner and lets the developer put their game logic close to its relevant other code.

If this method is called, any future invokations that would’ve happened to ProcessReceipt for the given product ID will instead go to the specified callback function - which has the the receipt table as a parameter, and returns an EnumItem of the ProductPurchaseDecision enum type.
In case a developer product ID hasn’t been added with the suggested method, ProcessReceipt is invoked as normal.
Multiple calls to the method will override older ones, but not affect callback functions that are currently running.


Here is a similar thread (but not same – so don’t merge) that has a few staff responses that will be valuable to some topics that may spring up here.

Mhm, I did check it out - I still believe it’s a good addition, though - and isn’t quite the same, in response to those replies.
Purchases may be triggered in multiple scenarios, but the logic to handle it is tied to the product, and not as much the instance of someone purchasing it.

A problem with a suggestion to the other thread is what would happen to a callback attached to a dev product prompt triggered by a client :thinking:

Oh I know the pain :frowning: In Deathrun we have many products and gamepasses that have to be supported by our transaction logic. Currently it are modules that are called whenever the product has been sold… It would be so much easier to just create a custom callback for the product and use that instead…

(Yes it is possible with a BindableEvent that is invoked on the default callback and then let all our code listen to it with a custom ID and … but come on !)