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?
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, 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.
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.
You're right, I can see that. Would it not be a good idea to create a higher level framework based on one of the existing ones? With a mature and massively used core you could focus more on making your framework user [developer] friendly in the way you think Django gets it right.
I am just thinking out loud. It's a good idea, but I am afraid it could easily be too much work to reinvent a wheel instead of building the car around a well tested existing.
That's cool. I still wonder what will be the main difference between "DjangoPHP" and the other frameworks. Don't they support most of the same features that Django provides?
I am a huge fan of Django, so of course, but are there any reasons for using your young untested framework instead of an existing like Laravel or Symfony?