Detect custom fields and disclose when they may cause conflicts with express checkout methods

[FangedParakeet]

Description

It appears that custom fields are currently incompatible with express checkout methods. For example, this is explicitly stated in Apple Pay's documentation.

Collect necessary information, like color and size options, before people reach the Apple Pay button. When additional information is needed at checkout time — perhaps because the customer forgot to choose an option — gracefully point out the problem and help them correct it. Use highlighting or warning text to identify missing information, and automatically navigate to the problematic field so people can correct it quickly and complete their purchase.

Collect optional information before checkout begins. There’s no way to input optional data — like gift messages or delivery instructions — on the payment sheet, so collect this information ahead of time or even after the purchase is complete.

It would be great if we could detect when this scenario may be present and be able to warn store owners that one of their plugins responsible for adding these custom fields may cause conflicts with the express checkout methods that they present at checkout. It appears that the detection of these custom fields should be feasible from our perspective (see pb22l9-2s6-p2#comment-2665 and paJDYF-ckK-p2#comment-23071).

This issue is to explore a valid way to provide this warning to store owners and to implement a solution that offers this information in an acceptable manner.

Acceptance criteria

1. Confirm that detecting when custom fields are added to checkout is feasible.
2. Collaborate with design and product owners to devise appropriate feedback to store owners.
3. Implement a solution following the above discussions.

Update: steps 1 & 2 have both been completed within this issue. Please read #8299 (comment) for more up to date acceptance criteria on step 3.

Designs

Soon.

Testing instructions

N/A

Dev notes

Additional context

#5018
#6539
paJDYF-ckK-p2
paJDYF-ckK-p2#comment-23071
pb22l9-2s6-p2#comment-2665

CC @pierorocca and @nikkivias, to help us to decide the right format to provide this feedback to store owners.

[pierorocca]

Thanks @FangedParakeet!

A hard dependency, prior to providing merchant guidance, is getting the express checkout payment methods, WooPay included, into the payments method list on checkout so that the info can be collected prior.

1. In the current settings design, we'd update the PRB settings pages adding another checkbox to allow enablement of the EC in the payments method list.

2. Similar to how we message a known WooPay incompatibility, we'd show an inline notification underneath the payment method. We'd tailor the message to indicate that custom fields are incompatible with Google Pay and Apple Pay and recommend that they disable the EC buttons and enable it as a payments method.

3. And again in the customization page.

How does that sound to you all?

[FangedParakeet]

A hard dependency, prior to providing merchant guidance, is getting the express checkout payment methods, WooPay included, into the payments method list on checkout so that the info can be collected prior.

Definitely: this will be explored in #8297 (see Q.5 in the acceptance criteria) and will hopefully be included as something supported by our express checkout element implementation.

How does that sound to you all?

Those three bullet-points sound beautiful to me. Exactly what I was looking for--cheers, @pierorocca! 🙌

[FangedParakeet]

Hey team! Please add your planning poker estimate with Zenhub @gpressutto5 @FangedParakeet

[gpressutto5]

I'm working on detecting custom fields. The suggested variable wc.wcSettings.allSettings.defaultFields does not exist.

The notice will look like this. I used the same message as WooPay, so it can be reused for other incompatible extensions, e.g., WooCommerce Deposits.

The Learn More link points to https://woo.com/document/woopayments/payment-methods/#express-checkout-methods but we still need to add the compatibility section to the docs like the one from WooPay.

Do you think this is good or do we need a specific warning for custom fields?

[pierorocca]

Thanks @gpressutto5. The compatibility messaging is misleading for the duplicates scenario and could lead to the merchant disabling WooPayments payment methods. In fact, that's the most likely scenario with WooPay. It's designed so that they disable WooPay because of the incompatibility.

What do you think about "One or more of your extensions are enabled with a duplicate payment method. Learn more."

WooPay will never be duplicated so we don't need to worry about a scenario where there will be two notices at the same time AFAIK.

[pierorocca]

@csmcneill what are your thoughts on a new section in the WooPayments merchant docs for duplicate payment method detection? If you're onboard with the idea, could you provide a placeholder url please?

[gpressutto5]

@pierorocca In this issue, we are working only on the custom checkout fields notice. It doesn't affect the WooPay component and is only displayed next to the Apple Pay and Google Pay settings.

An update on detecting the custom fields: I couldn't find a way to detect additional custom fields, but I found a way to detect if any extension is changing anything in the fields. For example, just having CFE installed will trigger this validation, not requiring any change to the checkout lists. I've done this by calling the filters woocommerce_billing_fields, woocommerce_shipping_fields, and woocommerce_checkout_fields with empty arrays and then checking if they are still empty. I'm still testing this method, but it is proving reliable.

[csmcneill]

@pierorocca I'm going to hold off on creating docs because it depends on the implementation. Duplicate payment method detection could be its own page or it could be slotted into an existing page; some of that will depend on how we proceed with this issue and the topic brought up in paJDYF-ck0-p2. I won't know until I can get my hands on a PR.

FWIW, each express checkout method has its own separate compatibility information:

• https://woo.com/document/woopayments/payment-methods/apple-pay/#product-compatibility
• https://woo.com/document/woopayments/payment-methods/google-pay/#product-compatibility
• https://woo.com/document/woopay-merchant-documentation/#incompatible-extensions
• https://woo.com/document/woopayments/payment-methods/link-by-stripe/#compatibility

[pierorocca]

Oh geez, I've totally mixed this up with the duplicate detection not the custom field detection. My bad. I retract my comment above.

[pierorocca]

An update on detecting the custom fields: I couldn't find a way to detect additional custom fields, but I found a way to detect if any extension is changing anything in the fields

@gpressutto5 besides the Custom Field Editor, is there a way for merchants to add custom fields to checkout?

1. Revised wording so that it doesn't seem like all Express Checkouts are incompatible:
   "One or more of your extensions that adds a custom field to checkout is incompatible with this payment method." (may change depending on answer to 2.)

2. @FangedParakeet we had also discussed allowing the merchant remove the button from the Express Checkout component, cart and product pages and instead place the payment method in the payment methods list, after the custom field, in order to achieve compatibility. If that's true and the merchant does disable the button and does instead include it in the payments method list, would this warning still show?

[FangedParakeet]

we had also discussed allowing the merchant remove the button from the Express Checkout component, cart and product pages and instead place the payment method in the payment methods list, after the custom field, in order to achieve compatibility. If that's true and the merchant does disable the button and does instead include it in the payments method list, would this warning still show?

I think in this scenario, where the express checkout buttons essentially function as regular checkout payment methods, would probably allow these methods to be compatible with custom fields and would probably invalidate this warning at checkout. However, we still need to explore how this implementation could work and how this option would be presented in settings as well. Store owners would need to be made aware that even with this implementation, the express checkout methods would only be compatible at checkout and not on the product or cart pages.

I think I would like to delay this investigation until after the express checkout element in #8297 has been solved, so that we can ensure that any improvements in this area are as future-proofed as possible.

[pierorocca]

That sequencing @FangedParakeet makes sense. Great idea.

[gpressutto5]

What about this message?

One or more of your extensions alters the checkout fields. This might cause issues with Express Checkout methods.
Learn more (We need to update the docs with more information on this or remove this Learn more link)

[gpressutto5]

besides the Custom Field Editor, is there a way for merchants to add custom fields to checkout?

It is not possible to add custom fields without coding. An extension specifically created for that is not necessary, as a snippet could do it, but it still requires intended code changes or an extension to add snippets.

[pierorocca]

One or more of your extensions alters the checkout fields. This might cause issues with Express Checkout methods.
Learn more (We need to update the docs with more information on this or remove this Learn more link)

Thanks for asking the question Guilherme. Let me step back and make sure I'm understanding the detection mechanism and which express checkout methods are impacted.

An update on detecting the custom fields: I couldn't find a way to detect additional custom fields, but I found a way to detect if any extension is changing anything in the fields.

1. If I understand this statement correctly, we can only detect alterations to existing fields and cannot detect new checkout fields? What qualifies as an alteration? Reordering, which CFE enables, but not changing the field attributes would that qualify?

2. When we say "Express Checkout methods" do we mean only Apple and Google Pay or all methods including WooPay and Link?

3. If CFE is installed and a new custom field is added to checkout, would the notice display?

4. Do we have a sense which is a more common failure, altering existing fields or adding new fields? Asking in case we need to think about an incompatibility warning in general for CFE.

[gpressutto5]

1. Anything that uses one of those filters to add or change a field is detected. We currently can't detect which fields were added/updated. We can only detect that the list of checkout fields was changed.
2. In this issue, we're introducing a notice specifically for Apple Pay / Google Pay. This notice, as shown in the picture above, is strategically placed adjacent to these payment options. It serves to warn users about potential incompatibility issues. WooPay uses a different component for this purpose, and Stripe Link doesn't have a component like this yet, as we have not found any incompatible extension.
3. Yes, any change to the existing fields or the addition of new ones would trigger this warning. It doesn't mean it would make it incompatible, but we can't check if the changes are compatible, so we display a warning.
4. Changing checkout fields only breaks Apple Pay and Google Pay because they skip the checkout page. This could be caused by a new required field, an updated validation rule, new custom logic added depending on a field that was renamed, etc. If the merchant makes minor changes, it would not break Express Checkout.

[pierorocca]

1. Got it thanks. That would be sufficient to trigger the notice. Nice.
2. Gotcha. As "Express Checkouts" is the Group category name on the left, to avoid confusion and to keep it generic does "One or more of your extensions alters checkout fields. This might cause issues with this payment method." work?

[gpressutto5]

It looks great!

[pierorocca]

Nice work!!

[csmcneill]

@gpressutto5 How would you like to link to documentation here?

Since incompatibilities are listed on separate pages for Google Pay and Apple Pay, one option would be to move the information from https://woo.com/document/woopayments/payment-methods/google-pay/#product-compatibility and https://woo.com/document/woopayments/payment-methods/apple-pay/#product-compatibility onto a separate, standalone page.

[gpressutto5]

@csmcneill The text in their incompatibility section is the same, which makes sense as they use the same logic and components. If we have a page dedicated to both these methods, it would be the perfect page to put this information, but the Express checkout methods page is also connected to WooPay and Stripe Link, so it would be confusing.
Having two links in the notice would not look great either.

I think creating a new page just for compatibility information for Google Pay / Apple Pay is the best solution.

[csmcneill]

I think creating a new page just for compatibility information for Google Pay / Apple Pay is the best solution.

Perfect, thank you! I've created https://woo.com/document/woopayments/payment-methods/apple-pay-and-google-pay-compatibility/ that contains compatibility information specifically for Apple Pay and Google Pay.

[csmcneill]

@gpressutto5 Quick edit: I added an anchored heading specifically citing the incompatibility with checkout field editor in case you want to use that instead: https://woo.com/document/woopayments/payment-methods/apple-pay-and-google-pay-compatibility/#faq-extra-fields-on-checkout

[FangedParakeet]

We are temporarily disabling and removing this feature in #9329 due to #8752 and the false positives caused by our implementation in #8339.

Consequently, I am reopening this issue to maintain the history of the discussion within this issue along with all of the accompanying design considerations made along the way. After discussing this issue internally, we have arrived at the conclusion that a client-side detection mechanism would provide more accurate results, while being less intrusive and less likely to cause similar issues as described in #8752.

This change of direction still leaves sufficient room for interpretation for whomesoever will pick up the work on this issue. Considering this, here are a few more pieces of acceptance criteria that would be valuable to include in a future solution.

• We should not access checkout or custom field filters from contexts other than those from which they are originally defined within.
• We should only display a warning in settings when we have reasonably high confidence that the custom fields included will short-circuit our express checkout button functionality (e.g. specific mandatory fields have been added/removed or we have detected actual errors from the EPM buttons).
• If we can indicate which extension has introduced the offending custom fields, that would also be desirable.

Note that there are modals and acceptable UI functionality developed in #8339 and reverted in #9329 that could and, if possible, should be reused in a future implementation.