#zepatrik_api
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1272600297092546612
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi ๐
Unfortunately you can only Void an Invoice that has been finalized
https://docs.stripe.com/api/invoices/void
So you could listen for the invoice.finalized webhook event. At that point the invoices could be voided and then deleted.https://docs.stripe.com/api/events/types#event_types-invoice.finalized
at that point the customer already got the email about the new invoice, so this is not an option
can we maybe use the invoice.upcomming event? if we cancel the subscription there, will the invoice not be created in the first place?
Yes that would be another approach you could take. Canceled subscriptions do not generate Invoices.
https://docs.stripe.com/billing/subscriptions/cancel
I would read through this carefully though and create a few Test mode subscriptions to validate the behavior you expect
You can also set the number of days ahead of the Invoice being created that the invoice.upcoming webhook will fire, if you want to give yourself more time to handle the scenario
will the invoice then not be created anymore?
You can cancel customer subscriptions manually through the Subscription or the Dashboard. By default, cancellation takes effect immediately and invoices are no longer generated for canceled subscriptions.
From the doc. I recommend you review it thoroughly for any edge cases though
ok, maybe a job to do the cleanup is even better, but we thought of keeping the webhook handler in case this state drift happens again for some reason
thx anyway