v1.19.2 doesn't use latest API version

[nibblesnbits]

Issue

When running stripe trigger checkout.session.completed targeting a .NET project using Stripe.net v43.11.0, I get the error:

Stripe.StripeException: 'Received event with API version 2022-11-15, but Stripe.net 43.11.0 expects API version 2023-10-16. We recommend that you create a WebhookEndpoint with this API version. Otherwise, you can disable this exception by passing throwOnApiVersionMismatch: false to Stripe.EventUtility.ParseEvent or Stripe.EventUtility.ConstructEvent, but be wary that objects may be incorrectly deserialized.'

when calling EventUtility.ConstructEvent(json, req.Headers.GetValues("Stripe-Signature").FirstOrDefault(), _stripeEndpointSecret);

Expected Behavior

Successful validation of header

Steps to reproduce

1. install stripe cli v1.19.2
2. install Stripe.net v43.11.0 in a .NET project
3. send stripe trigger checkout.session.completed to the .NET project

Traceback

Stripe.StripeException
  HResult=0x80131500
  Message=Received event with API version 2022-11-15, but Stripe.net 43.11.0 expects API version 2023-10-16. We recommend that you create a WebhookEndpoint with this API version. Otherwise, you can disable this exception by passing `throwOnApiVersionMismatch: false` to `Stripe.EventUtility.ParseEvent` or `Stripe.EventUtility.ConstructEvent`, but be wary that objects may be incorrectly deserialized.
  Source=Stripe.net
  StackTrace:
   at Stripe.EventUtility.ParseEvent(String json, Boolean throwOnApiVersionMismatch)
   at Stripe.EventUtility.ConstructEvent(String json, String stripeSignatureHeader, String secret, Int64 tolerance, Int64 utcNow, Boolean throwOnApiVersionMismatch)
   at Stripe.EventUtility.ConstructEvent(String json, String stripeSignatureHeader, String secret, Int64 tolerance, Boolean throwOnApiVersionMismatch)
   at My.Functions.StripeSubscriptionWebhook.<Run>d__10.MoveNext() in D:\My\mono\serverless\My.Functions\StripeSubscriptionWebhook.cs:line 44

Environment

.NET 8.0

[SweetpopcornSimon]

+1

[PatryxCShark]

Can someone from Stripe answer?
I have the same problem

[ChrisBrackleyInfinity]

I was experiencing the same issue.

I managed to resolve this issue by updating my API version in the Stripe Dashboard.

Go to dashboard > Developers > Overview tab - Scroll to the bottom and find API version. Change it the latest version and then retest.

[PatryxCShark]

what about test mode?
Test mode - new API, Production -> the previous one till we release version to currently work production.

[tomer-stripe]

Hey all! There's a couple things to unpack here, I'll probably give too much info in case it's useful.

There are a few potential ways versions can be set (and exist) within Stripe:

• your Stripe account will have a default API version attached to it. We use this when someone makes API requests to Stripe without an explicit API version
• Webhooks endpoints will have an explicit API version coupled to the endpoint to handle rendering the webhook event sent to the endpoint
• SDKs have hardcoded API versions that they use to send requests to Stripe. This will override the default API version on your account but will not change the API version of the Webhook endpoint.

The CLI tries to be as version-agnostic as possible to support different users' integrations:

• it does not hard code an API version when we send requests over to Stripe (unless you manually specify one via the --api-version flag). We do generate the CLI commands against an API version but that's it
• the listen command defaults to using your Stripe account's API version or let's you use the --latest flag for the most recent API version.

In this case, when you run the stripe trigger command it won't send an API version to Stripe since we don't provide one by default but you can always provide one using --api-version. It wouldn't impact the API version of the event you receive though since Webhook event rendering specifies its own API version. On the CLI, if you run stripe listen --latest, it'll create a new listener with whatever the latest version of the Stripe API version is. Unfortunately the CLI doesn't have the option to explicitly ask to listen for webhooks for a specific API version.

Upgrading your account's API version could help since that would change the default version the CLI is using too (after 24 hours) but that can only be done in livemode as well and is a large effort you'd have to undertake (I would not recommend doing the upgrade via the dashboard for the problem here).

[BEST-Thanawat]

Add --latest solved my issue in Test mode as @tomer-stripe mentioned

[chrisjainsley]

The C# stripe.net package (a 2023-08-16 version) only accepts the 2023 version when processing a webhook.

Is this an issue with the library or the stripe CLI. Is stripe.net supposed to be backwards compatible?

[mason-stewart]

Hi, thanks for all of the teams work on the CLI. I want to point out that the inability to specify a version via stripe listen renders the Stripe CLI unusable over time for local webhook development. Here's why:

We have some legacy applications that use older version of the Stripe API. Updating all of those API calls would be a major lift. Because there are potentially many requests in the legacy application not specifying an API version via request headers, we can't simply update the default version. Because the default API version can't be changed independently in test mode and must be globally changed in live mode, we're not in a position to update the default version on our account.

We created webhooks using Stripe API version 2023-10-16 a few months ago and ran stripe listen -l ..., which worked fine until the newer version 2024-06-20 rolled out. Now stripe-go complains, as it should, about a version mismatch. In production this isn't a problem as the version configured in the webhook is used as expected by the Go package in our application. But with the Stripe CLI, the webhook's API version is ignored and instead uses the default API version that predates 2023-10-16 or uses 2024-06-20 which is currently latest.

While it's possible to configure the stripe-go client to ignore version mismatch, this seems unhealthy and risks a deserialization problem later that I assume will be hard to understand. It seems critical that we can either have the stripe listen command honor the Stripe API version as specified in the webhook config, or at least be able to specify a non-latest, non-default version.

As is, this means that a new version of the Stripe API rolling out breaks all webhooks that we're consuming via stripe listen. Thanks for your time and consideration on this!