#Nick-sub-end-date

1 messages · Page 1 of 1 (latest)

thick herald
#

Hey. Which end date? There's no predefined end date for a subscription – they're ongoing until you/customer cancels

keen cloak
#

We use yearly prices, and we don't have auto renew enabled

#

So it always creates it with an end date 1 year from the creation date, rather than 1 year from the date of payment

thick herald
#

Auto renew?

keen cloak
#

current_period_end is what I'm referring to with end date

#

yeah we create them with CancelAtPeriodEnd set to true

thick herald
#

We'd like it so that the subscription dates are based on the day they pay for the subscription
Sounds like a better use case for subscription scheduling rather than this hacky way

keen cloak
#

Only sort of familiar with schedules. Could you give me a quick idea of what the phases would be in this case?

#

I'm just not seeing how it will work with sending an invoice, since Stripe doesn't generate the invoice until the subscription actually starts AFAICT

thick herald
#

I misunderstood your use case, scheduling probably isn't advantageous here

keen cloak
#

So adjusting the billing cycle anchor at the time of purchase would do what I want re: current_period_end dates, however, it will generate another invoice for the customer

#

Can I avoid that in any way?

thick herald
#

It shouldn't if you pass proration_behaviour: 'none'

#

If that's still the case, please share a req_xxx

keen cloak
#

Yeah passing "none" just generates another invoice with the full term amount

#

sub_1LEBtUI67GP2qpb41z4z6VRF is a test mode subscription.

Initial invoice for 14640 was the one I wanted

The second one for 0.79 was simply a billing_cycle_anchor=now call

The most recent invoice was setting the billing cycle anchor to now but also passing proration_behavior: 'none'

#

here are the events
ProrationBehaviorNone: https://dashboard.stripe.com/test/events/evt_1LECLrI67GP2qpb4EcsDFM0Z

ProrationBehavior Default (create_prorations?): https://dashboard.stripe.com/test/events/evt_1LECKoI67GP2qpb4LxGW9k9x

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

thick herald
#

Ah, I guess this is expected:

When resetting billing_cycle_anchor, the customer is invoiced immediately for the next period

#

It's a strange use case. My guess would be to just delay the start of the subscription until that initial invoice is paid

#

So you'd use a one-time invoice instead

#

With send_invoice the subscription starts active immediately, regardless of payment. Just how it works

#

And at that point the billing clock is ticking to the next cycle

keen cloak
#

I feel like it isn't that out there re: use case? Like if you send an invoice to a customer for a 1 year subscription, they expect to get the full year, but with the way it is, they would get 1 year minus how long it for them to open the invoice email you know?

#

The allow_incomplete state of the subscription would also be something that would work, but then you can't set the amount of days due, and it will just expire if the invoice isn't paid within 24 hours, which isn't enough time

thick herald
#

Yeah but in most instances that's what charge_automatically serves

#

It's uncommon I'd say to use send_invoice for subs where you need to track the subscription status

#

My recommendation would be to just use a one-off invoice, then delay the (now free) subscription creation until that is paid

keen cloak
#

So create a one-off, store the ID for it, then listen for invoice.paid events for that ID, and once it comes in, generate the subscription?

random dawn
#

Hello 👋
Stepping in here
Give me a moment to catch up and I'll respond as soon as I can 🙂 Thanks