#eunoia90.
1 messages ยท Page 1 of 1 (latest)
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.
thanks! ill take over from our side from here
Are you two working on this together?
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
never did get the subscription schedule to work, ultimately ๐ฆ
it did seem like the "right" solve but was definitely more complex
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
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
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
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
mm yes i can answer that, 1s
Compare to sub_1Ns5ZzEk6sr5GyDhayrPzguD which has this update request: https://dashboard.stripe.com/logs/req_iiPHpNP1arXX9f
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
Yes, it looks that way
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
Sounds good -- hope that helps you dig in
thanks! appreciate it