Why the shipping calculator on your website calculates incorrectly
A shipping calculator almost always diverges from reality not because of an error in the formula, but because of the data it calculates on.
The carrier's rate grid changes more often than it can be transferred into code: while a manager manually edits the price list in the admin panel, the carrier has already introduced a fuel surcharge or redrawn its zones.
As a result, the shipping cost calculation on the website shows one amount, while the waybill at dispatch reveals another — and it's the operator, not the website, who has to explain the difference to the customer.
The second reason is dimensions. The customer enters "a box, roughly small," while the carrier calculates volumetric weight using three measurements and compares it with the actual weight.
If the calculator only takes mass into account, a 40×30×20 cm parcel with lightweight filler will ship at the price of a kilogram, while the carrier will bill by volumetric weight.
Then there are zones and lead times: some destinations go by the long-haul tariff, some by the local one, and suburban areas are calculated separately altogether.
The third reason is manual input. A manager enters the city, postal code, or pickup method by hand, and where an exact locality code is needed, "roughly nearby" appears instead.
Integrating the carrier through its directory and API removes this layer: the address is normalized, the zone is determined automatically, and the tariff is requested at the moment of checkout rather than pulled from a week-old cache.
Separately, there's the discrepancy in surcharges — insurance, pickup from a parcel locker, door delivery, oversized cargo. If the calculator doesn't account for them, shipping calculation errors accumulate on every order and surface later in accounting. Let's break down how this is closed at the level of the calculation architecture.
How a delivery calculator with CDEK and Russian Post integration works
The calculation is built on two independent loops: a directory of populated areas and live rates. The first is cached for a long time — the list of cities and postal codes changes rarely.
The second is requested for every cart because the rate depends on weight, dimensions, declared value, and the selected mode.
CDEK integration and Russian Post integration are structured differently: for one service the rate is calculated by volumetric weight and cargo density, for the other — by shipment class and zone.
The delivery calculator brings both responses into a single structure so that the storefront compares options by unified fields.
Normalizing service responses
Each response from the delivery services' API is mapped into a common model: time in days, a "door or pickup point" flag, and size restrictions. This removes the main pain point — when the frontend starts branching by carrier name.
Timeframes are recalculated taking into account the shipment date and weekends, otherwise "3 days" on Friday and on Monday mean different things.
Cache and degradation
Rates are cached by the key "route + weight + dimensional class" for a short window. This cuts repeat requests when iterating through the cart and keeps the calculation within a second.
If a service does not respond, we show the last known rate marked "preliminary" — the buyer does not lose the cart because of someone else's failure.
Oversized items and remote zones
Heavy and bulky items go into a separate branch: some services do not accept them, some calculate by volumetric weight. Remote zones are marked as "delivery to a pickup point" — otherwise the client selects a courier that is not available there.
| Option | When it fits | Restrictions |
|---|---|---|
| Online request to services' API | Current rates, frequent changes | Dependence on the availability of a third-party service |
| Your own rate directory | Stable routes, high load | Becomes outdated when the carrier's price list changes |
| Hybrid: cache + online | Most online stores | Requires degradation and fallback logic |
CDEK and Russian Post provide rates through official interfaces, so the calculation does not have to be maintained manually.
Stages of implementing a delivery calculator on a website
Implementing a delivery calculator begins not with code, but with an audit of the current logistics: which services are already in use, how tariffs are calculated, where managers manually recalculate the cost, and on which orders the calculation diverges from the actual.
At this stage we fix the rules — where weight and dimensions come from, how zones, cash on delivery, declared value, and fitting are accounted for. Without agreed-upon tariff rules, setting up delivery calculation turns into endless edits after launch.
After that, the work proceeds in stages, each ending with a verifiable result:
- Logistics audit and requirements gathering — we analyze current orders, find discrepancies between the calculated and actual cost, and record the list of services and delivery methods.
- Approval of tariff rules — we describe the "zone / weight / dimensions / lead time" matrix, rounding rules, free delivery thresholds, and surcharges. The rules are approved by the client before development begins.
- Integration design — we determine which data is sent to the delivery services, how responses are cached, and what we show the customer if a service is unavailable or returns an error.
- Calculation setup — we connect city and pickup point directories, link the cart to tariffs, and configure the calculator's behavior when the order contents change.
- Integration testing — we run real orders: different weights, oversized items, remote zones, multiple services in a single order. We verify the calculation against actual waybills.
- Failure handling — we check what happens when a service is unavailable: the customer sees a clear message, the order is not lost, and the manager receives a notification.
- Documentation handover — we provide the integration diagram, the tariff matrix, instructions for editing the rules, and the procedure for updating the directories.
The key point is testing on real orders, not on test data: that is exactly where discrepancies in volumetric weight and oversized items surface. After handover, the client can change thresholds and surcharges independently, without contacting the developer. Describe your logistics — we will come back with an estimate and a stage-by-stage plan.
How does calculating via the CDEK API differ from calculating via Russian Post?
Calculation via the CDEK API is built around delivery zones: the service returns a tariff for a specific "sender's city → recipient's city" route, and the price depends on which zone the locality falls into.
Russian Post works differently — the tariff is calculated by the category of the locality and the weight of the shipment, not by a pair of cities.
Because of this, an order with identical contents is calculated "point to point" in one case and "region to region" in the other, and the delivery calculator must support both scenarios rather than forcing one to fit the other.
Weight and dimension limits also differ. CDEK calculates based on actual and volumetric weight, and separately accounts for oversized items and restrictions on the sum of three dimensions.
Russian Post calculates by weight in increments and strictly rejects shipments exceeding the maximum mass and size.
If these rules are not separated in the code, the customer will see a price that the service will later refuse to accept — and the order will fail at the checkout stage, not in the cart.
Tariff update frequency is the third discrepancy. With CDEK, tariffs and delivery zones change more often and come together with the service response, so they cannot be cached for long.
With Russian Post, the tariff grid is more stable but updates in batches, and a lag is possible between releases.
The differences in delivery calculation here manifest in how often you hit the API and how long you store the response in cache: too long a cache yields an outdated price, too short a one means extra requests and increased cart response time.
Error returns are the most underrated area. The CDEK API returns structured codes and clear reasons for rejection, while the Russian Post API more often returns a generic error flag, and it has to be deciphered from the request context.
Therefore, the calculator needs a normalization layer: both services are reduced to a single set of states — "calculated", "unavailable for this route", "limits exceeded", "service unavailable".
Then the interface does not depend on which service responded, and the customer sees a clear reason instead of an empty block with a price.
The practical takeaway: comparing two services by a single request is pointless — they have different pricing models, different limits, and different response discipline.
The calculator is built so that each service is calculated by its own rules, and the customer ends up with comparable options with honest timelines and clear reasons for rejection.
Case study: how a delivery calculator cut order checkout time
Before implementation, delivery cost was calculated by a manager: a request with the address and weight went manually to the carrier's personal account, the response came back within a business day, and the client saw neither the price nor the timeframe the whole time.
During peak loads, the queue of requests grew, some carts went cold, and orders were lost not because of the product, but because of uncertainty about delivery.
What was changed
We built a delivery calculator that, on the checkout page, calls the carriers' APIs itself and gives the client an exact price and timeframe.
The calculation logic was moved to the server: the browser sends only the address and the contents of the cart, while weight, dimensions, and tariff are pulled from product cards and the carrier's reference data.
- Calculation across two carriers at once — CDEK and Russian Post — with pickup point selection on a map.
- Server-side tariff cache: repeat requests for popular destinations don't hit the carrier's API and respond instantly.
- Fallback scenario: if the external service is unavailable, the client sees a price and timeframe range, and the order goes to a manager flagged for clarification.
Before and after metrics
| Metric | Before | After |
|---|---|---|
| Order checkout time | 20-40 minutes with manager involvement | 2-3 minutes without a manager |
| Calculation accuracy | manual recalculation, discrepancies for oversized items | price and timeframe match the final waybill |
| Share of orders with delivery recalculation | every other request | isolated cases |
| Load on managers | manual calculation for every cart | only disputed and non-standard shipments |
The key effect is not the response speed itself, but the fact that the client makes a purchase decision while already seeing the final amount.
Discrepancies between the price on the site and on the waybill, which previously surfaced after checkout and required back-and-forth, are gone: the tariff is calculated by the same rules as the carrier's.
The calculation is built on the carriers' official APIs — CDEK and Russian Post — with error and timeout handling, so that an unavailable external service doesn't block order checkout.
What if a carrier changes its tariffs? The tariff grid and calculation rules are moved into configuration rather than hardcoded — updating takes minutes without a release.
What if a product has no dimensions? The calculator substitutes default values and flags the order for review, instead of showing an incorrect price.
Doubts before implementation: compatibility, migration, rollback
The main risk when implementing a delivery calculator is not the calculation itself, but the junction with what already works on the site.
If you have a custom calculation by zones or fixed rates in the database, it does not need to be uprooted: a wrapper over the current logic preserves the familiar behavior of the cart, and the new module connects alongside and is enabled by a flag.
The old rates remain as a fallback mode — if the external service is unavailable, the buyer sees the price for the last known zone, not an empty block.
What if you already have your own calculation? We leave it as the default source of rates and switch to the CDEK and Russian Post API only for those destinations where the exact cost by weight and dimensions is needed. How to migrate data?
We export the order history and the zone reference to an intermediate format, verify line by line, and upload it into the new structure — we record discrepancies for each item in a report. Can you roll back?
Yes: the configuration is versioned, switching to the previous calculation is a single edit without deploying new code.
What access is needed for integration?
A test and production CDEK API key, the contract and personal account login for Russian Post, access to the site admin panel for editing the cart template, and access to the repository.
We store secrets in environment variables, not in code — when a key changes, a single value is edited.
What you receive: a diagram of the calculation flow with failure points, the configuration of rates and zones, a caching policy for API responses, a migration script for the reference data, instructions for switching and rollback, a pre-launch checklist, and delivery documentation for support.
Describe your current calculation and the site stack — we will get back to you with an estimate and a work plan.
Delivery calculator implementation timeline: stages and benchmarks
The timeline depends not on the number of carriers, but on the state of the catalog and how predictably their APIs behave. If products already have dimensions and weight, and there is a single warehouse, design and configuration go faster.
If weight is calculated by a formula from characteristics, and some items ship from multiple locations, a data normalization stage is added, and it most often determines the overall timeline.
The stages partially overlap: configuration begins while calculation rules are being agreed upon, and regional tests are launched before the interface is fully ready. Therefore, the total timeline is usually 3–5 weeks, not the sum of the table rows.
Separately, time should be set aside for access: obtaining production keys and coordinating the contract with the carrier happen in parallel and sometimes take longer than the development itself.
CDEK and Russian Post provide directories and tariffs differently, so the calculation is built through a single internal layer: each carrier is connected as a separate module, and adding a third one does not require rewriting the cart.
This also simplifies rollback — if one API fails, the calculator continues to calculate using the others.
