Update to Stripe PHP v10

As long as the API doesn't change from _this_ module, we should be able to handle a lot of this via composer dependencies. But show some code and it will be easier to decide if a new major version is needed or not.

Has anyone made any progress on this? I am seeing some console/js issues with payment_intents and haven't fully debugged, but wondering if this is related to the age of the 7x version and v1 API.

I hesitate to bump to another major version. From looking at the API footprint of Stripe's PHP framework, it seems to have pretty decent legacy support. I'm looking at https://github.com/stripe/stripe-php/wiki/Migration-to-StripeClient-and-...

I also manually tested this with the example checkout page bundled w/ this module. Can I get any other feelings here on bumping major. I feel it leads to a bad precident. When this was first proposed 2 years ago, the major version was v13. It is now up to v16. If we have to upgrade the major version of this module every time the stripe framework updates its major version, we're going to be in a bad place. That said, _this_ module's API footprint hasn't changed. I tend to think that is what I would bump a major version on, not on if a dependency of mine bumps. Thoughts from the wider community?

The older versions don't receive security updates. https://github.com/stripe/stripe-php?tab=readme-ov-file#support

When I say

I hesitate to bump to another major version.

I mean of the drupal stripe project. Not the general idea of upgrading to a newer stripe upstream library. The question is more around do we create a 3.x version of this project or stay in the 2.x range still.

Ah. I think a 3.x branch makes sense.

If we do that, it sets precident for a new major of this module for every major upstream. There's been 4 or 5 majors in around 2 years upstream and they are up to version 16. My caution is to ask if _this_ module's API changes with those bumps? If a custom user of the module needs a much older version of Stripe upstream, they could (maybe should) pin to that upstream version. Additionally, when testing this module, the functionality for presenting/accepting payment works the same in v7 (upstream-legacy) and v16. I'd hazard a guess that with BC shims in place upstream, the functionality of v7 and v16 are pretty close to the same thing. Is there any evidence that this isn't the case?

That last comment gave me a great idea. What about my suggested update to the upstream versioning? That way if someone finds they need an older version, they aren't locked into the most recent version.

Maybe we release a point release with full support from 7 => 16, then the subsequent release reduces that to 16. That gives folks time to upgrade (if they need to, although that need is questionable, see my earlier comments). Then if we need to take advantage of any of the new features like payment intent that are only available in a newer version, we don't have to do tons of version checking in this module. What I don't want to do is create lots noisy small, minor Major releases. Again, this modules' API footprint hasn't changed. And functionality with v16 or v7 is identical.

Even with the version supporting PHP 5.3, they say this:

If you are using PHP 5.3, you should upgrade your environment as this version has been past end of life since August 2014. Otherwise, you can download v5.9.2 (zip, tar.gz) from our releases page. This version will continue to work with new versions of the Stripe API for all common uses.

https://github.com/stripe/stripe-php?tab=readme-ov-file#legacy-version-s...

So it's probably true that the core of the API will work as it always has.

Let's do it. If folks really need the older version of the stripe library, they have the flexibility to revert to older. But _this_ module doesn't require a specific version.

Automatically closed - issue fixed for 2 weeks with no activity.