I want to be able to issue refunds when stuff like this happens. Fixing my code isn’t an option because I don’t know what might have gone wrong. It might not even have been my fault. In spite of that I would refund this guy’s 10 robux if it was as easy as clicking a button, but I’m not about to explain donation shirts and taxes to him and tell him he needs to buy BC.
The ability to search for purchases is needed for this too.
Altho I’m not super sure this is a good idea, suddenly everyone will complain to get refunds:
- They buy a weapon
- Play the game,
- Then when they get bored they demand a refund or they’ll report you etc.
6 Likes
Pretty sure people do those steps regardless of whether or not a refund feature is implemented. ROBLOX could include with a refund feature an expiration for refunds directly after purchase, I guess something like Steam does with their 14-day/two-hour refund period.
7 Likes
Developers should be able to use their own discretion when issuing refunds. Roblox should just allow them to do it.
5 Likes
Issuing refunds is the purpose of pending sales, so being able to do it at developer’s discretion at least within that 3-day window seems reasonable.
2 Likes
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.
3 Likes
I didn’t explicitly mean like we wouldn’t be able to revoke their request, something like this:
and then let’s say we can get a notification stating player requests for a refund for gamepass due to (their reason). But I would disagree with having no expiration on that. It would also easier on the developers who receive a ton of visitors or messages with a simple agree/disagree on refund etc.
We shouldn’t be the one having to select a player and get a list of gamepasses they purchased from our place.
5 Likes
Yeah my post came off wrong, meant to suggest that since there is already a system in place for issuing refunds under certain circumstances, developers should be able to use the same principle to issue refunds on their own.
My suggestion is for a developer-end refunding feature. A feature for filing refund requests makes it too easy to go around grabbing for money. The user should have to message the developer, the developer should be able to decide whatever they want, and then the developer should be able to use an official roblox feature to issue the refund.
5 Likes
Which is why I stated having an expiration on refunds, if we’re going on a developer-end refunding feature isn’t that basically ‘personal’ group payouts there must be at least confirmation from the player’s side that isn’t simply a pm and not have rogue developers? using this feature to deny a player’s purchase.
What? How could a developer possibly use a refund feature maliciously? You would go to a transaction’s info page and click a refund button. I don’t see the potential for abuse.
Except youre not paying someone, youre giving them a refund before roblox grants the develop money due to the 3 day holding period.
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