eunoia90.

[subtle harbor]

The "hack" is as follows.
We first create the subscription for the product. Here's more or less what we do:

const subscription = await stripe.subscriptions.create({
      customer: customer.stripe
CustomerId,
      items: [product.stripePriceId],
      payment_behavior: 'allow_incomplete',
      collection_method: 'charge_automatically',
      default_tax_rates: [stripeTax.id],    
    });

Afterwards, we check that the returned subscription from that .create call is "active" and try to update the subscription with a trial_period (this is the "hack") so that the first subscription period becomes truncated. Here is what we do there:

if (subscription.status === 'active') {
  await stripe.subscriptions.update(subscription_id, {
    trial_end: 73
    proration_behavior: 'none',
  });
}

An issue we've run into is that this doesn't seem to work consistently across the board for new subscriptions. Sometimes we will notice that a subscription has not been updated with the new trial_end. For example, this subscription: sub_1Ns6reEk6sr5GyDhY0Bk5YVY should have the 73 day trial period, but does not. This subscription: sub_1Ns5ZzEk6sr5GyDhayrPzguD DOES have the trial period updated on it.

Can you help us understand what the source of this inconsistency is? The sporadic behavior makes me think it could be a race condition, where the state of the subscription becomes "closed" for updates at a timing that only sometimes allows for this trial_period to be ammended after creation.

[glacial turret]

thanks! ill take over from our side from here

[edgy parrot]

Are you two working on this together?

[glacial turret]

yeah 🙂

@subtle harbor had to run

[edgy parrot]

GOtcha

So first of all, honestly not a bad approach to this. Using a trial period is one of the ways we recommend shifting billing cycle like this.

The alternative more complex version would be using a subscription schedule to force the first renewal early

[glacial turret]

never did get the subscription schedule to work, ultimately 😦

it did seem like the "right" solve but was definitely more complex

[edgy parrot]

https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#resetting-anchor

Essentially you set the end date of the first/current phase to be that target date 73 days away

and the new/second phase uses billing_cycle_anchor: 'phase_start' to force the reset

And if you don't want to credit for the prorated shortened period you can disable prorations: https://stripe.com/docs/api/subscription_schedules/update#update_subscription_schedule-phases-proration_behavior

[glacial turret]

we couldnt push the next invoice out (farther in the future) that way, only bring it closer. the "natural" recurrence would still run, then what we requested as the pushed out date. anywho, a little bit besides the point, but im happy to share code. and yeah we also know about that proration bit but thanks for surfacing

but anyway in the interest of time since i know you're probably super busy maybe just a quick answer to this bit of @subtle harbor's question?

For example, this subscription: sub_1Ns6reEk6sr5GyDhY0Bk5YVY should have the 73 day trial period, but does not. This subscription: sub_1Ns5ZzEk6sr5GyDhayrPzguD DOES have the trial period updated on it.

the inconsistent application of the trial period has us puzzled

[edgy parrot]

Taking a look at that sub

sub_1Ns6reEk6sr5GyDhY0Bk5YVY was created here: https://dashboard.stripe.com/logs/req_QvrFcf6yyZa1MC
This did not specify a trial period, so it has none. There have been no update requests after creation.

So I'd then ask why you expect sub_1Ns6reEk6sr5GyDhY0Bk5YVY to have a 73 day trial

[glacial turret]

mm yes i can answer that, 1s

[edgy parrot]

Compare to sub_1Ns5ZzEk6sr5GyDhayrPzguD which has this update request: https://dashboard.stripe.com/logs/req_iiPHpNP1arXX9f

[glacial turret]

we inherited some questionable code that included the following guard if (subscription.status === 'active') { before applying the trial period (directly after sub creation)

ah weird, but i see given your log that allegedly the result did have a status: active on it

[edgy parrot]

Yes, it looks that way

[glacial turret]

we dont await this promise so i actually wonder if we

're silently swallowing an error here... i guess it'd have to be prior to our call to you but still async

cause otherwise even if you threw an error we should see it in the stripe dash ui

alright, well, i think this is probably in our court given what we're seeing here

[edgy parrot]

Sounds good -- hope that helps you dig in

[glacial turret]

thanks! appreciate it