#jeremy-subscription-schedule
fervent fossil
unborn knoll
@nimble copper that is not something we support. The status of the Subscription is always active first before the first payment unfortunately.
What you need to do is track who has subscriptions already and not create a new one when they already have an existing one instead
candid harbor
Can you explain your business case in more details jeremy? I might have the similar case.
nimble copper
@candid harbor Yeah - we just need to be able to have a subscription schedule because we have things like "First month for $1, then the next 12 months for $50 off, etc."...we're using payment elements so a subscription has to be created first before we can show the payment form.
The easy thing would be if subscription schedules acted like subscriptions (as you mentioned) and allowed "default_incomplete"...
However, since that isn't an option, I suppose the only solution is to:
- Does a subscription already exist for this customer?
- If so, is it paid up? If so the user should not have been able to get here...bail....Otherwise, update the subscription to this new information (the promo code they used may have changed - which changes the schedule they would have).
The only problem I see with this is that if the user never comes back, then we have a customer and subscription just sitting out there as active.
unborn knoll
Well it doesn't "sit out there", they won't pay so it will get canceled right?
candid harbor
I understand. I had case where I needed to allow customer to pay in installments and I have used schedules for that, but the first installment was in fact handled as creating subscription with payment behaviour default incomplete. Then, as soon as the payment intent for that 1st installment was paid successfully, I created the remaining installments by creating schedule, whereas first phase was ended and the next phase started at the end of that first phase. I calculated recurring interval manually.
I created schedules this way (PHP):
$schedule = $stripeClient->subscriptionSchedules->create([ 'from_subscription' => $subscriptionId, ]);
nimble copper
Gotcha - that could work as well. I think @unborn knoll's idea seems simpler - I'm going to test it and if it is acceptable I'll probably go with that...However, your method is intriguing as well. I'm just not sure I want to create the schedule later...I'm guessing you did it from a webhook event for invoice paid or some such?
candid harbor
Indeed, I'm listening to INVOICE_PAID event
All cool, let me know if I can help more. I've struggled with that for few days haha. I can share my code with you if that will be needed, just message me privately.
nimble copper
@candid harbor I actually am starting to really like your idea...by chance - how do you determine when the invoice is paid if it should really convert to a subscription schedule? Like when they pay month 2...it shouldn't do anything. Do you just go get the subscription and check if its already a schedule and ignore if so?
candid harbor
Hmm, well, this is my flow:
If invoice billing_reason = 'subscription_create' && event type = 'invoice.payment_succeeded', then I proceed with the flow.
In your case, it seems like enough. In my case, I have some more checks to perform and I do it by adding metadata whilst creating subscription. Then I check metadata values and if these meet my requirements, I convert it to schedules.
I also create prices dynamically. Let me create a pastebin for you to have a better follow up.
Here you go. It will expire in 1 day. Please keep in mind that if you don't need to end subscription at some point, you might need to change the code a bit.
Hopefully it will be helpful.