Integration of Ukrposhta into the site

Two things: a directory and tariff classes. The address of the branch here is tied to the postal code, not to the number of the branch in the city, so the search in the basket should be done both by the name of the settlement and by the index. And tariffs are divided into express and standard with different delivery times. If you combine them into one line of "Ukrposhta", the buyer will not receive the term for which he expected, and the claim will go to you, not to the carrier.

Approximate - yes, according to weight, dimensions and declared cost. The exact amount is calculated by the carrier when receiving the shipment, and no module will bypass this. Therefore, we derive the calculation with the honest mark "approximate". What should not be done is to show "0 UAH" when delivery is paid: we saw exactly such a checkout in a store whose information page on the same domain called 35-80 UAH.

Yes, and it is noticeable. The most expensive part of the work is to get the cart delivery step right: calculation, validation, behavior when the API is not available. If this has already been done, Ukrposhta is placed as the second block in the finished scheme. The reverse is also true: if you plan both carriers, take them in one job - the checkout is processed once, not twice.

Technically yes, but conditions differ from commercial carriers and depend on the tariff and type of product. That's why the checkout check is done before the estimate: we see if your billing scenario is even supported for the rates you want to enable. Learning about pre-launch restrictions costs hours, after launch - canceled orders.

This is a separate scenario and needs to be addressed early on. A list of attachments, recipient data in Latin and a customs declaration are required. Technically, we collect this data in a form on the website and transmit it in a format accepted by the carrier. We do not undertake the customs clearance itself - it is your area of ​​responsibility, and we do not pretend that we know how to close it.

The term is 5–11 working days. By stages: checkout check 1–2 days, directory and tariffs 1–3, cost calculation 1–2, creation of shipments from admin 1–3, live run 1. The amount looks larger, because the stages are partly parallel: while the directory is being updated, the calculation is already being written. The lower limit of 3 days is real when access is available from the first day and one tariff class is enabled.

No one's hands. The directory resides in your database and is updated by a background task on a schedule - this is a conscious decision, not an API saving. If you drag the carrier on every cart render, your cart will stop working exactly when someone else's server goes down. With a local copy, at such a moment, the buyer simply sees a slightly older list of branches, and the order is processed.

We write API requests ourselves - this is done on Next.js showcases and self-written checkouts. The scope is larger than the box module setup, but there is no third-party code that will one day be deprecated. And a separate practical tip: before installing a plugin from the catalog, we open its code and look at the date of the last modification. The number of installations does not say anything about the vitality of the module.

When the number of shipments is one per month, then the carrier's office is cheaper than any development, and we will say it during the inspection, not after the bill. Another case: all goods are bulky or expensive, and Ukrposhta's tariffs are not suitable for them. Then an extra line in the cart only adds to the buyer's doubts at the moment when he almost clicked "check out".