4 ms·

Show HN: I made a credit system API

42 points by fraromeo 2y ago

I'm a solopreneur and I made it very easy to integrate a credit system into your apps and games using Creduse. I built Creduse because more and more users want pay-as-you-go models, and founders need new ways to increase user engagement or nicely limit cost-intensive features (see AI). Creduse is built by a developer for developers. I hope it will help as many startups as possible. Feedback are very much appreciated. Francesco

darrenwestall 2y ago
We’re about to implement a credit system for a new product, I’ll try this instead and feedback to you. Would be amazing if you handled the buying of additional pay as you go credits for us too - that’s the next thing we’d need to build.
- darrenwestall 2y ago
  Having to pay to try is a little disappointing, but I’ve done it. Sent you a chat with some queries - we need to use cycles and payg in combination, and the api call to get remaining credits should include the cycle start and renewal date, with the different credit types remaining too. The option to choose which credit type subtract should come from by default would be good too - to allow users to use their cycle credits first and then eat into their payg back up credits.
  - fraromeo 2y ago
    It's possible to use cycle and payg in combination, it's exactly the strength of Creduse. About the `get-active-balance` endpoint - you're right, it's pretty basic at the moment. It just gives you the total active balance and user ID. It doesn't break down cycle vs PAYG credits or show cycle dates yet. I've add it to the top of my pipeline. I'll be working on improving this endpoint to give you more detailed info about the user's credit balance. Regarding the option to choose which credit type to subtract from, I'll keep this in mind and consider its feasibility. Can't promise anything on this just yet, but I appreciate the idea. I really like your suggestions though! It's exactly the kind of feedback I'm looking for. Thanks for bringing this up, and thanks for subscribing!
- fraromeo 2y ago
  Great! Thanks for giving Creduse a try. By "handled the buying of additional payg credits" do you mean the payment processing?
  - darrenwestall 2y ago
    I do. I mean providing a JavaScript widget that lets people see their credits, renewal dates and buy more. Then it would be an end to end credit solution.
sparky_ 2y ago
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-macos-in-app-purchases-using-storekit-2-and-server-side-swift-98626641d3ea https://medium.com/@ronaldmannak/how-to-validate-ios-and-mac...
- fraromeo 2y ago
  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: francesco@creduse.com
  - lwansbrough 2y ago
    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 2y ago
      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 2y ago
  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
rany_ 2y ago
Can you make an OTE environment so we can test without payment or needing to contact you?
- fraromeo 2y ago
  I'm thinking about it. Would you be more interested in testing the API or see Creduse in action in an existing web app for example? (I imagine testing the api)
- fraromeo 2y ago
  Update - just released a 7 days free trial
imarkphillips 2y ago
Do you have some use cases that can show different ways of using the service?
- fraromeo 2y ago
  This is a great question. I'm actually working on it. In the meantime in the documentation there is a section called "Use cases" - here's the pay as you go model for example: https://doc.creduse.com/use-cases/payasyougo.html https://doc.creduse.com/use-cases/payasyougo.html I want to implement Creduse into a free ai character chatbot I've created in the past (hellspitching .com) to showcase its use.
msnkarthik 2y ago
congrats man. This is cool. Does the work on mobile apps too? We are coming up with a mobile app where users have to buy AI credits as add-ons - and we were building out own credit sysyem. How can this help?
- fraromeo 2y ago
  Hey there! Thanks a lot! Of course, it would work also on mobile apps. As long as you can make an http request to api.creduse.com/endpoint, you can run it wherever you want :) In your case if the user's payment is completed you can send a POST request to /add with the amount of credits you want to add. The user then, will receive his credits. That's it. You can find a lot more details on doc.creduse.com
  - msnkarthik 2y ago
    Awesome. I checked it out and forwarded it to my team. However their feedback back that since we already use chargebee for subscription management, this might add little value for our usecase. This requires the management of when to start the cycle, when to subtract credits, how much of credits to subtract at our end itself. Added info if required to be extracted will need to be passed on via apis - which might add more work to implement this. Thought i'll share the feedback so that you can think in this direction in the future. All the best!
- fraromeo 2y ago
  BTW this would exactly your case https://doc.creduse.com/use-cases/payasyougo.html https://doc.creduse.com/use-cases/payasyougo.html
anxman 2y ago
Can we get a trial to test this out? Been looking for this.
- fraromeo 2y ago
  Working on it. I'll let you know. Thanks for the interest!
- fraromeo 2y ago
  Update - Just released a 7 days free trial!

42 points by fraromeo 2y ago

darrenwestall 2y ago

We’re about to implement a credit system for a new product, I’ll try this instead and feedback to you. Would be amazing if you handled the buying of additional pay as you go credits for us too - that’s the next thing we’d need to build.

darrenwestall 2y ago
Having to pay to try is a little disappointing, but I’ve done it. Sent you a chat with some queries - we need to use cycles and payg in combination, and the api call to get remaining credits should include the cycle start and renewal date, with the different credit types remaining too. The option to choose which credit type subtract should come from by default would be good too - to allow users to use their cycle credits first and then eat into their payg back up credits.
- fraromeo 2y ago
  It's possible to use cycle and payg in combination, it's exactly the strength of Creduse. About the `get-active-balance` endpoint - you're right, it's pretty basic at the moment. It just gives you the total active balance and user ID. It doesn't break down cycle vs PAYG credits or show cycle dates yet. I've add it to the top of my pipeline. I'll be working on improving this endpoint to give you more detailed info about the user's credit balance. Regarding the option to choose which credit type to subtract from, I'll keep this in mind and consider its feasibility. Can't promise anything on this just yet, but I appreciate the idea. I really like your suggestions though! It's exactly the kind of feedback I'm looking for. Thanks for bringing this up, and thanks for subscribing!
fraromeo 2y ago
Great! Thanks for giving Creduse a try. By "handled the buying of additional payg credits" do you mean the payment processing?
- darrenwestall 2y ago
  I do. I mean providing a JavaScript widget that lets people see their credits, renewal dates and buy more. Then it would be an end to end credit solution.

sparky_ 2y ago

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-macos-in-app-purchases-using-storekit-2-and-server-side-swift-98626641d3ea https://medium.com/@ronaldmannak/how-to-validate-ios-and-mac...

fraromeo 2y ago
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: francesco@creduse.com
- lwansbrough 2y ago
  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 2y ago
    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 2y ago
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

rany_ 2y ago

Can you make an OTE environment so we can test without payment or needing to contact you?

fraromeo 2y ago
I'm thinking about it. Would you be more interested in testing the API or see Creduse in action in an existing web app for example? (I imagine testing the api)
fraromeo 2y ago
Update - just released a 7 days free trial

imarkphillips 2y ago

Do you have some use cases that can show different ways of using the service?

fraromeo 2y ago
This is a great question. I'm actually working on it. In the meantime in the documentation there is a section called "Use cases" - here's the pay as you go model for example: https://doc.creduse.com/use-cases/payasyougo.html https://doc.creduse.com/use-cases/payasyougo.html I want to implement Creduse into a free ai character chatbot I've created in the past (hellspitching .com) to showcase its use.

msnkarthik 2y ago

congrats man. This is cool. Does the work on mobile apps too? We are coming up with a mobile app where users have to buy AI credits as add-ons - and we were building out own credit sysyem. How can this help?

fraromeo 2y ago
Hey there! Thanks a lot! Of course, it would work also on mobile apps. As long as you can make an http request to api.creduse.com/endpoint, you can run it wherever you want :) In your case if the user's payment is completed you can send a POST request to /add with the amount of credits you want to add. The user then, will receive his credits. That's it. You can find a lot more details on doc.creduse.com
- msnkarthik 2y ago
  Awesome. I checked it out and forwarded it to my team. However their feedback back that since we already use chargebee for subscription management, this might add little value for our usecase. This requires the management of when to start the cycle, when to subtract credits, how much of credits to subtract at our end itself. Added info if required to be extracted will need to be passed on via apis - which might add more work to implement this. Thought i'll share the feedback so that you can think in this direction in the future. All the best!
fraromeo 2y ago
BTW this would exactly your case https://doc.creduse.com/use-cases/payasyougo.html https://doc.creduse.com/use-cases/payasyougo.html

anxman 2y ago

Can we get a trial to test this out? Been looking for this.

fraromeo 2y ago
Working on it. I'll let you know. Thanks for the interest!
fraromeo 2y ago
Update - Just released a 7 days free trial!