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
feat: error message on 1M+ amount #8793
Conversation
Test the buildOption 1. Jetpack Beta
Option 2. Jurassic Ninja - available for logged-in A12s🚀 Launch a JN site with this branch 🚀 ℹ️ Install this Tampermonkey script to get more options. Build info:
Note: the build is updated when a new commit is pushed to this PR. |
Size Change: +317 B (0%) Total Size: 1.25 MB
ℹ️ View Unchanged
|
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 is working as expected for me and the changes look fine.
I wasn't able to remove the "save payment method" checkbox on blocks checkout
I guess, AFAICT, it appears that this option is set when we register the payment gateway and presumably cannot be updated later. Stripe will only inform us of the error after this fact, so I guess we're stuck here.
You might notice there is a console error related to Stripe fingerprinting, but I wasn't able to resolve it 😬
I spent a little time investigating this as well...and was unsurprisingly unable to come up with any more answers than you have. This error does appear to originate from within Stripe's own iframe, so perhaps this is just some error case that they are failing to handle adequately on their end. So it goes.
I did notice this error appearing on the blocks checkout.
I thought this was particularly peculiar, because it seemed to originate from the paymentRequestPaymentMethod
object, which is part of our payment request button implementation. The error message is unsurprisingly unhelpful, but I noticed that this error still appeared even when I disabled the express checkout methods from my store's payments' settings.
It looks like we are registering the payment request button, unless I'm mistaken, in all cases, so perhaps there needs to be additional error handling here--with no fault being given to the changes here nor any onus on resolving this within the current PR.
I did notice one more thing that did give me a little further pause for thought. In both our blocks and shortcode checkouts, when the payment error returns an error and is unusable, the "Place order" button is still selectable.
On the blocks checkout, if we select the "Place order" button, we are returned this error message, which is somewhat meaningful and prevents the checkout from continuing.
Blocks checkout place order error message
However, on the shortcode, we are presented with this lovely "r is undefined" error message instead.
I was wondering whether you had encountered this rather unattractive message or if you had any thoughts about how we might deal with it? Also, did you consider disabling the "Place order" button at all, in case there are no other payment gateways available. I'm not sure if there is a way for a payment gateway to inform WC that the gateway is inoperable, but I'd presume there isn't one.
Interested to hear your thoughts on the above before proceeding. 🙏
Ah, good find! While debugging this, I noticed that the exception is being thrown around here on shortcode checkout. But it's weird that blocks checkout uses the same function, but a different error is thrown 🙄 I'll continue looking into this, thanks for pointing it out! 👍 |
@FangedParakeet in 5f15aa6 I made a change to align the implementation with the blocks checkout a bit more - on the blocks checkout we rely on the Now the two implementations should be a little bit more aligned. |
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.
Nice one! Tested on blocks and shortcode, plus a few checkouts with new and saved information just to be safe, and this is working mostly as expected for me. I just want to raise two small peculiarities that I noticed along the way.
Firstly, on my hideous dark-mode test-site, I noticed that the warning was sadly illegible. This isn't necessarily the fault of this PR and I'm not sure if there's much in our power to improve this, so don't think it's a big deal.
Also, I noticed on the shortcode checkout, if I tried to place an order with the payment element prevented from working, the error at the top of the page appeared as expected, but the warning on the payment element disappeared, leaving the gateway empty. On the block checkout, both warnings persisted.
This also isn't really a big deal, because the goal is to prevent the checkout and to show a warning--and one warning is better than none.
Anyways, I don't think either of these problems are showstoppers, so let's keep the train rolling.
upeElement.on( 'change', ( e ) => { | ||
gatewayUPEComponents[ paymentMethodType ].isPaymentInformationComplete = | ||
e.complete; | ||
} ); | ||
upeElement.on( 'loaderror', ( e ) => { |
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.
upeElement.on( 'change', ( e ) => { | |
gatewayUPEComponents[ paymentMethodType ].isPaymentInformationComplete = | |
e.complete; | |
} ); | |
upeElement.on( 'loaderror', ( e ) => { | |
upeElement.on( 'change', ( event ) => { | |
gatewayUPEComponents[ paymentMethodType ].isPaymentInformationComplete = | |
event.complete; | |
} ); | |
upeElement.on( 'loaderror', ( event ) => { |
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.
Unfortunately, event
is already defined a few lines above, so I can't name this the same :(
Do you happen to know if the other WC frontend notices that appear on your site also have insufficient color contrast? |
I tested this a bit today and have these observations:
|
I did some more testing and found another quirk: saved cards can still be used for orders exceeding the maximum amount, but errors aren't always shown. On my self-hosted site, using a saved payment via the Checkout Block produces a However, on my Atomic site, using a saved payment via the Checkout Block produces a |
Hey @csmcneill , thanks for testing! 👋 |
@frosso That's it! I was testing the latest Nightly build on my self-hosted site. I forgot to revert back to WooCommerce 8.9.x before testing this :) |
Fixes #7485
Changes proposed in this Pull Request
Adds an error notice when the amount exceeds 1M in the settlement currency (EUR, USD, etc.).
Testing instructions
Blocks checkout with SEPA/Card
Shortcode checkout with TT4 theme & SEPA
Shortcode checkout with Storefront theme & SEPA/Card
npm run changelog
to add a changelog file, choosepatch
to leave it empty if the change is not significant. You can add multiple changelog files in one PR by running this command a few times.Post merge