Five delivery services in one plugin: SDEK, KIT, Business Lines, Russian Post, Boxberry

Last week the owner of an online store for industrial lubricants wrote to me. A man sells oils, hydraulic fluids, antifreeze - heavy, bulky goods that need to be delivered throughout Russia. And here’s what he said: he has five separate delivery plugins on his website. One for SDEK, one for Boxberry, one for Business Lines, another for Russian Post, and the last one for KIT. Each plugin costs from three to ten thousand rubles per year. Each one is updated on its own schedule. Each has its own settings interface. And so he sits and thinks - is it really impossible to make it all work from one place? So that the buyer at checkout can see all the delivery options at once and can select a pick-up point on the map, rather than having to dig through endless radio buttons?

I listened to him and realized that this was not a unique situation. This is a pain that almost every WooCommerce store owner in Russia faces. And the larger the store, the more acute this pain. Because five plugins are not just five subscriptions. These are five potential points of failure. Five different development teams that may abandon their product or release an update that breaks compatibility with the latest version of WordPress. These are five different styles of display on the checkout, which are inconsistent with each other and give the buyer the feeling that the site is assembled from pieces on tape.

When we designed the delivery module for COS WP Woo, we started with a simple idea: one plugin - all carriers. Not an aggregator that charges you a commission for each order. Not a universal wrapper that breaks whenever the transport company's API changes. And full-fledged direct integration with the API of each carrier, united by a single software interface. Sounds simple? In practice, this means months of work, hundreds of hours of testing and dozens of nuances that I want to talk about.

But let's start not with technical details, but with economics. Because in the end, the store owner is not interested in how beautifully we designed the architecture, but how much money he will save and how many problems will disappear from his daily life.

Arithmetic that speaks for itself

Let's do the math. Plugin for SDEK - from five thousand rubles per year for the normal version with support for API v2. Boxberry - about the same, maybe a little cheaper, three or four thousand. Business Lines - there are fewer options here, good plugins start from six thousand. Russian Post - another three to five thousand. KIT - very few people do it, but when they do it, they ask for five to seven thousand, because the market is small and there is almost no competition. Total - from fifteen to fifty thousand rubles per year only for delivery plugins. And this does not take into account the time that your technician (or you yourself) spends setting it all up, synchronizing and maintaining it in working order.

But money is not the worst thing. The worst thing is conflicts. I remember a case when one of our clients, after updating WordPress to 6.5, two out of five delivery plugins stopped working. They just stopped. The developers of one responded in a week, the second - in three weeks. All this time, the store worked with limited delivery options, lost orders and received negative reviews. Because the buyer will not figure out why his favorite transport company is not at the checkout - he will simply go to a competitor.

There is one more point that few people talk about. Each delivery plugin adds its own scripts and styles to the checkout page. One connects a jQuery widget for a map, another connects its own React component, the third connects something else. As a result, the checkout page loads in four to five seconds instead of the required two, and the conversion rate drops. There are studies that show that every additional second of loading at checkout reduces conversion by seven to ten percent. Multiply this by your average bill and the number of orders per month - the numbers are impressive.

When all carriers work from one plugin, this is one script download, one map, one AJAX request for cost calculation. Not five requests to five different APIs, but one request to your server, which on the backend in parallel queries all the necessary APIs and returns a consolidated result. The difference in speed is colossal.

How we approached the architecture: one interface - all carriers

Do you know what distinguishes a good engineering system from a bad one? A good system is designed so that adding a new element does not break existing ones. When we started designing the delivery module, the first thing we did was define a common contract for all carriers. In programming, this is called an interface, and our CarrierInterface describes exactly four things that every carrier should be able to do: provide its code and name, calculate the cost of delivery, return a list of pickup points, and check whether API keys are configured.

Why is this important to you as a store owner? Because this means that all carriers work exactly the same from a system point of view. At checkout, the buyer sees a uniform table, where for each carrier the cost, delivery time, and whether delivery is available to the door or to the pick-up point are shown. No need to understand different interfaces of different plugins. Everything looks like one because it is one.

We implemented five carriers: SDEK, KIT, Business Lines, Russian Post and Boxberry. Each of them is a separate class that implements a common interface. CdekCarrier works with SDEK API version 2.0, uses OAuth authorization and supports two tariffs - delivery to the point of issue and delivery by courier to the door. KitCarrier integrates with the KIT Auto API, which is especially relevant for intercity transportation of heavy and oversized cargo. DellineCarrier works with Business Lines, one of the largest transport companies in Russia, which is indispensable if you send pallets or large goods. PostRussiaCarrier connects to the Russian Post API via otpravka-api.pochta.ru and calculates the cost for parcels, parcels, EMS and courier delivery. Finally, BoxberryCarrier works with the Boxberry API, which is especially popular in the small and medium-sized parcel segment.

This is where I want to stop and explain why we chose direct API integration rather than an aggregator. There are solutions on the market like eShopLogistic, which act as an intermediary between your store and transport companies. The idea is beautiful - you connect one service and get access to all carriers through a single API. We ourselves used this approach on one of the projects and encountered a number of problems that forced us to reconsider our strategy.

The first and most obvious problem is an additional point of failure. When there is another service between your store and SDEK, any failure on the side of this service means that all your carriers stop working at the same time. We encountered this twice in six months - the aggregator lay down for several hours, and the entire checkout was paralyzed. With direct integration, if the SDEK API does not respond, all other carriers continue to work. The buyer simply will not see the SDEK options, but will be able to choose Boxberry or Business Lines.

The second problem is speed. The request through the aggregator goes like this: your server → aggregator → carrier API → aggregator → your server. This is an additional one hundred to two hundred milliseconds for each request, which adds up to a noticeable delay at checkout. With direct integration, your server directly accesses the carrier's API, and the response comes faster.

The third problem is data relevance. Aggregators do not always immediately pick up changes in the API of transport companies. When SDEK updated its API to version 2.0, some aggregators still worked for months on the old version and returned inaccurate data on costs and terms. With direct integration, you work with the latest version of the API and get the most accurate calculations.

To be honest, direct integration has one downside - it is difficult to support. When each carrier updates its API, we need to update the corresponding class in our plugin. But this is exactly why there is a single CarrierInterface - changes in one carrier do not affect the others. We can easily update CdekCarrier without touching BoxberryCarrier, and everything will continue to work.

What if we look at it from another perspective? Imagine that tomorrow a new transport company appears on the market that offers excellent rates to your region. With our architecture, adding a new carrier is creating one new class that implements the same interface. No changes to existing code, no risk of breaking anything. We created a class, registered it in the system - and it already appeared at checkout next to the others. Try to achieve this with five separate plugins from different developers.

FIAS, addresses and why string search is a path to nowhere

There is one topic that delivery plugin developers are usually shyly silent about. This is a problem of determining the recipient city. It would seem that there is nothing complicated here - the buyer entered the city, the system transferred it to the transport company, and they received a calculation. But in practice everything is much more fun.

Try entering “Chelyabinsk” into different APIs - everything will work fine. Now try Nizhny Tagil. Or “Naberezhnye Chelny”. Or "Rostov-on-Don". Each transport company has its own directory of cities, its own name format, and its own codes. SDEK uses its own internal city codes. Boxberry - ours. Business Lines - your own terminals. Russian Post operates according to postal codes. And now you are writing converters from one format to another, handling differences in spelling (with or without a hyphen, in what order the words appear), and it turns into an endless support nightmare.

We solved this problem fundamentally. Instead of matching string city names between different APIs, we use FIAS - Federal Information Address System. This is the official address classifier of the Russian Federation, where each locality is assigned a unique identifier - GUID. This identifier does not depend on how you write the name of the city - Cyrillic, Latin, with or without a typo.

In our system, each shipping class in WooCommerce is tied to the FIAS code of the city of dispatch. This means that when a product is sent from a certain warehouse, the system knows exactly which city it is sent from - not by its string name, but by a unique identifier in the federal directory. For the recipient's city, we use a combination of methods - FIAS code, if available, or postal code for Russian Post, or internal city code for those carriers that provide a city search API.

I've been wondering for a long time why other developers aren't using this approach. The answer, as usual, is simple - it is more difficult to implement. String search is one line of code. FIAS integration is a separate ShippingFias class that adds a FIAS code column to the WooCommerce shipping class settings, stores these codes in taxonomy metadata, and provides them when calculating shipping. But the result is worth the effort - the calculation works correctly for any city in Russia, without errors due to differences in the spelling of names.

Here is a specific example from our practice. One of the clients sold oils throughout Russia and was faced with the fact that when sending to the city of Noyabrsk, the old SDEK plugin could not find this city, because in its internal directory the city was recorded as “Noyabrsk (Tyumen region)”, and the buyer entered simply “Noyabrsk”. The order was stuck, the manager called the client, clarified the address, and manually created an application on the SDEK website. Multiply this by twenty to thirty such cases per month and you will understand the scale of the problem. With FIAS, this problem simply does not exist, because Noyabrsk has one and only one GUID in the federal directory, and all carriers receive exactly that.

There is one more aspect of working with addresses that is worth mentioning - grouping goods by dispatch warehouses. In real business, especially in the B2B segment, goods are often stored in different warehouses. One of our clients had Shell oils in a warehouse in Chelyabinsk, Lukoil oils in a warehouse in Nerson, and hydraulic fluids in a marketing warehouse in another location. Each warehouse is its own delivery class in WooCommerce with an associated FIAS code. When a buyer adds items from different warehouses to the cart, our system automatically groups them and calculates the shipping cost separately for each group. The buyer sees that delivery costs so much for Shell oils, and so much for Lukoil oils, and the total cost is this. Transparent, understandable, without hidden surprises.

Checkout you can be proud of: delivery matrix and pickup point map

Now let's talk about what the buyer sees. Because you can build the perfect architecture on the backend, but if at checkout everything looks like an Excel spreadsheet from 1998, no one will be better off.

We have built a delivery matrix - a table in which the buyer sees all available options from all connected carriers. For each option, the name of the carrier, type of delivery (to the door or to the pick-up point), cost and estimated time are shown. The buyer selects the appropriate option with one click. If he has chosen delivery to the pick-up point, a map opens with the marked points of the carrier he has chosen. On the map you can find the nearest pick-up point, see its address and opening hours.

You know what has always annoyed me about existing delivery plugins? They show the options sequentially - first all SDEK options, then all Boxberry options, then all Russian Post options. And the buyer himself must scroll through this endless list, comparing prices and terms. Everything is clear in our matrix - all carriers are nearby, compare and choose. I believe that this significantly affects conversion, although we have not yet conducted accurate A/B tests for this particular element. But logic dictates: the easier it is for a person to make a decision, the faster he will place an order.

It is worth mentioning separately about the technical implementation of the matrix at checkout. WooCommerce provides a standard Shipping Methods mechanism, and our module registers a single shipping method with the ID wpaic_shipping. One method, not five separate ones. This means that all carriers work within the same WooCommerce Shipping Method, integrate correctly with WooCommerce shipping zones, and do not conflict with other shipping methods you may use (for example, curbside pickup or free shipping over a certain order amount).

Cost calculation occurs in real time through the API of each carrier. When the buyer enters his address at checkout, our plugin sends the order parameters (weight, dimensions, declared value, recipient city) to each connected API and receives back the cost and delivery time. Results are cached for ten minutes—this is a configurable setting—to avoid burdening the API with redundant requests if a customer refreshes the page or changes the number of items in the cart.

Here I want to talk about one technical nuance that may seem trivial, but in practice it cost us several days of debugging. In WooCommerce, session data is strings. When you get the weight of an item from a session, you get the string "1.5" rather than the number 1.5. And if you pass this string to the round() function in PHP 8.x without explicitly casting it to float, you will get an error. It sounds trivial, but imagine that you have five carriers and each of them receives data from the session - if at least one developer forgets about type casting, the cost calculation will break. In our code, each numeric value from the parameters is explicitly converted to a float before mathematical operations. Trifle? Yes. But it is precisely these little things that make up stable work.

And here’s another point that I think is fundamentally important. Delivery calculations are rendered through the woocommerce_review_order_before_payment hook, and not through before_order_review, as many guides advise. Why? Because before_order_review does not work correctly with block WordPress themes, which are becoming a standard. We spent a lot of time figuring out why the delivery matrix was simply not appearing on one of our test sites with the Twenty Twenty-Five theme until we discovered that the before_order_review hook in block themes was triggered before the checkout form had fully rendered. Switching to before_payment solved the problem. There are dozens of such nuances, and they are what distinguish a plugin that “seems to work” from a plugin that works reliably.

Tracking: from order creation to parcel delivery

Delivery is not only about calculating the cost and choosing a carrier at checkout. This is also what happens after placing an order. The buyer wants to know where his package is, when it will arrive and what to do if something goes wrong. This is where chaos begins for most WooCommerce stores.

A typical scenario looks like this: a manager places a shipment on the transport company’s website, gets the tracking number, copies it, pastes it into the order note in WooCommerce, and maybe - maybe! — sends the buyer an email with this number. The buyer receives a letter, goes to the carrier’s website, enters the track number, and checks the status. If the carrier is different, he needs to know which site to check on. If the order contains goods from several carriers (remember about grouping by warehouses?), the buyer needs to track several track numbers on different websites.

We have integrated tracking of shipments directly into the system. When the manager enters the track number in the order card, the buyer sees it in his personal account on the store’s website. No need to go to third-party sites, no need to remember which carrier delivers which part of the order. Everything is in one place - carrier name, track number, current status. When the shipment status changes, the buyer receives an email notification.

I often hear the question: “Why do this in a plugin if the buyer can already check the track on the carrier’s website?” The answer is simple - because it's about customer experience. A store in which all information is available in one place - in your personal account - is perceived as more professional and reliable. The buyer does not think “I ordered on some website, but it’s delivered by SDEK.” He thinks, “I ordered from this store and they made sure it was easy for me to track the delivery.” It's the little things that build loyalty.

Now let's talk about the seller's side. If you have an online store with dozens of orders a day, managing delivery becomes a chore. Track numbers, statuses, notifications - all this needs to be controlled. Our delivery module integrates with the 1C module, which is also part of COS WP Woo. This means that shipment statuses can be synchronized with your accounting system. The manager in 1C sees that the order has been sent, what is its track number, what is the carrier, what is the current status. No need to switch between multiple systems - everything is synchronized.

I know a lot of people are skeptical about the "all in one plugin" idea. And I understand this skepticism. Universal solutions are often inferior to specialized ones in terms of elaboration. But there is an important nuance here: we do not make one plugin for everything. We are making one plugin for the WooCommerce store ecosystem, where all modules work together and exchange data. The delivery module knows about the 1C module. The 1C module knows about the B2B module. The B2B module knows about the email notifications module. This is not a collection of disparate functions crammed into one ZIP file - it is an integrated system, where each module enhances the others.

Russian Post is a carrier that has always stood apart

I want to talk about Russian Post separately, because its integration is a separate story, full of pain and joy at the same time. Russian Post is the country's largest logistics network. More than forty two thousand branches. Delivery to any locality, including villages and towns, where no commercial carrier will go. For many stores, Russian Post is the only way to deliver goods to remote regions.

At the same time, the Russian Post API is, to put it mildly, a peculiar thing. They have two APIs: a tariff calculator (public, without authorization) and a sending API (with authorization through a token and login). The tariff calculator works by postal code - you pass the sending index, receiving index, weight, type of item and declared value, and get the cost. It sounds simple, but the devil, as always, is in the details.

The dispatch type is something that confuses most developers. Parcel, parcel post, EMS, courier delivery - each type has its own code, its own restrictions on weight and dimensions, and its own tariff schedule. Our PostRussiaCarrier automatically determines the optimal type of shipment based on the weight and declared value of the order. If the parcel is light, it is calculated as a parcel post (it’s cheaper). If it’s heavy, it’s like a standard parcel. If the buyer wants faster, he offers EMS or courier delivery. The buyer sees all available options with prices and terms and chooses what suits him.

Error handling is a different story. The Russian Post API may return an error for a completely unobvious reason - for example, because the postal code refers to a military unit or a closed territorial entity. In such cases, our plugin does not show the buyer a cryptographic error message, but simply does not display Russian Post options, leaving other carriers available. This seems like a small thing, but for the buyer there is a huge difference - between “Error in delivery calculation, try again later” and a normally working checkout, where one of the options is simply not available.

And this is where the fun begins from an architectural point of view. Remember when I talked about the single CarrierInterface? Each carrier in the calculate() method returns a standardized result - success status, price, deadline, error text (if any) and carrier code. This means that the results processing system is absolutely the same for all carriers. If SDEK returned an error, we display the rest. If Russian Post returned an error, we display the rest. If everyone returned a successful result, we show the full matrix. The logic is simple and reliable, because it does not depend on the specifics of a particular carrier.

SDEK and Boxberry are two giants that should be friends

SDEK and Boxberry are perhaps the two most popular carriers for online stores in Russia. SDEK has a huge network of delivery points - more than four thousand across the country. Boxberry has its own advantages, especially in the segment of small parcels and in regions where SDEK is poorly represented. Many stores connect both services to give the buyer maximum choice.

SDEK switched to API v2.0, which uses OAuth authorization. This means that to gain access to the API, you must first obtain an access token by exchanging client_id and client_secret for a temporary bearer token. Our CdekCarrier handles this automatically - receives the token, caches it in WordPress transients, automatically updates it when it expires. For you as a user, this means that you enter client_id and client_secret in the plugin settings once and never think about it again.

The situation with Boxberry is simpler - they have authorization through a token, which is passed as a request parameter. But Boxberry has its own difficulties in defining a city. Boxberry uses its own internal city directory with its own codes. Our BoxberryCarrier first resolves the buyer's city - finds its code in the Boxberry directory by name and postal code - and only then calculates the delivery cost. If the city is not found (which happens in small towns), Boxberry simply does not appear in the delivery matrix, and the buyer can choose another carrier.

An interesting thing I've noticed over the years of working with delivery is that customers are very loyal to "their" carrier. Some people choose only SDEK as a matter of principle, because there is a convenient pick-up point near their house. Some people prefer Boxberry because they deliver faster to their region. Some people love Business Lines because they reliably deliver heavy loads. And the store’s task is not to impose a specific carrier on the buyer, but to give a choice. The more options there are, the higher the likelihood that the buyer will find what suits him and complete the order.

But there is another side to the coin. Each additional carrier means additional API keys that need to be obtained and configured. For SDEK you need to register an agreement and gain access to the API. For Boxberry - get a token. For Business Lines - enter into an agreement and receive an API key. For Russian Post - register at otpravka.pochta.ru and receive an authorization token. For KIT it’s the same. We cannot do this part for you - it is a process between you and the shipping company. But we can - and do - provide clear instructions in the plugin settings on where and how to get each key, with direct links to the registration pages.

Do you know what's the best part? The is_configured() method in each carrier checks whether the API keys are configured. If not, the carrier simply does not participate in the calculation. This means that you can first connect only SDEK and Boxberry, and then, when you agree with Business Lines and KIT, add them by simply entering the keys in the settings. No reconfigurations, no repeated tests. The system will automatically pick up new carriers and start showing them at checkout.

KIT and Business Lines - for those who carry serious cargo

There is a market segment that SDEK and Boxberry do not serve very well - these are large and heavy cargo. A 20 liter canister of motor oil weighs about 18 kilograms. A 200 liter barrel is already about 200 kilograms. Pallet of oils - 500-800 kilograms. Such cargo requires carriers who specialize in consolidated cargo and have terminals for receiving large shipments.

KIT (Industrial Transportation Company) is one of the leaders in the segment of intercity road freight transportation. They have more than five hundred terminals throughout Russia, and they cope well with cargo from 20 to 20,000 kilograms. For our clients who sell industrial oils and lubricants, KIT often turns out to be the best choice in terms of price/speed ratio for intercity shipments.

Business Lines is another major player in this segment, with more than a thousand terminals and branches throughout Russia. Their API allows you to calculate the cost of delivery both to the terminal and to the recipient’s door, taking into account additional services - insurance, rigid packaging, lifting to the floor.

When we integrated KIT and Business Lines, we were faced with the fact that their APIs are structured completely differently than those of SDEK or Boxberry. They have a different authorization model, a different request and response format, and a different logic for determining terminals. But this is precisely the value of a single interface - all these differences are hidden within specific carrier classes. From the outside, for the delivery calculation system, all carriers look the same: we call calculate(), get the price and deadline. We call get_terminals() and get a list of pickup points. Everything is uniform, everything is predictable.

For a store owner who sells heavy goods, the presence of KIT and Business Lines in the same plugin where SDEK and Boxberry are already installed is not just convenience. This is an expansion of delivery geography and a reduction in cost for the end buyer. Because to send a 100-kilogram order through SDEK the cost can be ten thousand rubles, and through KIT - three thousand. And when the buyer sees both options side by side at the checkout, he makes an informed choice and does not feel that the store is trying to make money on delivery.

I often hear from store owners: “Why do I need KIT or Business Lines? I have small goods, SDEK and Boxberry are enough.” And in most cases this is true. But here’s what I noticed: as soon as the store begins to grow and expand its assortment, sooner or later products appear for which SDEK and Boxberry are not the best choice. And if by this moment you already have a plugin with support for KIT and Business Lines, you just need to get the API keys and enter them in the settings. If not, you need to look for a new plugin, buy it, configure it, test it, and hope that it won’t conflict with existing ones.

Caching and performance: making checkout work

I already mentioned caching, but I want to go into more detail about it because it is a critical topic for any online store. Each request to a carrier's API is a network request that takes anywhere from two hundred milliseconds to two seconds, depending on the carrier and how busy its servers are. If you have five connected carriers and for each you need to calculate two options (courier and pick-up point), that’s ten network requests. Consistently - this is ten to twenty seconds of waiting at checkout. In parallel, it’s two to three seconds, but the load on your server is still significant.

Our approach is to cache calculation results for ten minutes (configurable parameter cache_ttl). The cache key is formed from the order parameters: city of dispatch, city of receipt, weight, declared value. If the buyer refreshes the page or goes to checkout again with the same set of products, the calculation results are returned from the cache instantly. If he changes the quantity of goods or the delivery address, the cache is invalidated and the calculation is performed again.

Ten minutes is a reasonable compromise between data relevance and performance. Tariffs of transport companies do not change every minute. They can change once a day, once a week or once a month. A ten-minute cache ensures that the buyer receives the current price, but the checkout will not be slowed down due to redundant requests to the API.

There is another aspect related to performance that few people think about. When you use five separate delivery plugins, each of them includes its own PHP classes, its own WordPress hooks, its own AJAX handlers. This is an additional load on the server with each request, even if the buyer is not on the checkout page. In our plugin, all carriers are lightweight PHP classes that are loaded and initialized only when they are actually needed, that is, when calculating delivery. They do not add hooks to every page of the site, nor do they include scripts on pages where delivery is not needed.

What does this all mean for your business?

I started this article with a story about a lubricant store owner, and I want to return to it. After he switched from five separate plugins to our delivery module, a few things happened. The savings on subscriptions amounted to about thirty thousand rubles per year. Checkout loading time has been reduced from five seconds to one and a half. The number of support calls regarding delivery has dropped by forty percent. And - perhaps most importantly - he no longer fears WordPress updates, because now he has one plugin instead of five, and one team is responsible for its compatibility, instead of five different developers.

But I don't want to give the impression that our solution is perfect for everyone. If you have a small store with twenty orders a month and the only carrier is SDEK, a free plugin for SDEK is probably enough for you. Our delivery module comes into full play when you have several carriers, several shipping warehouses, when checkout speed and uniformity of customer experience are important to you. When you need integration with 1C to synchronize statuses. When you sell both light goods (SDEK, Boxberry, Russian Post) and heavy ones (KIT, Business Lines) - and you want it all to work as a single mechanism.

There is another argument that I have been thinking about recently. The transport services market in Russia is changing. New carriers appear, old ones change their conditions, some leave certain regions. When you have a single carrier interface architecture, adapting to these changes is quick and painless. Need to add a new carrier? Create a new class that implements CarrierInterface. Need to disable the carrier? We remove its API keys from the settings, and it simply stops being displayed at checkout. Need to update your integration with a carrier that has changed its API? We update one class and leave the rest alone. This is flexibility that you can't get with a bunch of disparate plugins.

I debated for a long time whether to write this article because the topic of delivery seems boring. This is not artificial intelligence, not blockchain, not some fancy technology. But you know what - delivery directly affects money. For checkout conversion, for support costs, for customer loyalty, for business scalability. And when you find a solution that makes delivery easier, faster and cheaper - it may not sound so nice at a conference, but this is exactly what real businesses need.

We continue to develop the delivery module. The plans include expanding the list of carriers, deeper integration with the API for automatic creation of requests, and an interactive map with a visual display of all pick-up points at checkout. But already now what we have - five carriers, a single interface, FIAS addresses, a checkout matrix, tracking and integration with 1C - covers the needs of the vast majority of WooCommerce stores in Russia.

One last thing. People often tell me: “All in one means that if the plugin breaks, everything breaks.” A fair concern. But let's be honest - if you have five separate plugins and one of them is broken, part of your checkout is also broken. And if two out of five are broken, you are still frantically looking for a solution. The difference is that with one plugin you have one support team, one feedback channel, one update process. And if something goes wrong, you know where to turn. Instead of figuring out which of the five plugins is to blame for the conflict, you write to us and we will solve the problem. It's not a perfect world, but it is a world where problems are solved faster.

Try COS WP Woo - 14 days free. One plugin instead of five for delivery, plus another forty-odd modules for your WooCommerce store. Connect SDEK, Boxberry, Business Lines, Russian Post and KIT in one evening, not in a week. Set it up once and forget about the headache of delivery.