We couldn't find the minimums in section 3.2.1 of
pe.usps.com/text/dmm300/101.htm
, which you mentioned.
It appears the 6" x 3" x 0.25" either is not kicking or something in the plung-in isn't working right.
I'm still encountering situations where it returns no rates or incorrect rates with the wrong processing category.
Stay with me, because below is the result of hours of trial and error and parsing USPS documentation.
I am also pretty sure we discovered a bug or two in which the weight unit is used with LETTERS and FLAT processingCategory.
It started with testing an item with one 3.75 x 0.313 x 0.028, 1.5oz, up to 8 of the same decal in the cart produced a first-class letter metered at $0.74.
That seems OK.
NOTE: it should be $0.78, not metered, when using retail, I believe, since Account Type is NONE
The quantity 9+ is where we first see a problem: no rate is returned.
In the debug log, it returns:
[message] => Provided dimensions do not meet minimum allowed for First Class Flats.
[errors] => Array
(
[0] => Array
(
[title] => Provided dimensions do not meet minimum allowed for First Class Flats.
[detail] =>
[code] => 030018
Note that it changed the category to [processingCategory] => FLATS vs LETTERS; it was previously (in the log), which seems odd.
Checking our current plugin settings:
- USPS Account Type is NONE.
- Priority Mail, Ground Advantage, and First-Class Mail selected.
- Processing category is set to MACHINABLE (but setting it to ALL has the same results).
- The rate indicator restriction only has Single Piece selected.
- Price type is Retail
My understanding is that the changes in v1.4.4 of the plug-in should make it MACHINABLE under those conditions, not LETTER or FLATS
This is when I started to suspect that the plugin's minimums were wrong, but something else was wrong, too.
Per
pe.usps.com/text/dmm300/101.htm
:
For LETTERS:
Minimum is 5" x 3.5" x 0.007"
Maximum is 11.5" x 6.125" x 0.25"
Max weight is 3.5oz
For FLATS
Minimum is 11.5" x 6.125" x >0.25"
Maximum is 15.5" x 12" x 0.75"
Maximum weight 13oz.
In debug mode, when a dimension doesn't meet the minimum for a processingCategory, it defaults to the above minimum, or at least LETTERS and FLATS.
i.e., if I set the product dimension to be less than the minimum, USPS returns results for the minimum dimensions (below).
<pre>Array
(
[weight] => 0.03125
[length] => 5
[height] => 3.5
[thickness] => 0.007
[processingCategory] => LETTERS
)
</pre>
Seems fine until we test a HikaShop product with a weight of 14 and a unit type of
oz.
I'm stressing that this is the unit type set in Hikashop for the product: oz, not lbs.
<h3>01.09.26 19:20:06</h3>
<pre>Array
(
[weight] => 0.875
[length] => 11.5
[height] => 6.125
[thickness] => 0.25
[processingCategory] => LETTERS
)
</pre>
<h3>01.09.26 19:20:06</h3>
<pre>Array
(
[totalBasePrice] => 0.74
[rates] => Array
(
[0] => Array
(
[SKU] => DFLL0XXXXR00010
[description] => First Class Letter Metered
[priceType] => RETAIL
[price] => 0.74
[weight] => 0.875
[fees] => Array
(
)
[startDate] => 2025-10-05
[endDate] => 2026-01-17
[warnings] => Array
(
)
[mailClass] => FIRST-CLASS_MAIL
)
)
)
</pre>
We get a result for a LETTER, not FLAT or MACHINEABLE, despite [weight] => 0.875
or above.
My guess is that HikaShop is converting 14 oz to 0.875 lb, which seems reasonable, but it is still above the 3.5- and 13-oz maximums for letter and flats.
But we entered up to 56 oz (3.5 lb) in the HikaShop product, and it still returned LETTERS results.
Obviously, you can't fit 3.5 lbs in a letter envelope.
It is when we got to 56.1 OZ (above 3.5 lbs) in Hikashop that it finally broke:
<pre>Array
(
[weight] => 3.5000625
[length] => 11.5
[height] => 6.125
[thickness] => 0.25
[processingCategory] => LETTERS
)
</pre>
<h3>01.09.26 19:29:57</h3>
<pre>Array
(
[apiVersion] => /prices/v3
[error] => Array
(
[code] => 400
[message] => Provided weight exceeds maximum allowed for First Class Letters.
[errors] => Array
(
[0] => Array
(
[title] => Provided weight exceeds maximum allowed for First Class Letters.
[detail] =>
[code] => 030014
)
)
)
)
</pre>
<h3>01.09.26 19:29:57</h3>
<pre>Array
(
[apiVersion] => /prices/v3
[error] => Array
(
[code] => 400
[message] => Provided weight exceeds maximum allowed for First Class Letters.
[errors] => Array
(
[0] => Array
(
[title] => Provided weight exceeds maximum allowed for First Class Letters.
[detail] =>
[code] => 030014
)
)
)
)
</pre>
It seems one side uses OZ, and the other uses LBS.
Converting to LBS in HikaShop doesn't fix the problem either.
i.e, setting the product to 0.875 lb (14 oz) yields LETTERS.
It only breaks when the [weight] value exceeds 3.5, according to the debug log.
I'm not sure where the conversion problem is occurring (on the USPS side or the plug-in side).
Now back to FLATS and dimensions.
Weight-wise, if you set any of the dimensions above the minimum (thickness/height is the easiest), it goes to FLATS:
<pre>Array
(
[weight] => 13
[length] => 11.5
[height] => 6.125
[thickness] => 0.251
[processingCategory] => FLATS
)
</pre>
<h3>01.09.26 19:38:34</h3>
<pre>Array
(
[totalBasePrice] => 5.04
[rates] => Array
(
[0] => Array
(
[SKU] => DFXF0XXXXR00130
[description] => First Class Flats
[priceType] => RETAIL
[price] => 5.04
[weight] => 13
[fees] => Array
(
)
[startDate] => 2025-10-05
[endDate] => 2026-01-17
[warnings] => Array
(
)
[mailClass] => FIRST-CLASS_MAIL
)
)
)
</pre>
But the same issue as with LETTERS, USPS sees 13 oz, not 13 LBS, despite it being 13 LBS in HikaShop:
<h3>01.09.26 19:44:16</h3>
<pre>Array
(
[weight] => 13.001
[length] => 11.5
[height] => 6.125
[thickness] => 0.251
[processingCategory] => FLATS
)
</pre>
<h3>01.09.26 19:44:16</h3>
<pre>Array
(
[apiVersion] => /prices/v3
[error] => Array
(
[code] => 400
[message] => Provided weight exceeds maximum allowed for First Class Flats.
[errors] => Array
(
[0] => Array
(
[title] => Provided weight exceeds maximum allowed for First Class Flats.
[detail] =>
[code] => 030015
)
)
)
)
</pre>
However, if I adjust one of the dimensions above the maximum for FLATS (thickness/height against the easist, i.e., 0.751), it returns MACHINEABLE results!
But now it is giving us price results for lbs pricing (i.e., USPS lbs matches HikaShop lbs).
For dimensions and parcels, it seems that if any dimension exceeds FLAT's maximum, MACHINABLE will be returned. I found using the height/thickness to be the easiest, i.e., 0.75,1 but that's also generally where our problem is with thin decals. Others could have issues with width or height. It may be that we are yet to discover those products in our own catalogs.
I'm not sure what the best approach is, but the weight issue has to be fixed; otherwise, LETTERS and FLATS have real issues.
I'm not sure what the best approach is to ensure results are returned in the plug-in itself.
Obviously, the minimum and maximum values for productCategory define a range for LETTERS and FLATS; anything above those should be classified as MACHINEABLE.
I think it's the range of the minimum and maximum values for both weight and dimensions that is making it difficult.
Two other things came out of this as well, which may be a bug in the plug-in, I'm not sure:
- What we set the plug-in's pricing didn't matter for FLATS and LETTERS, the results always returned retail
- What we set the processing category to didn't seem to matter, LETTERS and FLATS are not listed but are used - I expected ALL to be required to get FLATS and LETTERS results
I hope the above helps. I'm sorry for the long post, but I wanted to share what we found and tested.
HIKASHOP ESSENTIAL 60€The basic version. With the main features for a little shop.
HIKAMARKETAdd-on Create a multivendor platform. Enable many vendors on your website.
HIKASERIALAdd-on Sale e-tickets, vouchers, gift certificates, serial numbers and more!
MARKETPLACEPlugins, modules and other kinds of integrations for HikaShop
