Mr. @davismwfl gave me some really good directions on my problem in his answers, do you agree on that way?
Is there a reason you suggest managing the subscriptions directly in the app instead of in Stripe? And does it count as "my app" if I manage it in a separate service, as @davismwfl solution?
Codegeek is right on with this, the description I gave is in line with the same thing he is stating. Our data store is mongo so we use documents for the subscription details but if I was in an rdbms it would likely be a key/value pair as described.
The detail about storing all your subscription details locally is valid. We do it but also put the details in Stripe as that is what enables the recurring billing. That is also what I was pointing out in the web hooks as we store all the Stripe history from the web hooks. Works great.
Thank you, that is great information to have in mind! As I wrote in another answer, the subscription will most likely end up as a separate service so it wouldn't be a problem for customers to access the application if I get trouble with Stripe, at least. I would imagine that having a third party gateway would add to the expenses. I am not really too interested in that in the beginning.
Could you educate me when a chargeback would occur using Stripe?
Thank you for the magnificent answer. It seems like a good idea to create a separate service to handle the registration. My app is backed by a REST API (I know, I am so trendy), so it would just be to call that one and a call to Stripe's API and be done.
One thing I realized now, reading your answer, is that the customer's plans should be changed depending by the user's usage (think storage space). Should I be running a cron job once or twice a day to check the usage, compare it to their subscription plan and update it at Stripe? Of course notify them by email, and maybe give them a day to re-do and not give them unexpected charges.
So if your plans vary based on usage patterns and that carries additional charges, then yes, you'll have to run some sort of scheduled job to check for users getting close to plan thresholds. IMO you don't want to auto upgrade people, but rather warn them at say 80%, then 90% and give them the option to upgrade or be frozen at their current use level. This prevents chargebacks and complaints for auto upgrades they didn't want to have happen. Seems you already are on that path.
But on the other hand (thinking storage space), if your model is such that they pay $9.99/month with up to 5gb and for every gb over 5 they pay $0.99 say. Then you can auto charge the incremental fees and just make sure you are sending the clients an email and keeping them in the loop. I have not done this with Stripe myself so I am not sure the best way to set it up, but my initial guess would say you leave their base plan alone (unless they upgrade/downgrade it) and just add a surcharge to their account at Stripe if they go over their allotted storage space. One way I can think of off the top of my head is to change their account balance to be -$.99, or whatever their overage is, so that Stripe can bill that plus their next monthly service. But I am sure there is likely a more elegant solution.
Someone else mentioned Chargebee, which is a great service, but we chose not to go the route of like a Chargebee because paying additional fees on top of Stripe just didn't fit our model initially, and we feel our chargeback risk is very low. But if you have a higher risk business with a greater potential for chargebacks and disputes then it is best to insulate your self as best you can, and Chargebee helps you do that. In our case, we actually can process charges through Stripe or Balanced payments (although 100% is going through Stripe right now), which is why we did the vendor based model as I described above, that was our insurance in case we every had problems with one provider.
This is amazing, thank you again!
It seems that the way you have decided to solve this is both scalable and modular, so it's very likely that I will adopt it.
I will talk with my business people about the best solution for us on handling tier upgrades, notification etc. Right now you have assured me I can let the subscription integration wait, so I'll continue focusing on the actual product and implement the subscription later.
Thank you. I'm planning to use Stripe for payment service.
The thing I am looking for is the practical implementation of adding a user to my application, and creating a subscription account at the same time without mixing Stripe code into my product. Do you have any experience with that to share?
Start off by reading documentation, preferably good. It's not easy, but just as everything else you will get better with practice so you'll have to just write. You can always go back and revise just like your code!
Usually I decide to learn a new language or framework because I've researched that it will be the best tool for the job for the project I'm currently working on. In my opinion the most useful way to go ahead is to start by developing stripped down, simple versions of the selected components of the project. Then I build, read documentation / code and refactor until the problem is solved in a good way. By then I usually have a good grasp on how to use the language properly and can go on.
As an independent, paid hourly, On many gigs over the years I have tried to to get 4 day (28 or 32 hrs) work weeks, but most client companies still insist on a 40 hour week. I work mostly in the northern midwest for mostly large enterprises, and these clients are "conservative", and 40 hours is "what is needed". I don't try to bill fewer hours at a higher rate.
