Fix - Scope nexus address validation to the fields the value object reads.

Addresses review feedback on the TaxJar request seam.

Two regressions, both introduced by validating the nexus address through the
shared address schema.

The origin state is now required for the US only. Address::validate() defaults to
requiring country and state and errors on present-but-blank, where the loop it
replaced only errored when the key was absent. The nexus address this plugin
builds for the merchant's own store always carries a 'state' key, and
WC()->countries->get_base_state() is '' for 19 of the 31 countries in
get_supported_countries() -- GB, FR, NL, BE, DK, SE, PL, PT and the rest of the
stateless EU. Every tax calculation for those merchants therefore dropped the
store's own nexus block from the request and wrote a forced error log plus a
persistent admin error notice.

The US-only boundary is measured, not assumed. Probed against the live TaxJar
API (scripts under .issues/WOOTAX-313/work/): GB, FR, NL, DK, DE, ES, IT, IE, CA
and AU all return an identical rate whether the nexus carries its state or an
empty string, because VAT and GST are rated from the destination. A US nexus with
a blank state returns HTTP 200 with has_nexus:false and zero tax -- it fails
silently, so the check has to stay there. Keying the requirement off whether
WooCommerce models states for the country would have kept wrongly rejecting DE,
ES, IT, IE, GR, HU, HR, RO, BG, CA and AU, which matters because TaxJar supports
those markets for legacy accounts even though it documents US/CA only.

The non-scalar guard no longer inspects unknown keys. It iterated every key of
the filter-supplied address, so a custom key holding an array rejected the whole
nexus address -- silently changing which nexus TaxJar was asked about, and
logging "field must be a string" for a field that is never cast to string. Only
the six fields the value object actually reads are checked; everything else is
merged back untouched, which is what the documented array-in / array-out
contract promises.

Adds eleven tests. Nine non-US store countries and the unknown-key case fail
before this change; the US blank-state case bounds the relaxation and passes
either way.

Author: bartech

classes/class-wc-connect-taxjar-integration.php

@@ -1444,6 +1444,14 @@ function ( $line_item ) use ( $new_tax_rate ) {
 	 * rules the rest of the integration uses, and — because `calculate_tax()` sends
 	 * the normalised address — is checked in the shape it is sent.
 	 *
+	 * Country is always required. State is required for the US only; see the inline
+	 * comment for the measurement behind that, and for why a blanket requirement
+	 * rejects the plugin's own nexus across most of TaxJar's supported list.
+	 *
+	 * Validation is deliberately confined to the fields the value object reads. Extra
+	 * keys supplied by a filter are neither validated nor rewritten — `calculate_tax()`
+	 * passes them straight through to the request body.
+	 *
 	 * @param  array $address Nexus address, as returned by `woocommerce_taxjar_nexus_address`.
 	 *
 	 * @return bool
@@ -1463,17 +1471,52 @@ private function is_nexus_address_valid( $address ): bool {
 			return false;
 		}
 
-		// The value object casts each field to string, so reject anything that cannot
+		// The value object casts these fields to string, so reject anything that cannot
 		// survive that cast rather than triggering an array-to-string conversion.
-		foreach ( $address as $field => $value ) {
+		//
+		// Only the fields the value object reads are checked. Any other key a filter
+		// added is passed through untouched below and is never cast, so it carries no
+		// conversion risk — rejecting the whole address over it would turn the
+		// documented array-in / array-out contract into a whitelist.
+		foreach ( array( 'id', 'country', 'state', 'zip', 'city', 'street' ) as $field ) {
+			if ( ! array_key_exists( $field, $address ) ) {
+				continue;
+			}
+
+			$value = $address[ $field ];
+
 			if ( null !== $value && ! is_scalar( $value ) ) {
 				$this->logger->error( 'Nexus Address ERRORS: [' . $field . '] field must be a string' . PHP_EOL . 'Nexus address removed from request body.' . PHP_EOL . wp_json_encode( $address ), 'WCS Tax' );
 
 				return false;
 			}
 		}
 
-		$errors = Address::from_nexus( $address )->validate()->get_error_messages();
+		$nexus = Address::from_nexus( $address );
+
+		/*
+		 * The origin state is required for the US, and only for the US.
+		 *
+		 * US nexus is determined from the ORIGIN state; VAT and GST countries rate from
+		 * the destination and ignore a blank origin state. Measured against the live
+		 * TaxJar API rather than assumed -- GB, FR, NL, DK, DE, ES, IT, IE, CA and AU
+		 * all return an identical rate whether the nexus carries its state or an empty
+		 * string, while a US nexus with a blank state returns HTTP 200 with
+		 * `has_nexus: false` and zero tax. It fails silently, which is exactly why the
+		 * check has to stay for the US.
+		 *
+		 * Requiring it everywhere is what makes this wrong. The nexus address this
+		 * plugin builds for its own store always carries a 'state' key, and
+		 * WC()->countries->get_base_state() is '' for 19 of the 31 countries in
+		 * get_supported_countries() -- so a blanket requirement rejected the store's own
+		 * nexus on every tax calculation for those merchants, dropping the nexus block
+		 * from the request and writing a forced error log plus a persistent admin error
+		 * notice. For a filter-supplied nexus it is worse than noise: falling back to
+		 * the store's from_* address changes which origin TaxJar rates against.
+		 */
+		$required = ( 'US' === $nexus->country() ) ? array( 'country', 'state' ) : array( 'country' );
+
+		$errors = $nexus->validate( $required )->get_error_messages();
 
 		if ( ! empty( $errors ) ) {
 			$this->logger->error( 'Nexus Address ERRORS: ' . implode( ', ', $errors ) . PHP_EOL . 'Nexus address removed from request body.' . PHP_EOL . print_r( $address, true ), 'WCS Tax' );

tests/php/test-class-wc-connect-taxjar-integration.php

@@ -2548,4 +2548,144 @@ function ( $nexus_address ) {
 		$this->assertIsArray( $body );
 		$this->assertArrayNotHasKey( 'nexus_addresses', $body );
 	}
+
+	/**
+	 * A non-scalar value under an unknown key must not reject the whole address.
+	 *
+	 * The non-scalar guard exists because the value object casts the fields it reads to
+	 * string. Keys it does not read are never cast — they are merged back untouched —
+	 * so they carry no conversion risk. Checking them anyway made a single custom key
+	 * holding an array discard the entire nexus address, silently swapping which nexus
+	 * TaxJar was asked about, and logged "[meta] field must be a string" for a field
+	 * that is never treated as a string.
+	 */
+	public function test_non_scalar_unknown_nexus_key_is_passed_through() {
+		$body = $this->capture_taxjar_request_json(
+			$this->in_state_options(),
+			function ( $nexus_address ) {
+				$nexus_address['meta'] = array( 'source' => 'erp' );
+
+				return $nexus_address;
+			}
+		);
+
+		$this->assertIsArray( $body );
+		$this->assertArrayHasKey(
+			'nexus_addresses',
+			$body,
+			'A non-scalar value under an unknown key rejected the whole nexus address.'
+		);
+		$this->assertSame( array( 'source' => 'erp' ), $body['nexus_addresses'][0]['meta'] );
+		$this->assertSame( 'US', $body['nexus_addresses'][0]['country'] );
+	}
+
+	/**
+	 * A store outside the US keeps its own nexus address even with a blank state.
+	 *
+	 * `to_nexus_array()` always emits a `state` key, and `WC()->countries->get_base_state()`
+	 * returns `''` for 19 of the 31 countries in `get_supported_countries()` — GB, FR,
+	 * NL, BE, DK, SE, PL, PT and the rest of the stateless EU. Requiring a non-blank
+	 * state therefore rejected the nexus this plugin builds for the merchant's own
+	 * store, on every tax calculation, and each rejection wrote a forced error log and
+	 * a persistent admin error notice.
+	 *
+	 * The provider deliberately mixes countries WooCommerce gives no states (GB, FR, NL,
+	 * DK) with ones it does (DE, ES, IT, CA, AU). Both groups belong here: measured
+	 * against the live TaxJar API, every one of them rates a blank-state nexus
+	 * identically to a populated one, because only the US derives nexus from the origin
+	 * state. Keying the requirement off "does WooCommerce model states for this country"
+	 * would pass the first group and wrongly reject the second.
+	 *
+	 * @dataProvider provider_non_us_store_countries
+	 *
+	 * @param string $country   Two-letter country code.
+	 * @param string $postcode  A postcode valid for that country.
+	 * @param string $to_state  Destination state. Only CA needs one — `validate_taxjar_request()`
+	 *                          requires a destination state for US and CA, which is a rule about
+	 *                          where the customer is, not about the store's nexus.
+	 */
+	public function test_non_us_store_keeps_its_nexus_address_without_a_state( $country, $postcode, $to_state = '' ) {
+		$store = array(
+			'street'   => '1 Store Way',
+			'city'     => 'Somewhere',
+			'state'    => '',
+			'country'  => $country,
+			'postcode' => $postcode,
+		);
+
+		$options               = $this->in_state_options();
+		$options['to_country'] = $country;
+		$options['to_state']   = $to_state;
+		$options['to_zip']     = $postcode;
+		$options['to_city']    = 'Somewhere';
+
+		$body = $this->capture_taxjar_request_json( $options, null, $store );
+
+		$this->assertIsArray( $body, sprintf( 'A %s store aborted the tax calculation.', $country ) );
+		$this->assertArrayHasKey(
+			'nexus_addresses',
+			$body,
+			sprintf( 'The store nexus was rejected for %s, where TaxJar does not need an origin state.', $country )
+		);
+		$this->assertSame( $country, $body['nexus_addresses'][0]['country'] );
+		$this->assertSame( '', $body['nexus_addresses'][0]['state'] );
+	}
+
+	/**
+	 * Non-US TaxJar-supported countries, with and without WooCommerce states.
+	 *
+	 * The `has states` flag is recorded only to document that the split is deliberate —
+	 * nothing in the assertion depends on it, which is the point.
+	 *
+	 * @return array<string, array{0: string, 1: string, 2: string}>
+	 */
+	public function provider_non_us_store_countries() {
+		return array(
+			// No states in WooCommerce.
+			'GB' => array( 'GB', 'SW1A 1AA', '' ),
+			'FR' => array( 'FR', '75001', '' ),
+			'NL' => array( 'NL', '1011 AB', '' ),
+			'DK' => array( 'DK', '1050', '' ),
+
+			// States in WooCommerce, but TaxJar rates them from the destination anyway.
+			'DE' => array( 'DE', '10117', '' ),
+			'ES' => array( 'ES', '28001', '' ),
+			'IT' => array( 'IT', '00184', '' ),
+			'AU' => array( 'AU', '2000', '' ),
+
+			// CA needs a destination state to clear `validate_taxjar_request()`; the
+			// store's own state stays blank, which is what this test is about.
+			'CA' => array( 'CA', 'M5H 2N2', 'ON' ),
+		);
+	}
+
+	/**
+	 * The US keeps the strict requirement, because there a blank state loses the tax.
+	 *
+	 * This is the one country the relaxation must not reach. US nexus is derived from
+	 * the origin state, and TaxJar does not reject a blank one — it returns HTTP 200
+	 * with `has_nexus: false` and zero tax, so an accepted blank-state US nexus is a
+	 * silent under-collection. Rejecting it here falls back to the store's `from_*`
+	 * address, which carries the real state.
+	 *
+	 * This passes before the relaxation too — it bounds the change rather than
+	 * demonstrating a fixed bug.
+	 */
+	public function test_blank_state_is_still_rejected_for_a_us_nexus() {
+		$body = $this->capture_taxjar_request_json(
+			$this->in_state_options(),
+			function ( $nexus_address ) {
+				$nexus_address['state'] = '';
+
+				return $nexus_address;
+			}
+		);
+
+		$this->assertIsArray( $body, 'A blank nexus state aborted the request instead of falling back.' );
+		$this->assertArrayNotHasKey(
+			'nexus_addresses',
+			$body,
+			'A US nexus address with a blank state was forwarded.'
+		);
+	}
 }