As a Roblox developer, it is currently too hard to create products with variable properties. For example, imagine a developer product for a pet where you can enter a custom name for the pet. In order to do this correctly, you would have to have access to the custom name inside of the ProcessReceipt function, each time it is called. This means you must somehow store the name in a way that is specific to that purchase.
I propose that one of these three redresses be implemented…
1: Add another parameter to PromptProductPurchase, which is a table of variables that is also added to the ReceiptInfo of ProcessReceipt, allowing direct access to them in ProcessReceipt.
2: Return the ReceiptInfo (Or just the ProductId) from PromptProductPurchase. This would allow the variables to be saved in a datastore and accessed again in ProcessReceipt.
3: Add a Cancel option to ProductPurchaseDecision, so that if the variables are no longer accessible (i.e. the player leaves before the purchase is processed then returns) the purchase will not have to go through.
If Roblox is able to address this issue, I would be able to increase the reliability of my developer products.
I guess another way to do this is in the example of the pet would be to purchase the pet, THEN be able to change the name, but that wouldn’t be optimal in the scenario I’m using this for. I’d like to be able to have the player enter the name before they buy the product.
I’d prefer the option of PromptProductPurchase returning the PurchaseId. That way I could save the custom variables in a data store under a key with the productId, and save with it a variable of if it has been successfully purchased…
If you need a feature like this, your code is probably structured in a hacky/messy way. A devproduct purchase is basically a ticket saying I have the rights to this thing. That thing could be anything from in-game currency to admin commands, furniture or whatever. In your case it would be; “I have rights to a pet”. What the pet’s name is, is not important for the purchase. Adding custom data that has nothing to do with the process of purchasing would be messy for the API (this is what the ProcessReceipt callback is for). Devproducts are already a difficult concept to grasp for the lesser experienced developers, and I think this feature would make it even more confusing.
Here’s what you should do in the case of your pet example:
Client sends a signal to the server saying I want to buy a pet with name X.
The server has a piece of logic that reads the data from the client and stores the pet name. It then sends a signal to your market logic saying this player wants to buy a pet.
Your market logic prompts a purchase.
The client either accepts or declines the purchase.
In case of a decline, do nothing. Otherwise, the market logic sends a signal back to the logic with the pet’s name stored.
Your pet code assigns the name to the pet and returns Enum.ProductPurchaseDecision.PurchaseGranted to indicate that the purchase was successful.
What if the player leaves before the purchase is granted? When the player returns and ProcessReceipt is called again, how would it find the name of the pet when you entered it on another server?..
I think that would be confusing. I’d rather be able to cancel the purchase.
Or like I said, if PromptProductPurchase returned the productId, that would be optimal.
If I can’t do either of those then I’ll make it so you can edit the variables after purchasing the item, but I wish I didn’t have to make any compromises.
7 years later and I’m here to annoy everyone by bumping this up. Was going to make a new one but this is actually the closest to what I want.
In my case, I have a game with a gamepass gifting system, and at present the way we have to store who you’re gifting to is just on the server with a player-to-target table. I can separate the products for the individual gamepasses, but there’s no way to correlate who a product purchase was targeted for, simply the fact it was purchased. This means that if we don’t implement a way of blocking multiple gifts being done at once, there can be a conflict where a gift is accidentally redirected to a different player if they decided later on to change their gift target.
I personally believe the first proposed API that was given would be good (being able to provide a serializable object that is added as metadata which is then passed back at ProcessReceipt), but considering the current method signature for PromptProductPurchase this might be difficult to implement in a nice way whilst preserving backwards compatibility.
The second proposition would preserve backwards compatibility, but also is similar to the player-to-target table, just with a different key, but is better since it can’t be overridden as easily.
The third proposition of this, whilst a bit unrelated, is still important and I’m surprised this still hasn’t been implemented all these years later. Using NotProcessedYetisn’t an appropriate solution and whilst it does encourage developers to implement “banking” systems for products (i.e., when a revive can’t be used, add it to a revive counter for future use), in some cases it’s not possible for event-timed items or if a product changes price to become more expensive or cheaper, and in our case the gifts that we have are sometimes for limited-run items that get removed from sale at a later date. I personally believe it would be disingenuous if we banked such gifts and they gave a different item later on as compensation, and it would be unfair to other players to make it award an item that should have been limited at a later date. I’m aware that at ProcessReceipt time the purchase has already gone through, but it’s still really awkward that we have no way of refunding purchases that should no longer be valid.
Enough yapping though, I think there definitely needs to be a way of adding metadata to product purchases at the very least. Stripe acts as a very good prior art for why it should exist and how it can be used effectively.
