#bojan_subscription-incomplete
fervent narwhalBOT
👋 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/1276306409545535528
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
heavy tangle
Additionally I'd like to allow for our subscriptions to be created even if the customer doesn't have a default payment method. Sometimes we collect the payment method later on, but we would like to start the subscription (which would go into past due) automatically
gentle siren
@heavy tangle it's not really something we support anymore unfortunately and it will almost always go to incomplete in that case. If it didn't, then it'd just error on creation and fail fully (the old behaviour)
heavy tangle
This is a core behavior we'd need to support
gentle siren
There are some ways around it though they are a bit hacky/confusing
- Put the Subscription on a trial for a few minutes
- Use SubscriptionSchedules instead because they don't finalize the first Invoice so they start as
active
bojan_subscription-incomplete
heavy tangle
It felt odd to me to couple the collections of the payments with the creation of the subscription
We unfortunately cannot use SubscriptionSchedules because they cannot prorate the first payment
gentle siren
yeah that is fair but they are definitely deeply correlated.
Unfortunately what you are trying to do is impossible on Subscription without "hacks". Can you say more about proration? Maybe lay down the exact flow in one clear paragraph so I can see if there's a workaround that fits
heavy tangle
Sure!
We run schools, and offer two "products" - tuition and aftercare.
Tutition is always charged on the 2nd of the month, and comes in 10 installments (ie. it's a subscription schedule w/ 10 iterations starting in aug through may).
Aftercare is an ordinary subscription that can be started at any time. We want to prorate the first month, so that if e.g. it's started today on 8/22, it'll charge the customer today a prorated amount for 8/22 -> 9/2, and then go onto monthly subscption with an 'anchor' which is the same as the tuition product.
Subsciption schedules do not allow for a 1st month proration - Instead they'll charge the full month (so the customer will pay for 8/22 -> 9/22), and then on 9/2 it'll 'reset' by issing a new invoice with a negative line item for the unused portion. This is suboptimal for the parents, and messes our reporting.
Chatted with one of your coworkers few weeks ago about this - we couldn't find a way to make subscription schedules work for this case
I could put the subsciption on a trial - will that ensure that the first invoice is always finalized? Is there any minimum/gotchas I need to be aware of?
gentle siren
yeah what you described makes sense as something we don't support. So the trial is likely the best approach.
Alternatively you could use collection_method: 'send_invoice' as a hack. It won't finalize that first Invoice. And then you can swap back to charge_automatically and finalize the Invoice.
Super messy but I can't think of a better way
heavy tangle
will that actually send an invoice?
gentle siren
it won't if you swap it before you finalize
I think the trial period will be the easiest for you so you might want to try that first
heavy tangle
that might be cleaner than trial method, i'm afraid that the trial will cause us issues downstream with reporting
will the invoice method work for folks without a payment method?
heavy tangle
yup yup!
so just to be clear:
- start a subscription w/
collection_method: 'send_invoice' - right after I create the subscription, call subscription update and set
collection_method: 'charge_automatically'
i can add state/run a job to ensure that all subs go from step 1 -> step 2
is there anything else i need to be aware of? what's the min/max time between step 1 & 2?
gentle siren
yeah you also need to swap collection_method on the first created Invoice before you finalize it https://docs.stripe.com/api/invoices/update#update_invoice-collection_method
gentle siren
sounds good
heavy tangle
yeah you _also_ need to swap `collection_method` on the first created Invoice be...
i assume this is subscription.latest_invoice
gentle siren
yes
heavy tangle
It looks like setting a send_invoice adds this as a default payment method?
gentle siren
ugh yeah it's a bit annoying it's the old bank transfer integration. No way around it unfortunately
Sorry, all of this is clearly a hack to get what you want which isn't a flow we support 😦
heavy tangle
let me try the trial route - do you know on the top of your head if that'd work for customers with no payment method?
gentle siren
yes it will work fine
heavy tangle
great - thank you!
it looks like setting a trial for 10 sec in the future works well
it generates a $0 invoice for the trial but that's something our accounting can live with 🙂
will probably increase the buffer to 10 mins just in case of clock drift/etc
but unless i'm missing something this looks like the way to go
gentle siren
yeah that seems like the best approach though a bit hacky
heavy tangle
thanks for the help!
i do understand that this is not the main usecase of subscriptions, but i am still under the impression that the scheduling should not be tied to the collection the way it is done today.
additionally the docs were not straight-forward about this behavior, we only learned about it b/c it caused problem in prod. today i was still confused after carefully reading the docs. coming here cleared things out, so thanks a ton for that.
gentle siren
but i am still under the impression that the scheduling should not be tied to the collection the way it is done today.
sure that's fair and I agree. But it's not how we built it 12+ years ago and it's quite hard to undo. We want to separate the payment billing cycle from the service fullfilment billing cycle but it definitely is not as easy as it looks
heavy tangle
oh i can only imagine!
posting it here so it gets +1 in some backlog and tilts that project just a tiny bit 🙂
gentle siren
🙂