_nerder

[cerulean tiger]

Hello! What's your use case?

[tight crypt]

👋

basically i'm creating a checkout session from our mobile app

ok let me explain real quick

Our app is managing gyms, we are using Stripe Connect (Standard) for our integration.

We handle subscription creations for our customers and purchases of other one-off products

While we support cards and SEPA DD "natively", we also give our customer the option to choose checkout

this is mainly when they want to give their customer the option to purchase their membership with the preferred payment method, instead of "force" cards for instance

now the problem is that we support 2 types of billing:

• automatic
• manual

Automatic billing is the default setting the billing cycle to "forever"

instaed Manual, is to set cancel_at_period_end: true

now the problem is that we have a bug in which if the customer (of our customer) is paying using checkout for a membership with "manual" renewal, this has not being respected

and the checkout API doesn't seems to support cancel_at_period_end

therefore i'm stuck

[cerulean tiger]

I might be missing something, but it sounds to me like the manual option would just be a one-time payment not involving a Subscription, right? Could you use Checkout in payment mode instead of subscription mode for that scenario?

[tight crypt]

nope, because that membership will stays active for that amount of time

imagine that you purchasing a gym membership that will lasts 1 month and then cancel automatically

[cerulean tiger]

Ah, I see, you're keeping track of the duration based on the Stripe Subscription rather than tracking it on your end.

[tight crypt]

yes, which is quite convenient

[cerulean tiger]

In any case, you're correct that you can't do this automatically. What you can do is listen for checkout.session.completed Events with a Webhook Endpoint and set cancel_at_period_end on the manual Subscriptions Checkout creates.

[tight crypt]

ok I see

but there is any reason why this is not inside subscription_data?

I was expecting to find it there

[cerulean tiger]

Probably because it's never come up before. Using Checkout to create a Subscription that cancels after the first period boils down to a one-time payment.

This is the first I've heard of someone wanting to do something like this.

I can flag it internally as a feature request though.

[tight crypt]

But the same will be true for creating a subscription from the normal subscription.create endpoint, but probably following your logic that is there just because can be useful in subscription.update and I just got lucky that it was there already

I found super convenient to leverage currentPeriodStart & currentPeriodEnd from you instead of implementing on my side when 99% of the time this 2 things will coincide anyway

[cerulean tiger]

I think it's more because we generally provide more granular control via the API, and there are likely more use cases when using the API as a result, but with Checkout it would just be a one-time payment instead of a Subscription.

[tight crypt]

but anyway yes, thank you so much for taking care of it

makes total sense, if you would like to flag it internally it might be discussed

i'll take care of it as you proposed me for now

[cerulean tiger]

Yep, will do!

[tight crypt]

I have another question unrelated, is better to open a new thread?

[cerulean tiger]

You can ask here!