Vue.js delivery calculator breaks at checkout
Most often, the Vue.js delivery calculator breaks not at startup, but at the moment when the order is already being assembled and the buyer changes the address or delivery method.
The component recalculates the cost asynchronously, the response from the service arrives with a delay, and the cart on 1C-Bitrix manages to show one amount while the delivery block shows another.
The buyer sees the discrepancy, loses trust and leaves, and orders end up with items that have incorrect delivery costs, which then have to be sorted out manually.
The second bottleneck is desynchronization with the cart during a partial change of the order composition. Vue redraws only its own block, while the server-side recalculation on the Bitrix side is triggered by its own event.
If there is no single source of truth between them, then when adding or removing an item, the delivery cost calculation relies on outdated weight and dimensions.
A calculation failure manifests as a "stuck" amount or an empty field without a clear error — and checkout stops at the last step.
The third cause is the interface freezing on large orders. When the cart contains dozens of items and the calculator synchronously calls an external service for each one, the main thread is blocked, the buttons do not respond, and the buyer clicks "checkout" again.
Duplicate orders, repeated requests to the carrier's API, extra load on the server — the price of one unoptimized reaction.
We break down how this is resolved: a single data source for the cart and the calculator, deferred recalculation with state indication, and protection against repeated submission at the checkout level.
What the reworked delivery calculation provides
Recalculating the delivery cost stops being a blocking operation. Previously, every selection of a city or delivery method went to the server, waited for a response from the delivery service, and came back — with three or four changes in a row, the user saw a pause and left.
Now the calculation runs on the browser side: the rate grid and zone rules are loaded once, and recalculation when parameters change happens instantly, without contacting the server.
In our experience, this removes the main reason people abandon the cart at the checkout step — waiting for something unclear.
The second effect is resilience under peak load. When the calculation lives on the client, a traffic spike during a sale does not turn into a queue of requests to the external delivery service API.
The server serves static assets and accepts only the final order, so the "calculation not responding" class of failures disappears: the checkout page works even if the external service responds slowly.
This is the same principle used when caching a catalog — we compute the heavy things in advance and serve the light things quickly.
Vue.js here provides predictable reactivity: changing one field automatically recalculates the total, while the rate logic stays in one place and is not duplicated between the template and the script.
For the customer, this means that new delivery rules — a new zone, weight, threshold — are added by editing the configuration rather than rewriting the form.
Separately, there is synchronization with 1С: the final amount and the selected delivery method must land in the order without discrepancies.
We maintain a single source of rules — if a rate changes in the accounting system, it changes in the calculator too, so the client will not see one price on the site and another on the invoice.
How we calculate delivery: implementation options
Delivery calculation almost never comes down to a single formula: the carrier has its own tariff grid, the warehouse has zones and dimensional restrictions, and the client expects to see the cost before payment. Below are working options that are actually chosen between on projects, and their limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Fixed tariffs by zones | Small catalog, 1-2 carriers, stable conditions | Does not account for weight and dimensions; when tariffs change, it is edited manually |
| Calculation via carrier API on the server side | Multiple delivery services, up-to-date tariffs | Dependence on the availability of a third-party service, response delay |
| Calculator on Vue.js in the browser + server-side validation | Need for instant recalculation when the city, weight, or delivery method changes | Requires synchronization of rules between the frontend and backend |
| Calculation inside 1С with export to the catalog | Complex logic: contractual prices, discounts, regional coefficients | Price updates with a delay, not suitable for urgent promotions |
The calculator on Vue.js provides a responsive interface: the cost is recalculated without reloading the page while the client changes the order parameters.
But the final amount is still confirmed by the server — otherwise the calculation in the browser can be tampered with, and the order will go through with an incorrect price.
Integration with 1С is key here. Tariffs, zones, and restrictions are stored in the accounting system, from there they get into the catalog via exchange, and orders are returned back with the delivery cost already locked in.
This way, accounting and the warehouse see the same figures as the client on the website — there are no discrepancies between the storefront and the accounting system.
The choice of option depends on the number of carriers, the frequency of tariff changes, and how critical the response delay is. Let's discuss your delivery scheme — we'll come back with an estimate and an integration plan.
Stages of delivery calculator implementation
The work proceeds from analyzing the current calculation logic to handing over the finished component to support.
The order is not accidental: until it is established how the delivery cost is calculated now — taking into account zones, weight, dimensions, the free delivery threshold, and rounding rules — any integration turns into rewriting the rules by guesswork.
Therefore, we first describe the calculation as it is, then design how it will be exposed to the frontend.
- Calculation audit. We collect all sources of rules: delivery service reference books, tariff tables, regional exceptions, manual surcharges by managers. We record which data is stored in 1C, which in Bitrix, and which exists only in the head of the responsible employee.
- Integration scheme. We determine what the backend calculates and what the frontend does: heavy tariff grids go to the server, instant recalculation when the city or quantity changes goes to the client. We agree on the response format so that Vue.js receives a ready-made structure without additional calculations.
- Setting up data exchange. We connect the calculator to reference books and tariffs via standard exchange mechanisms, configure caching of tariff grids and behavior when the delivery service is unavailable — the buyer should see a clear status, not an empty block.
- Interface development. We build the component on Vue.js: selecting the city and delivery method, recalculating the cost without reloading the page, field validation, and correct operation on mobile.
- Verification. We run the calculation on control orders — boundary weights, remote zones, several services in one order — and compare the result with the manager's manual calculation. We separately check behavior when an external service fails.
- Handover to support. We provide documentation on the calculation rules, instructions for editing tariffs without a developer, and the procedure for rolling back to the previous version of the component.
Each stage ends with approval: changes to delivery rules do not go into code until the customer has confirmed that the calculation matches the commercial logic.
What the client receives
We hand over not a "finished website" but a complete package that allows the system to be operated, developed, and transferred to another team without us.
Below is exactly what remains with the client after the delivery of the delivery calculator on Vue.js and its integration with 1C-Bitrix.
- Integration configuration: connection parameters to 1C, delivery service directories, tariff zones, and cost calculation rules — moved into a separate layer rather than hardcoded.
- Interaction schemas: how the calculator frontend exchanges data with the Bitrix backend and the accounting system, where tariffs are calculated, where responses are cached.
- Access policies: separation of rights for editing tariffs and zones, administrator and manager roles, rules for handling external service keys.
- Documentation: description of the calculation logic, extension points, and the procedure for adding a new delivery service — so that edits don't require us every time.
- Operational regulations: procedure for updating tariffs, actions when an external service is unavailable, calculator behavior during a failure, and rollback rules.
- Instructions for employees: how to change delivery conditions through the admin panel without a developer and what to check after changes.
- Access and handover: repository, environments, accounts, and rights are transferred to the client with recording in the act.
Each artifact addresses a specific risk: tariffs change without a release, a new delivery service is connected according to the described template, and a failure of an external service does not break order checkout. Describe your task — we'll come back with an estimate and a work plan.
Case study: how delivery calculation stopped holding up orders
The client is a wholesale company with regional delivery and a catalog on 1C-Bitrix.
The cart calculated shipping cost on the server side: when the city or order contents changed, the page went into a full reload, and the calculation waited for a response from an external delivery service.
At peak — morning hours, when managers and retail place orders simultaneously — recalculation took 6-9 seconds, some requests timed out, and the client saw an outdated total.
Calculation errors accumulated quietly: when the city changed, items with individual dimensions were recalculated using the old tariff, and the difference was caught only at the shipping stage.
What was changed
The calculator was moved to Vue.js as a separate layer on top of the cart: the interface recalculates delivery parameters without reloading the page, and the Bitrix server side returns only confirmed tariffs.
Requests to delivery services run in parallel and are cached by the combination of "region + weight + dimensions", so a repeated calculation for the same city does not hit the external service again.
The tariff logic and recalculation rules for a city change were consolidated into a single module — previously they were spread across templates and handlers.
Before and after metrics
| Metric | Before | After |
|---|---|---|
| Recalculation time when changing city | 6-9 seconds | up to 1 second |
| Share of orders with calculation errors | ~7% | less than 0.5% |
| Behavior under peak load | timeouts, outdated totals | stable calculation, cache handles repeated requests |
| Support requests about delivery | regular | occasional |
We also separately tested behavior at peak: previously the external service could not respond in time and the cart showed the previous cost, but now, when the source is unavailable, the client sees an honest "confirming cost" instead of an incorrect figure. This eliminated a class of errors that were the most expensive at the shipping stage.
How does client-side calculation differ from server-side calculation?
Client-side calculation is when the delivery cost is calculated by the visitor's browser: a Vue.js script recalculates the cart when the city, weight, or delivery method changes and immediately shows the result.
There are no intermediate requests to the server, so the interface responds instantly and the server is not burdened with repeated requests.
The price for this is trusting the data on the client side: delivery service rates, coefficients, and restrictions must already be loaded into the browser.
Server-side calculation is performed on the 1C-Bitrix side: the browser sends the order parameters, the server contacts 1C, applies the current rates, and returns the final cost.
This option is more reliable — the rules and prices do not leave the server, they cannot be substituted through developer tools, and the logic lives in one place.
But each recalculation is a network request, and if 1C responds slowly, the visitor waits for the response while looking at the loading indicator.
In practice, a hybrid scheme wins. The initial calculation is done on the client using a pre-exported rate reference — the visitor immediately sees an estimated cost and changes the conditions without delays.
The server recalculates the final amount before placing the order, when accuracy matters: dimensional restrictions, delivery availability to the selected pickup point, and the relevance of the rate for the current date are checked. If the data diverges, the interface shows the updated amount and explains the reason.
This separation delivers both characteristics at once: speed at the selection stage and reliability at the confirmation stage.
The rate reference is updated on a schedule from 1C, so the client-side calculation does not become outdated, while the server-side check remains the single source of truth for the final amount in the order.
Common technical concerns
A delivery calculator on Vue.js is a separate layer on the frontend that communicates with 1C-Bitrix through the standard exchange.
That is why compatibility, load, and updates are handled not "by eye" but at the architecture level: the Vue component renders the form and recalculates the cost without reloading the page, while the calculation comes from 1C via REST or through exchange with caching.
Bitrix remains the source of data on products, warehouses, and rates — no duplication of logic occurs.
Separately, we check that the calculator does not break the existing template and does not conflict with component caching.
If the site already has its own calculation or a third-party delivery module, we do not rewrite everything, but connect the new layer alongside and gradually migrate traffic to it.
We keep the load manageable by sending heavy requests to 1C into the cache and updating them on a schedule, rather than on every field input.
We separate Bitrix and Vue build updates into different environments so that editing rates does not require rebuilding the frontend, and updating the core does not bring down the calculator.
Is this compatible with the current version of 1C-Bitrix and our template?
Yes. The Vue layer is connected as a separate component and does not interfere with the core. We check compatibility with your Bitrix edition, template, and current delivery modules, and we resolve conflicts at the integration stage, not after launch.
What happens to the calculator when Bitrix or 1C is updated?
Core updates and rate edits are handled separately: the calculation logic lives in 1C, the display lives in Vue. Updating one part does not affect the other, so the calculator keeps working without rebuilding the frontend.
How do we roll back changes if something goes wrong?
Each release of the calculator is versioned, and the calculation configuration is stored separately. A rollback means restoring the previous build and rate settings, without editing the database and without site downtime.
Will the calculator withstand peak load during sales?
Yes, thanks to caching of calculations and a queue of requests to 1C. When traffic spikes, the calculator returns cached values instead of hitting the database on every request, so the form remains responsive.
Let's discuss your delivery calculation task
To come back with an estimate and a work plan rather than generalities, we need to understand your calculation logic: where rates and zones come from, whether the carrier has an API or only spreadsheets, how weight is calculated — by actual weight, by volumetric coefficient, or by the sum of packages.
This determines whether the delivery calculator on Vue.js will calculate instantly in the browser or call the server for up-to-date rates.
Send us access to a test environment and examples of real orders — with them we'll reproduce the calculation and verify the result against what managers calculate manually. That way the estimate is based on your data, not assumptions.
What's worth preparing for the conversation:
- a list of carriers and services whose rates are involved in the calculation;
- the rules: zones, weight, dimensions, surcharges for remoteness, free delivery threshold;
- where prices come from — API, export, or manual spreadsheets;
- how an order is currently placed and where a manager adjusts the amount manually;
- requirements for behavior when a delivery service is unavailable — a fallback rate or refusal;
- on which pages and in which scenarios the calculator should appear;
- constraints on timelines and on what cannot be changed in the existing site.
After the review, we'll come back with an estimate, a work plan, and an integration scheme: what data the server provides, what the browser calculates, how rates are updated, and how the correctness of the amount is verified. Describe your task — we'll discuss the details and propose a solution tailored to your process.