Help test new version of stripe module

[datakick]

Stripe is deprecating old source api soon, so we had to rewrite the module, and migrate all payment methods to use new PaymentIntents api. The rewrite is quite significant change, so I'd like to ask everyone to help with testing before we officially release it.

This new version also fixes couple of old bugs (related to webhooks, refunds, etc)

 

stripe-v1.8.2.zip

 

Edited March 6 by datakick
new module version

[30knees]

Is it ready "enough" to test in a live site? Then I'd be happy to test it.

[datakick]

Yes, I believe it is. I also deployed it to my store already

 

[30knees]

No problems so far.

I see that the module offers Stripe Checkout: https://docs.stripe.com/payments/checkout I have selected it.

Does the Checkout integration use this feature? https://docs.stripe.com/payments/dashboard-payment-methods Because I cannot get Apple Pay to show, see here: 

 

If Apple and Google Pay don't work, is it a major thing to implement them, perhaps using the dashboard payment method? See: 

 

[datakick]

Apple pay is displayed on embedded Stripe credit card form payment method. It is displayed only on devices that supports it.

On Stripe Checkout, it should be displayed as well, if device supports it.

[datakick]

I've attached new version of module to the first post of this thread.

Couple of small issues were fixed.

I've also implemented two new payment methods - WeChat Pay and Sepa Direct Debit to test how flexible the new system is. I'm happy to note that it's quite easy to implement the methods now - it looks something like this: https://github.com/thirtybees/stripe/commit/a184785c0475310d7f72d2736d43b0c7e13fb219

[datakick]

Thanks everyone that tested this version.

Because no major issues were found, I've just released these changes officially as version 1.9.0. 

[Yabber]

In OPC order mode, when customer logs in, the card data fields are not loaded. Only after refreshing page are these fields loaded.
Old version of module does not have this error.

[datakick]

Plese file a github issue

[Yabber]

And is it possible to add BLIK payments to the module?

https://docs.stripe.com/payments/blik

[datakick]

1 hour ago, Yabber said:

And is it possible to add BLIK payments to the module?

https://docs.stripe.com/payments/blik

Sure, here: https://github.com/thirtybees/stripe/commit/4483f54e17742744b001800c91e1f90d80a20cd2

[Yabber]

41 minutes ago, datakick said:

Sure, here: https://github.com/thirtybees/stripe/commit/4483f54e17742744b001800c91e1f90d80a20cd2

Thank you. Payment has tested, works perfect 🙂

[datakick]

Anybody having issues with new version of stripe module so far?

I personally encountered problem with P24 payment method -- sometimes stripe redirects customer back before the payment is marked as processed. Redirect handler then fetches payment status from stripe api, and fails because the transaction is not validated yet. In my opinion, this is bug on stripe side -- they should redirect only after the payment process is finalised, but sometimes they don't do that. My store successfully processed few P24 payments already, but yesterday there was one that failed. 

We will need to implement more robust validation methods (cron / webhooks) and not rely on redirects so much in the future. That will take some time to implement, though

[x97wehner]

10 hours ago, datakick said:

Anybody having issues with new version of stripe module so far?

I personally encountered problem with P24 payment method -- sometimes stripe redirects customer back before the payment is marked as processed. Redirect handler then fetches payment status from stripe api, and fails because the transaction is not validated yet. In my opinion, this is bug on stripe side -- they should redirect only after the payment process is finalised, but sometimes they don't do that. My store successfully processed few P24 payments already, but yesterday there was one that failed. 

We will need to implement more robust validation methods (cron / webhooks) and not rely on redirects so much in the future. That will take some time to implement, though

I have not noticed any issue recently. We use it heavily each day.

[Yabber]

19 hours ago, datakick said:

I personally encountered problem with P24 payment method -- sometimes stripe redirects customer back before the payment is marked as processed.

With Stripe -> Przelewy24 integration, I already had problems in old version of module. Every few, several payments transaction was not confirmed. Therefore, I disabled this integration and in new version of module I did not enable it either.

[30knees]

On 4/16/2024 at 9:16 AM, datakick said:

Anybody having issues with new version of stripe module so far?

I noticed that under https://dashboard.stripe.com/developers API overview it says: 

You may be using multiple API versions due to your client libraries or plugins.

And I see I'm using both API versions:

2023-10-16
2018-02-28

and not
 
2024-04-10 Latest

Here https://docs.stripe.com/building-plugins#set-api-version it says: 

Your plugin should use the setApiVersion function, which will set the Stripe-Version HTTP header on all requests. Your users will use their own API keys to access Stripe, but this header will be included with every request. We recommend that you use the most recently published version of the API. The current API version and details on our versioning policy can be found in the API reference.

New Stripe users automatically default to the latest version of the API. This header ensures that your connector is pinned to a specific API version, which keeps the occasional backwards-incompatible change from breaking your connector’s functionality.

Users can upgrade their own API version through the Stripe Dashboard. If your connector relies on webhook events, their data format and structure depend on the user’s account API version. You should instruct your users to set the version in their Dashboard to match your plugin.

Caution
API versions can’t be downgraded. You should regularly release new versions of your connector to correctly handle any changes to JSON responses.

[30knees]

Oh, and would it be possible to add the order number as https://docs.stripe.com/metadata?

[datakick]

Latest module of stripe uses api 2023-10-16 -- if you use stripe only with thirty bees, you should set this version as default in your stripe dashboard

[datakick]

2 minutes ago, 30knees said:

Oh, and would it be possible to add the order number as https://docs.stripe.com/metadata?

At the time of payment order does not exists yet. We could store cart id there, though.

[30knees]

10 minutes ago, datakick said:

Latest module of stripe uses api 2023-10-16 -- if you use stripe only with thirty bees, you should set this version as default in your stripe dashboard

Found it, thank you. I was only able to upgrade to the latest. I couldn't select the version in the dashboard. I'm on the latest and did a test purchase, it worked. 

The only breaking changes listed for the latest compared to 2023-10-16 are:

PaymentIntents now has automatic_async as the default capture method when capture method is not specified during PaymentIntents creation. For more information about async capture, view the asynchronous capture guide.
Fields under rendering_options for invoices are now migrated under rendering.
Product ‘features’ has been renamed to marketing_features.

I guess they don't affect the module? 

[30knees]

13 minutes ago, datakick said:

At the time of payment order does not exists yet. We could store cart id there, though.

I see ... I think for my purposes (payment reconcillation) cart id isn't helpful at the moment, but maybe for someone else? 

[30knees]

On 3/6/2024 at 3:48 PM, datakick said:

Apple pay is displayed on embedded Stripe credit card form payment method. It is displayed only on devices that supports it.

On Stripe Checkout, it should be displayed as well, if device supports it.

Yes, it works!

[30knees]

On 4/16/2024 at 9:16 AM, datakick said:

I personally encountered problem with P24 payment method -- sometimes stripe redirects customer back before the payment is marked as processed. Redirect handler then fetches payment status from stripe api, and fails because the transaction is not validated yet. In my opinion, this is bug on stripe side -- they should redirect only after the payment process is finalised, but sometimes they don't do that. My store successfully processed few P24 payments already, but yesterday there was one that failed. 

We will need to implement more robust validation methods (cron / webhooks) and not rely on redirects so much in the future. That will take some time to implement, though

I'm talking to Stripe about this because P24 regularly fails with me. The support is asking for any details we can share. I wrote what you wrote but is there anything else, some error log or anything that could be shared, too?

[datakick]

with P24 it's a timing issue. When stripe redirects customer back to your site, the payment is not yet processed, and payment intent data fetched from stripe api can have status requires_action with redirect url that matches the original payment authorization url (the url we have already redirected customer to, and they paid)

You can send them relevant log entries from file in /log/stripe_<date>.log

[beetea2]

I've been having problems with this new Stripe module. Several times in the past few days the customer gets an error message after using the Stripe module "A processing error occurred"

The order is not finalized, but the payment goes through on Stripe. So the customer (and us) never receives an order confirmation.

This has happened with Apple Pay a few times, so I disabled Apple Pay in the module configuration, but it just happened again with the customer using a VISA card.

Often the customer retries successfully with PayPal, so then we have to refund the Stripe payment.

I just found this in the log file:

[12:32:32.3232] [****************] Payment validation start
[12:32:32.3232] [****************] Payment method id: stripe_cc_form
[12:32:32.3232] [****************] Payment method: Credit Card
[12:32:32.3232] [****************] Stored payment metadata: {"type":1,"methodId":"stripe_cc_form","ts":***,"cartId":***,"cartTotal":7271,"id":****":"****"}
[12:32:32.3232] [****************] Payment intent id: ********
[12:32:32.3232] [****************] ERROR: Failed to validate metadata: Cart amount has changed
[12:32:32.3232] [****************] Validation end

Many (if not all) of these errors show an incorrect order total, but the PayPal module gets it correctly.

I'm using TB 1.5.1 and Stripe API version 2023-10-16

Should I change the Stripe API version? One of the above messages seemed to say no.

Any suggestions are greatly appreciated.

Edited May 21 by beetea2
more info