Release testing instructions for WC Payments 3.8.0

Changes to express checkouts settings section and second-level pages

Expected outcome

The settings page express checkouts section should display a simple Apple/Google Pay card where the option can be toggled on and off. All other Apple/Google Pay settings should be consolidated into a second-level settings page, accessible via a Customize link.

Testing instructions

Go to **Payments > Settings` via WP-Admin
Ensure you see a simple Apple Pay / Google Pay card next to the Express Checkouts section:

Make sure the Apple Pay / Google Pay checkbox is selected and save settings
From the front end, add an item to the cart, go to checkout, and attempt to checkout with Apple Pay (safari).
From the front end, add an item to the cart, go to checkout, and attempt to checkout with Google Pay (chrome).

Second level settings pages

Back in WooCommerce Payments settings, select the 'Customize' link next to Apple Pay / Google Pay
Ensure you are directed to the Apple Pay / Google Pay second-level settings page:

Ensure you can toggle/change the various checkbox and radio fields and saves persist these changes
Ensure changing these settings impacts the Apple Pay and Google Pay buttons on the front-end

Add Jetpack Sync to support Woo Mobile apps

Expected outcome

Selected options from a remote site are synced to WPcom without having Jetpack-the-plugin.

Testing instructions

For each step asking to verify the result (starting with Expectation), please do:

Log in wordpress.com with the account you used to connect your test site.
Visit https://developer.wordpress.com/docs/api/console/ and run GET /v1.1/me/sites.

There may be delay in reflecting the correct result but the delay time should not be longer than 5 minutes.

Test case for a new site connecting Jetpack:

If your test site has Jetpack-the-plugin active, DEACTIVATE IT.
If your test has not connected to Jetpack/WP.com, please do that but no need to go through the KYC process on stripe.com. Otherwise, you can use the site from other tests.
In your test site, go to site.com/wp-admin/plugins.php, try deactivating and activating the WooCommerce plugin.
Expectation: options.woocommerce_is_active reflects the state of WooCommerce plugin activation. In other words, this value is true if WooCommerce is active, and false otherwise.

Test case for a site upgrading WCPay:

MUST-DO: Create a new Jurassic test site.
If the test site has Jetpack-the-plugin active, DEACTIVATE IT.
Install "WooCommerce Payments" 3.7.x from WP.org in WP Admin > Plugins > Add new > search for "WooCommerce Payments". DO NOT use the testing zip file at this point.
Activate "WooCommerce Payments" and connect this site to WPcom. (No need to go through KYC in Stripe).
In your test site, go to site.com/wp-admin/plugins.php, try deactivating and activating the WooCommerce plugin.
Expectation: options.woocommerce_is_active is always false.
Make sure that "WooCommerce Payments" and "WooCommerce" are active.
Upload and activate the testing zip file for this week.
Expectation: options.woocommerce_is_active is switched to true.

Cache UPE intents for reuse

When UPE is enabled, new payment or setup intents are created on each load of the Checkout page. This results in a high number of abandoned intents, potentially wasting network resources. This change fixes this behavior by caching the newly created intent in the session. Once cached, it is then reused in the next mounting of UPE.

Expected outcome

Reloading the Checkout page does not lead to the creation of new intent.

Testing instructions

Testing will require you to enable UPE first. Do this by using the "Enable the new Stripe checkout experience" option on the Settings page. Update the store currency as per the payment methods you want to test. Eg. Giropay, iDEAL, etc. will require Euro as the store currency.

Payment Intent

Create a new order in the front-end.
Open Network tab in browser's dev tools, and visit the Checkout page.
On this page, notice an XHR call to create_payment_intent.
Reload the page. No fresh XHR call to create_payment_intent should be observed.
Complete the payment. The cached intent should be removed. Verify this by visiting the Checkout page again and observing an XHR call to create_payment_intent.
Also check if the cached intent is removed when a payment fails. When any of the following is used, reloading the Checkout page should generate a fresh XHR call to create_payment_intent:
- a credit card that is immediately declined
- a card that requires further authentication and eventually the transaction fails
- a redirection payment method (e.g. Giropay, SEPA, iDEAL, Sofort, etc.) and eventually the transaction fails
- a saved payment method that fails

FYI: The intent id retrieved from cache or received as a response from create_payment_intent is used only when a new payment method is used. Using saved cards (successfully) will create a new intent on the server, resulting in the UPE intent being abandoned.

Setup Intent

Open Network tab in browser's dev tools, and visit My account → Payment methods → Add payment method.
On this page, notice an XHR call to init_setup_intent.
Reload the page. No fresh XHR call to init_setup_intent should be observed.
Add a new payment method.
The cached intent should be removed after successfully adding a new PM.
Go back to the "Add payment method" page. A fresh XHR call to init_setup_intent will confirm that the previously cached intent was removed.

Example Scenarios

New card - successful payment
New card - declined
New card - authentication failed
Saved card - successful payment
Saved card - authentication failed
New SEPA - successful payment
Saved SEPA - successful payment
Giropay - successful payment
Giropay - failed payment

For a full sanity testing, it's a good idea to see if the remaining UPE methods are not breaking due with the new changes — Bancontact, iDEAL, Sofort, and Przelewy24.