Here. How to use the the login API, tried it, didn’t understand it.
How to use the captcha fields?
Terrible idea,
You are changing the devproduct for not 1 user, but for everyone. I am sure this game has a different way of doing it, besides, why would you want to do this?
Dynamic product prices for a given transaction.
The idea is to automatically change the price of a developer product right before asking a player to buy it. One use case is allowing a player to donate an exact amount of Robux of their choice.
I’m sure a large pool of developer products can be managed so that no player gets asked to pay an amount someone else requested.
What he’s saying is its a terrible idea to even try to do this. Since you’d be changing the price of a DevProduct for EVERYONE when someone inputs the amount they want. What happens when multiple people try to donate at the same time? Unless you have access to create new DevProducts (not really a scalable idea anyways), I wouldn’t recommend doing this
4 Likes
You need to pass a ROBLOSECURITY cookie along with your web request to the Roblox website, otherwise it will deny your request to change dev product prices.
I don’t recommend using a cookie from your main account, however.
Sure, it’s not the most scalable of ideas, but if you keep a database of ongoing transactions and in-use developer products, you can prevent collisions by never using developer products for multiple transactions at the same time.
Thanks. Will try this as soon as possible.
Since I was told that several times, look at the post in itself, edited it to answer to your concern.
Thanks for trying to warn me. Since I was told that several times, look at the post in itself, edited it to answer to your concern.
I apologise I’m advance but my response is more about advising against this.
I don’t advise directly modifying products to create custom donation products, especially if multiple people are buying, because such a task can quickly get muddled especially if products are modified mid-purchase. Users can quickly lose money or end up paying a different amount than what they expected and this will result in more than just unhappy users. You can return NotProcessedYet for unexpected amounts or prompts not made by the server, but there is still an inherent risk in doing this.
You need to tread carefully when making systems involving Robux that are not natively supported. Any mishap, unexpected processing of a purchase or otherwise a situation where a user pays a different amount than what they expected can result in serious action, including the loss of your account. It’s not a risk worth taking.
You are more advised to make incremental products (e.g. 1, 5, 10, etc), break down the requested donation amount and prompt purchases of the products until the user meets the total amount or cancels the purchase. A donation center using such a strategy released their source code for doing this.
Hm, thats a good idea. Will consider it.
I do agree with you that it’s a bad system, and I would like to thank you for telling me. As I was getting this told to me alot of times, I edited my post to answer in advance to everyone not recommending this.
Your friend doesn’t understand the risks nor the consequences of this then and they need to be enlightened about them. I don’t take “my friend told me to just do it” as an appropriate response to an advisory against doing this which involves very serious repercussions for failure. Not only for the person intending to use this, but for everyone else who attempts to do this.
Arbitrary modification of developer products from an external service is an inherent risk. We haven’t even yet asked the question if this is allowed and I strongly doubt it is.
Yes, all the answers were sent to my friends. Found an alternative way to do it (user would enter an amount, then It would list all the products he has to buy to complete that amount)
So… basically the post I linked earlier. Glad you’ve adopted that system instead of arbitrarily changing your developer products.
Please be sure to mark your post as the solution.
TL;DR: Using API to do this is really dangerous, consider other methods.
“Endgame” Post
I would like to thank everyone that warned me about the risks of this. I will be straightforward: do not use API to make dynamic developer products. There are a lot of ways to do that, but please do not take the API one, we do not know if it’s allowed and it’s really risky.
Solution 1: DevProduct Wall
You would have a list of DevProducts
Solution 2: The Counter
Basically, you input a number, (31 for instance), then a script will show a list of DevProducts to buy to reach the said amount (31).
I will NOT go into details in this post, but I will link all posts that told me to NOT do that.
1 Like
I understand why lot’s of people call this a bad idea - but if done right it’s actually really cool and powerful.
I’m not sure what you want to code this in - I’m going to assume it’s Node.js.
Editing existing developer products is a very bad idea (for reasons already mentioned). However, creating a new product isn’t so bad. With the right checks, both off-game and in-game, you shouldn’t run into issues where someone is paying what they shouldn’t.
First off, you should have a private API key that no one knows, aside from you and the game owner. You should then use one of my modules, RoCheck, to make sure the request is really from your game.
When your Roblox client joins a game, it asks the Roblox API for the IP address and port to send packets to. RoCheck basically does the same thing - it asks the Roblox API for the IP of a server. Using this information, we can compare it to the requesters IP address and we will know for sure that the request is from a Roblox game.
And once you know it’s from a real Roblox game, just do a simple if statement to check if the roblox-id header is your game.
As for actually handling the developer products, you should set up an API which just takes in the developer product cost. Your server should have a database of already created developer products. When it receives the request it should query the database for a document with that developer product price. If it exists you return the developer product ID to the game.
If it doesn’t already exist, use the Roblox API to create a new developer product with the desired price. Then add that to the database and return it to the game.
When the game receives the developer product ID, it should use MarketplaceService to do a double-check that the developer product exists and that it’s the correct price. If it is then prompt the purchase!
I hope I could have been some help to you. When creating something risky like this, you should always do your research into all the different methods and ways of securing it. Please ask if you have any questions!
Creating throwaway assets for one-time use cases is just as bad but in a different mannerism. You’re inflating the asset database by creating one-time assets that aren’t used ever again. Also, whether this is allowed or not hasn’t been addressed.
1 Like
You’re not creating one-time assets. I don’t know the exact use-case so I can’t tell how much variation there’s gonna be in dev product prices. The whole point of the database is so you can use existing developer products. E.g:
Person A buys something for 100 Robux (New product created)
Person B buys something for 200 robux (New product created)
Person C buys something for 100 robux (Existing product used)
I imagine that using the API is allowed (if it wasn’t, why is it publicly documented?). The bit that isn’t allowed is charging your users the incorrect price - which my method would prevent, especially if you do a final MarketplaceService check before purchase.
The point of setting up a system is accounting for arbitrary pricing, especially for a donation system. Keep in mind that OP isn’t the only one looking at this post. Variation can be anything, from a few to a lot. It’s better to just set up a set amount of products that you can incrementally prompt until the total is reached instead of trying to handle things like this.
As for the API - just because it’s public and documented, doesn’t mean that all uses cases of it are permitted. Saying “it’s public so it’s allowed” is bad justification and insufficient citation for making a judgement call about what engineering or moderation thinks about how you use the API.
1 Like
Yeah, I once had a project of making a “bank”, that was basically if you’re user 1 you can give ROBUX to user 2 via API and Developer Products, if I’d actually make that, i’d probably end up terminated, even though I can payout through API.
roblox staff i didn’t make it please do not terminate me i love roblox it was just an idea
1 Like