Jump to content
thirty bees forum

Help test new version of stripe module


datakick

Recommended Posts

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 by datakick
new module version
  • Like 1
Link to comment
Share on other sites

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: 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...

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.

Screenshot_20240406_034811.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

  • 1 month later...
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?

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

Posted (edited)

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 by beetea2
more info
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...