Openfoodnetwork: Stripe checkout issues

[RachL]

Description

We have been contacted by a hub which shoppers have issues with checkout on stripe. They also have issues with the capture of payments with Stripe.

So they contacted stripe.

The hub ID is 2323. Their shop is closed until Saturday so now is a good time to look at their data.

Here is Stripe answer (that I've translated please tell me if it makes no sense). FR team would like to be able to give an answer soon, hence the s1. Solutions can come later but the comment on the API is worrying.

On checkout problems
I would like to specify that the version of the API used by CoopCircuits dates from April 2015 - 2015-04-07 - and the version of the code dates from 2018 - 1.78.0 :
https://dashboard.stripe.com/developers
https://github.com/activemerchant/active_merchant/blob/master/CHANGELOG#L863
I strongly recommend updating the integration profile with the CoopCircuits team, because your API and code could present errors, especially for 3DSecure banking authentication, for which European standards require an API version greater than or equal to 2019-03-14 to be in compliance.

On capturing payments

Uncaught / Uncapture payments make use of our pre-authorization feature:
https://stripe.com/docs/payments/capture-later
-Stripe requests authorization to withdraw funds from the bank.
-The funds are locked for you in the customer's bank account.
-Within 7 calendar days, you will be able to capture the funds. If you do not capture the funds after this limit, the funds will be released and the order canceled.

This feature is used for deposits and card scans, but is of little value if you want to capture funds automatically.

On your account, all payments use this feature, however they are usually captured immediately:
https://dashboard.stripe.com/payments/pi_1IVXSQB29qx7Q5zR3OuIxeVA

This was not the case for your payment on the 10th, CoopCircuits did not send any capture calls for this payment:
https://dashboard.stripe.com/payments/pi_1ITP3BB29qx7Q5zRUo4CVbgz
Note that you can capture this payment manually at the top right of the page above. This pre-authorization will be released on March 17 at 11:14 UTC if no catches are processed.

I invite you to contact the CoopCircuits team, in order to obtain more information on the lack of capture for this payment.
Currently CoopCircuits manages this pre-authorization with capture_method = manual on all your payments. If this parameter is passed to automatic, or is not passed, your payments will no longer use the pre-authorization feature. You can ask the CoopCircuit team if this integration is available.

Steps to Reproduce

Don't know yet

Animated Gif/Screenshot

Severity

bug-s1: a critical feature is broken: checkout, payments, signup, login

I'm putting s1 on this for investigation.

[Matt-Yorkley]

Possibly related to: https://github.com/openfoodfoundation/openfoodnetwork/pull/7286

[andrewpbrett]

The first thing to determine is why Stripe thinks we're using an API version April 2015 - 2015-04-07 - both the platform account and hub account have been updated to a more recent one in the dashboard, and even the older version of the ActiveMerchant gem is more recent than that.

[RachL]

Indeed Andy showed me where to look, and when I mimic the hub's profile I can see:

Stripe was contacted. Waiting for their answer.

[Matt-Yorkley]

Just to clarify; is this just for one hub?

[RachL]

@Matt-Yorkley only one hub contacted us yes. But FR users are not speaking a lot, so I don't know how spread this is. Adding the bloked label because we are still waiting for Stripe's feedback.

[RachL]

Okay so as usual the day you complain they haven't answered, they do :D

Here's Stripe answer:

_My apologies, the 2015 version and 2018 code reported in my first email were for the integration used for your payment on March 10th. After more research, I see indeed that this has been updated as of March 23rd:
https://dashboard.stripe.com/logs?created%5Bgte%5D=1616367600&created%5Blte%5D=1616540399&method%5B%5D=post&method%5B%5D=delete&direction%5B%5D=self&direction%5B%5D=c_

Did we really do that kind of jump? @openfoodfoundation/core-devs

_The API version is now 2019-05-16 and the code version is 1.107.4 (2020-06-02):
https://github.com/activemerchant/active_merchant/blob/master/CHANGELOG
Although newer versions exist, this integration currently conforms to PSD2 standards and should not cause complications with the 3DSecure stream._

@openfoodfoundation/core-devs I think this part of the issue can be closed. Can anyone advise on the second part of their first email around capturing payments (see issue description)? Again I'm not looking to have this fixed, but more looking for an answer to give the hub who doesn't understand why there is a "manual" payment capture done by OFN.

Also FYI in their answer today they give a bit more information on where to check for API versions:

_Note the difference between the version of the API established on your Dashboard and the one of your Stripe directory:
-The API version of your Dashboard defines the version used for requests generated from the Dashboard. On your account, this is the most recent (2020-08-27):
https://dashboard.stripe.com/developers
-The API version of the Stripe directory defines the version used for requests generated from your integration. This is the one I alluded to above.
https://stripe.com/docs/libraries#server-side-libraries
Your directory version is typically larger than your Dashboard version, with the majority of your queries coming from your site / integration rather than being initiated manually from your Stripe account._

Do we need to have an issue somewhere around this (maybe we already do?).

[andrewpbrett]

That's useful to know about the API version on the Dashboard being unrelated to the version being used by the code (and it makes sense now that I think about it).

We updated the API version in this release, but that would have been after March 23, and it was from ActiveMerchant 1.107.4 to 1.119. So I'm not really sure where Stripe is getting the API version that we're using.

As far as the second part goes, we use the "manual" capture parameter when we authorize the payment. It sounds like Stripe is pointing out that we end up immediately capturing the payment anyway, and therefore could simply pass the "automatic" capture parameter? We definitely could investigate whether the first call is unnecessary. Is there a specific problem that this hub is having with payments, though? The original issue description doesn't give details on what the issues are.

[RachL]

@andrewpbrett thanks for the investigation!

Is there a specific problem that this hub is having with payments, though? The original issue description doesn't give details on what the issues are.

Yes I've tried to translate that part but it wasn't clear sorry about that: if we do not capture the payment, Stripe releases the funds and cancels the order. This has happened quite a few times, so the hub would like us to capture automatically. I can open an issue? What I'm unclear about is how spread this problem is: the hub has given us some examples of uncapture payments, but I don't know how often this happens, or if there is any particular good reason that we do sometimes fail to capture them...

[andrewpbrett]

Do you know if all of the orders were created through the standard checkout, or maybe through the backoffice? That would be a good first step to narrowing it down, if we can. I do see that when we create a payment in the backoffice, we call authorize which uses the capture_method = manual parameter.

[andrewpbrett]

I think there's a good chance that this is fixed by https://github.com/openfoodfoundation/openfoodnetwork/pull/7497

[RachL]

thanks @andrewpbrett ! As we are waiting for the hub to get back to us re admin issues I'm closing this, and we will reopen if the fix does not work for this case :thumbsup:

[Cecilia-Hn]

I just had the client who's confirming that all the orders were created through the standard checkout and not through the back office.

[andrewpbrett]

all the orders were created through the standard checkout

In that case, yes, I think we should keep this open, #7497 deals with charges where the customer is not in the standard checkout.

[sauloperez]

I had the chance to get acquainted with another Stripe SCA integration at Coopdevs and we always capture payments as the last step of the flow so funds go to the seller. I don't understand why payments aren't captured in OFN just sometimes.

[andrewpbrett]

On that particular payment that's mentioned, we got a response from Stripe saying that the transaction required additional (SCA) authorization. Since it was during the checkout flow, the customer should have been redirected to their bank to authorize the transaction, and then back to OFN once they had. It looks like something went wrong during that process. It's possible that the customer just never completed authorization, but if we're seeing this same pattern happen frequently, there's probably something else going on. I'll keep investigating.

[sauloperez]

we might need to log the state of the process either in logs or updating DB records, or both? it should be straightforward to find out at which step the process died. I don't know if it is already.

[andrewpbrett]

The Stripe logs are actually pretty good at indicating what steps were completed, but you have to look pretty carefully through them and be familiar with this part of our codebase. The logs for this payment are actually consistent with the customer being sent to the SCA auth step, confirming the payment, and then something going wrong when we confirm the payment intent...

[andrewpbrett]

@sauloperez made some fixes for that step where we handle the payment intent in https://github.com/openfoodfoundation/openfoodnetwork/pull/7562, so it's possible that those changes will fix this issue as well. Could we follow up with the hub a week or two after that release is deployed (it's scheduled for 11 May 2021) and "snooze" this issue until then @RachL?

[RachL]

sure, I'm closing and we can reopen if they still face the problem. ping @Cecilia-Hn