Skip to content

Conversation

@wjrosa
Copy link
Contributor

@wjrosa wjrosa commented Nov 18, 2025

Fixes STRIPE-818

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:
Screenshot 2025-11-18 at 16 52 41
  • 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

@wjrosa wjrosa self-assigned this Nov 18, 2025
@wjrosa wjrosa marked this pull request as ready for review November 18, 2025 19:44
@wjrosa wjrosa requested review from a team, Mayisha and daledupreez and removed request for a team November 18, 2025 19:53
$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();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@Mayisha Mayisha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@daledupreez daledupreez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@wjrosa
Copy link
Contributor Author

wjrosa commented Nov 25, 2025

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

@wjrosa wjrosa requested a review from daledupreez November 25, 2025 13:57
@wjrosa wjrosa requested a review from daledupreez December 2, 2025 16:34
Copy link
Contributor

@daledupreez daledupreez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌 This is pretty much exactly what I was thinking, @wjrosa! My only minor comment is that we should use a more specific option name to match the specificity of the current use case. I'll re-test once we confirm the option name we want to use.

wjrosa and others added 4 commits December 4, 2025 10:26
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
@wjrosa wjrosa requested a review from daledupreez December 4, 2025 13:31
Copy link
Contributor

@daledupreez daledupreez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing went smoothly, for both a simulated new install, reconnection, and simulated upgrade. However, I did notice an issue we should address in this PR.

$options[ $prefix . 'publishable_key' ] = $publishable_key;
$options[ $prefix . 'secret_key' ] = $secret_key;
$options[ $prefix . 'connection_type' ] = $type;
$options['pmc_enabled'] = 'connect' === $type ? 'yes' : 'no'; // When not connected via Connect OAuth, the PMC is disabled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought for a follow-up/separate PR: maybe we should default to '' or not even set pmc_enabled when we don't have connect type.

Suggested change
$options['pmc_enabled'] = 'connect' === $type ? 'yes' : 'no'; // When not connected via Connect OAuth, the PMC is disabled.
$options['pmc_enabled'] = 'connect' === $type ? 'yes' : ''; // When not connected via Connect OAuth, defer the decision until we try to get a valid PMC.

Co-authored-by: daledupreez <dale.du.preez@automattic.com>
@wjrosa wjrosa requested a review from daledupreez December 4, 2025 17:02
Copy link
Contributor

@daledupreez daledupreez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the tweak! The update looks good to me based on inspection. 🚀

@wjrosa wjrosa enabled auto-merge (squash) December 4, 2025 19:24
@wjrosa wjrosa merged commit a58814c into develop Dec 4, 2025
40 checks passed
@wjrosa wjrosa deleted the update/making-ocs-enabled-by-default-for-new-installs branch December 4, 2025 19:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants