Refactor webhook handler to compute order or refund upfront

[daledupreez]

Towards STRIPE-564
Related to #4466

Changes proposed in this Pull Request:

This PR explores refactoring our webhook handler in two specific ways:

• Centralise the code responsible for looking up an order for the various notification types from Stripe
• Call that code from process_webhook() and then pass in the order that was identified

The refactor stems from a discussion in #4466, where we're trying to build WordPress hooks for developers to process webhooks more easily.

Testing instructions

---

• 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

• 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)

[Copilot]

Pull Request Overview

This PR refactors the webhook handler to centralize order lookup logic and pass the resolved order directly to webhook processing methods. This change aims to improve maintainability and supports the development of WordPress hooks for webhook processing.

• Centralized order lookup logic into a single get_order_from_notification() method
• Modified all webhook processing methods to accept an optional $order parameter
• Updated process_webhook() to resolve the order upfront and pass it to each handler

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
includes/class-wc-stripe-webhook-handler.php	Refactored webhook handler methods to accept order parameter and added centralized order lookup logic
tests/phpunit/WC_Stripe_Webhook_Handler_Test.php	Added missing notification type field to test data

[Copilot]

The @param documentation incorrectly states '$refund' as the parameter name when it should be '$order'. Also, the description 'The related order' is inconsistent with other methods that use 'The related order.'

[Copilot]

Missing 'break;' statement after the setup_intent case block. This will cause the code to fall through to the next statement, which could lead to unexpected behavior.

Suggested change

	break;

[Copilot]

Creating an empty stdClass as a fallback could lead to unexpected behavior when the object properties are accessed later. Consider logging a warning or returning false early when the notification data object is missing.

Suggested change

	$object = $notification->data->object ?? new stdClass();
	if ( ! isset( $notification->data ) || ! isset( $notification->data->object ) ) {
	if ( function_exists( 'wc_get_logger' ) ) {
	wc_get_logger()->warning(
	'Stripe webhook notification missing data object: ' . wp_json_encode( $notification ),
	array( 'source' => 'wc-stripe-webhook-handler' )
	);
	} else {
	error_log( 'Stripe webhook notification missing data object: ' . print_r( $notification, true ) );
	}
	return false;
	}
	$object = $notification->data->object;