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.
