Delivery Calculator Integration with CDEK and Russian Post
A customer fills a cart, sees a delivery cost at checkout—and leaves. According to Baymard Institute 48% of abandoned carts are due to unexpected shipping costs. We design shipping cost estimators that display the exact amount with a choice of method and timeframe before checkout. The result: checkout conversion improves by 15–25%. For example, an electronics store experienced a 20% boost in conversion, saving an average of 350 rubles per order. In this article, we explain how we build such a calculator—from data schema to integration with CDEK and Russian Post.
For example, an electronics store had an outdated cost calculator that only computed after entering all details, causing high abandonment. We implemented instant calculation via PostgreSQL caching and geospatial indexing, increasing checkout conversion by 20% in one week. Typical scenario: without upfront estimation, the customer doesn't see the final price and abandons.
Problems Solved by the Shipping Cost Calculator
Unexpected costs. The customer sees the final amount before checkout—fewer abandonments. We add caching to ensure calculation takes 200–500 ms, three times faster than a direct API call.
Non-working APIs. Carriers change versions, limits drop—our architecture with interfaces isolates failures. If CDEK goes down, the customer sees rates from the database or Russian Post.
Complex rules. Free shipping from a certain amount, zones, volumetric weight—all built into the rate table. Configured without code via the admin panel.
Faster Calculation via DB
Zone and rate tables in PostgreSQL run queries in 10–50 ms using JSONB fields for conditional rules. An external API takes 200–1000 ms. We cache the result for 5 minutes, so for repeated requests (same city and weight), the response is instant. This reduces server load and prevents rate limiting issues.
Avoiding Errors When Integrating API
The main mistake is ignoring volumetric weight. Courier services charge by volume, not actual weight. We embed a check: max(weight, length*width*height/5000). The second mistake is lack of fallback: if the carrier's API doesn't respond, we show rates from the database automatically using a circuit breaker pattern. The third mistake is slow computation without caching: we cache for 5 minutes and use debounce on the frontend.
Choosing PostgreSQL for Rates
PostgreSQL allows flexible management of zones and rates using SQL queries with array fields for regions and JSONB for additional rules. Performance: 10–50 ms per query, critical for checkout. Asynchronous fallback to database ensures we are not dependent on carrier API availability.
How We Develop the Calculator
Stages
- Analytics — determine carriers, delivery zones, free shipping rules. Collect average weight and dimensions of products. Cost: depends on project complexity.
- Schema design — create
delivery_zonesanddelivery_ratestables with indexing on carrier_id and zone_id. Design theDeliveryProviderInterface. - Service implementation — write
DeliveryCalculatorServicewith 5-minute caching and database fallback using asynchronous request handling. - API integration — connect CDEK and Russian Post via unified interface. Each service is a separate class implementing idempotency keys.
- Frontend — React component with city autocomplete via DaData. Debounce of 600 ms to avoid hammering the server.
- Testing — unit tests for service, integration tests for API, load tests for caching.
- Deploy — deploy to server, configure Redis caching if needed.
Data Schema
CREATE TABLE delivery_zones (
id BIGSERIAL PRIMARY KEY,
name VARCHAR(255),
country CHAR(2) DEFAULT 'RU',
regions TEXT[], -- FIAS region codes
cities TEXT[], -- KLADR city codes
carrier_id INT REFERENCES carriers(id)
);
CREATE TABLE delivery_rates (
id BIGSERIAL PRIMARY KEY,
carrier_id INT REFERENCES carriers(id),
zone_id BIGINT REFERENCES delivery_zones(id),
method VARCHAR(50), -- 'courier', 'pickup', 'post'
weight_from_g INT DEFAULT 0,
weight_to_g INT,
price NUMERIC(10,2) NOT NULL,
days_min SMALLINT,
days_max SMALLINT,
free_from NUMERIC(12,2), -- free when order total >= X
is_active BOOLEAN DEFAULT TRUE
);
CDEK Integration
class CdekDeliveryProvider implements DeliveryProviderInterface
{
private string $baseUrl = 'https://api.cdek.ru/v2';
public function calculate(DeliveryRequest $request, int $weightG): array
{
$token = $this->getToken();
$response = Http::withToken($token)
->post("{$this->baseUrl}/calculator/tarifflist", [
'type' => 1,
'currency' => 1,
'lang' => 'rus',
'from_location' => ['code' => config('cdek.from_city_code')],
'to_location' => ['address' => $request->destination->address],
'packages' => [[
'weight' => $weightG,
'length' => 30,
'width' => 20,
'height' => 10,
]],
]);
if (!$response->successful()) return [];
return collect($response->json('tariff_codes', []))
->map(fn($t) => new DeliveryOption(
carrierId: 'cdek',
method: $this->mapTariffToMethod($t['tariff_code']),
name: 'CDEK — ' . $t['tariff_name'],
price: $t['delivery_sum'],
daysMin: $t['period_min'],
daysMax: $t['period_max'],
))
->toArray();
}
}
Russian Post is connected similarly via the RussianPostProvider class.
Frontend Component
const DeliveryCalculator: React.FC<{ cartItems: CartItem[] }> = ({ cartItems }) => {
const [city, setCity] = useState('');
const [options, setOptions] = useState<DeliveryOption[]>([]);
const [loading, setLoading] = useState(false);
const calculate = useDebouncedCallback(async (cityValue: string) => {
if (cityValue.length < 3) return;
setLoading(true);
try {
const res = await api.post('/delivery/calculate', {
destination: cityValue,
items: cartItems.map(i => ({ product_id: i.id, quantity: i.qty })),
});
setOptions(res.data.options);
} finally {
setLoading(false);
}
}, 600);
return (
<div>
<input
placeholder="Enter delivery city"
value={city}
onChange={e => { setCity(e.target.value); calculate(e.target.value); }}
className="border rounded px-3 py-2 w-full"
/>
{loading && <p className="text-sm text-gray-400 mt-2">Calculating cost...</p>}
{options.length > 0 && (
<ul className="mt-3 space-y-2">
{options.map(opt => (
<li key={opt.id} className="flex justify-between items-center border rounded px-3 py-2">
<div>
<p className="font-medium">{opt.name}</p>
<p className="text-sm text-gray-500">{opt.daysMin}–{opt.daysMax} days</p>
</div>
<span className="font-semibold">
{opt.isFree ? 'Free' : formatPrice(opt.price)}
</span>
</li>
))}
</ul>
)}
</div>
);
};
Comparison of Carriers
| Parameter | CDEK | Russian Post |
|---|---|---|
| Delivery types | Courier, parcel locker, pickup point | Parcel locker, office, courier |
| Average delivery time | 1–5 days | 3–14 days |
| Calculation accuracy | High (API v2) | Medium (requires postal code) |
| Volumetric weight support | Yes | Yes (via volume) |
How to Avoid Common Mistakes
The most frequent oversight is ignoring volumetric weight—courier services often charge by volume rather than actual weight. We enforce max(weight, length*width*height/5000). Another pitfall is not having a fallback: if the carrier's API is down, we retrieve rates from the database automatically via DeliveryCalculatorService using a circuit breaker pattern. Lastly, slow calculations without caching lead to poor UX; we cache results for 5 minutes and debounce frontend requests.
What's Included and Timeline
Scope of work:
- Data schema (zones and rates tables).
- DeliveryCalculatorService with caching support and asynchronous fallback.
- Integration with two carriers: CDEK and Russian Post.
- React/Next.js frontend component with city autocomplete via DaData.
- API endpoint with 5-minute caching.
- Documentation on configuring rates and adding new carriers.
- Post-launch support — 1 month warranty.
Estimated timeline by stage:
| Stage | Duration |
|---|---|
| Analytics | 0.5–1 day |
| Schema design | 0.5 day |
| Service implementation | 1–1.5 days |
| API integration | 1–2 days |
| Frontend | 1–2 days |
| Testing | 0.5–1 day |
| Deploy | 0.5 day |
Total time: from 3 to 5 working days, depending on the number of carriers and tariff complexity.
Our team has 5+ years of experience in e-commerce shipping solutions, having completed 50+ projects. Implementation cost is determined individually, with significant savings per order and increase in average order value. Order the development of a shipping cost estimator so your customers see the exact cost before checkout—saving up to 500 rubles per order in avoided returns. Contact us for a project estimate.