I love the idea.
1 Like
I guess that explains it better, but I still don’t see how it would be any less ‘grabbing for money’ considering a refund feature exists in the first place and that the player requests for one. What’s the difference with messaging the developer and having a user-ended refund when either way you get a message that player would like a refund? It’s one step less for the developer. I don’t see how they could abuse that? It could be a one time request per product. Pretty sure one doesn’t need all the time to issue a refund, it’s a yes or no response.
The holding period for gamepass/product sales aren’t exactly consistent, but nevertheless my first post simply stated that refunds should be only available within a certain period of time, while:[quote=“Sharksie, post:6, topic:31436, full:true”]
If the developer is the one issuing the refunds then it can just come out of their robux balance, no need to require it to come from pending sales.
[/quote]
@GollyGreg It’s a developer-ended feature and also includes giving refunds even after the holding period. So no limit of refunding for the developers. (I guess it sounds cool, refunds with no expiration) Still adds support to the ‘I got bored of this and would like to request a refund because I know developers have the power to do so at any time’.
Would they persist even after a response such as ‘sorry, that’s not valid reasoning for a refund’ or do we just ignore it?
What if the developer doesn’t have enough funds, do they wait for their pending sales?
(Why wouldn’t refunds be taken from our pending sales in the first place? Isn’t that where their Robux is? Or would be any refunds issued to a player who purchased a product and has owned it for more than 3 days will deduct the Robux from your account?)
I’d set up a logging system and don’t grant the ProcessReceipt request until you know the purchase went through and the data was saved.
2 Likes
Good thing to do but bugs can happen separately from ProcessReceipt e.g. wrong item being saved to inventory. I’m not particularly sure in what case refunds are a better option than data restores (maybe @Sharksie could chime in here), but regardless it’d be a powerful tool for a game’s CS.
I agree that there should be no limitations. If a player bought something a week ago, it’d suck if I weren’t able to refund it just because the refund is happening > 3 days after the purchase. If I have the ROBUX in my account as Sharksie mentioned, I should be able to unconditionally do a refund – it’s my revenue and it’s my choice what I do with it.
Refunding should also be sure to work with developer product sales, even though they aren’t a traditional asset.
Well I mean, the real solution is to just design a perfect bug-free system. Why do we even have dev stats? Just make the perfect game the first time, you know?
1 Like
Sarcasm noted, but it really is something you should be careful about.
Make sure you do extensive testing of your game’s purchases. Test disconnection scenarios or server crashes during purchases. Organize and plan out the code design in a smart manner so you don’t have to have the excuse of not knowing what exactly went wrong.
I’m not saying I’m a genius when it comes to this stuff, but it is money, so you gotta take extra precautions to make sure the purchase went through before you authenticate the receipt. Log receipts so you can check if the person Is lying or not.
1 Like
We can talk about a perfect system all day but when you actually implement it it’s going to have flaws and bugs, some of which are out of your control. There’s currently no way to make a perfect purchase handler that works 100% of the time because of how datastore limits inherently work. There will always be problems, I’m just asking for a way to handle them.
3 Likes
If you use developer products, don’t return PurchaseGranted from the ProcessReceipt until you’ve saved the player’s purchase in a data store. That way if your code fails the player will get his money back.
2 Likes
ProcessReceipt is unrelated. The previous posts clarify that.
How is it unrelated? In the original post, it sounds like players’ Robux are being taken and they aren’t receiving what they paid for. The solution to that is to wait to accept their money until you’ve given them what they paid for and stored the transaction in a data store.
That isn’t the problem. The problem is that I want to have the option to give refunds when players aren’t satisfied with the product, whether it be because my code didn’t work or datastores broke or amazon exploded or they just didn’t like what they bought.
In the example in the OP I have a problem where my code works fine whenever I test it but occasionally players say they didn’t get what they bought. How can I even debug that when it works for me 100% of the time? But that isn’t the only use case for refunds, so I don’t want the thread getting hung up on that one example.
Which is why I specifically referenced previous posts rather than the OP. I will re-iterate and add to the points of interest so we’re all on the same page and there’s no further confusion:
-
Even following good ProcessReceipt practices, code can be bugged and I may have players not receive the item / receive the wrong item
-
Again due to bugs, players may have their data reset (not related to ProcessReceipt, but rather the DataStore loading code); Since I have no idea what specifically was in their inventory (they could have bought 10 items and used 5 of them), I may want to refund x% of what they spent in the past y days
-
Players may buy something thinking it’s something else because of bad design on my part, and for good PR I want to refund their money
-
I may implement ability X in a game, find out it’s not very balanced for a game of my scale after testing it on production, and want to refund players who bought it
When it comes to micro-transactions I believe it is better to give the user the benefit of the doubt. A customer who receives something from my game for free is not an issue compared to a customer purchasing something and not receiving it. Whenever I am designing my system I ensure that for a low-price item the user receives it before I receive my payment, and I believe when the price is negligible most developers should adopt this principle.
Sometimes there are bugs that are out of our control though, so this would be very useful indeed.
What would you do in this situation? Gamepasses he bought totals around 150 Robux.
1 Like
It’s tricky though, because users might start spontaneously getting little brothers if you do start giving refunds for these reasons. I just don’t think refunds make a lot of sense unless a user didn’t actually get anything in return, or if the item is broken and you can’t fix it. But I guess a refund feature could still help for extreme cases.
How is this related to the feature? This already happens now with data restores – I’ve had to deal with it while restoring data for Zombie Rush. It’s developers’ who are responsible for this. If they start giving instant refunds to every sob story, then of course players will exploit that. If they use the feature responsibly this won’t be an issue for them. Developers are responsible for determining what deserves a refund, and this feature has nothing to do with poor oversight – that’s just user error.
1 Like
What you just wrote is an expanded version of what I meant with “could still help for extreme cases”, so we’re on the same page.
I think people in this post are getting way too deep into the technical issues for the example scenario and overlooking the real point: regardless of the problem, allow us to issue refunds whenever we see fit.
I’m not sure how I feel about refunds, though. Allowing refunds will mean players will constantly expect refunds and at the end of the day will cause far more unfair complaints than happy customers. Honestly I for one would much rather not have to deal with constant refund demands because children irresponsibly spend their birthday money on my game and then feel buyers remorse.
1 Like
I am going to bump this up because of another possible bug with no automatic refunds happening.
By the way, it becomes 900% more for NBC players to do a refund like that instead of 42%. That isn’t the main reason I am bringing this up, this is:
info@roblox.com is telling players that they won’t handle refunds, and developers are responsible for doing it. This either 66% lose or 1030% lose is not something we should have to handle.
- Buy ingame stuff
- Use ingame stuff
- Demand refund
- Report game