Release testing instructions for WC Payments 11.1.0

Baseline: US test store, test mode, latest WooCommerce (11.1.0 RC if available). Use a fresh Jurassic Ninja site unless a flow says otherwise.

1. Core payments smoke (block + classic checkout)

Covers the order-service and duplicate-payment refactors that touch every checkout.

1. Place an order with 4242 4242 4242 4242 on the block checkout.

• Payment succeeds; order-received page loads.

2. Repeat on the classic (shortcode) checkout.

• Payment succeeds; no console errors.

3. Refund the first order from wp-admin.

• Refund completes.

4. Check out with declining card 4000 0000 0000 0002.

• Order is marked Failed and checkout shows the decline gracefully.

5. Open Payments → Overview, Transactions, Payouts.

• All three load data with no console errors.

2. Fraud rules on the order screen (#11990)

Setup: enable a few rules in Payments → Settings → Fraud protection; set the item purchase price and item quantity thresholds low so they trigger.

1. As a customer, place an order that exceeds a threshold (for example, quantity above the limit) with 4242 4242 4242 4242.

• The order is blocked; its order note names the risk filters that fired.
• The Fraud & Risk meta box on the order screen lists the triggered filters.

2. Place an order within the thresholds using AVS test card 4000 0000 0000 0036 (with the AVS rule enabled).

• The block is attributed to the AVS check in the note and meta box.

3. Click View more details in the blocked-order note.

• It opens the payment details for the specific blocked attempt (repeat attempts each link their own transaction).

3. Early fraud warnings (#11915, #11967)

1. Place an order with Stripe's early-fraud-warning test card 4000 0000 0000 5126.

• Within a few minutes (webhook delivery) the order gets a note about the early fraud warning.
• The Fraud & Risk meta box shows the warning details.
• The transaction timeline on the payment details page shows the early fraud warning event.

2. If the order note offers a refund link, follow it.

• It lands on the expected refund path (payment details when the quick refund is unavailable).

4. No second charge on an already-paid order (#11994)

1. As a merchant, create a manual order and open its Customer payment page link in two browser tabs.
2. Pay in the first tab with 4242 4242 4242 4242, then submit payment in the second tab.

• The second submission does not create a second charge; you are redirected to the order-received page.
• The order has a single charge in Payments → Transactions, and a note about the prevented duplicate payment.

5. Long refund reason (#12006)

1. Refund an order and paste a very long reason (over 500 characters).

• The refund completes instead of erroring; the reason is stored truncated.

6. Disputes on the order screen

Covers the dispute copy and multi-dispute changes in this release.

1. Place an order with dispute test card 4000 0000 0000 0259.

• The order screen shows the disputed-order notice with the evidence response deadline.
• Payment details labels the withdrawn amount as Deducted (not "Refunded"), and no dispute fee line shows a $0.00 amount or a dash when the fee is zero.

2. Accept the dispute from the dispute screen.

• The flow completes and the order reflects the outcome.

7. Support phone is now required in settings

Intended change: the support phone field is required.

1. On a store with no support phone set, open Payments → Settings and change any unrelated setting.

• Save is blocked with a single plain validation message about the phone number.

2. Enter a valid phone number and save.

• Save succeeds and sticks.

8. Upgrade path (if you have a site on 11.0.1)

1. Upgrade an existing 11.0.1 test site (ideally one that had used the test-drive/sandbox mode) to this package.

• No errors on upgrade; Payments screens load.
• If sofort was still present in the payment method settings, it is gone after the upgrade (intended cleanup re-run).
• Checkout still works after the upgrade.