OAuth scope for reading a user's transactions history

I am working on a platform which heavily promotes collaboration safety in regards to scammers, it acts as a middleman between two developers ensuring both get their part. Currently the only way we have to ensure the person who commissioned work paid the developer is by making them pay through a developer product owned by our Roblox group and then making a payout. However this system is inefficient, both because it slows down payments and because it can potentially trigger moderation actions against our group for too frequent payouts.

An OAuth2 scope for reading a user’s transactions history would be ideal because we could verify a gamepass created by the developer was purchased by the other user and the payment would be sent directly to the developer.

If Roblox were to address this issue it would heavily improve our development process.

4 Likes

Hey there, in principle this seems to make sense but it sounds like you don’t need to broadly read someone’s transaction history, you just need to validate one particular purchase right?

It doesn’t seem great for your app that you need to list a bunch of transactions and manually filter those down to just the one you need. I also worry about the privacy implications of such a scope for user safety.

Sounds like the core problem here is that you want to validate or control the timing of a particular purchase, so you can make some effect happen once that purchase is made?

Have you considered creating a Roblox game where people can join and make the payments, and you can call out from there to your back-end via HttpService whenever you get the callback about the purchase in-experience? You can use dev products to ensure that people are not buying the product out-of-experience.

1 Like

Yes exactly, the problem though is that it’s particularly difficult to automate payouts because the apis are very obscure for 2FA verification, and we’re uncertain whether frequent payouts to many different users could lead to moderation actions.

We would prefer the group approach, but regardless having a scope for transactions history would be a nice addition. In the end it’s the user who’s informed about what the application will have access to deciding whether to allow it or not so I wouldn’t be concerned about privacy here. Also transaction entries are most likely identified by an id, but how would we request a specific entry without knowing its ID from a list?

If you could clear up the moderation aspect of group payouts it’d be perfect.

1 Like

Indeed, I would strongly recommend against automating purchasing logic.

Perhaps, but we don’t want to build the wrong product here. If the only real use case for viewing transactions is that you want to validate a particular purchase, we should just build something to make it easier to do what you actually need to do.

Could you comment on the suggestion I mentioned above regarding the Roblox experience to manage the payments and side effects of payments? The buyer would pay you via the Roblox experience, you send some calls via HttpService to trigger your back-end to process that in whatever way you need.

Disclaimer: please ensure you are working against our policies when creating your third party apps, my comments here are mostly on the technical side to help unblock you. Our policies are authoritative here, not my comments.

As long as it gets what we need done any way it’ll be implemented will be fine.

That is the way we originally wanted to build it, but then your reply gets contradictory: you advise against automating payouts without clearing up doubt, yet encourage using group payouts. Unless what you mean here is that we should manually pay out people, when the platform will scale it won’t be easy to manage. I would really appreciate if you could clear up the moderation aspect.

Thanks for the extra details!

I can’t assist you with a definitive answer there, you’ll need to consume our terms and other policy docs and make a decision based on that or ask for legal support to help interpret them.

My comment was around the buying side where it is definitely a bad idea to automate. (asking users for e.g. cookies and making the purchases on their behalf)

(Same disclaimer as my post above!)

Thank you for the quick reply, the reason I was asking for clarification is because the terms don’t make it clear and it was moreso asking for an insight on a possibly automated group flagging system in place.

This is a major pushback for our project which would benefit by this sort of things immensely.