|
|
|
|
|
by user3487
4201 days ago
|
|
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. |
|
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.