Skip to content

Conversation

@wjrosa
Copy link
Contributor

@wjrosa wjrosa commented Nov 12, 2025

Changes proposed in this Pull Request:

In this simple cleanup PR, I am removing all the legacy checkout payment method classes, as we are no longer using them.

Testing instructions

Code review. Check if the tests are still passing. Perform some basic smoke testing and confirm no regression was introduced.


  • 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 12, 2025
@wjrosa wjrosa changed the title Dev/removing legacy payment method classes Removing legacy payment method classes Nov 12, 2025
@wjrosa wjrosa marked this pull request as ready for review November 12, 2025 19:14
@wjrosa wjrosa requested review from a team, daledupreez and malithsen and removed request for a team November 12, 2025 20:36
Copy link
Contributor

@malithsen malithsen left a comment

Choose a reason for hiding this comment

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

Looks good. Are we planning to do a similar cleanup for the frontend code (to remove is_upe_enabled distinction) in a separate PR?

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 have some initial comments from inspection, and I will move to test this later this morning. That said, it feels like it might be worth splitting this PR up a bit so we can tackle more specific and focused testing.

* @var string
*/
private $legacy_sepa_gateway_id = WC_Gateway_Stripe_Sepa::ID;
private $legacy_sepa_gateway_id = 'stripe_sepa';
Copy link
Contributor

Choose a reason for hiding this comment

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

Might it be worth using a new constant for this rather than having 'stripe_sepa' everywhere?

It also feels like it could be worth pushing just that change into a dedicated PR, as that would be easy to inspect and review, and we could get it shipped with minimal risk. That would also reduce the size of this PR by quite a few files.

wjrosa and others added 10 commits November 14, 2025 08:22
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
Co-authored-by: daledupreez <dale.du.preez@automattic.com>
@wjrosa
Copy link
Contributor Author

wjrosa commented Nov 14, 2025

Looks good. Are we planning to do a similar cleanup for the frontend code (to remove is_upe_enabled distinction) in a separate PR?

@malithsen yes. I have some other branches to push related to code cleaning up. I will open other PRs in the next couple of weeks

I have some initial comments from inspection, and I will move to test this later this morning. That said, it feels like it might be worth splitting this PR up a bit so we can tackle more specific and focused testing.

@daledupreez I tried to make this PR focused on just removing the payment method classes, to avoid it getting too big or risky. Which parts do you think would be better to move to another PR?

@daledupreez
Copy link
Contributor

For splitting the PR, I was thinking it might make sense to change the references to WC_Gateway_Stripe_Sepa::ID (which occurs a few times) to 'stripe_sepa' (or another constant), as changing the string and what we reference can happen without removing the underlying class. It also touches quite a few files, but is pretty easy to validate from inspection alone, as this should be an implementation detail.

@wjrosa
Copy link
Contributor Author

wjrosa commented Nov 14, 2025

Oh right. I created the other PR here: #4802

@wjrosa wjrosa requested a review from daledupreez November 28, 2025 12:33
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.

While I would love to remove all of this code, I am really worried about unforeseen consequences of removing so much code without looking deeply into some of the nuances of what we're changing and/or removing.

}

// Bail if no Stripe payment method is enabled.
if ( 'no' === $this->enabled && empty( WC_Stripe_Helper::get_legacy_enabled_payment_methods() ) ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: should we be queuing these scripts for any pages when UPE is enabled?

* @deprecated 9.6.0 The customization of individual payment methods is now deprecated.
* @deprecated 10.2.0 This method will be removed in future versions.
*/
public static function get_legacy_individual_payment_method_settings() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: It feels like it would be worth splitting this out into a dedicated PR so we can correctly capture the removal in a changelog entry. I almost missed that these two functions had been removed.

*
* @since 4.0.0
*/
class WC_Gateway_Stripe_Alipay extends WC_Stripe_Payment_Gateway {
Copy link
Contributor

Choose a reason for hiding this comment

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

These classes were not marked as deprecated. Just to be good citizens, I think we should deprecate them before removing them, as merchants may be referencing them in custom code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. New PR is here #4839


const STRIPE_ID = WC_Stripe_Payment_Methods::ALIPAY;

const LPM_GATEWAY_CLASS = WC_Gateway_Stripe_Alipay::class;
Copy link
Contributor

Choose a reason for hiding this comment

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

As with the class removals, I think we should deprecate these constants first, as they are public and could be in use.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright. New PR here #4838

protected function enable_upe( $settings ) {
$settings['upe_checkout_experience_accepted_payments'] = [];

$payment_gateways = WC_Stripe_Helper::get_legacy_payment_methods();
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we safely remove this logic? What will happen to merchants upgrading from older versions where UPE was not enabled yet?

];
}

public function test_turning_on_upe_enables_the_correct_upe_methods_based_on_which_legacy_payment_methods_were_enabled() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't we still need the underlying logic for upgrades?

@wjrosa wjrosa added the status: blocked The issue is blocked from progressing, waiting for another piece of work to be done. label Dec 1, 2025
@wjrosa wjrosa changed the title Removing legacy payment method classes [DO NOT MERGE] Removing legacy payment method classes Dec 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: blocked The issue is blocked from progressing, waiting for another piece of work to be done.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants