-
-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix failed SCA authentication on subs. order payment not reflected in OFN #7562
Fix failed SCA authentication on subs. order payment not reflected in OFN #7562
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7562 +/- ##
==========================================
- Coverage 93.19% 90.62% -2.57%
==========================================
Files 635 635
Lines 18115 18227 +112
==========================================
- Hits 16882 16518 -364
- Misses 1233 1709 +476
Continue to review full report at Codecov.
|
eabfd5e
to
051bb9a
Compare
Now the existing validation is redundant. It's Stripe's API who does that now. It's up to them to decide what's a valid intent.
This gives us the opportunity to retry the operation in case the processing fails.
051bb9a
to
69b91ea
Compare
I couldn't figure out how to ask Codecov to reassess the branch. That's clearly wrong. |
😮 it looks good now. It may handle it eventually 🤷 |
flash[:error] = "#{I18n.t("payment_could_not_process")}. #{result.error}" | ||
end | ||
@order.reload | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I plan to move this to its own purpose-specific controller action in an upcoming PR so we don't mix the two concerns and potentially introduce bugs. This will also make it much easier to improve this further us outlined on #7509 (comment).
if params.key?("payment_intent") | ||
result = ProcessPaymentIntent.new(params["payment_intent"], @order).call! | ||
unless result.ok? | ||
flash[:error] = "#{I18n.t("payment_could_not_process")}. #{result.error}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a path where #ok?
returns false
but #error
is nil
(line 34 in the service), right?. Do we want to add a message there instead? Or avoid setting flash[:error]
with an empty message? Otherwise I think the user will see a red flash message box but with no message in it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to check but I purposefully left the empty string as the default Result error message so this doesn't happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see now. In that case #ok?
returns false
but #error
is an empty string. As we don't pass a specific error message flash[:error]
shows a generic The payment could not be completed
. This is exactly what I reproduced on https://github.com/openfoodfoundation/openfoodnetwork/pull/7571/files#diff-0a685f6019d68e59a8758de19d720e12dbc646b712de620e7f066226e181417fR162.
I left this open for further improvement. If we need to in the future, we can extract a custom validation class and be more specific. For the purpose of this bugfix it felt too much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks excellent, thanks @sauloperez. The change that Matt mentions will be nice, as well as moving to a specific controller method. But that can come later 👍.
@@ -3,39 +3,72 @@ | |||
# When directing a customer to Stripe to authorize the payment, we specify a | |||
# redirect_url that Stripe should return them to. When checking out, it's | |||
# /checkout; for admin payments and subscription payemnts it's the order url. | |||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is crucial 😂 #OCD
Hey @sauloperez , This looks good now. Did a brief sanity check, to see if authenticating the payment still leads to a complete and paid order: Looks good 👍 After that, I reproduced the scenario leading to the bug, and now (as on the video above) it leads to the expected scenario:
If we do this the other way around - fail payment, then place a new sub with a valid payment - we get the flash message, but this is rather a previously observed "memory effect" on flash messages... It looks weird, but it's actually a separated issue: So, in summary, this is good to go 💪 The followup issues required (on my to-do list) are:
|
That is concerning 🤔 I think it deserves to be s3 because it's really misleading for the user. |
We had a similar issue in the past around checkout flash messages: https://github.com/openfoodfoundation/openfoodnetwork/pull/5906/files |
What? Why?
Closes #7509. This validates payment intents against Stripe and displays all the possible errors to the user.
This is how it looks:
What should we test?
The exact scenario described in #7509.
Release notes
Fix Stripe's unauthorized payments not reflected in the order and show any possible error with the payment to the user.
Changelog Category: User facing changes