WooPay Checkout appearance UI refactor

[pierorocca]

Problem: Shoppers can bypass standard checkout and use the WooPay hosted checkout for purchases. Doing so may bypass the store's privacy policy and terms of service which are added to shortcode and blocks checkout automatically. This puts merchants at legal and regulatory risk.

Outcome: As a merchant, I want my shortcode or blocks terms and privacy policy strings to be pulled into the WooPay checkout UI automatically, so that I meet my legal requirements and so that I don't have to set it separately from standard checkout.

If it's not possible to pull in the strings automatically and to display the TOS acceptance checkbox, upgrading the custom message text field to a wysiwyg editor would be a viable backup.

Additionally as an enhancement, we will replace the preview image asset with a real image of checkout over which the logo preview will display.

cc @elizaan36

[frosso]

I believe the initial intent of the "Custom message" field was to allow merchants to manually enter links to their internal pages (although it isn't too user friendly at the time - it's also too short). Should we maybe make the current field into a textarea, pre-populated with some links, which also allows the merchant to add/edit information/links?

[elizaan36]

Hey @stephendharmadi, Could you take a look at this one? In the WooPay settings there should be a summary text field showing the existing Terms/Privacy policy copy with the ability for merchant to edit as needed.

@frosso How do links appear in that text field now? It's not a full text editor where you can add links, is it? I'm wondering if merchants would be required to use markdown.

In terms of the shopper experience, it appears like this as a default on the block based checkout, and WooPay checkout will need to display this copy as well.

Also, could you provide a recommendation on how to improve the preview display? Currently it looks a bit confusing as to what you're looking at. :)

[pierorocca]

I included below a few useful screenshots of where merchants (and core) set the ToS and privacy policy that show up on Checkout. Ideally WooPay pulls in what the merchant has setup for Checkout automatically. For other custom text, I suggest that becomes part of the broader discussion about custom field support. This way WooPay is kept as a tightly integrated extension of Checkout rather than as a standalone application.

[frosso]

How do links appear in that text field now? It's not a full text editor where you can add links, is it? I'm wondering if merchants would be required to use markdown.

Merchants would have to insert markup by hand in order to add links, but they would be limited by the current 100 characters limit :/ we could expand the field to a textarea, tho, in order to make it easier for merchants to add more text (alluding at what @pierorocca added to the description - "upgrading the custom message text field to a wysiwyg editor would be a viable backup").

Ideally WooPay pulls in what the merchant has setup for Checkout automatically

@pierorocca @elizaan36 as you both have noticed, the settings for the terms and conditions + privacy policy displayed at checkout can be set either in:

• in the case of shortcode checkout: the WC settings + theme settings
• in the case of blocks checkout: through the block editor (which is not an individual "setting" like in the shortcode checkout case - the T&C text is an integral part of the editable page's content)

From the code perspective, we won't be able to know if the merchant's default "checkout" page uses the shortcode checkout flavor or the blocks checkout flavor - we would need to manually parse the checkout page's content to determine which checkout flavor is being used. Needless to say, this parsing could take precious time to be executed on the merchant's site. Moreover, with the blocks checkout, we would still need to parse the checkout page's content to get the text from the "T&C" inner block content.

If we could leverage the existing "Custom message" field by expanding its size and add an editor to it, we could significantly speed up the turnaround time on this issue without affecting the checkout performance as much 😬 The downside is that the merchant would have another setting for tweaking the checkout (which goes against this statement: "This way WooPay is kept as a tightly integrated extension of Checkout rather than as a standalone application."). But maybe we could help the merchant by using a sensible default field value.

In short - it's fine to pull the text from the shortcode checkout, but the blocks checkout requires a bit more work. And, given that a site could have either checkout flavor, the complexity of the solution would slow down the checkout experience for the shopper.

[stephendharmadi]

Hi, I have read all the comments. How if we could automatically duplicate (one-time) the existing terms and conditions + privacy policy (from either shortcode checkout or the blocks checkout) into the WooPay settings with the additional fields of "privacy policy" and "Terms and conditions." By doing that, we won't require merchants to input it again manually (although they still need to maintain both settings afterwards).

In my opinion, It's more important not to slow down the checkout experience for shoppers. Also, considering terms and conditions + privacy policies are not something that merchants will update frequently.

[pierorocca]

Is this a major downside of Blocks in that certain data is only accessible via the block? If yes is it worth raising this limitation to the blocks team?

Feels like merchant tos and privacy policy relative to shortcode was tacked on as text rather than as an important data element.

If we can't access attributes of the site and checkout like global styles, logo, policy/tos, custom fields and not just customer order data, and in a performant way, WooPay will struggle to be a tightly integrated solution. I know Emma was working with Rubik on custom text fields and how we could access that data. May be worth connecting with her in case there's an alternative?

[frosso]

How if we could automatically duplicate (one-time) the existing terms and conditions + privacy policy (from either shortcode checkout or the blocks checkout) into the WooPay settings with the additional fields of "privacy policy" and "Terms and conditions." By doing that, we won't require merchants to input it again manually (although they still need to maintain both settings afterwards).

We could definitely work out something like this 👍

Is this a major downside of Blocks in that certain data is only accessible via the block? If yes is it worth raising this limitation to the blocks team? Feels like merchant tos and privacy policy relative to shortcode was tacked on as text rather than as an important data element.

I'm not sure if it's a limitation, it might be by design. Regardless, I reached out here to see what's available :) p1688648673160969-slack-C02UBB1EPEF

[pierorocca]

(although they still need to maintain both settings afterwards).

If we sync once, could we sync again on a change?

I'm not sure if it's a limitation, it might be by design. Regardless, I reached out here to see what's available :) p1688648673160969-slack-C02UBB1EPEF

Thanks for that. I think it's worth putting this use case on the platform team's radar in the interest of furthering discussion about extensibility and interoperability even if it not resolvable at this time.

[frosso]

If we sync once, could we sync again on a change?

We could, maybe with a button to manually copy the content from the page. Keep in mind that we're adding scope/time to implementing the solution.

Could we implement the solution gradually, keeping in mind GA timing? Example:

1. Extend the current field to a WYSIWYG editor/shortcode editor (or create a new field) to allow the merchant to manually enter T&C (in the meantime, we'd pre-populate the field's copy for the merchant with a "pre-defined"/"default" message like: "By proceeding with your purchase you agree to our [Terms & Conditions] and [Privacy Policy]" (in a similar fashion to what Blocks checkout is rendering))
2. Add a mechanism that copies the T&C text from either blocks/shortcode checkout
3. Find a way to keep the copy in sync with less involvement from the merchant (e.g.: the merchant could toggle between using their text from the blocks checkout or they could customize the text entirely)

[pierorocca]

1 and 2 work for GA. Thanks @frosso. 3 is going to be a longer term and critical discussion with the platform team and architecture on how we can be tightly integrated. Goal is to have merchants manage checkout config in only one place vs. multiple places with completely different UI/UX.

[pierorocca]

For the record adding my comment to the Blocks team in which I make the case that the approach to not persist the data in the database unlike what is done for shortcode is problematic and adds to UI/UX fragmentation. p1689292152587309/1688648673.160969-slack-C02UBB1EPEF

[pierorocca]

pre-populate the field's copy for the merchant with a "pre-defined"/"default"

As most sites are shortcode, I highly recommend that we pull in the tos and policy strings from the site wp_options table at the time Woopay is enabled. That way for existing merchants, the copy and links will match 1:1.

[frosso]

We'll move forward as follows:

• "Custom text" pulls in the text from woocommerce_checkout_privacy_policy_text and woocommerce_checkout_terms_and_conditions_checkbox_text by default, concatenating them
• "Custom message" is renamed to "Checkout Privacy Policy and Terms and Conditions" (or "Checkout Privacy Policy and T&Cs" if too long)
• If the merchant wants to override the "custom message" value, they can enter some new text in there

@elizaan36 do you think we should convert the current "custom message" field to a textarea without a character limit? Do you have suggestions for the help text copy?

This is part of a short-term solution to consolidate the settings/experience for the merchant, before the refactoring of the whole "Checkout appearance" section.

[pierorocca]

Thanks for the working session today @frosso. @elizaan36 longer terms ideally the WooPay settings page is refactored so that:

1. The preview is replaced with a true visual representation of WooPay checkout
2. The site_logo is pulled in automatically, is displayed on the new preview, and there's an option to override the site default by uploading a new image. If the custom image is cleared, we revert back to the site logo.
3. The site legal T&Cs and privacy policy strings are pulled in automatically into WooPay, is displayed on the new preview, and there's an option to override the site default setting. If the override is cleared, WooPay reverts back to the site/std. checkout settings.

The idea is that WooPay is tightly integrated with the platform and by default, WooPay matches the site's and standard checkout's settings. If the merchant does nothing, WooPay will be in synch with the site and we've provided an easy and effortless setup experience. For flexibility, we allow an option to override the site's settings.

[aheckler]

Noting here that this will need a (minor) docs update once it's done.

[stephendharmadi]

Hey, thanks for the suggestions.

The preview is replaced with a true visual representation of the WooPay checkout

Why do we need to display a true visual representation of WooPay checkout on settings? Do we intend to display how the checkout T&Cs and privacy policy strings? The visual representation might be too small to display a text preview, so I would suggest adding the link to redirect them to the appearance view of WooPay Checkout.

The site_logo is pulled in automatically, is displayed on the new preview, and there's an option to override the site default by uploading a new image. If the custom image is cleared, we revert back to the site logo.

Sorry my test admin has an issue now so I can't check the current experience. I believe it was the current experience, no? I would think it makes a lot of sense to pull the site_logo by default.

The site legal T&Cs and privacy policy strings are pulled in automatically into WooPay, is displayed on the new preview, and there's an option to override the site default setting. If the override is cleared, WooPay reverts back to the site/std. checkout settings.

By default when it's empty, the override text field will display the site checkout privacy policy as a greyed-out placeholder. We shouldn't add another CTA "Override" and keep the single "Save" CTA. If it's cleared and "Save changes" then we revert it back to the site one. We can communicate this to merchants in the help text copy (draft below).

By default, display the site privacy policy on (WooCommerce > Account & Privacy). Optionally override the text about your store privacy policy to show during WooPay checkout.

@elizaan36 do you think we should convert the current "custom message" field to a textarea without a character limit? Do you have suggestions for the help text copy?

Yes, we should follow the existing site settings without a character limit. Here's the updated mockup, I need advice on the help text copy @pierorocca @elizaan36 @aheckler

[pierorocca]

Why do we need to display a true visual representation of WooPay checkout on settings? Do we intend to display how the checkout T&Cs and privacy policy strings? The visual representation might be too small to display a text preview, so I would suggest adding the link to redirect them to the appearance view of WooPay Checkout.

It was feedback from a recent user flow review with Kelly, Elizabeth, Bummy and myself. The existing preview was found to look like a crude placeholder and didn't give a good idea what checkout would look like nor where the custom text would show up.

Sorry my test admin has an issue now so I can't check the current experience. I believe it was the current experience, no? I would think it makes a lot of sense to pull the site_logo by default.

No problem. The current experience is that the name of the store is set as the title of the WooPay checkout. The font is a WooPay font, not the store's font and the size is not configurable.

Note a site needs both terms of service and privacy policy in their checkout. Some may add a separate refund policy or link to the refund policy subsection. So we're attempting to pull into two strings though @frosso for some reason the tos is not persisted in wp_options like the privacy policy. What challenges does that present? Could we hide the text in a hover tool tip so the UI has a clean appearance?

Also note we don't have a way to link out to a preview and I don't find that to be an efficient or user friendly approach to split the two different previews. I know there's a space limitation, let's see if we can make it work.

[aheckler]

I need advice on the help text copy

I might take out the parentheses though and bold the menu items/path, and then adjust some of the wording. My version:

By default, this will display the privacy policy from WooCommerce > Settings > Account & Privacy. You can override that by entering some custom text in the box above.

[stephendharmadi]

Thanks for the copy suggestions @aheckler , I really appreciate it! Copy has been updated in the design.

It was feedback from a recent user flow review with Kelly, Elizabeth, Bummy and myself. The existing preview was found to look like a crude placeholder and didn't give a good idea what checkout would look like nor where the custom text would show up.

Thanks for letting me know the context. For that matter, I would suggest Option B to improve the existing preview to highlight 2 areas of customization (Logo and Privacy policy). I attached the mockup below and let me know your thoughts. @pierorocca @frosso

You can also try out the prototype here to get a sense of what the experience looks like.

[pierorocca]

Team as you all pick this up again want to get our update on timing. In the interest of time, a phase 1 option could be to simply populate the following with links to the respective pages:

• 'By placing this order, you agree to our [Terms of Service] and understand our [Privacy Policy].'

If that doesn't save that much time then let's stick with the original plan.

LOGO SECTION

1. Section title: I'm proposing to update the section title from 'Store logo on checkout' to 'Checkout logo'

2. Update the copy I'm proposing to update the copy from:

Use a custom logo to WooPay if the one taken from your store doesn’t look right. For best results, upload a high-resolution horizontal image with white or transparent background.

to

'Upload a custom logo. For best results, upload a horizontal image with white or transparent background. HEIC, WEBP, SVG, PNG, or JPG. Recommended width: 512 pixels minimum.'

(above file formats need to be confirmed @frosso @stephendharmadi )

And at some point grab the site_logo file automatically on first enablement. While we currently say it loads the logo, it does not.

CUSTOM MESSAGE SECTION

1. Update the copy: I recommend updating 'By default, this will display the privacy policy from WooCommerce > Settings > Account & Privacy. You can override that by entering some custom text in the box above.'

to:

'Override the default privacy policy and terms of service, or add custom text to WooPay checkout.'

2. Section Title I recommend updating this to 'Policies and custom text'

[frosso]

I'll make sure that smaller issues are created to ensure that there's understanding on what will need to be delivered before GA and what will be delivered after GA.

[frosso]

@pierorocca @bummytime I created the following issues:

To be adjusted prior to code freeze, with high priority:

• https://github.com/Automattic/woocommerce-payments/issues/6993 - inclusion of T&C & Privacy Policy

To be fixed afterwards:

• https://github.com/Automattic/woocommerce-payments/issues/6994 - Add store logo on enablement
• https://github.com/Automattic/woocommerce-payments/issues/6995 - preview UI refactor

[stephendharmadi]

above file formats need to be confirmed

For transparent background, it should be in PNG format. JPG can't achieve that.

For updating the copy, here's the updated mockup. Also, I made a change to remove the header of "back" and "Powered by WooPay" for simplicity.

Figma link here