#env
1 messages ยท Page 1 of 1 (latest)
Hi ๐
That's both a lot of explanation and still not enough to get a clear picture. So let's start with some simple descriptions here.
sure ๐
Okay so the tiered plans make sense. Would you want to model these as separate products?
from what I read in the docs (the t-shirt example), separate products probably make sense
what other options would there be?
Well we do allow you to create multiple prices for a single product. This allows you to do things like upsell to subscriptions with longer billing cycles.
ah, right. we could already use that for the discount based on the subscription length, right?
Yes you can
sounds good. how would we implement the additional features (X,Y,Z) and the validation checks?
Okay that's the bit I'm confused about. What are these validation checks for and how would they work?
we have the base modules (A,B,C), right? they are important for different areas of business and different businesses will probably need different modules (business 1 might need A and C, business 2 might only need B). we need a pre-checkout check to see if the customer has at least one of these modules in his cart, as it does not make any sense not to have one of these but still get access to our app.
Okay, that level of checking is something you would need to store/perform in your integration. Like a database table that maps the base modules to specific Product IDs in Stripe.
ok, so my understanding of the workflow is the following:
- we have a custom store implementation in the frontend which checks the validity of the configured package.
- if fine, the request gets sent to our backend and also validates the configured package
- if also fine, our backend calls the stripe api with the products the customer selected
- our backend reports back to the frontend (+customer) that everythings fine
- our backend reacts to some webhooks, if needed for post - transaction actions
How are you collecting payment information from your Customers. Is that already saved to the Customer object?
currently, not at all, we are still in the brainstorming phase ๐ i guess we would go with the default?
Just to be clear, when you make the call to the stripe API are you creating a Subscription or and Invoice?
are subscriptions just recurring invoices?
for testing i used subscriptions so far, and the whole service is subscription-based
Subscriptions are how Stripe handles recurring charges
We have a number of good integration guides for this so I would recommend you start here https://stripe.com/docs/billing/subscriptions/overview to get an idea of how the workflow looks for the Stripe side of things and whether or not this will fit into your overall flow
If you have specific questions about a section in this or other docs I will be happy to help
But it will help both of us quite a lot if you familiarize yourself with the overall process
sounds good, but the overall workflow should be the same, no?
for the package configuration process of the customer?
ah, i see, the examples look pretty nice ๐
ok, i'll have a look at the docs first if you sense a lot of missing knowledge which would point me in the right direction by going through the overview you sent me
The overview is going to follow the most common integration. There are more Subscription docs you can see in the navigation sidebar that may get closer to your particular use case
ok, i'll try that first. if i have questions afterwards, should i ask a new question in the #dev-help channel or continue our conversation here?
We archive threads after a period inactivity. If this thread is still open you can ask here but if not you are welcome to ask in the #dev-help channel
sounds good, thanks for your help!