[HELP] PrestaShop 8.2.0 – State Change Not Updating Shipping Price or Saving Correctly

[Shantonu Acharjee]

Hi everyone,

I'm using PrestaShop 8.2.0 on my website https://bigyanproject.com/en/ and running into a frustrating issue with shipping zone calculation and address state saving. I’ve set everything up properly, but the system isn't working as expected.

 

✅ My Setup:

I’ve created 3 shipping zones, each with different rates.

Every state is correctly assigned to the appropriate zone.

Carriers are configured with different pricing per zone.

 

❌ The Problem:

When a customer changes the state in the address form during checkout, the shipping cost does NOT update.

The correct shipping price only appears after placing the order, not during cart or checkout.

If a customer places an order using state-1, and then tries another order with state-2, the backend still shows state-1 as selected.

It's like the state isn’t saving or updating properly in the address, even when selected.


 

🔍 What I’ve Tried:

Cleared cache and forced compilation in Advanced Parameters > Performance.

Double-checked zone assignments for all states.

Verified carrier pricing for all zones.

Tried using new customer accounts and addresses — issue still persists.


 

❓What I Need Help With:

How can I force PrestaShop to recalculate the shipping cost immediately after changing the state in the address form?

Why is the selected state not saving properly in the customer’s address?

Is there a known issue in PrestaShop 8.2.0 or do I need a JavaScript or PHP override fix to handle this correctly?

[Mr Rick]

Hi,

Did you check the console, for Javascript error probably.

[Shantonu Acharjee]

I am not an expert in JavaScript. will you plese help me to solve the problem.

[El Patron]

The error is caused by a JavaScript problem in your ETS One Page Checkout module.
When you change the state during checkout, the module's code fails, so the address and shipping updates do not work correctly. This isn’t a PrestaShop core bug—it’s a problem in the ETS module (specifically in their JS file bottom-fca930273.js).

What You Should Do Now:

1. Disable the ETS One Page Checkout module and switch back to the PrestaShop default checkout.
This will let you process orders normally and avoid further stress or lost sales. PrestaShop’s native checkout works well and supports shipping/state updates as expected.

2. Create a copy of your shop for testing and troubleshooting.
On this test shop:

Enable the ETS module.

Try to reproduce the error (change states, watch for the JS error).

Debug the issue, or ask someone with JavaScript/PrestaShop experience to help track down the bug in the ETS module code.

3. Your can try to each out to the ETS module developer with the error details and your screenshot. Ask if they have an update or fix for PrestaShop 8.2 compatibility.  Also you will have a copy of the shop they can prove the fix on, then apply to production.  

4. Once the issue is fixed and you’ve tested everything works on your test copy,
update your production shop with the fixed module or code changes.
Never update directly on production—always make sure it’s working on your copy first!

In short:
Disable the ETS module on your live shop and use PrestaShop default checkout for now—this should fix your address and shipping problems instantly. Use a test copy of your shop to debug and sort out the ETS module issues without risking live orders. Once you have the fix, update production.

Let us know if you need help with setting up the test shop or finding someone to look at the JavaScript error!

Edited July 12 by El Patron (see edit history)

[El Patron]

Ok thought, saturday  morning, let's me see  if I can debug a little more....

Your main checkout JS error is not a classic code bug, but a server connectivity problem.
The error:

POST https://bigyanproject.com/en/checkout 523

is a Cloudflare 523 error, which means Cloudflare cannot connect to your origin server.

 

Quick Tip About Cloudflare and PrestaShop

I strongly recommend you don’t use Cloudflare as a proxy/cache for dynamic eCommerce shops like PrestaShop. Cloudflare can cause issues with cart/checkout, address saving, admin logins, and module compatibility unless you configure very strict page rules to bypass cache on all dynamic URLs (/cart, /order, /checkout, /admin, etc).
Most shop owners end up with random checkout failures, broken carts, and more stress than it’s worth.

What you can use Cloudflare for:

DNS only: They’re great as a nameserver/DNS provider.

Turnstile (Captcha alternative): If you need a captcha, Cloudflare Turnstile is solid.

What to avoid:

Don’t use Cloudflare’s cache/proxy/security for your front shop or admin—leave those features OFF for your dynamic store URLs.

Summary:
Cloudflare can be a good tool in the right scenario, but for most PrestaShop owners it just creates more issues than it solves. If you keep Cloudflare, set it to DNS-Only (gray cloud) for your shop’s domain and use Turnstile only.