Setting subscription end date using the stripe checkout API (C#)-CodePudding

Hopefully the title describes the issue, but I'll give a little more context.

So, I have test app with two price plans a one-off payment (which is working perfectly), and a subscription.

The nature of the service only requires a 12 month subscription. While I can create the subscription, I cannot set an end date for the subscription using the checkout api?

Below is a snippet of code:

        var baseUrl = $"{_configuration["BaseURL"]}";
        var options = new SessionCreateOptions
        {
            Mode = "subscription",
            SuccessUrl = $"{baseUrl}/payment/success/?session_id="   "{CHECKOUT_SESSION_ID}",
            CancelUrl = $"{baseUrl}/payment/cancelled",
            CustomerEmail = customerEmail,
            LineItems = new List<SessionLineItemOptions>()
        };
        var sessionLineItem = new SessionLineItemOptions
        {
            Quantity = 1,
            PriceData = new SessionLineItemPriceDataOptions()
            {
                UnitAmount = (long)19.99 * 100,
                Currency = "gbp",
                ProductData = new SessionLineItemPriceDataProductDataOptions
                {
                    Name = "subscription"
                },
                Recurring = new SessionLineItemPriceDataRecurringOptions
                {
                    Interval = "month",
                    IntervalCount = 1
                }

            }

Having gone the through majority of properties, it doesn't appear to exist? I'm wondering if anyone has managed to successfully implement this?

Thank you for your time.

CodePudding user response：

It's not possible within the Checkout Session call.

You would have to do it later, in one of two ways:
1 - Update the Subscription with cancel_at
https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at
2 - Add a Schedule to the Subscription, then update that Schedule with phases[0]iterations=12
https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#existing-subscription

I personally prefer option 2, even though it's more calls, because at least you shouldn't get any issue with prorations triggered by a Unix timecode miscalculation.