Let’s get you some solutions. Access our on-demand resources, participate in the Chargebee customer forum, or raise a ticket to talk to our team.
I've built a SaaS solution which is currently free to use. I'm just starting to build out the ability for users to upgrade and pay for it on a monthly or annual basis.
I've decided to use ChargeBee with Stripe as the gateway.
However, I'm not sure exactly how to structure the application design/architecture. I'm a full-stack developer, but am aware that my knowledge of architecture is limited, and I don't want to corner myself by building a bad solution.
The signup process will be something like this:
Now my main questions are:
I don't see a problem with pinging ChargeBee to return the subscription info all of the time, but then again is that the "right" thing to do? If so, should I cache the ChargeBee info for a user upon logging in?
This probably seems like an obvious answer to most; but I can't see a right or wrong answer without some advice or pointers...
Apologies for the contradicting statements! What I meant is you do not need to store any data on your end, unless you require it for some purpose on your end.
Since you do require it to provide different access levels to customers on your domain, it would be best to store these details for easier and quick access.
Answering your question, it would be difficult to narrow down the events that you should keep track of since we generate different events for different actions/operations performed in Chargebee. However, since you'd be storing only the subscription details you can listen to all the subscription-related events. You may exclude the ones which might not be relevant to your use case.
Also yes, you seem to be on the right track. The fields that you've specified should suffice for the subscription table.
Hope this helps!
Thanks for your quick response Vaishnavi.
Do both of your answers contradict themselves? In (1) you said I don't need to store the data on my end, but then on (2) you said I should store the details on my end?
I think I know what you mean though. (2) looks like the more scalable solution as I noticed your API rate limit was 150 hits per minute, which wouldn't take too long to reach...
So far I'm looking at having a 'suscriptions' table on my end which includes the following columns:
Each user would have 1 corresponding row in the subscriptions table. Subscriptions table would be created when the ChargeBee subscription is created, and would be updated on some key ChargeBee events.
Another question: which are the most important events from ChargeBee's side to keep this up-to-date?
Do you think I'm on the right track? Would you change anything about my subscriptions table?
Thanks for reaching out to us and explaining your requirement in detail.
I've answered your questions inline:
1. What data should I be storing and relying on in both applications (my own, and ChargeBee)? I.e. should I store the user's current subscription plan in my own application database once they're returned to my application? If so, why not just rely on ChargeBee?
- Since you'd be using Chargebee's hosted checkout pages for sign up, you needn't store any data on your end. All the customer and subscription data can be stored in Chargebee and retrieved when required.
2. How do I know what access level to give the user once they're in my domain - do I ping ChargeBee in my middleware to find out what plan the user is on, OR should that data ALSO be kept in my own application AS WELL AS in ChargeBee (like double accounting?)
- You can certainly use our APIs to retrieve data and check the customer's current plan. However, this may not be scalable since it would increase the number of API requests to our server and might slow down the response time. So you can store the subscription details on your end by configuring webhooks in Chargebee. This will also help sync the subscriptions and customer updates made in Chargebee. Does this work?