Skip to content

Release testing instructions for WC Payments 3.8.0

Jump to bottom
Taha Paksu edited this page Mar 1, 2022 · 8 revisions

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:

  1. Log in wordpress.com with the account you used to connect your test site.
  2. 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:

  1. If your test site has Jetpack-the-plugin active, DEACTIVATE IT.
  2. 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.
  3. In your test site, go to site.com/wp-admin/plugins.php, try deactivating and activating the WooCommerce plugin.
  4. 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:

  1. MUST-DO: Create a new Jurassic test site.
  2. If the test site has Jetpack-the-plugin active, DEACTIVATE IT.
  3. 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.
  4. Activate "WooCommerce Payments" and connect this site to WPcom. (No need to go through KYC in Stripe).
  5. In your test site, go to site.com/wp-admin/plugins.php, try deactivating and activating the WooCommerce plugin.
  6. Expectation: options.woocommerce_is_active is always false.
  7. Make sure that "WooCommerce Payments" and "WooCommerce" are active.
  8. Upload and activate the testing zip file for this week.
  9. 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:

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.

Changes to how order status and notes are set within the plugin

There was an internal refactor that changed how the order statuses were changed and how notes were applied with those changes.

Expected outcome

Specific notes should be added to orders based upon how the order was moved to a certain status.

Testing instructions

Successful order:

  • Add item to cart and check out with test card.
  • View order in admin.
  • Order should be Processing or Completed, depending on if the product is virtual and downloadable.
  • Order should have 3 notes:
    • A payment of TOTAL was started using WooCommerce Payments (INTENT_ID). (Will not show if using a saved card.)
    • Order status changed from Pending payment to Processing.
    • A payment of TOTAL was successfully charged using WooCommerce Payments (CHARGE_ID). Total is the order total, and Charge_Id will be a link to the transaction details page.

Failed order:

  • Add item to cart and check out with 4000000000000002 as your test card.
  • Order will fail.
  • View order in admin.
  • Order should be in Failed status.
  • Order should have 3 notes:
    • A payment of TOTAL was started using WooCommerce Payments (INTENT_ID).
    • Order status changed from Pending payment to Failed.
    • A payment of TOTAL failed using WooCommerce Payments (INTENT_ID). Total is the order total, and Intent_Id will be a link to the transaction details page.

Pending order:

  • Go to Payments > Settings and enable Bancontact as a payment method.
  • Add item to cart and go to checkout page.
  • Update your currency to Euro via MC widget.
  • Select Use a new payment method, and then select Bancontact.
  • Click Place order, but do not complete the order on the next page.
  • View order in admin.
  • Order should be in Pending payment status.
  • Order should have 1 note:
    • A payment of TOTAL was started using WooCommerce Payments (INTENT_ID).

On-hold order:

  • Go to Payments > Settings and then the Transactions and deposits section.
  • Enable the Issue an authorization on checkout, and capture later setting.
  • Add item to cart and check out with test card.
  • View order in admin.
  • Order should be in On Hold status.
  • Order should have 3 notes:
    • A payment of TOTAL was started using WooCommerce Payments (INTENT_ID).
    • Order status changed from Pending payment to On hold.
    • A payment of TOTAL was authorized using WooCommerce Payments (INTENT_ID). Total is the order total, and Intent_Id will be a link to the transaction details page.

Capture authorized payment:

  • Using previous order, go to Order actions at the top right of the order in the admin.
  • Choose Capture charge and either click the right arrow or Update.
  • Order should be Processing or Completed, depending on if the product is virtual and downloadable.
  • Order should have 2 new notes:
    • Order status changed from On hold to Processing.
    • A payment of TOTAL was successfully charged using WooCommerce Payments (CHARGE_ID). Total is the order total, and Charge_Id will be a link to the transaction details page.

Cancel authorized payment:

  • Add item to cart and check out with test card.
  • View order in admin.
  • Order should be in On Hold status.
  • Choose Cancel authorization and either click the right arrow or Update.
  • Order should be in Cancelled status.
  • Order should have 2 notes:
    • Order status changed from On hold to Cancelled.
    • Payment authorization was successfully cancelled.

Capture authorization failure:

  • Enable below snippet in your store, either through theme or Code Snippets.
  • Add item to cart and check out with test card.
  • View order in admin.
  • Order should be in On Hold status.
  • Choose Capture charge and either click the right arrow or Update.
  • Order should remain in On hold status.
  • Order should have 1 new note:
    • A capture of TOTAL failed to complete using WooCommerce Payments (false_id). Error: No such payment_intent: 'false_id'
add_filter( 'woocommerce_order_get_transaction_id', function() {
	return 'false_id';
});

Fix report emailed for deposit transactions

There was a bug that would send all transactions whenever an email download was sent in regards to transactions related to deposits.

Expected outcome

The file in the email should only include transactions related to the selected deposit.

Testing instructions

  • Go to Payments > Deposits and choose a deposit that has more than one transaction. This can be a pending/estimated deposit.
  • After the page loads, add &per_page=1 to the url in the address bar and hit return/enter.
  • There should now be one transaction showing per page, and now you can click the Download button at the top right of the list to trigger the email download.
  • You should receive an email with a csv file with the transactions related to the deposit that was chosen.

Capital testing instructions

Some context first, Stripe lends you money (advance amount), with a price of a fee (fee amount), that you should pay in 18 months, and it has 60 day terms that you should pay it back. The minimum payment that you should pay back in 60 days is (advance amount + fee amount) / 9 and even you reach the paydown amount in the middle of the 60 day period, Stripe continues to charge the payback until the loan is fully paid back. If you don't reach the minimum, Stripe calls you to find solutions. More information can be found at https://stripe.com/docs/capital/faqs.

To test this feature, you need to request a loan offer for your connected Stripe account from @sigma-team. The UI won't have anything different, unless you get an active loan. Please include your stripe account ID acct_xxx when requesting the loan offer, this way it'll be faster to process. When you have an active loan offer, you won't get another one, the one needs to be expired, or fully paid off when requesting a new one.

You can request to change the parameters of a loan offer like below from the team:

Advance Amount: 1000 USD (The money you'll see in your balance after your loan offer application is approved) Fee Amount: 100 USD (The money you agreed to pay extra when paying back the loan, like an interest rate) Withhold rate: 15% (When you sell something, this percent of the total sale will be cut for the loan paydown)

Testing e-mail features

  1. When a loan is created, check if you've received the initial loan offer email.
  2. When you click the "View your offer" button, you should be redirected to Stripe's loan application form via your store website.
    1. Check if when you're already logged in, you directly go to the Capital application page.
    2. Check if when you're not logged in, you first see the login form, and with the correct credentials, you are redirected to the Capital application page.
  3. When you click the "Unsubscribe" link on the e-mail, you get a confirmation message.
    1. When you request another offer from @sigma-team after you unsubscribed, check you're not getting any emails.
    2. You can ask for subscribing back to Capital e-mails by pinging @sigma-team with the request.
  4. Check if the loan you asked from @sigma-team matches the content on the e-mail.
  5. Check if the email contains the statement indicating WCPay 3.8.0 is the required minimum WCPay version to apply for a loan.
  6. Check if the design matches with the below screenshot and it doesn't contain any typo.

Testing payouts

  1. Click "View your offer" button on the email and on the redirected page, fill out the form.
  2. Note the amount that you are offered, the fee you will pay when the loan is accepted, and the withhold rate on the application summary page (where you check 3-4 checkboxes on the application).
  3. Ask @sigma-team to approve your loan offer and pay out the amount.
  4. When it is approved, you'll get an e-mail from Stripe, saying that your loan is approved and paid out.
  5. After you receive that e-mail, go to WP-Admin > Payments > Overview screen and you should see the loan summary card and an inbox note telling your loan is approved.
  6. The View transactions link on the loan summary card should send you to the Payments > Transactions page, with the active loan added as an advanced filter.
  7. The View loan details button on the inbox note should send you to the Payments > Capital page.
  8. Check the loan summary box, if it contains the right values that you've applied for.
  9. Check the inbox note if it contains the right amount that you've applied for.
  10. Go to your Payments > Transactions screen, and you should see the Loan dispersement item in your transactions list. The row should not be clickable, since it doesn't contain any details.
  11. If the paydown transaction row isn't there, check back after 5 minutes from the time the loan got approved.

Testing pay downs

  1. Go to your store and sell some items.
  2. After the payment, go to WP Admin > Payments > Transactions screen.
  3. You should be able to see the charge row related to that order.
  4. And also you should see a paydown transaction titled Loan repayment having the same order ID with the related charge (Like the payout transaction, it may have a 5 minute delay)
  5. The row should be clickable, and it'll take you to the main transaction screen.
  6. It should show the loan paydown amount on the transaction details overview box above the transaction timeline
  7. It should display the paydown item as a timeline item in the timeline, saying "XXX $ will be subtracted from a future deposit" if the deposit date is unknown (manual deposits), or the next deposit date if its automatic.
  8. Check the loan summary box in Payments > Overview screen if it reflects the repayments you've made.

Testing Capital page

  1. The Payments > Capital page should be hidden by default, will get visible once you have an active loan, or previously had one.
  2. The page should show a similar overview box for the active loan on top. The View transactions link should redirect you to the Payments > Transactions page with the active loan filtered.
  3. Check the displayed amounts if they present the correct current status.
  4. The page should also list all the loans you have/had until now, check if they show the correct values and are exportable.

Testing transaction page filters

  1. After you have an active loan, or had at least one fully paid loan, go to the transaction screen.
  2. On the filters above, there should be two loan related type filters, "Loan repayment", and "Loan dispersement", when you select one of those, the related transactions should be filtered.
  3. There's a new "Loan" named advanced filter, it should display all the loan related repayment and dispersement transactions of a specific loan. And it should show | Active after the active loan, and | Paid in full on the past fully paid loans. No expired, canceled, or rejected loan offers should be displayed.

Testing loan completion

  1. You can request from @sigma-team to fully pay down your "active and paid out loan". Or you can create dummy sales that its withhold amount covers the entire loan debt.
  2. After your loan is fully paid down, you should get an email from Stripe confirming that the loan is fully paid down.
  3. And after you receive that message, the loan summary box and the inbox note should disappear from the Payments > Overview screen.
  4. Check if the transaction screen loan filter option for the current loan has changed the suffix from | Active to | Paid in full

Home

Critical flows

Release testing instructions

Testing resources, tips and tricks

Clone this wiki locally