UPSTREAM FIX

magento2-40307: UPS REST rate requests treating commercial destinations as residential

Community fix magento2-40307 merged into magento/magento2 on 2026-01-16, released in 2.4.9; applies cleanly to 17 releases from 2.4.7 to 2.4.8-p5.

Fixes UPS REST rate requests treating commercial destinations as residential edited

Pull request title: Commercial destination should not be treated as residential
Pull request: magento/magento2#40307
Issues: #40314 pr-derived
Author: @dmytrokaplin
Merged: 2026-01-16
Fixed in: 2.4.9
Reported on: —
Categories: Shipping
Components: magento/module-ups

Labels

Area: Shipping
Component: Ups
Priority: P2
Severity: —
Reported on (labels): 2.4.x

Issue

Title and steps come from the upstream issue and pull request.

Description

The UPS REST rate request builder in \Magento\Ups\Model\Carrier always includes the ResidentialAddressIndicator field in the ShipTo.Address section, even when the destination type is commercial (49_residential = "02").

Steps to reproduce

#### Scenario 1: Commercial destination should not be treated as residential

1. Configure UPS shipping in Magento with valid UPS credentials and enable the REST API integration (US → US shipment).
2. Create a quote/cart with:
- Origin in the US (e.g. Miami, FL 33127).
- Destination in the US with a commercial destination type (49_residential = "02").
- A package weight of approximately 20.8 lbs.
3. Request shipping rates (via storefront checkout or REST API).
4. Before the fix:
- Inspect the UPS REST request (debug/logs):
- ShipTo.Address.ResidentialAddressIndicator is present with an empty value.
- UPS returns rates that include “Demand Surcharge - Residential is applied on Package 0” and higher total charges.
5. After the fix:
- Inspect the UPS REST request again:
- ShipTo.Address does not contain the ResidentialAddressIndicator field for 49_residential = "02".
- UPS returns commercial rates (no “Demand Surcharge - Residential” message), and totals match expected commercial pricing.

#### Scenario 2: Residential destination still behaves as residential

1. Using the same configuration, create a quote/cart with a residential destination (49_residential = "01").
2. Request shipping rates.
3. Verify that:
- ShipTo.Address.ResidentialAddressIndicator is present in the UPS REST request.
- UPS returns rates that include residential surcharge (e.g. “Demand Surcharge - Residential is applied on Package 0”).
- Behavior matches previous residential handling and the XML-based UPS rates.

### Resolved issues:
1. [x] resolves magento/magento2#40314: Commercial destination should not be treated as residential

Taken from the upstream pull request.

Code match per tag

Each tag was checked with git apply --check against that tag's files. A clean match means the change applies; it is not a test result. Tags that already contain the fix are marked.

Line	Code match per tag	Tests
2.4.6	2.4.6 conflict 2.4.6-p1 conflict 2.4.6-p2 conflict 2.4.6-p3 conflict 2.4.6-p4 conflict 2.4.6-p5 conflict 2.4.6-p6 conflict 2.4.6-p7 conflict 2.4.6-p8 conflict 2.4.6-p9 conflict 2.4.6-p10 conflict 2.4.6-p11 conflict 2.4.6-p12 conflict 2.4.6-p13 conflict 2.4.6-p14 conflict 2.4.6-p15 conflict	2.4.6: no test data 2.4.6-p1: no test data 2.4.6-p2: no test data 2.4.6-p3: no test data 2.4.6-p4: no test data 2.4.6-p5: no test data 2.4.6-p6: no test data 2.4.6-p7: no test data 2.4.6-p8: no test data 2.4.6-p9: no test data 2.4.6-p10: no test data 2.4.6-p11: no test data 2.4.6-p12: no test data 2.4.6-p13: no test data 2.4.6-p14: no test data 2.4.6-p15: no test data
2.4.7	2.4.7 clean 2.4.7-p1 clean 2.4.7-p2 clean 2.4.7-p3 clean 2.4.7-p4 clean 2.4.7-p5 clean 2.4.7-p6 clean 2.4.7-p7 clean 2.4.7-p8 clean 2.4.7-p9 clean 2.4.7-p10 clean	2.4.7: no test data 2.4.7-p1: no test data 2.4.7-p2: no test data 2.4.7-p3: no test data 2.4.7-p4: no test data 2.4.7-p5: no test data 2.4.7-p6: no test data 2.4.7-p7: no test data 2.4.7-p8: no test data 2.4.7-p9: no test data 2.4.7-p10: passes before and after (test does not cover the fix)integration: passes before and after
2.4.8	2.4.8 clean 2.4.8-p1 clean 2.4.8-p2 clean 2.4.8-p3 clean 2.4.8-p4 clean 2.4.8-p5 clean	2.4.8: no test data 2.4.8-p1: no test data 2.4.8-p2: no test data 2.4.8-p3: no test data 2.4.8-p4: no test data 2.4.8-p5: passes before and after (test does not cover the fix)integration: passes before and after
2.4.9	2.4.9 conflictcontains the fix	2.4.9: no test data

Triage

Model @cf/cloudflare/clef. Probability this is a bug fix: 97.1%. Probability it is security relevant: 0.7%.

Show the model's answers and probabilities

Question	Answer	Probabilities	Confidence
Change kind	bugfix	bugfix 97.0%, refactor 1.0%, tests_only 0.7%, feature 0.7%, dependency 0.3%, docs_only 0.3%	93.0%
Area	checkout	checkout 95.9%, other 0.9%, graphql_api 0.7%	90.9%
Reported version	unspecified	unspecified 24.0%, 2.4.6 3.2%, 2.4.8 2.5%	5.6%
Scope	0.66 of 2	0 45.3%, 1 43.1%, 2 11.5%	10.7%
Risk	0.49 of 2	0 69.0%, 2 17.9%, 1 13.1%	28.8%
Worth backporting	1.70 of 2	2 74.6%, 1 20.4%, 0 5.0%	40.1%

Download

For cweagans/composer-patches, choose a version below and download the bundle. Copy its magento2-40307/ folder into patches/composer/, merge composer.patches.json into composer.json, then run composer install. Test files are always removed; paths are relative to each package root, using the default -p1 level.

Bundle README (what the ZIP ships)

# magento2-40307

Community fix merged upstream into magento/magento2, adapted by magento.watch.
This is not a patch published by Adobe.

Pull request: https://github.com/magento/magento2/pull/40307
Issue: https://github.com/magento/magento2/issues/40314
Author: @dmytrokaplin
Source commit: 0d3de781d2a00664bc0ac6e3ef06fb499318e9c9
Modifications: test files and documentation removed, paths rewritten relative to each Composer package.
Licence: OSL-3.0 / AFL-3.0, as the original Magento Open Source code.
Maintainer: Łukasz Bajsarowicz (@lbajsarowicz)

Licence: Magento Open Source code under OSL-3.0 and AFL-3.0. The bundle carries the original author, source commit and the list of modifications.