#sai_rez-subscriptions
distant hemlock
@gray sphinx hi! what do you mean by a 'cancelled' subscription being reactivated exactly? You can't actually re-activate them by updating them.
Maybe you mean you have the subscription set to cancel_at_period_end as in the first example at https://stripe.com/docs/billing/subscriptions/cancel#reactivating-canceled-subscriptions ?
gray sphinx
Yes sorry I should have been more clear, I was referring to that section in the docs
distant hemlock
if it's that, then just setting cancel_at_period_end"="false" doesn't process a payment no.
for some reason that example also seems to include changing the Price(which would generate some proration for the next invoice with that code as written) but you don't have to do that part, you can just set cancel_at_period_end"="false"
gray sphinx
Okay so we have a scenario wherein our code we call stripe.subscriptions.update() and set the cancel at period end to false then on the client run stripe.confirmCardPayment(). The question I was asked was would this result in two payments being taken, one from their old card and another with a new one they provide?
distant hemlock
as far as I know it shouldn't!
gray sphinx
And just to confirm a payment will only be taken straight away if you're changing the price when updating the sub?
distant hemlock
yes, or if you change the billing cycle, see https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
gray sphinx
Brilliant, thanks for your help and info!
distant hemlock
@gray sphinx how can I help?
gray sphinx
Hey sorry, i came across this text in the docs and had a question about it
'If the cancellation has already been processed and the subscription is no longer active, a new subscription is needed for the customer. Keep in mind that Stripe immediately starts your customer’s subscription under a new billing cycle, so this action results in a new charge. You can override this behavior using the trial_end parameter so the customer isn’t immediately billed (for example, to maintain the old billing cycle).'
As our user is cancelled and is no longer active, would the above text apply when updating their sub?
distant hemlock
yep that's what I was referring to when I said " You can't actually re-activate them by updating them." initially
if it's actually cancelled, you can't make any type of update call that would re-activate it, you create and entirely new subscription
so the stuff above is not really related to that I suppose, it's specifically about updating a subscription that was set to cancel at the end of the period but hasn't happened yet
gray sphinx
I see, so taking this into account, if a cancelled user has a new sub created and confirmCardPayment is called after with a new card, two payments would be taken out, is that right?
distant hemlock
confirmCardPayment is called after with a new card
what are you calling it on though?
do you mean calling confirmCardPayment on the PaymentIntent from an old Invoice on the cancelled subscription? Then yes, that might lead to two payments , sure
unfortunately unpaid Invoices are left open after the subscription cancels I think, so sometimes this happens(somehow confirming the old PaymentIntents), not sure there's a good solution beyond just not providing that option in the design of your integration, or manually voiding all the open invoices when the existing subscription is cancelled
gray sphinx
Yes we called confrimCardPayment with the paymentIntent of the latest invoice received from the response of creating a new sub
Would a better approach be to create a new payment intent and pass that into confirmCardPayment?
distant hemlock
if you're creating a new subscription, then yes
it's exactly the same flow as creating the subscription initially — you'd create a Subscription, then access subscription.latest_invoice.payment_intent and confirm that one
there's no link/connection to the older, cancelled subscription
gray sphinx
Ah that is what we're doing I believe, I'll show you a glimpse of our flow, maybe it makes more sense seeing it in code
step1
const reactivate = await reactivateSubscription({ planId }); //function to create new sub if user is cancelled via api call
step2
const invoiceClientSecret = reactivate.result.data.data.latest_invoice.payment_intent.client_secret; //get latest invoice client secret
step3
const cardElement = elements.getElement('cardNumber'); //confirm new card details
const stripeResponse = await stripe.confirmCardPayment(invoiceClientSecret, { payment_method: { card: cardElement, }, });
distant hemlock
hmm ok, seems sensible!
you'd have to test this of course and inspect your dashboard etc and see what it does but it seems reasonable
gray sphinx
Yea it's confusing as going by the docs it seems they'll be two payments but your flow suggests otherwise
If we're using stripe test cards to create our accounts, would it be possible to see if the old card gets charged?
distant hemlock
A payment only happens if a PaymentIntent is confirmed so if your code doesn't confirm two PaymentIntents I don't see how it would create two charges, but it's really hard to talk about this in abstract
distant hemlock
If we're using stripe test cards to create our accounts, would it be possible to...
you could look at the Customer object in the dashboard, it shows associated payments on them, that's what I would do
gray sphinx
Yea that would be good to confirm, I'll create a test account and go through our app flow to monitor this
Can we keep this chat open in case further questions are needed and let it expire after 24hrs?
distant hemlock
you can post in the main channel with any follow ups! I'll keep this thread open for a little while but we need to archive them as multiple folks staff the channel across different timezones so we have to keep the handover of state manageable
gray sphinx
Okay no problem, should I reference you directly? Thanks for being patient btw
distant hemlock
I would just ask the specific question you have and whomever is online will be able to help!
gray sphinx
Awesome, cheers!