USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?

Hello,

1.
Regarding the packing logic, where the 2x to 3.9x discrepancy almost certainly comes from, HikaShop does not have a "shipping box catalogue" concept. It does not know about your Small (1,440 cu in) or Medium (3,584 cu in) USPS boxes. What it does instead, for every quote request, is:
- Take each product's per-unit dimensions (length, width, height) and weight.
- For an order line of N units of one product, build a virtual package by stacking N units along the product's smallest dimension. So for example 6 units of a 4 x 6 x 10 in product become a single 24 x 6 x 10 in virtual package. The other two dimensions stay at the single-unit max.
- Split that into additional packages only when a hard USPS limit is reached (provided by the plugin): 70 lb total weight, or 130 in length + girth.

2.
HikaShop doesn't compute DIM weight on its side. It sends raw weight + length/width/height to USPS, and USPS applies its own DIM weight rule on their end.

3.
There is no built-in way to map "Product X => Small Box" or "Product Y => Medium Box". The dimensions sent to USPS come from the product record, not from a box library. The two workarounds we suggest to merchants in your situation are:
- Set each product's dimensions to the dimensions of the shipping box that will actually be used for one unit of that product (so a soap that goes in a 6 x 6 x 4 mailer should be configured as 6 x 6 x 4, not as the bar itself). HikaShop's stacking logic for multi-unit orders then approximates a stack of those boxes, which is usually closer to the truth than stacking the bare products.
- Use a "Group packages" toggle on the plugin (setting "Group packages") and the per-API "Packaging weight" settings (Letters / Flats / Packages) to add the empty-box weight on top, so the rated weight matches what you actually put on the scale.
The "Group packages" option is enabled by default; when disabled, each unit is rated as its own package, which would absolutely explain a 2x+ overquote on multi-unit orders. Worth a quick check that it is on for your configuration.

A few other usual suspects for 2x+ over-quotes on Ground Advantage:

- "Price type" in the plugin settings: should be Commercial in your case (you mentioned you use Click-N-Ship Commercial Plus). Retail would be substantially higher.
- "Weight approximation" and "Dimension approximation" inputs in the plugin: any non-zero value here is added on top of every package's weight / smallest-dim and can quietly inflate the rated package.
- "Has nonstandard characteristics" toggle: if on, USPS adds a nonstandard surcharge that you probably do not pay on your own labels.

To investigate your specific 2x to 3.9x gap, what would help us most is one concrete order from your data:
- The list of products in the cart, each with their HikaShop product dimensions (L x W x H, units) and weight (units) as stored in the backend, and the quantity ordered.
- The shipping destination ZIP code.
- The rate HikaShop quoted at checkout, and the rate Click-N-Ship actually charged you on the label.
- A screenshot of the USPS plugin's settings page, especially the Price type, Services, Group packages, the approximation fields, and the packaging weight fields.

4.
Yes, the plugin we released last year at www.hikashop.com/marketplace/product/290-usps.html uses the new API.

Thank you for the very detailed example. It actually points straight at the cause, and it is not the packing or dimensional weight.

On the dimensional weight edge case first, so it is out of the way: for Ground Advantage, USPS only applies dimensional weight to parcels that measure more than one cubic foot (more than 1,728 cubic inches), and only for zones 5 to 9. Your case is exactly 1,728 ci, which is the threshold, not above it, so dimensional weight does not trigger at all here. The package is rated on its actual 8.64 lb. So DIM weight is not what is inflating your quote.

The real cause is the price tier the plugin is asking USPS for. The new plugin has a "Price type" setting with three values: Retail, Commercial and Contract. You have it set to Commercial, so the USPS API returns the published Commercial Base price. The rate you actually pay through Click-N-Ship Business (your Business Rate Card) is not the published Commercial price, it is account specific negotiated pricing, which USPS exposes through the API only under the Contract price type, and only when you identify your account.

So the fix to try is:

- In the USPS plugin settings, set "Price type" to Contract.
- Fill in "Account type" with the type that matches your USPS account (EPS, PERMIT or METER, EPS being the usual one for a Click-N-Ship / online account).
- Fill in "Account number" with your USPS account number.

With those set, the plugin sends your account details to USPS and the API returns your account's contract pricing instead of the generic Commercial price. That is what should bring the quotes down to what you actually pay on the label. If your Business Rate Card is tied to that account, Contract is the price type that surfaces it.

To verify exactly what each price type returns for a given order, enable Debug mode in the plugin and place a test order through checkout. The payment log file in the HikaShop configuration page will show the request sent to USPS and the prices returned, so you can compare Commercial vs Contract side by side for the same parcel.

On your example numbers, a $25.24 Commercial quote versus $10.74 Business Rate Card is exactly the kind of gap you would expect between published Commercial and account contract pricing, so this is very likely the whole story.

On your second question about upgrading:

The breakage you described from the previous update (product images unlinking, currency reset from USD to EUR, default shipping address deleted) is not normal HikaShop update behaviour. A standard update does not touch your currency configuration, your stored product image assignments, or your addresses. There is no code in HikaShop's update mechanism (even updating from really old versions) in order to trigger what you describe. So it is most likely specific to how that one update ran on your server, not an expected behaviour of a given version jump. From what you're saying, I would say that the hikashop_config table in the database got emptied and default data got put in afterwards.

Your plan to test 6.1.0 to 6.4.1 on a cloned subdirectory first is exactly the right approach. A few points for the clone:

- A full file backup plus a full database dump is the authoritative backup. There is no separate export needed to protect image assignments or config values: the image assignments live in the database (the hikashop_file table) and the configuration lives in the hikashop_config table, so a complete database dump already captures both. The Products CSV export is not the right tool for that and is not needed for the backup.
- Run the update in one clean pass: put the site offline, make sure PHP max_execution_time and memory_limit are generous, and let the update finish without interruption.
- After updating the clone, check the configuration page (currency, default addresses) and a few products with images before touching the live site.

If the clone update completes cleanly and your config and images are intact, the live update should behave the same way.

Hi,

There is no such step or setting because this is not supposed to happen and it doesn't happen for anyone else when updating their HikaShop.
What's likely is that you have a problem with the hikashop_config table which leads to the update system behaving in an unexpected manner.
Try clicking on the "Check database" button on the configuration page of HikaShop. Does it says anything about the hikashop_config table ?

Hi,

The hikashop_config table is supposed to have a primary key on the config_namekey column, so there is only one entry per setting. The update system relies on that primary key: if an entry already exists for a setting it leaves it alone, otherwise it adds it. On your database that primary key is missing, so each update keeps adding a new (default) row for settings that already exist. When HikaShop reads the table, the last row returned by MySQL wins, which is the newly added default one, and your real settings look wiped out.

So the fix is to remove the duplicate rows (keeping one per setting) and let "Check database" put the primary key back. Rather than deleting them one namekey at a time, you can clean the whole table at once.

1. First make a backup: in phpMyAdmin, select the hikashop_config table and use Export, so you have a copy if anything goes wrong.

2. Then open the SQL tab and run this (replace PREFIX_ with your table prefix, the part before hikashop_config that you see in phpMyAdmin):

ALTER TABLE PREFIX_hikashop_config ADD COLUMN tmp_id INT AUTO_INCREMENT PRIMARY KEY;

DELETE c1 FROM PREFIX_hikashop_config c1
JOIN PREFIX_hikashop_config c2
ON c1.config_namekey = c2.config_namekey AND c1.tmp_id > c2.tmp_id;

ALTER TABLE PREFIX_hikashop_config DROP PRIMARY KEY, DROP COLUMN tmp_id;

What it does: it temporarily numbers the rows in the order they were added, deletes every duplicate while keeping the oldest one of each setting (your original value, not the default that was re-added), then removes that temporary column. It does this for every setting at once, not only cart_retaining_period_checked.

3. Click the "Check database" button again. With the duplicates gone, it will be able to add the missing primary key to hikashop_config, and the problem won't come back on the next updates.

4. Finally, go through your HikaShop configuration page settings and re-save anything that still looks wrong; now that there is a single entry per setting, the saved value sticks.

If "Check database" then reports the same kind of duplicate-key error on another table, the same approach works on that table by changing the table name (and the column it complains about).

The action_button_type error is probably linked to this and I hope the steps above will also take care of this.