Why is stripe-php requirement still stuck on version 7? What does it imply?

Here is a few things I think I understood since I wrote my first message.
Payment Element is not a new API replacing Payment Intent. It is a new JS component replacing Card Element.
We still use the Payment Intent API to create the transactions even when using Payment Element as the way to let the user finally choose a payment solution.
The Payment Element component offers multiple payment solutions but only counts as one Payment Gateway in terms of Commerce configuration.
The more stuff Stripe handles on its side, the less code we actually need to maintain. Which explains why Payment Element actually works easily with an old API and an old SDK / library.

I also start to understand why not upgrading the API version and the SDK has been possible. Since we rely on JS components for the payment part. Either the simple Card Element or new Payment Element, Stripe handles on its side a lot of the transaction process. We only need to create the Payment Intent and plug this to a JS component for transaction. I can understand that this small part has not required any upgrade of the API or SDK and still works with our old versions.

Now I still wonder what risks we take by never upgrading, what benefits could me make by upgrading, how difficult would it be to upgrade, and so on…?

Nicolas, do you see all enabled payment methods? I'm currently stepping in the dark, why only credit cards and Google Pay is shown, although several others are activated. I am not seeing clear signs, why the others should not be visible. I have also seen now in Stripe Admin that there are a couple of old API calls (2019-12-03), which brought me to this issue here.

Do you think, the old API usage is the reason?

Hi, I don't think the old API calls are a problem. From what I understand, Payment Element is just a JS component. I also have had trouble seeing (on Drupal's end) all activated methods (on Stripe's end). But I think this might not be linked to Commerce Stripe. First of all, I have noticed some kind of delay before an activated method finally shows up (maybe 2 minutes?). Also, some methods like Google Pay or Apple pay are only available on very specific cases (ex Safari with Apple pay activated on user phone / computer) you need to read more on Stripe doc... I have been able to see Paypal, Google Pay, Apple Pay, Ideal and bancontact but have not started to test them yet. So far I'm still working on being able to reuse stored credit cards (with Card Element) with the Payment Element payment gateway (not via the JS component though). So I can't help you much more on that part sorry.

ok thanks anyway! I have already contacted Stripe support. Via chat, they couldn't help me, because everything looks fine at first glance. So I'm waiting for an e-mail after they have further investigated the problem

@agoradesign, you would need ✨ Add the option to not setup payment methods for future usage Fixed to see single-use payment methods

@skyredwang thank you very much! I'll try tomorrow

This is indeed very likely solving our problems :-))) I'll have to wait until afternoon to enroll it to production environment, but it looks great in dev

I can confirm that this solved our problem :-) thank you so much!

Coming from 📌 Add PayPal support to Payment Element Gateway Active , the outdated PHP library is at least a small problem for me.

I started implementing the PayPal payment method plugin - thought it might be a good idea to store the PayPal e-mail address in a field, so that at least we can use it for building the payment method's label. In the currently used old PHP API (7.x), \Stripe\PaymentMethod class does not contain a StripeObject representing PayPal data, but the current version does have one (was added about 9 months ago)

I'm gonna try to pick the e-mail address from the billing details instead for now, but I may encounter the next problems, when I try to implement another plugin... so I'm totatlly in favour of upgrading the PHP library

PS: also, what about PHP compatibility? Is it fully PHP 8.2 compatible? If yes, that's random good luck, but we may get problems in future versions... so let's start upgrading :D

Hello,

I second @Nicolas Bouteille on what was said in #3 about the risks and efforts involved in upgrading stripe/stripe-php from the currently used version 7.x to the latest one (13.x). At the same time, I am not an expert in either Commerce Stripe module or Stripe itself. However, perhaps if we were able to summarize what needs to be covered, we could split efforts and test the module against the latest library version. I volunteer to help out with this work, but would certainly need guidance from someone with experience in the module.

One example of issue I'm having now with the library's old version is that I'd like to search customers by their email addresses in a custom functionality, using Customer::search(), but I get the error message:

Search is not supported on api version 2013-02-13. Update your API version, or set the API Version of this request to 2020-08-27 or greater.

Restating what @Nicolas Bouteille said in the description, we are probably missing out sticking with an old version, taking the risk of having to run into an urgent upgrade if Stripe eventually stops supporting other functionalities, similar to the above.

vmarchuk → made their first commit to this issue’s fork.

The patch is ready https://git.drupalcode.org/project/commerce_stripe/-/merge_requests/90.diff
Who can help with testing? Basically, there are not many changes and everything works fine.

The payloads returned by the latest version of the API are different. (They can potentially be different in every API version change, which presents a challenge to move to a new version, without causing break changes to anyone doing custom webhook processing.)

At a minimum, the Event::CHARGE_REFUNDED code fails with the latest payload and would need to be updated. (See: 🐛 The charge.refunded webhook fails, response structure differs from the expected one Fixed , which did a retrieve to ensure we had the expected (older) payload, which had more data in it.) We would need to modify the refund code to use some faulting and/or additional retrieves to get the additional details needed.

We'll also need to communicate the version change, as any existing implementations with custom webhook processing will most likely break with the change in version. Would probably be better to make the version change in a new major release, rather than in a minor update.

I posted a comment just now in #3205084: Update to use current Stripe API → because that issue was closed as outdated and pointing to this one instead. But it should be noted that the API Version and the PHP Library are different, and independent of one another. For instance you can update to the latest PHP Library but specify an older API Version in the request. It may take some work to get the module into a position where "any" API version will work, though, so that's a consideration that should be kept in mind.

@TomTech Thank you for pointing out any issues that may occur after the update.

From the documentation https://docs.stripe.com/upgrades#2022-11-15

Charge no longer auto-expands refunds by default. You can expand the list but for performance reasons we recommended against doing so unless needed.

Added a fix for this.

As @torgosPizza noted, the SDK and API are not version dependent.

The SDK has been updated to support both version 7 and the latest version 15. See: 📌 Support Stripe SDK version 15 Fixed

The SDK major version is being updated on an average of every 3 months, which is pretty quick.

Both work with the current code in the module, but if you are extending or subclassing, you might have a different experience. If so, you can specify the version 7 sdk in your composer.json until you are able to resolve any changes.

Generally speaking the SDK has been extending, rather than modifying things, so this should be unlikely to occur.

The REST API, on the other hand, changes the payload depending on version, so it is more fragile, and require more communication for a change.

@agoradesign, you mentioned not having the paypal object without the latest SDK. This should be resolved with the update, but bear in mind that the properties are added by the SDK dynamically, so it would be present, even without the latest SDK. The same was true for other payment methods, like cashapp, karma, etc... that work with the v7 SDK, even though not explicitly defined in the SDK.

Let's have this issue focus on updating the REST API.

Thank you Tom for your time and work!