Implementing the new test mode class

[wjrosa]

Base PR #3583

Changes proposed in this Pull Request:

This is a simple refactoring PR implementing the new WC_Stripe_Mode (added in #3583). The purpose here is to reduce many of our duplicated codes by checking for the test mode setting and centralizing the logic on that class.

This is based on the same approach we have in WooPayments.

Testing instructions

Code review. Check if the tests are still passing. You can also perform some smoke testing:

• Connect your Stripe account to your test store (test mode and live)
• Enable and disable some payment methods
• Purchase some products as a customer

Since this is just a refactoring PR, no behavior should change.

---

• Covered with tests (or have a good reason not to test in description ☝️)
• Added changelog entry in both changelog.txt and readme.txt (or does not apply)
• Tested on mobile (or does not apply)

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)

[Mayisha]

Changes look good 👍

✅ Reconnected to my Stripe account in live mode.
✅ Reconnected to my Stripe account in test mode.
✅ Payment with regular card.
✅ Payment with 3ds card.
✅ Payment with regular card.
✅ Payment with GPay
✅ Payment with SEPA, iDeal
✅ Payment with Multibanco (voucher)
✅ Payment with Cash App (wallet)
✅ Payment with Klarna (bnpl)

Noticed that there are still a couple of places where we have $stettings['testmode'] instead of calling the new function. Those instances are from recently merged PRs like this one. Before merging this, let's give the codebase another scan.

I have another thought for future enhancement. With this newly introduced class, we are still getting the settings or testmode from the DB option everytime we make a call to this function. We can keep the data in the class to avoid this.

[Mayisha]

It's a very unusual scenario, but if in any case $settings['testmode'] is not defined the is_live and is_test both functions will return false.

Probably is_live should return true in this scenario.

[wjrosa]

I thought about that as well. But I did a test here, and it behaves as you suggested already:

var_dump( 'yes' !== ( $settings['testmode'] ?? 'no' ) ); // `is_live()`: prints `true`
var_dump( 'yes' === ( $settings['testmode'] ?? 'no' ) ); // `is_test()`: prints `false`

[wjrosa]

Noticed that there are still a couple of places where we have $stettings['testmode'] instead of calling the new function. Those instances are from recently merged PRs like this one. Before merging this, let's give the codebase another scan.

Thanks for the review, Mayisha! I have updated the remaining occurrences in 4a232be.

I have another thought for future enhancement. With this newly introduced class, we are still getting the settings or testmode from the DB option everytime we make a call to this function. We can keep the data in the class to avoid this.

Yeah, that's a good idea. I will work on that later 👀

[wjrosa]

@Mayisha I have rewritten the class in ac19e7a making it simpler and persisting the mode inside the static property. In case you think it is not good, I can revert this change.

Edit: tests broke. Looking into it

Edit 2: I decided to revert the change for now and merge this. I will work on refactoring this later 👍