#NoahBundeling-upcoming-invoice
hollow locust
Take your time!
In the meantime, I'm going home but I'll check it tonight. Thanks in advance for helping me
magic horizon
Can you share the request ID for the latest trial subscription creation?
hollow locust
Yeah, sure. This is the one: req_IfKDsPQqk3tDsv
normal spear
Hi 👋 I'm stepping in for @magic horizon . Give me a sec to catch up
hollow locust
Thanks!
normal spear
Okay so you create a subscription with a free trial that cancels at the end of the trial. Why would you expect it to have an upcoming invoice?
hollow locust
Because I need the tax information in case the customer already sets up billing address and decides to take the product. We're having a dashboard where, in that case, the expected amount to pay should be displayed including tax.
normal spear
As it's configured, this subscription record will not generate a new invoice. So the function that runs when you hit the upcoming invoice endpoint does not create an invoice
Have you tried making a request to the upcoming invoice API and removing the cancels_at parameter?
hollow locust
So, situation...
Client has a ten day period trial, but can already setup everything. Like licenses, address, plugins, etc. at that moment, there should be already payment info (including tax) displayed so that the client knows what he is going to pay in case he actually starts the subscription.
hollow locust
Have you tried making a request to the upcoming invoice API and removing the `ca...
But, that means the subscription, after trial, will automatically try to let the client pay, right? Which it retries for a month or so (based on settings), before it cancels?
normal spear
Not if you use that parameter with the upcoming invoice API. That API allows you to preview what an invoice would look like if you made those changes
hollow locust
Alright. So, for that I need to remove the cancels_at parameter from the create subscription API post then?
normal spear
It's not really clear what you are actually trying to achieve.
You can have the subscription not automatically attempt to collect payment if that's what you want.
But what is the overall experience you want the user to have?
hollow locust
The ideal situation is:
- client fills in a selfmade onboarding wizard
- Stripe customer and subscription 10-day trial are being created with just the main product
- Through our backend the client can setup their licenses (quantity) and add plugins (different products in Stripe) to their environment
- In the backend the client can then have a visual of what the costs would be IN CASE they actually get an active subscription (which obviously should include the tax information)
We figured the easiest way to make sure a client's data gets removed if they don't get an active subscription, would be to immediately cancel after trial, unless they set it to active. That's why we decided for the cancels_at in a subscription create.
normal spear
So in that case, you would pass the different parameters of the subscription (included a null or none for cancels_at) to the Upcoming Invoice endpoint
This will return the invoice that would be generated if you made those changes to the actual subscription
hollow locust
Alright, thanks! I'm gonna try later tonight.