Fix 3D secure payment errors #3272
Conversation
Aljullu
added
status: needs review
type: bug
|
Size Change: +994 B (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
Aljullu
force-pushed
the
fix/payment-method-validation-duplicate-errors
branch
from
5095d55
to
eca892f
Compare
Ya I see the issue here. The intention behind the design was to always ensure that other things hooked into the event emitters can react to any errors that might have happened (which is why an error from the success emitter will in turn trigger the I do agree we need to try and make things fairly simple for payment methods instead of the approach you've done so far in this pull. For subscribers registered to the events, they should only care about reacting to the events, not having to worry about internals causing duplicate notices etc. I think removing the default error message that is added on |
Aljullu
force-pushed
the
fix/payment-method-validation-duplicate-errors
branch
from
8aadd85
to
26069ef
Compare
Make sense, I needed to create a This PR is ready for review again. |
|
|
|
Ahh, right! I am a bit wary about that if we add other notice contexts to checkout, this won't automatically account for them. Still it might be premature optimization to try and figure that out right now. |
|
As far as I can understand the code it makes sense to me and it works. |
Aljullu
force-pushed
the
fix/payment-method-validation-duplicate-errors
branch
from
63cd93b
to
8be2654
Compare
Fixes #2743.
This PR fixes a couple of issues with 3D secure payment errors:
onCheckoutAfterProcessingSuccess, when an error is created at that stage, it then triggersonCheckoutAfterProcessingErrorevents. If no error was returned fromonCheckoutAfterProcessingErrorevents, we were adding a default one. That's why two errors were appearing: the one generated by the payment method inonCheckoutAfterProcessingSuccessand the default one generated by Blocks inonCheckoutAfterProcessingError.For now, I fixed it in Stripe's side saving the error message internally and returning it ononCheckoutAfterProcessingError(4a5c04e), but I feel that's a bit complicated for payment methods. For example, the same issue occurs in WC Payments so we will need to fix it there too. That makes me wonder if we could make the process easier. Maybe removing the default error message that is added ononCheckoutAfterProcessingError? Another option would be not to triggeronCheckoutAfterProcessingErrorafter an error occurred inonCheckoutAfterProcessingSuccess. Thoughts @nerrad?Update: we decided to add a check before showing the default error notice. So if there is already an error notice, the default one won't be added in
onCheckoutAfterProcessingError.useEffect()dependencies (33280b5).Screenshots
How to test the changes in this Pull Request:
4000 0027 6000 3184(it will open an authentication modal).Now, let's pretend there is a payment gateway which doesn't add an error message when throwing an error. This way, we will ensure a default error notice is shown.
use-payment-intents.js, make the following change:if ( response.type === emitResponse.responseTypes.ERROR && response.retry ) { setSourceId( '0' ); + return { type: response.type, retry: response.retry }; }4000 0027 6000 3184(it will open an authentication modal).Changelog