Spike: Revisiting test mode badges on shortcode checkout

[FangedParakeet]

Description

Recently we added a new dynamic test mode badge to WooPayments payment gateways on both shortcode and blocks checkouts. Unfortunately, this implementation overrode the get_title() function of each relevant payment gateway, which had many unfortunate side-effects and even blocked the checkout from being completed for a subset of users using particular incompatible extensions. These changes were reverted from the shortcode checkout in #9800.

We would like to return to resurrect this reverted functionality, but via a less intrusive implementation. We want to avoid overwriting the get_title(), since this function is relied upon in more places than simply the checkout where we intend this badge to be present, such as the errors produced in #9779. This will likely need to be a purely client-side, but the assignee is welcome to explore any other viable approaches. If there are multiple approaches, they can be compared in this issue prior to embarking on a full-fledged implementation.

Edit: converting this issue into a spike, since there are multiple available approaches and we should discuss these approaches with the core WC team before deciding upon an optimal path.

Here are the available options that we discussed together:

• Client-side implementation to add badge to DOM.
• Creating alternative get_title() function specifically for checkout DOM in WC core.
• Adding filter into get_title() to allow extensions to alter output.
  • This could run into similar problems as in Completed order email has incorrect payment method title #9779, since we would still need to ensure the filter only functioned on checkout.
• Adding new filter into checkout template outside of get_title() function to add to DOM.
• Overriding core WC checkout template with specific WooPayments checkout template. (Author's note: this is probably a bad idea due to compatibility issues, just including for completeness.)

Acceptance criteria

• Test mode badge should present on relevant gateways on shortcode, pay for order, and add payment method pages (see Add: Test Mode badge to Classic Checkout, Pay for Order, and Add Payment Method #9495).
• Test mode badge should not be present on change payment method form (see Omit Test Mode badge in the Change payment method form #9615).
• Test mode badge should only appear on selected payment gateways (see update: payment method test mode label behavior #9647).

Dev notes

Note that these changes were reverted in #9800, which in turn reverted the following PRs, whose functionality should all be returned.

• Add: Test Mode badge to Classic Checkout, Pay for Order, and Add Payment Method #9495
• Omit Test Mode badge in the Change payment method form #9615
• fix: payment method icon alt text #9648
• update: payment method test mode label behavior #9647
• feat: add filter to override rich payment method label #9783

Additional context

• Would be beneficial to ensure Completed order email has incorrect payment method title #9779 does not raise its head again in testing this solution.
• Possibly beneficial to ensure Improve BNPL PMME and icon placement in shortcode checkout #9817 has been implemented prior to completing the implementation here to ensure that we don't cause alignment collisions in changes to the same element of the code.

[brettshumaker]

Hey @Automattic/heisenberg - I’ve looked over this quite a bit this week and have pared this down to two possible solutions. I cut out any option listed above that relied on some sort of filter on the get_title() method for the payment method. Unfortunately, I don’t see a good way to go that route and avoid the problems that caused the revert to begin with. These options are in my preferred order, though that’s up for debate (and the purpose of this comment). Note that option 2 below will require buy in from the core WC team, but I don’t think it’s a bad longer-term solution to what we’re trying to do here.

Happy to chime in on the discussion when I'm back from afk on the 7th, but feel free to discuss without me until then.

Option 1: Pure client-side implementation

• This is the quickest to implement, simplest, and maybe least-likely to have negative side effects with 3rd party plugins option as we’re simply looking for a specific DOM element and then injecting HTML to it.
  • Pros
    • We’re no longer filtering any data coming from WC that other plugins may be relying on.
    • We add the JS and can control when it applies.
    • Won’t apply to emails
    • Doesn’t require a merchant to update WC core or themes.
  • Cons
    • Still might run into issues being able to find the correct target HTML on all themes.
    • Feels less “approved” and more “hacky.”

Option 2: Add new hook to the payment method template in WC core.

• Ideally, this would live in templates/checkout/payment-method.php and sit between $gateway->get_title(); and $gateway->get_icon(). I suppose it doesn’t even have to be a hook - it could just be a new method on gateways like $gateway->get_label_extra but with a better name. Then we’d be able to add that method to our gateways and add anything we wanted there without messing with filters and potentially running into conflicts with 3pd plugins.
  • Pros
    • It’s an “approved” way to add extra data/content to the payment method label in core.
    • No possibility of 3rd party plugins interacting with our gateway’s output.
  • Cons
    • Requires an update to the core WC template.
    • Requires a merchant to update WC to get the feature.
    • If a theme overrides that template, it requires the theme to make the update to the template, which requires the merchant to update their theme.

[FangedParakeet]

Cheers for the excellent exploration here, @brettshumaker! 🙌

So it appears we have a short-term client-side option available, which we estimate at around a sprint's worth of effort; and then a more comprehensive longer-term solution developed in WC Core that might require some additional buy-in and collaboration with the core checkout team. @pierorocca, would you mind dearly if I were to pick your brains to try to prioritise the optimal pathway to proceed here?

First of all, it must be stated that this issue of test mode badges is already solved in blocks checkouts, so any effort expended here will only apply to the shortcode checkout. Would maintaining parity between our blocks and shortcodes offerings motivate us to implement a short-term solution or conversely might we be less eager to resolve this issue in the shortcode checkout, since withholding it adds value to the blocks product?

With regards to our longer-term solution on core, the biggest vulnerability of this solution is that it is dependent on the WC core checkout template. Store owners would need to update WooCommerce on their site in order to encounter the test mode badges provided by our plugin and if stores use themes that override the core checkout template, then our changes would also not be visible. Would either of these hurdles be insurmountable blockers for this approach? In that case, the client-side solution may be the only option available to us.

Essentially, we're trying to understand the general priority of restoring this feature on the shortcode checkout and how problematic some of the concerns around resolving this issue in core might be. 🙏

[pierorocca]

The ROI on this now appears to be quite low. Does this also impact the ability to dispaly the brand icons? If not what are the alternatives such as moving the badging out of the radio button? Thanks for the full context and sizing @FangedParakeet.

[FangedParakeet]

Does this also impact the ability to dispaly the brand icons?

Is that the problem we are solving in #9826? AFAIA, that is unrelated to the effort required here and this issue is not a blocker for that feature.

If not what are the alternatives such as moving the badging out of the radio button?

It's worth noting that in the existing blocks implementation, the test mode badge only appears when the relevant payment gateway is selected. Consequently, I think adding the test mode badge somewhere in the below area, in the payment gateway body on shortcode, would be a relatively lightweight lift--especially, if we decided to add the badge before the testing instructions; placing the badge alongside the payment information fields presented by Stripe might be less feasible.

If we just wanted to enhance the testing instructions with the test mode badge for the shortcode checkout, I would expect this to be a 1-2 story point effort. Though, I'll defer to @brettshumaker in case there are other available alternatives. Option 1, described in #9819 (comment), might be a slightly larger effort, but not too serious of a task; though, this does come with a few caveats of maintainability and potentially compatibility that @brettshumaker has described.

[pierorocca]

Is that the problem we are solving in #9826? AFAIA, that is unrelated to the effort required here and this issue is not a blocker for that feature.

Correct.

It's worth noting that in the existing blocks implementation, the test mode badge only appears when the relevant payment gateway is selected. Consequently, I think adding the test mode badge somewhere in the below area, in the payment gateway body on shortcode, would be a relatively lightweight lift--especially, if we decided to add the badge before the testing instructions; placing the badge alongside the payment information fields presented by Stripe might be less feasible.

That's probably our best best. What does it look like with the badge inline with "Use test card" and on other payment methods on the first row, left aligned?

[pierorocca]

Alternatively would something like this work on Shortcode checkout sites only @elizaan36?

[pierorocca]

It's a bit tight extending that to other payment methods without moving content down a bit