USPS Shipping (RESTful) (USPSr)

A client still using the older cart and original USPS module is gettng this message at checkout

The message is: 80040B1A - Error: Your Web Tools API service has been disrupted because we have been unable to contact you about migrating to the newest version of our API software. Please fill out the following Migration Feedback Form to begin upgrading and restoring your service: https://forms.osi.office365.us/r/n6njkKcCaz. After completing the form, please contact [email protected]. Thank you for your attention to this matter.

Office 365? could the cart be hacked or is this legit. ?

this was mentioned in another thread. When USPS can not contact (bounce email) the original email address in the web portal account, they seem to be making the brilliant assumption, that the account is no longer in use and shut down the access using the credentials attached to that old account.

delia:

A client still using the older cart and original USPS module is gettng this message at checkout

The message is: 80040B1A - Error: Your Web Tools API service has been disrupted because we have been unable to contact you about migrating to the newest version of our API software. Please fill out the following Migration Feedback Form to begin upgrading and restoring your service: https://forms.osi.office365.us/r/n6njkKcCaz. After completing the form, please contact [email protected]. Thank you for your attention to this matter.

Office 365? could the cart be hacked or is this legit. ?

It's likely legit but if you want to be sure, try contacting the USPS web tools team. I have a feeling they will force you to migrate over.

They have been adamant about getting people to transition to the Oauth version.

It is a legitimate message but just a ridiculous way of getting my client's attention. She, like me, got her original credentials over 20 years ago. I just set her up very easily - migration is simply not necessary when you have no negotiated rates with USPS>

USPS replied within an hour after my email. But seriously? Using microsoft unbranded forms?

delia:

It is a legitimate message but just a ridiculous way of getting my client's attention. She, like me, got her original credentials over 20 years ago. I just set her up very easily - migration is simply not necessary when you have no negotiated rates with USPS>

USPS replied within an hour after my email. But seriously? Using microsoft unbranded forms?

Yeah I'll admit that is a bit dangerous. Like I know MS offers a way to put branding up at least.

One of my clients also got this "unable to contact you so we're killing your service" message.

If you are using the Webtools interface and thinking you have until the end of the year to upgrade, you could be in for a surprise. :(

Thanks to @retched and other contributors for getting this module ready in time.

In a test environment with 1.4.0, PHP 8.4, and the latest changes to 2.20A, I get a partial blank screen when attempting to edit the module's settings. I do not see this in 2.1.0.

It comes with the log file:

[20-Sep-2025 20:42:53 UTC] PHP Fatal error: Uncaught TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, array given in /MY_ADMIN/includes/functions/general.php:618Stack trace:
#0 /MY_ADMIN/includes/functions/general.php(618): htmlspecialchars_decode(Array, 2)
#1 /MY_ADMIN/modules.php(410) : eval()'d code(1): zen_cfg_read_only(Array, 'v1.4.0', 'MODULE_SHIPPING...')
#2 /MY_ADMIN/modules.php(410): eval()
#3 /MY_ADMIN/index.php(16): require('/home/my_user/...')
#4 {main}
thrown in /MY_ADMIN/includes/functions/general.php on line 618


[20-Sep-2025 20:42:53 UTC] Request URI: /MY_ADMIN/index.php?cmd=modules&set=shipping&module=uspsr&action=edit, IP address: 123.234.123.234
--> PHP Fatal error: Uncaught TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, array given in /MY_ADMIN/includes/functions/general.php:618
Stack trace:
#0 /MY_ADMIN/includes/functions/general.php(618): htmlspecialchars_decode(Array, 2)
#1 /MY_ADMIN/modules.php(410) : eval()'d code(1): zen_cfg_read_only(Array, 'v1.4.0', 'MODULE_SHIPPING...')
#2 /MY_ADMIN/modules.php(410): eval()
#3 /MY_ADMIN/index.php(16): require('/home/my_user/...')
#4 {main}
thrown in /MY_ADMIN/includes/functions/general.php on line 618.


[20-Sep-2025 20:42:53 UTC] Request URI: /MY_ADMIN/index.php?cmd=modules&set=shipping&module=uspsr&action=edit, IP address: 123.234.123.234
--> PHP Fatal error: Uncaught TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, array given in /MY_ADMIN/includes/functions/general.php:618
Stack trace:
#0 /MY_ADMIN/includes/functions/general.php(618): htmlspecialchars_decode(Array, 2)
#1 /MY_ADMIN/modules.php(410) : eval()'d code(1): zen_cfg_read_only(Array, 'v1.4.0', 'MODULE_SHIPPING...')
#2 /MY_ADMIN/modules.php(410): eval()
#3 /MY_ADMIN/index.php(16): require('/home/my_user/...')
#4 {main}
thrown in /MY_ADMIN/includes/functions/general.php on line 618.

I believe the problem may have been caused by recent changes to MY_ADMIN/includes/functions/general.php in ZC2.2.0A.

The fix that worked for me in the 2.2.0A test environment was to ensure the configuration_value's and the set_function's correctness was to run a sql patch.

UPDATE configuration SET set_function = 'zen_cfg_read_only(', 
    configuration_value = 'v1.4.0' 
WHERE configuration_key = 'MODULE_SHIPPING_USPSR_VERSION';

The original set_function was set to:

zen_cfg_read_only(['v1.4.0'],

Out of curiosity, I looked at a test site using USPR 1.2.0, and it did not have problems.

It did not have problems when upgraded to 1.4.0, but the database remained with the configuration_value as 1.2.0, and the set_function was at 'zen_cfg_select_option(['v1.2.0'],'

dbltoe:

In a test environment with 1.4.0, PHP 8.4, and the latest changes to 2.20A, I get a partial blank screen when attempting to edit the module's settings. I do not see this in 2.1.0.

It comes with the log file:

[20-Sep-2025 20:42:53 UTC] PHP Fatal error: Uncaught TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, array given in /MY_ADMIN/includes/functions/general.php:618Stack trace:
#0 /MY_ADMIN/includes/functions/general.php(618): htmlspecialchars_decode(Array, 2)
#1 /MY_ADMIN/modules.php(410) : eval()'d code(1): zen_cfg_read_only(Array, 'v1.4.0', 'MODULE_SHIPPING...')
#2 /MY_ADMIN/modules.php(410): eval()
#3 /MY_ADMIN/index.php(16): require('/home/my_user/...')
#4 {main}
thrown in /MY_ADMIN/includes/functions/general.php on line 618

[20-Sep-2025 20:42:53 UTC] Request URI: /MY_ADMIN/index.php?cmd=modules&set=shipping&module=uspsr&action=edit, IP address: 123.234.123.234
--> PHP Fatal error: Uncaught TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, array given in /MY_ADMIN/includes/functions/general.php:618
Stack trace:
#0 /MY_ADMIN/includes/functions/general.php(618): htmlspecialchars_decode(Array, 2)
#1 /MY_ADMIN/modules.php(410) : eval()'d code(1): zen_cfg_read_only(Array, 'v1.4.0', 'MODULE_SHIPPING...')
#2 /MY_ADMIN/modules.php(410): eval()
#3 /MY_ADMIN/index.php(16): require('/home/my_user/...')
#4 {main}
thrown in /MY_ADMIN/includes/functions/general.php on line 618.

[20-Sep-2025 20:42:53 UTC] Request URI: /MY_ADMIN/index.php?cmd=modules&set=shipping&module=uspsr&action=edit, IP address: 123.234.123.234
--> PHP Fatal error: Uncaught TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, array given in /MY_ADMIN/includes/functions/general.php:618
Stack trace:
#0 /MY_ADMIN/includes/functions/general.php(618): htmlspecialchars_decode(Array, 2)
#1 /MY_ADMIN/modules.php(410) : eval()'d code(1): zen_cfg_read_only(Array, 'v1.4.0', 'MODULE_SHIPPING...')
#2 /MY_ADMIN/modules.php(410): eval()
#3 /MY_ADMIN/index.php(16): require('/home/my_user/...')
#4 {main}
thrown in /MY_ADMIN/includes/functions/general.php on line 618.

> 
> I believe the problem may have been caused by recent changes to MY_ADMIN/includes/functions/general.php in **ZC2.2.0A**.
> 
> The fix that worked for me in the 2.2.0A test environment was to ensure the configuration_value's and the set_function's correctness was to run a sql patch.
> 
> ```
UPDATE configuration SET set_function = 'zen_cfg_read_only(', 
    configuration_value = 'v1.4.0' 
WHERE configuration_key = 'MODULE_SHIPPING_USPSR_VERSION';

The original set_function was set to:

zen_cfg_read_only(['v1.4.0'],

> **dbltoe:**
>
> Out of curiosity, I looked at a test site using USPR 1.2.0, and it did not have problems.
> 
> It did not have problems when upgraded to 1.4.0, but the database remained with the configuration_value as 1.2.0, and the set_function was at 'zen_cfg_select_option([\'v1.2.0\'],'

Was this an encapsulated install by chance? I'm 95% sure I had this fixeed but it might have been on the GitHub instead.

It was an encapsulated install.

dbltoe:

It was an encapsulated install.

Yup that would be the busted version. 1.4.1 would fix that.

retched:

Yup that would be the busted version. 1.4.1 would fix that.

I'll go ahead and submit this to the Module DB later. But you can find 1.4.1 here:
https://github.com/retched/ZC-USPSRestful/releases/tag/v1.4.1

Note: You might have to do a "reinstall" because of something not submitting the configuration correctly on updates. I'm actively looking into it.

Does this module max out at 1 box when quoting rates? If an order exceeds the maximum weight, should the module be quoting based on two boxes?

I’m comparing rates between the older USPS module and this new one. Both match perfectly up until I exceed the max weight (set in Admin → Shipping/Packaging which i have set to 70 lbs).

Example:

With 12 bags (67 lbs, just under the 70 lb max), both the old and new modules quote $52.93.

But if I increase to 13 bags (72.8 lbs, which should require 2 boxes), the old module quotes $69.56, while the new module drops to $34.78.

In debug, the cart weight looks correct, but the Total Quote Weight shows only half the load (36.4 lbs not seeing anything on box count logged so not sure what is happening).

debug for 12 bags:
Cart Weight: 67.2 lbs ( 67 lbs. , 3.1999999999998 oz. )
Total Quote Weight: 67.2 lbs. ( Pounds: 67, Ounces: 3.1999999999998 )
Maximum: 70 lbs , Tare Rates: Small/Medium: 0:0 Large: 0:0
Order Handling method: Box, Handling fee Domestic (Order): $0.00, Handling fee International (Order): $0.00

debug for 13 bags:
Cart Weight: 72.8 lbs ( 72 lbs. , 12.8 oz. )
Total Quote Weight: 36.4 lbs. ( Pounds: 36, Ounces: 6.4 )
Maximum: 70 lbs , Tare Rates: Small/Medium: 0:0 Large: 0:0
Order Handling method: Box, Handling fee Domestic (Order): $0.00, Handling fee International (Order): $0.00

If that cart weight is 72 lbs, that would be beyond the upper limits of most USPS services at 70.

retched:

If that cart weight is 72 lbs, that would be beyond the upper limits of most USPS services at 70.

I understand the 70 lb limit, but what I’m trying to figure out is why the Total Quote Weight shows 36.4 lbs (Pounds: 36, Ounces: 6.4) when the cart weight is 72.8 lbs.

If a customer selected that rate, I would lose money. The module should either:

Return no rate because the order exceeded the USPS service limit, or

Assume the order would be split into a 2nd box and calculate the shipment cost accordingly.

Right now, it’s doing neither—it’s returning a rate of $34.78 for a 72.8 lb order, which seems incorrect.

I am using the latest version 1.4.1 encapsulated.

marcopolo:

I understand the 70 lb limit, but what I’m trying to figure out is why the Total Quote Weight shows 36.4 lbs (Pounds: 36, Ounces: 6.4) when the cart weight is 72.8 lbs.

If a customer selected that rate, I would lose money. The module should either:

Return no rate because the order exceeded the USPS service limit, or

Assume the order would be split into a 2nd box and calculate the shipment cost accordingly.

Right now, it’s doing neither—it’s returning a rate of $34.78 for a 72.8 lb order, which seems incorrect.

I am using the latest version 1.4.1 encapsulated.

If you're generating debugs, can you post up what the request is that is being sent to USPS for quotes? Not the result but the part that shows the origin zip, destination zip, and cart weight?

retched:

If you're generating debugs, can you post up what the request is that is being sent to USPS for quotes? Not the result but the part that shows the origin zip, destination zip, and cart weight?

I’ve attached two debug files:

SHIP_uspsr_Debug_20250924_141402.log-12-bags
SHIP_uspsr_Debug_20250924_141548.log-13-bags

The only difference between these two runs is the bag count. At 12 bags, everything is correct and under the 70 lb limit. At 13 bags (which pushes the cart weight over the 70 lb USPS limit), the module behaves as described earlier.

marcopolo:

I’ve attached two debug files:

SHIP_uspsr_Debug_20250924_141402.log-12-bags
SHIP_uspsr_Debug_20250924_141548.log-13-bags

The only difference between these two runs is the bag count. At 12 bags, everything is correct and under the 70 lb limit. At 13 bags (which pushes the cart weight over the 70 lb USPS limit), the module behaves as described earlier.

So I figured it out.

After looking over classes/shipping.php: when the following lines of code are hit, the shipping weight gets cut in half.

// total weight with Tare
$_SESSION['shipping_weight'] = $shipping_weight;
if ($shipping_weight > SHIPPING_MAX_WEIGHT) { // Split into many boxes
     $zc_boxes = zen_round(($shipping_weight / SHIPPING_MAX_WEIGHT), 2);
     $shipping_num_boxes = ceil($zc_boxes);
     $shipping_weight = $shipping_weight / $shipping_num_boxes;
}

The numbers of boxes are set at two. (that's OK) The weight is divided by two. (Still fine) What is supposed to happen is the quote (of the halved weight) is supposed to be multiplied by two but that never carried over. So in your case, the quote is supposed to be sent out as 36lbs and then the end result multiplied by two.

I'll start working through this.

AND finished.

https://github.com/retched/ZC-USPSRestful/blob/main/zc_plugins/USPSRestful/v0.0.0/catalog/includes/modules/shipping/uspsr.php

Copy and replace your version of the uspsr.php file with the one linked above. If you capable, you would only have to replace the quote method. (This way you don't get the annoying 0.0.0 warning banner.)

Going to also try to improve the "hunt and peck" of the module that was used to try to scan the JSON result before making a full release. (I'm hoping that helps with the slow downs that people have reported.)

retched:

AND finished.

https://github.com/retched/ZC-USPSRestful/blob/main/zc_plugins/USPSRestful/v0.0.0/catalog/includes/modules/shipping/uspsr.php

Copy and replace your version of the uspsr.php file with the one linked above. If you capable, you would only have to replace the quote method. (This way you don't get the annoying 0.0.0 warning banner.)

Going to also try to improve the "hunt and peck" of the module that was used to try to scan the JSON result before making a full release. (I'm hoping that helps with the slow downs that people have reported.)

Tested and confirmed. Everything is working perfectly now the rates match the old module’s exactly. I tested all the way up to 100 bags and the quotes line up perfectly. Great work, and thank you!