Display Checkout Field Validation Message for other type of errors too (not only required fields) (947)

[dademaru]

Describe the Bug

Thanks for the improvements to Checkout Field Validation Message (#740 - #513), but it still remains limited to 'required' fields notice.

All other types of errors (e.g. 'phone', 'post code', 'email', … validations) aren't displayed.

So if fields are populated but with invalid data, user will know the real errors only after proceeding with PayPal checkout, filling in PayPal credentials and clicking the pay button.

To Reproduce

Fill in phone or post code fields with invalid data (e.g. 'test').

Expected Behavior

WooCommerce displays fields validation message:

• Billing Postcode / ZIP is not a valid postcode / ZIP.
• Billing Phone is not a valid phone number.

Other custom validation error messages can be added by developers or plugins - e.g. via one of these hooks:

• 'woocommerce_process_checkoutfield*'
• 'woocommerce_checkout_process',
• 'woocommerce_after_checkout_validation'

and are correctly displayed among the other errors.

Actual Behavior

Only required field messages are displayed. All the other error messages are displayed only after PayPal checkout processing.

Possible solutions

If it's not possible to output the WooCommerce error notices as it happens for all the other payment gateways, could it be possible for you to add a hook to let developers adding filters for other validations?

Thanks

[InpsydeNiklas]

Hi @dademaru, the basic validation before clicking the button, as the name suggests, only performs a basic validation task by ensuring that required form fields are not left empty before clicking any smart button. The email address field is validated to contain a valid email format, though. But the zip code field is more complicated because every country has special requirements for the zip code format. This would be possible to improve further, but it's not currently on the roadmap.

In any case, improvements are coming towards the behavior when the buyer returns to the Checkout with an error message. The smart buttons should be automatically hidden at this stage since the payment was already pre-authorized. This would make it more obvious to the buyer how to complete the payment after encountering an error.

[dademaru]

@InpsydeNiklas sorry, having been somehow 'forced' to switch to WC PayPal Payments from WC PayPal Checkout and being used to seeing validation errors before being redirected and prompted to fill in PayPal login details and then redirected back to WC checkout, I thought it was possible and the normal way to proceed.

In general I think it's more proper and better in terms of user experience to be able to process the checkout only if all the fields are valid(ated), without intermediate redirects/other forms (e.g. PayPal login, payment fund/method selection) to be filled in and then being redirected again to the checkout page with errors shown.

There may also be fields that, if properly filled in (and correctly) validated, could change the total (e.g. VAT ID with VAT exemption). So pre-authorizing a total that might differ if the invalid field is later corrected does not seem to me to be the best solution.

If a user is unwilling/unable to provide valid information to complete an order, why does he/she have to enter PayPal information, choose what funds to use, and pre-authorize a payment that he/she will not be able to complete?

– I am not criticizing, I am just sharing my considerations, hoping you can take them into account.

[dademaru]

@InpsydeNiklas I try to demonstrate additional problems caused by this 'basic' checkout error validation.

1. If I try to click the PayPal button with invalid Post Code, Phone and Email, it only marks Phone and Email as errors but only reporting that they are required, not that they are invalid:

---

2. Fixing the email field, it reports the error only for the phone field (still not for the post code field):

---

3. Fixing the phone field as well, clicking the PayPal button redirects/open the PayPal log in page (while on the checkout page, the error notice for the phone remains displayed):

---

4. Once redirected to checkout page it eventually displays the post code field error notice:

Please also note two UX issues:

• now the error notice is displayed below the coupon notice while before it was displayed above
• the invalid field (post code) is not highlighted (red border)

---

5. Then happens the worst bug: if the user fills in other invalid data (e.g. wrong phone, email, or other custom field) it now prevents you checkout while still only showing you the post code error:

---

6. Even if you fix the post code field (but have other invalid fields, e.g. phone) it still displays only the previous error notice (post code):

So the user can't easily understand which is the error to fix and can't checkout.

One of our customers received several calls from users complaining that they could not complete the order even though they had corrected the reported error but it kept reporting it.

---

Possible solution

Instead of trying to validate each type of field through JS, clicking the PayPal button should perform the WC()->checkout()->process_checkout() to allow WC()->checkout()->validate_checkout() & WC()->checkout()->validate_posted_data(). Only if no error is returned then you should initialize the order with PayPal (prompt to login).

Hope this helps. Thanks.

[InpsydeNiklas]

Thanks for the details! The team is looking at further improving the basic validation, while other options to improve the timing of the WC validation behavior are still under investigation. For compatibility reasons, the real WC validation currently has to happen after creating the PayPal order. Performing the WC validation on button click would lead to compatibility problems that are worse compared to what you reported.

now the error notice is displayed below the coupon notice while before it was displayed above

The basic validation displays the errors above the coupon notice while the regular WooCommerce errors are displayed below. This should be aligned in a future update.

the invalid field (post code) is not highlighted (red border)

We have a list of possible improvements for the whole validation flow and this will be checked as well.

I can't reproduce the behavior under 5 & 6, but there are some upcoming improvements that should make a scenario where the user is "stuck" essentially impossible.

[dademaru]

@InpsydeNiklas thanks for returning to this issue.

Concerning points 5 & 6 I only used WC, Storefront theme and your plugin so it should be easily reproducible. Anyway (point 5), once a field validation error (not the required field error) is displayed, so for example the post code error, if other invalid data is subsequently entered in other fields, these errors are not detected and only the first error is always shown:

Then (point 6), even if you fix the invalid field concerned by error message (but have other invalid fields, e.g. phone) it still displays only the previous error notice (post code):

I've reproduced it with WC 7.0, Storefront 4.1.3, PayPal Payments 1.9.4 and still the same errors.

For compatibility reasons, the real WC validation currently has to happen after creating the PayPal order. What do you mean? WC PayPal Checkout plugin seems to work with WC validation before redirecting to PayPal login/process.

I look forward to the upcoming improvements. Thanks

[AlexP11223]

clicking the PayPal button should perform the WC()->checkout()->process_checkout() to allow WC()->checkout()->validate_checkout() & WC()->checkout()->validate_posted_data().

We were doing this before, but it was causing some issues because it supposed to be done at the end of checkout.

942 now attempts to validate without process.

[dademaru]

@AlexP11223 thank you, I'll give it a try as soon as released.

[AlexP11223]

It probably will not be included in the next release (next week), you can try this package if you want.

pcp-817-woocommerce-paypal-payments.zip

[InpsydeNiklas]

The validation behavior was improved over the course of the last few updates. Please get in touch with the support team directly if any validation issues persist for you with the latest update 2.0.1. Thanks!