Stripe Payment processed with incorrect amount

[chezaorchard]

Description

Customer progressed through order to payment via stripe and received a payment failed message due to an incorrect expiry date for the credit card number.

Customer revised the expiry date and made no other changes to the order - stripe payment was successful however the amount charged was not the full order total.

Discrepancy is $18.62 - which is the combined total of the orders shipping $15.00 and the transaction fee $3.62.

Expected Behavior

Payment should have progressed for the full order total.

Actual Behaviour

Payment progressed for an amount less than the full order total.

Steps to Reproduce

Have not been able reproduced

Workaround

No workaround

Severity

bug-s2: a non-critical feature is broken, no workaround

https://github.com/openfoodfoundation/openfoodnetwork/wiki/Bug-severity
-->

Your Environment

• Version used:
• Browser name and version: Firefox 78.0.2, Windows 10
• Operating System and version (desktop or mobile): desktop

Possible Fix

[kirstenalarsen]

Just confirming that Stripe gives us same info as customer. First payment at 12:48pm failed with incorrect details

2nd payment 2 mins later succeeds with incorrect amount.

[mkllnk]

We don't have any automated tests around failed Stripe payments.

I think it's time to start using VCR and Puffing Billy to test payments properly. They work really well in our Ceres Fair Food project.

[mkllnk]

I tried a failed checkout locally and found two fees:

• The admin fee is is added before checkout and after the payment failed it's in state closed.
• The transaction fee is added during checkout and after the payment failed it's in state finalised.

Trying to check out a second time creates another transaction fee. That sounds right. And the payment has the same amount again (items + admin fee + shipping fee + transaction fee). So with a simple failing payment (invalid Stripe api key), I can't reproduce the problem.

Update: I could reproduce the problem. I forgot to reload the payment object. It got updated to contain only items and admin fee, no shipping or transaction fees.

[luisramos0]

Hello, I tried to replicate this with sample data but I cant reproduce it.
I have basically tried to place an order with a problem in the payment and then fix the problem and press the checkout button again. No luck, shipping fees, payment fees and enterprise fees all maintained correctly. I tried with both StripeConnect and StripeSCA.

The live issue is with StripeConnect btw.

@mkllnk can you please add more details about how you have managed to reproduce this problem?

[luisramos0]

Let's remove the v3regression label until we know it's a regression, ok?

[mkllnk]

I downloaded the production database and tried to checkout with the shop which reported this problem. When I tried to check out, it failed because the production Stripe API keys don't work with my development account and in test mode. So the payment failed. Then I pressed the button again and it failed again. Looking into the database, I saw two failed payments. The first was for the full amount, the second one was missing fees.

[chezaorchard]

Two additional orders have experienced the same issues with a different Aus hub:

Worthy or further investigation and possibly retag with V3 regression - I don't have permissions to update label, please update as required

[kirstenalarsen]

I've been looking through Stripe and this is happening more often than not - I'm not sure that it's every time but looks like it for Prom Coast (see also #5785)

On the basis of that I'm putting the regression label back on @luisramos0 as it wasn't happening before the release.

[luisramos0]

ok about the regression label 👍 we are not 100% sure it's a regression but it's fair to assume it is. I am saying this because then that means this should block the v3 roll out plan. No more upgrades to v3 until this is sorted. Right?

[kirstenalarsen]

Yes definitely @luisramos0 and the sooner we can get it sorted the better as it's a lot of faffing around to try and get it sorted at hub / customer end and we now have at least 17 occurrences of it . .

[RachL]

@kirstenalarsen all 17 occurrences are for the same hub?

[kirstenalarsen]

Prom Coast (#2252)
R706775248
R410335530
R038117225
R314228858
R223614724
R578773210
R624646775
R658448253

North Arm Farms (#2331)
July 19, 2020
R481312456
R464138500

Fawkner Commons (#1411)
July 19, 2020
R352208840
July 18, 2020
R778343338
R484845217
July 17, 2020
R057835623
R812510135

The Bicycle Baker (#2876)
July 17, 2020
R730600760

[luisramos0]

ok, I can replicate this locally.
I confirm this is a v3-regression, it's not happening in v2.
It looks like it will always happen when the first checkout attempt fails.
This is an S1 I think.

This problem is related to the complicated order workflow and recalculation of order adjustments. I am trying to understand what's happening but no luck yet. I will report back in an hour or so.

[luisramos0]

ok, I found the problem, in the order workflow there's a step where the fees are recalculated, charge_shipping_and_payment_fees! (there are multiple places where the fees are updated, this is one of them 🙈). In this method we are updating the payment amount based on the order total, but the process is selecting the first payment of the order (not the first pending payment) which can result in updating the total in a past failed payment, not the payment that will be processed.
The PR #5793 updates the code to look at pending payments only ✔️
I can replicate the problem and I can verify the PR fixes the issue.

[kirstenalarsen]

Can I please have some order numbers for each of the cases above so that I can check in ofn and stripe before contacting the users @luisramos0 @sauloperez ? And more information on the case where you think it could only have been done by super-admin (seems very unlikely to me - we really don't switch people's payment methods)

[mkllnk]

@luisramos0 I believe you opened this issue by mistake. This has been solved by #5798 and the remaining issue about Stripe-SCA has a new issue: #5816

I'm closing this now but feel free to correct me if I'm wrong.

[luisramos0]

I kept it open to clean up data and address any questions about the topic from the support team as some orders were not correct after the fix. Sorry, I could have commented.
We now have #5836 to track that so we can keep this one closed 👍