#lucas
radiant rose
You would need to set the Payment Method as default for recurring payments — you would set either the invoice settings of the Customer (https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method), or the default_payment_method of a particular subscription (https://stripe.com/docs/api/subscriptions/update#update_subscription-default_payment_method).
As for deleting the draft Invoice, you would need to set it to void which effectively renders it unpayable: https://stripe.com/docs/api/invoices/void
lone bolt
thanks for the quick response. theyve got a good default card on the sub and on her customer
oops, the 8193 is the default
radiant rose
Ah, okay. I don't have a lot of context on the dashboard functionality. I wish I could help, but this chat is focused on developers and API integration questions. Our support team will be able to assist you better than I can: https://support.stripe.com/contact
lone bolt
oh, im happy to use the api when necessary
let me go through your instructions earlier and get back to you
alright - a few hiccups
setting the default card for the customer returned a 200 success with a json payload, but the subscription is still marked unpaid
trying to delete the draft invoice returned this error "You can only pass in open invoices. This invoice isn't open."
should i try to set a default card for the subscription?
radiant rose
What's the Invoice ID?
lone bolt
in_1Mq3BoEk6sr5GyDhuAhZ7UGL
radiant rose
Ah! Okay, so you can actually delete it in this case: https://stripe.com/docs/api/invoices/delete
lone bolt
so close 🙂 You can't delete invoices created by subscriptions.
i did get a prompt first
radiant rose
Huh... well alright. I guess that's the way it is. Are you wanting to charge the Customer for that Invoice? I reread the thread and I'm not sure if that was another option you were looking at
lone bolt
generally, the customer had an issue with their bank/card that was rectified and we want them back on a happy path track. there was a successful invoice that was charged against that default card recently (weirdly, the stripe UI is inconsistent about that), and the UI alleges in some places that it'll charge again in june, but based on our recurrence of 3 months it really should be july
super high level i'd love for this subscription to just get back to autocharging with the next charge ~july 25th
junior zephyrBOT
radiant rose
So the customer was charged successfully via a different invoice that has nothing to do with the subscription? Or their payment was for the December invoice that was due and they just didn't pay it until April 24th?
lone bolt
nah, charged successfully for an invoice that was a part of this subscription but not displayed in the UI for the subscription, oddly enough. in the logs for that invoice payment event i can tell the billing reason was "subscription_cycle" and includes the appropriate subscription id.
as far as which invoice was paid, let me see. yes you're right, looks like it was an invoice for quite a broad time window starting from dec....
aaah. i think what i thought was inconsistency was that the dec invoice was paid yesterday, so its just whether you're sorting by invoice time or payment time
yeah, in_1MJQJhEk6sr5GyDhWtTJ4Eh7
swift mortar
Hi. Taking over for two-shoes as they have to step out. Do you still need help/have any outstanding questions?
lone bolt
hello! yes still the same as up here - #1100483248401952788 message - ty!
swift mortar
You bill every 3 months and the next bill is due June 26th. You want to just delay it another month? Do you want them to receive a month free?
lone bolt
true - well - we ship products (womens health epharmacy), not metered access to a resource or similar. so all i really need is an invoice paid and i'll ship the product. so one was paid a day or two ago, which should give 90 days of supply, and i want the next 90 days from now, ~july 25th
so - yeah - delay another month but do invoice and ship automatically
swift mortar
Ok. Am confused though. The previous bill was never paid (March-June). So does that mean you just want to ignore that one and their product was never shipped?
lone bolt
ah okay that's fair, just so im clear, you're talking about the draft invoice that was created march 26th? yes - since that invoice was never paid, let's just dump it into the void, no product was shipped
(we only ship based on the payment success webhook)
swift mortar
Got it. Ok I see
You may want to think about implementing some timeout on your end after which you void previous unpaid invoices
Theoretically a customer could wait a long time and pay several unpaid sub invoices at once
At which point you'd be shipping multiple orders out at once for them
Unless that's desired behavior
Ultimately up to you though
lone bolt
ah no definitely not, actually, if you guys had customer success folks i could talk to i'd love to pick their brain, we're looking to surface more subscription flexibility to the end customer and this would be a good time to chat
although i/r/t voiding & deleting this invoice, neither worked (that was two-shoes first suggestion) - the api balked since its draft
i could move it to july but i wouldnt want the doublecharge situation you mentioned for sure
swift mortar
Ah ok. So it didn't progress past draft because the subscription didn't have a default payment method set at the time. That wasn't set until this request was made: https://dashboard.stripe.com/logs/req_dzaRHb6ikZYYLV. Now it has a default payment method so should be fine in the future. To reset billing to July, you'd need to reset the billing cycle anchor on the subscription. Here's a couple different ways to do so: https://stripe.com/docs/billing/subscriptions/billing-cycle#changing and https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#resetting-anchor
If your further questions are api related, we can help in here
Otherwise, our support team would be happy to assist: https://support.stripe.com/contact/email
Actually one more thing. Since the subscription is in an unpaid state, future invoices will not finalize (will just remain in a draft state). So you'll need to do the steps outlined here: https://stripe.com/docs/billing/subscriptions/overview#unpaid-subscriptions to make it active again prior to resetting the billing cycle anchor.
Sorry for the info dump lol. Actually since you don't want to attempt payment on that previous draft invoice, just leave it in place. See that last paragraph in the unpaid subs link:
no worries, knowledge is power 🙂 digesting
thats great! so to recap im hearing you say
- don't touch the draft/unpaid invoice, it'll never try to charge, which is what i want
- turn auto-advance back on (looking at your steps in the link, and we've got the default good payment on file, and i dont want any more payments to happen, so step 1 is done and step 3 i will not complete)
- reset the billing anchor to whenever i need it (push it out one month)
- once the july payment is charged, if successful, the subscription status will return to active
correct?
swift mortar
That sounds right to me
Turning auto advance back on will be key here
But yeah just don't finalize that last invoice if you don't want it to ever be paid
lone bolt
ok great, thanks, ill give it a shot
swift mortar
No problem
lone bolt
oh one point of confusion, looking in detail with the auto advance bit - this is actually at the invoice level, and i dont want the draft to auto advance, but i would like the upcoming invoice to auto advance... but its not a "real" invoice yet, just upcoming. i dont see an auto advance on the subscription api (but i do see in the UI that the subscription is supposed to automatically charge)
(as you mentioned, something i set with the CLI earlier during this discussion)
autumn depot
Hi there 👋 jumping in as my teammate needs to step away soon. We chatted a bit about what you're trying to accomplish, and I'd like to echo some of it back to you to make sure you and I are aligned.
My understanding is that you're looking to set up a flow where Subscriptions that had failed payments, continue to generate, finalize, and attempt to collect payments for Invoices each billing period. Is that right?
lone bolt
yeah that's right. this customer had three failed payments which forced her subscription into unpaid, then a very old invoice was paid, but there's still an unpaid draft out there (in addition to an upcoming june invoice that i'd love to move to july)
she's got an active/known good card on file now, default on her customer, and default on her subscription
that draft i dont want ever collected, the upcoming june i would just like to move to july (which im hearing can be done with the api <> subscription schedules)
autumn depot
Gotcha, let's split our thinking on this into two distinct topics.
-
How to adjust your settings so all Subscriptions will continue to finalize and attempt payments for Invoices regardless of previous payment failures. This change will only be used on Subscriptions moving forward.
-
Since the above doesn't impact Subscriptions already in this state, we can then discuss how to handle the Subscription you're referring. That may get a bit lengthy if you want to do more than revive that Subscription immediately (making changes, etc).
So for 1, is that a settings change you'd like to implement? Or is the primary focus here taking action on the Subscription you're referring to?
lone bolt
oh - actually - i havent been in a "change general settings" headspace, but if you're open to it, i'm open to it. i inherited the setup here, but i dont think many / any default settings have been changed. i think generally it cant hurt to have customer invoices continue to try to charge in perpetuity - from our viewpoint, a customer wants their recurrences until they ask us to cancel. my major concern would be when a problem with a charge is fixed that only one invoice is successfully paid, they shouldnt stack up and charge the customer multiple times immediately. we sell treatments for menopause so the customer just needs dosages on-hand for the next 90 days
question here - agreed and understand any changes wouldnt impact subscriptions currently in this state, but is it global in the sense that it would be used for historical/current subscriptions as well as new subscriptions, or does the config change get applied to only new subscriptions?
im not terribly concerned about #2 to set june back to july if its lengthy. if its easier to just remake the subscription thats ok too (but it cant charge till july)
autumn depot
Yes, the setting change will impact all Subscriptions, existing and new, just ones that have already been moved to an unpaid state won't be impacted by the setting change (until they go active again).
There is a Manage failed payments section in the settings for you account here:
https://dashboard.stripe.com/settings/billing/automatic
You can change the "Subscription status: If all retries for a payment fail," section to "leave the subscription as-is".
Doing this will cause Subscriptions to not move to an unpaid state, and they will continue to generate and attempt to process payments for Invoices. However, it will not aggregate all previously unpaid Invoices into one, nor will it attempt to process payments for previously failed Invoices (which I believe is what you're hoping for). The other thing to be wary of with this approach, is that the Subscription won't change states, so if you were relying on that to trigger downstream processes on your side then we will need to find a new approach for that.
Let me know if there are any questions on that and we can dive into those, or let me know when you're ready to proceed to talking about part 2.
lone bolt
no that's great. i'll want to check with some folks on my side to make sure they understand and agree to it, but we dont act on unpaid state right now, and it is seemingly getting in the way otherwise, so it seems smart to change that setting generally. thanks
ready for part 2
autumn depot
👍 sweet, one additional warning, changes to those settings do apply for both live and test mode simultaneously, so double checking with everyone else involved in the flow is a good idea.
Alright, lets sync on part 2.
Can you share the ID of the Subscription you're referring to so I can pull it up and take a closer look (apologies if you've already shared it before in the thread)?
Then can you also help me understand what the ideal scenario for that Subscription and its Invoices would be from your point of view? We can talk through how to get to that state and discuss alternatives if it starts to sound like too much effort.
lone bolt
yes! you rock. the subscription is sub_1LpKjsEk6sr5GyDht58EucDS
i would like for this customer to continue receiving invoices in perpetuity on a 3 month recurrence based on the last successfully paid invoice (4/24),
although there's another little rub in there.... since we're speaking globally and in ideal states 🙂
we would like to be using subscription schedules to "artificially" shorten the first recurrence window based on the recurrence length of the product/prices (all 3 months atm but changing soon)
we do this so that we charge then ship prior to the customer running out of that 90 day supply, then the cadence is essentially offset by that ~2 week window forever, guaranteeing payment/shipment prior to the supply running out
the previous dev implemented this using subscription trials which i would call a "clever hack", it messes with our analytics and makes downstream processing difficult (this ends up spitting out 0 dollar invoices which we need to sidestep when calling the CRM to send folks emails, etc)
and! while i have you, we'd love to surface recharge-like functionality (schedule next bill/ship (maybe several), pause/unpause, and more) via the UI, which i think means really leaning hard into the subscription schedule functionality
(just to circle back to this customer, it might be smart to shorten her window since she lapsed, but usually, we would only shorten the first)
(less onus on us to automatically do the right thing here when we surface more external customer portal UI for these things)
autumn depot
Alright, I'm taking a look at that Subscription, and I do see it's based on a 3-month recurring price so once we get it back to an active state it should continue processing on those timelines.
I'm not seeing an April Invoice for that Subscription though, March is the most recent one that I'm seeing. Is that the Invoice you're referring to, or does it sound like I'm missing something?
lone bolt
yeah that threw me for a loop too initially. there was a recent invoice that was successfully paid (apr 24th), but the invoice that was charged was originally for dec
in_1MJQJhEk6sr5GyDhWtTJ4Eh7
junior zephyrBOT
autumn depot
Ah, I see, but since it was paid in April after the March Invoice had been created, it was no longer the newest Invoice for the Subscription and therefore didn't set the Subscription back to active.
Thinking through whether there is a way you can force that status change.
autumn depot
It should prevent the next Invoice from being finalized.
I'm going to run a test in my account, but want to let you know what I'm doing so I can set it aside if it doesn't sound like what you want.
Since paying the most recent Invoice is how you restore a Subscription that was moved to an unpaid state, I'm going to try paying that Invoice "out of band" to see if that restores the Subscription. Typically "out of band" is used to indicate that an Invoice was paid outside of Stripe (imagine businesses with offices where customers could pay cash in person, like utilities used to and maybe still do).
This will cause the Invoice to appear paid in Stripe, without ever processing a payment for it. I'm not sure how that would impact your reporting and other processes though.
lone bolt
ah yeah ok, that's not greeeat for us since that sends an api call that'll try to auto-ship more product for them, but i can tell the pharmacy vendor to cancel it. its not terrible
oh actually
does that send the payment success event or not, i suppose
autumn depot
I think it throws invoice.paid but not invoice.payment_succeeded, but will double check while I test
lone bolt
ah okay. thats perfect if true
im gonna be in and out making dinner, thanks so much for all your help so far, ill check back every few mins
autumn depot
Alright, ran through the test. When paying the Invoice as out of band, it did mark the Invoice as paid and reset the Subscription to an active status. The process also only triggered an invoice.paid Event, there was not an invoice.payment_succeeded Event generated.
However, one thing I didn't think about until afterwards, was that with a valid payment method on file for the Customer, the Invoice will automatically try to charge that Payment Method when it is finalized. I'm running through the test again with a slight change to try to avoid billing that Payment Method. Thank you so much for your patience!
lone bolt
not at all, you rock! thanks for being so diligent
autumn depot
Alright, that seems to have worked, so doing that in the shortest number of steps I did:
1: Finalize the Invoice, being sure to set auto_advance to false so the Invoice doesn't automatically process a payment (https://stripe.com/docs/api/invoices/finalize?lang=cli#finalize_invoice-auto_advance)
2: Pay the Invoice, using the paid_out_of_band parameter (set to true) to indicate that a payment does not need to be processed in Stripe for this Invoice (https://stripe.com/docs/api/invoices/pay?lang=cli#pay_invoice-paid_out_of_band)
lone bolt
ah thats perfect, thanks, i'll take note of this for our internal processes in the future
autumn depot
That should cover adjusting your settings, and building a recovery flow for this particular Subscription. So let's circle back to the other topics you mentioned, if you have time (I know I get pretty hangry when people get between me and dinner, so I don't want to do that to you 😅 )
lone bolt
haha! ill have a little bit of time here once i prep some stuff that has to go in the oven. do i need to run those steps against the offending subscription? i see that its still unpaid (fine if true, just dont want to duplicate efforts)
autumn depot
Yup, you will need to run those actions, we won't take action on objects in your account on your behalf.
lone bolt
ten four!
autumn depot
Sincere apologies but I'll need to step away soon. I'm leaving you in good hands with my teammate @fresh swift, who can help address your questions/concerns regarding Subscription Schedules and the other features you were interested in adding.
fresh swift
Thanks toby, just reading through the tread here and catching up.
In the meantime @lone bolt , can you write out the outstanding issues here?
This is to make sure that I can provide the best support and share relevant next steps
lone bolt
oh hey that's ok - if you guys need to take a break, i sent a support request to talk through that stuff high level. and yeah, making dinner 🙂 lets table for now
btw its a spaghetti squash pad thai and its a great and healthy recipe
you should try it sometime!
autumn depot
That sounds amazing!