#zach_code
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/1356896939647434792
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Once you started using SubSchedule, I would say it's better to keep using it
What error do you encounter when running above code?
Does it say you can't modify current phase?
If you look at the Subscription Schedule, do you see the change is reflected?
Did you pass proration_behavior on the parent level (instead of inside each phase level)
Proration behavior is set on parent level:
Stripe::SubscriptionSchedule.update(
Current.user.active_subscription.stripe_schedule_id,
{
proration_behavior: :none,
phases: [
{
items: [ { price: latest.phases.first.items.first.price } ],
start_date: latest.phases.first.start_date,
end_date: "now"
},
{
items: [ { price: latest.phases.last.items.first.price } ]
}
]
}
)
I'm not sure if it is reflected, this is the response:
{
"id": "sub_sched_1R93FtDER5aMALszvyTg7sJg",
#...
"current_phase": {
"end_date": 1746172008,
"start_date": 1743580008
},
"customer": "cus_S1IYK7llZsgsIN",
#...
"metadata": {
},
"phases": [
{
"add_invoice_items": [
],
"application_fee_percent": null,
"billing_cycle_anchor": null,
"billing_thresholds": null,
"collection_method": null,
"coupon": null,
"currency": "usd",
"default_payment_method": null,
"default_tax_rates": [
],
"description": null,
"discounts": [
],
"end_date": 1746172008,
"invoice_settings": null,
"items": [
{
"billing_thresholds": null,
"discounts": [
],
"metadata": {
},
"plan": "price_1R7Ef6DER5aMALszYgvDl3O9",
"price": "price_1R7Ef6DER5aMALszYgvDl3O9",
"quantity": 1,
"tax_rates": [
]
}
],
"metadata": {
},
"on_behalf_of": null,
"proration_behavior": "create_prorations",
"start_date": 1743580008,
"transfer_data": null,
"trial_end": null
}
],
"released_at": null,
"released_subscription": null,
"renewal_interval": null,
"status": "active",
"subscription": "sub_1R7FxrDER5aMALszR3cJQdMA",
"test_clock": null
}
But is it the expected way to do a renewal? Previously I simply did:
Stripe::Subscription.update(stripe_id,
billing_cycle_anchor: :now,
proration_behavior: :none
)
I just want to replicate that using subscription schedules (with 1 infinite phase)
Well so it should be identical. Your customer isn't charged because proration_behavior is none.
Are you expecting to charge the Customer?
Yes expecting to charge. Using
Stripe::Subscription.update(stripe_id,
billing_cycle_anchor: :now,
proration_behavior: :none
)
it would charge my customer for a new cycle (and set the anchor to now)
Our pricing model is you pay a monthly amount, which is translated to usage credits. If you use up all your credits, you can renew (by setting anchor to now and paying instantly) to reset your credits
For the second phase, can you specify billing_cycle_anchor to phase_start?
1 sec, i'll try
Stripe::SubscriptionSchedule.update(
Current.user.active_subscription.stripe_schedule_id,
proration_behavior: :none,
phases: [
{
items: [ { price: latest.phases.first.items.first.price } ],
start_date: latest.phases.first.start_date,
end_date: "now"
},
{
items: [ { price: latest.phases.last.items.first.price } ],
billing_cycle_anchor: :phase_start
}
],
)
It triggers no payment.
API gives response
#...
"phases": [
{
"add_invoice_items": [
],
"application_fee_percent": null,
"billing_cycle_anchor": "phase_start",
"billing_thresholds": null,
"collection_method": null,
"coupon": null,
"currency": "usd",
"default_payment_method": null,
"default_tax_rates": [
],
"description": null,
"discounts": [
],
"end_date": 1746172772,
"invoice_settings": null,
"items": [
{
"billing_thresholds": null,
"discounts": [
],
"metadata": {
},
"plan": "price_1R7Ef6DER5aMALszYgvDl3O9",
"price": "price_1R7Ef6DER5aMALszYgvDl3O9",
"quantity": 1,
"tax_rates": [
]
}
],
"metadata": {
},
"on_behalf_of": null,
"proration_behavior": "create_prorations",
"start_date": 1743580772,
"transfer_data": null,
"trial_end": null
}
],
What's the sub_sched_xxx ID?
sub_sched_1R93FtDER5aMALszvyTg7sJg
I'm looking at this request: https://dashboard.stripe.com/test/logs/req_8tIQ6q4uArhc7y
What didn't work as you expect? I see a new invoice on the subscription to reflect the change: https://dashboard.stripe.com/test/invoices/in_1R9MCuDER5aMALszifamjRO7
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Ah yes, I see an invoice is now created. However that's a draft invoice that wont be charged for an hour.
Is it not possible to replicate this non-schedule functionality:
Stripe::Subscription.update(stripe_id,
billing_cycle_anchor: :now,
proration_behavior: :none
)
when using subscription schedules?
No, you'd need to manually finalize the invoice if you want payment attempted immediately
Schedule's stick to the 1 hour rule
Ah ok, I'll try that. Is it really recommended to wrap all subscriptions in schedules like this? It feels like it might be easier to release the schedule when not waiting for a upgrade/downgrade, and stick to non-scheduled subscriptions for the regular states.
Depends on if you use case requires a schedule. It's not recommended to just blindly use a schedule no, but if you want to facilitate a scheduled downgrade/upgrade at a future date then they automate that
My use case only requires schedules doing upgrades/downgrades (which should happened at end of cycle). So I could potentially release the schedule after upgrades/downgrades happen
Yeah there's no other way to do that today
Ok, thanks for the help!