[sparky_]

The difficulty you'll face for mobile is users man-in-the-middling their own device to find your developer's API key, and then making their own POST requests to increment their credit balance. This is why platforms like the App Store offer the ability to validate receipts of transactions [1].

Probably something you'll need to grow support for if you want this to be a drop-in solution for mobile devs.

[1] https://medium.com/@ronaldmannak/how-to-validate-ios-and-mac...

[fraromeo]

Very interesting point. Thanks for bringing this up.

Couple of questions: shouldn't my customers be taking care of this since I don't know their architecture? I think mobile devs can hugely benefit from Creduse, can you point me on how to support them for this scenario?

open to discuss via email if you prefer: [e-mail]

[lwansbrough]

If you’re intending for your API to be server to server then it’s not an issue. But that may limit uptake from mobile devs who may be looking for a more plug and play solution to dodge the need to build their own infra.

[fraromeo]

I intend it as server to server but you made me think about this specific case. I might have found a solution that bypass and solve the problem you are referring to but I need to deeply think about it. Not only needs to be secured the API Key (which is solved by the solution I have in mind), but also the content/payload of the request (otherwise the client would change the amount of credits).

[boopdewoop]

Why would you use this on the frontend? anything that requires auth tokens should never be used on the front end, You would be using this on your own server

[fraromeo]

Totally agree. I understand his point but can’t do much unless I implement some very complex stuff specifically for mobile (and I’m not even sure it would work safely)