Making OCS enabled by default for new installs #4811

wjrosa · 2025-11-18T19:44:50Z

Changes proposed in this Pull Request:

As originally envisioned, with this PR, we are making the Optimized Checkout Suite feature enabled by default for all new installations. This is to make sure merchants are using the latest integration recommended by Stripe.

Testing instructions

Checkout and build this branch on a new test environment (update/making-ocs-enabled-by-default-for-new-installs)
Connect your Stripe account
Confirm the Optimized Checkout feature is enabled in settings:

Covered with tests (or have a good reason not to test in description ☝️)
Tested on mobile (or does not apply)

Changelog entry

This Pull Request does not require a changelog entry. (Comment required below)

Changelog Entry Comment

Comment

Post merge

Added testing instructions to the Release Testing Instructions wiki page (or does not apply)
Added the needs docs label (or does not apply)
Included this PR in the Release Thread scope (or does not apply)

…new-installs

daledupreez · 2025-11-19T20:02:57Z

includes/connect/class-wc-stripe-connect.php

 			$options['enabled']                         = 'yes';
 			$options['testmode']                        = $is_test ? 'yes' : 'no';
 			$options['upe_checkout_experience_enabled'] = $this->get_upe_checkout_experience_enabled();
+			$options['optimized_checkout_element']      = $this->get_optimized_checkout_element_default_value();


I will keep thinking about this tomorrow, but it feels like it might be really good to add some unit tests so we can correctly track what is going on here and what edge cases might exist.

I am concerned that we might have edge cases where merchants upgrade, and then reconnect, and we auto-enable Optimized Checkout just because we hadn't saved any data in that sub-option from before that reconnection attempt.

Might it be better to create some code in WC_Stripe::install() and/or hook into the woocommerce_stripe_updated action to set/pick the default value for optimized checkout based on whether there is data in the wc_stripe_version option from before? That way OCS would be default-on for fresh new installs only, whereas we'd leave it off for any other install.

Mayisha

It looks good and is working well as per my testing in JN sites. 👍

New installations
- Directly installed this branch build in a fresh JN site.
- Connected to a test Stripe account.
- OCS is enabled after account connection.
Existing account
- Installed Stripe 10.1.0 in a fresh site.
- Connected to a test Stripe account.
- Changed a few settings keeping OCS disabled.
- Updated the plugin with this branch's build.
- Refreshed settings page -> OCS disabled.
- Reconnected to the Stripe account -> OCS disabled.
- Disconnected the Stripe account, connected again -> OCS disabled.

On the topic of tracking possible edge cases, can we add some logs when we auto enable OCS?

daledupreez

I just confirmed that the current logic will not work as expected for upgrades from versions where Optimized Checkout was not initialised by default, and then the merchant reconnects.

I specifically tested the following:

Install Stripe 9.5.2 on a fresh site
Connect to Stripe
Verify that the optimized_checkout_element sub-option is empty -- wp option pluck woocommerce_stripe_settings optimized_checkout_element
- I also confirm that sync is enabled, but that may not be relevant -- wp option pluck woocommerce_stripe_settings pmc_enabled should show yes
Upgrade to a Stripe build from this branch
Verify that the optimized_checkout_element sub-option is still empty -- wp option pluck woocommerce_stripe_settings optimized_checkout_element
Reconnect to Stripe
Verify that the optimized_checkout_element sub-option is now set to yes -- wp option pluck woocommerce_stripe_settings optimized_checkout_element

…new-installs

wjrosa · 2025-11-25T13:57:37Z

Good catch, Dale! Thanks. I have updated the main implementation in 3ee6a77. I have also included unit tests specific for this behavior.

daledupreez · 2025-11-27T20:03:56Z

includes/class-wc-stripe.php

+					unset( $stripe_settings['pmc_enabled'] );
+					WC_Stripe_Helper::update_main_stripe_settings( $stripe_settings );
+					WC_Stripe_Logger::warning( 'Settings synchronization eligibility will be re-checked after upgrade' );
+				} else if ( 'yes' === $stripe_settings['pmc_enabled'] ) {


I think this approach also has issues. If we have a merchant who has settings sync enabled but hasn't had the optimized_checkout_element sub-option set, upgrading will now result in Optimized Checkout being enabled. AFAICT, we don't have any logic that's only going to run for a new/fresh install.

I had a fairly different thought about how to approach this much earlier in install():

Get current value of wc_stripe_version (which we're already doing for the comparison against WC_STRIPE_VERSION)

If the value is empty, we have a new install, so set a new option (or maybe sub-option) like wc_stripe_optimized_checkout_default_on to yes

Leave all other logic in this code as-is -- we only want to take action when we (re)enable settings sync

Then in WC_Stripe_Payment_Method_Configurations::maybe_migrate_payment_methods_from_db_to_pmc(), if we execute the code path where we set pmc_enabled to yes, also set optimized_checkout_element to yes if it wasn't previously set.

I am planning to do something very similar for enabling Amazon Pay on fresh installs as well. Let me know if it would help for me to put together an initial PR. I am now thinking that it could be worth creating a helper method like init_on_new_install() that handles initialising some options for managing default behaviours like this.

I see. I'd appreciate it if you could open another PR then. We can move forward from there 👍

The problem here is that if we run the code in install just for new installations (wc_stripe_version is false), pmc_enabled will be undefined, and we will never set wc_stripe_optimized_checkout_default_on there

What we can do is set a flag/constant when we identify a fresh install, and proceed with the settings update in maybe_migrate_payment_methods_from_db_to_pmc.

That wouldn't work either, because the install and the connection method are called different in different flows 🤔

I did a refactor using a new flag in options to identify new installs. See 7f2b87d. Let me know what you think. It worked for me

…new-installs

Making OCS enabled by default for new installs

2ca2bf1

wjrosa self-assigned this Nov 18, 2025

wjrosa marked this pull request as ready for review November 18, 2025 19:44

wjrosa requested review from a team, Mayisha and daledupreez and removed request for a team November 18, 2025 19:53

Merge branch 'develop' into update/making-ocs-enabled-by-default-for-…

8943509

…new-installs

daledupreez reviewed Nov 19, 2025

View reviewed changes

Mayisha approved these changes Nov 20, 2025

View reviewed changes

daledupreez requested changes Nov 20, 2025

View reviewed changes

wjrosa added 2 commits November 25, 2025 09:30

Merge branch 'develop' into update/making-ocs-enabled-by-default-for-…

36fb55d

…new-installs

Moving the main implementation to the install method + unit tests

3ee6a77

wjrosa requested a review from daledupreez November 25, 2025 13:57

daledupreez reviewed Nov 27, 2025

View reviewed changes

wjrosa added 3 commits November 28, 2025 09:34

Merge branch 'develop' into update/making-ocs-enabled-by-default-for-…

5e53aae

…new-installs

Merge branch 'develop' into update/making-ocs-enabled-by-default-for-…

17eba2f

…new-installs

Enable OCS only for new installs

7f2b87d

wjrosa requested a review from daledupreez December 2, 2025 16:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Making OCS enabled by default for new installs #4811

Making OCS enabled by default for new installs #4811

wjrosa commented Nov 18, 2025 •

edited

Loading

Uh oh!

daledupreez Nov 19, 2025

Uh oh!

Mayisha left a comment

Uh oh!

daledupreez left a comment •

edited

Loading

Uh oh!

wjrosa commented Nov 25, 2025

Uh oh!

daledupreez Nov 27, 2025

Uh oh!

wjrosa Dec 1, 2025

Uh oh!

wjrosa Dec 2, 2025

Uh oh!

wjrosa Dec 2, 2025 •

edited

Loading

Uh oh!

wjrosa Dec 2, 2025

Uh oh!

wjrosa Dec 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Making OCS enabled by default for new installs #4811

Are you sure you want to change the base?

Making OCS enabled by default for new installs #4811

Conversation

wjrosa commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes proposed in this Pull Request:

Testing instructions

Changelog entry

Comment

Uh oh!

daledupreez Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

Mayisha left a comment

Choose a reason for hiding this comment

Uh oh!

daledupreez left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wjrosa commented Nov 25, 2025

Uh oh!

daledupreez Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

wjrosa Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

wjrosa Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

wjrosa Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wjrosa Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

wjrosa Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

wjrosa commented Nov 18, 2025 •

edited

Loading

daledupreez left a comment •

edited

Loading

wjrosa Dec 2, 2025 •

edited

Loading