Why is stripe-php still stuck on version 7 and Stripe API on 2019-12-03? What does it imply?

Created on 23 November 2023, 12 months ago
Updated 26 August 2024, 3 months ago

Hello,

I recently realized that the latest version of stripe/stripe-php is currently version 13 and that Commerce Stripe is still stuck on version 7.
https://www.drupal.org/project/commerce_stripe/issues/3284996 β†’
Also, the latest API version is 2023-10-16 and Commerce Stripe still uses version 2019-12-03.
https://www.drupal.org/project/commerce_stripe/issues/3205084 β†’

I have also noticed that despite not using the most recent version of stripe-php and of the API, you guys have managed to release a new version of the module that handles the new Payment Element feature.

From what I understand, stripe-php is just a helper that makes it easier to communicate with Stripe's API. And one can decide on each request which version of the API to use for each call.

Instinctively, I would have assumed that using the new Payment Element component would require to use a version quite recent of the API… but apparently not because I have noticed that even in StripePaymentElement::init() we can see:
StripeLibrary::setApiVersion('2019-12-03');

And I would have also assumed that it would have been easier to implement using the latest stripe-php library.

So here are my many questions:

Why - and how come - have you never bothered / needed to upgrade either the API or PHP library so far?

Is it a problem? Is it assumed?

What we are potentially missing out by sticking to a stripe-php version 7 that has not been updated since May 2022 (7.128) and and API version of late 2019?

How did you manage to include Payment Element without a recent version of the API?

Have you decided not to rely on the PHP library anymore and write custom code instead?

Wouldn't it have been easier and better (official) to implement the Payment Element relying on a more recent version of the PHP library?

Is the stripe-php library still a requirement? How much code of this module now actually relies on stripe-php? Would it be harder to remove any dependency on stripe-php so that is it not required anymore, or to upgrade the code that relies on it to v13?

I actually have custom code that uses Stripe's API for other stuff on my project, so since I use Commerce Stripe, I cannot upgrade stripe-php for my custom code…

Thanks in advance for any clarification you can bring on the matter :)

Nicolas

πŸ’¬ Support request
Status

Needs work

Version

1.0

Component

Code

Created by

πŸ‡«πŸ‡·France nicolas bouteille

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @nicolas bouteille
  • πŸ‡«πŸ‡·France nicolas bouteille

    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…?

  • πŸ‡¦πŸ‡ΉAustria agoradesign

    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?

  • πŸ‡«πŸ‡·France nicolas bouteille

    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.

  • πŸ‡¦πŸ‡ΉAustria agoradesign

    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

  • πŸ‡¨πŸ‡³China skyredwang Shanghai

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

  • πŸ‡¦πŸ‡ΉAustria agoradesign

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

  • πŸ‡¦πŸ‡ΉAustria agoradesign

    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

  • πŸ‡¦πŸ‡ΉAustria agoradesign

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

  • πŸ‡¦πŸ‡ΉAustria agoradesign

    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

  • πŸ‡¨πŸ‡¦Canada maursilveira Windsor, ON

    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.

  • πŸ‡ΊπŸ‡¦Ukraine marchuk.vitaliy Rivne, UA

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

  • Status changed to Needs review 8 months ago
  • πŸ‡ΊπŸ‡¦Ukraine marchuk.vitaliy Rivne, UA

    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.

  • Status changed to Needs work 8 months ago
  • πŸ‡ΊπŸ‡ΈUnited States TomTech

    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.

  • πŸ‡ΊπŸ‡ΈUnited States torgosPizza Portland, OR

    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.

  • πŸ‡ΊπŸ‡¦Ukraine marchuk.vitaliy Rivne, UA

    @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.

  • πŸ‡ΊπŸ‡ΈUnited States TomTech

    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.

  • πŸ‡«πŸ‡·France nicolas bouteille

    Thank you Tom for your time and work!

Production build 0.71.5 2024