#alpha-tings_best-practices
topaz phoenixBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- alpha-tings_docs, 2 days ago, 19 messages
fathom vaultBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1251206795465326614
đ Have more to share? Add details, code, screenshots, videos, etc. below.
fossil pivot
If the customer has outstanding unpaid invoices, you can List All Invoices and check to see if their most recent one(s) have an uncollectible status: https://docs.stripe.com/api/invoices/list
outer hare
If they do have uncollectible invoices, would I create a new invoice based off the old invoice or handle that via subscription schedules or another strategy?
fossil pivot
That depends on what you're trying to achieve. You wouldn't likely want to create anything based on the old subscription. You would just create a new Subscription with the same Customer and (potentially) the same Payment Method
outer hare
I guess there's no real need to collect the uncollectable invoices yeah? If I make it so they cannot use the service as soon as the status changes to past_due seeing as they pay for the use at the beginning of their billing cycle
Different question for ya
My checkout flow is currently:
User signs up -> create stripe customer ->create a trial subscription
when a user wants to make changes to their subscription:
use stripe.invoices.retrieveUpcoming to show the potential proration amount
So two questions:
- should I be using stripe.invoices.createPreview instead of stripe.invoices.retrieveUpcoming or does it not matter
- Should I use the quote API for users that either have scheduled a cancelation, or for statuses that are not "active" or "trialing" or is there a better approach?
fossil pivot
- Only you would know what approach is best. I would read the docs for both and decide which makes the most sense:
- I would not use the Quote API unless you specifically need to create quotes. Quotes are not intended for use with existing Subscriptions for the most part. What are you trying to do here?
outer hare
When a user wants to change their plan, I send a request via the stripe.invoices.retrieveUpcoming with the data to get
const {amount_due: dueToday, tax: dueTodayTax} = upcomingInvoice;
so on the users screen I can display the attached. It's to get them the most accurate quote with tax information.
The issue I am having is that I can't use the stripe.invoices.retrieveUpcoming api if their subscription is cancelled or scheduled to be canceld via the because they no longer have an upcoming cancellation via cancel_at_period_end:true on their subscription
I have already accounted for the scheduled cancellation part by making them cancel their upcoming cancellation, however for when they already are cancelled what would be the best approach to getting them the most accurate quote information with taxes?
Should I do this, or use quotes?
` // --Calculate the tax amount for recurring charges
const recurringTaxAmount = await stripe.tax.calculations.create({
currency: 'usd',
customer: stripeCustomerId,
line_items: [
{
amount: foundProductUnitAmount * seatsForQuote,
tax_code: foundProductTaxCode,
reference: 'Tax on product unit amount',
},
],
});
const {
amount_total: recurringAmountTotal,
tax_amount_exclusive: taxesOnRecurring,
} = recurringTaxAmount;`
In what scenario does cancelling a Subscription result in another Invoice being required for payment?
outer hare
If the user wants to resign up for the service at a later date, they hit the same quote endpoint on our server regardless of their subscription status. The endpoint then routes based on their subscription status and type of change.
Essentially what I'm asking is how do I quote a new subscription to show the accurate monthly dues accounting for potential taxes?
fossil pivot
Ah, okay so they might have chosen to cancel a subscription and sign up again
outer hare
Correct
fossil pivot
In this scenario are they choosing to keep the existing Subscription basically? Or would they potentially sign up for a different product completely?
outer hare
Could be either but I would need to account for both
fossil pivot
Okay, so we'll split those up into 2 scenarios:
**(a) **Customer wants to create a new Subscription, or
(b) Customer wants to keep their existing subscription
outer hare
Oh my b, misunderstood your question
fossil pivot
For (a), you would just let the previous cancelled subscription resolve (i.e. let it cancel as expected) and create a new one entirely separate from it
fossil pivot
Okay, yeah can do
Is there a good reason to use the context from the previous subscription here? Like, why not handle (a) with the same exact workflow as when they first signed up? Why not just create a net-new Subscription without any context from the previous Subscription?
outer hare
The kicker is when they first sign up it's done automatically, the user just enters their Organization email, org name, and org picture to sign up for our service and our BE takes that data, does stuff and things on our databases and then creates the customer in stripe and creates a trial plan on our best plan for 30 days no payment required. From there they can manage their plan, add a payment method, schedule cancel etc.
On the manage plan page is where they are shown the quote data in that screenshot above, there they can end their trial early, adjust their trial (if trialing) or quote new plan changes using their current plan as the base
So when they cancel, they have 30 days after their last billing date before our system deletes all their data and their organization
So if they want to make a change within that 30 day limbo period is the when I need to account for because their subscription will canceled at that point
So I think the game plan is to use that tax.calculations above to quote the new plan, then when they accept to make a new subscription
unless you disagree with that lol
fossil pivot
Would it simplify the issue to cancel the Subscription immediately? Like, does it make your system's workflow simpler if there is no active Subscription when they choose to re-signup?
outer hare
I think I misspoke,
when they click cancel, they have until their last billing day, at any point they can make changes, ez pz lemon squeezy. After their last billing date and their subscription cancels they have 30 days before our system deletes all their data and their organization. So tldr cancelling immediately or cancelling later results in the same need to handle the new plan quote
Imma try the tax.calculations and see if that works for the use case but I greatly appreciate the help! Attempting to explain it made it make sense to me, I'm sure I probably just confused you further lol
fossil pivot
Ahhhh, okay