Categories, search, and filters progressively narrow the range, while the product page surfaces what matters for purchase.

A dedicated search index

Products and their searchable attributes are synchronised from the commerce backend to Meilisearch. The index includes names, descriptions, article numbers, categories, and the parameter values customers use to identify a model.

Results that remain part of the catalogue

Search opens a normal product listing with the same cards, availability, prices, and filtering rules as category pages. A customer can begin with a broad phrase and then narrow the result by meaningful parameters.

Controlled empty and partial states

The interface explains when no exact match is found and lets the customer adjust the query or return to the catalogue. Product links remain ordinary navigable links, so search supplements rather than replaces the catalogue structure.

Checkout moves from the cart and contact details to secure payment through Robokassa.

Delivery options before payment

The geocoder validates courier addresses, Yandex Delivery calculates available tariffs, and pickup points are selected on an interactive map. The chosen method, address, cost, and estimated date are saved with the cart and shown before payment. A saved address also enables an estimate on the product page.

Fulfilment only after assembly confirmation

After successful payment, the server creates the Medusa order and places it in the assembly queue. It does not create a Yandex shipment at this stage. Once a manager confirms assembly and creates the standard Medusa fulfilment, the server sends the verified shipment data to Yandex, saves the external request number, and receives the official tracking link. This keeps warehouse confirmation as the required boundary before hand-off to the carrier.

Order status and repeat purchases

The account shows contents, payment, assembly, and delivery stages, while the profile and address book accelerate repeat checkout. Tracking uses the official carrier link stored with the fulfilment.

Cancellation and return branches

If no external shipment exists, the standard Medusa cancellation workflow is used. If an active but unshipped Yandex fulfilment already exists, the server first obtains an admissible cancellation response from the provider, then cancels the order, releases reservations, and starts a full refund of captured payment.

For an already shipped Other-Day or pickup-point order, ordinary cancellation becomes a recall and Return: the payment refund starts after Yandex accepts the stop request and a Return is created in Medusa, while inventory is restored only after the goods physically return. An express order cannot be cancelled automatically after courier hand-off and requires Yandex support.

The account separates available and pending balances, shows transaction history, and explains earning and spending rules.

A dedicated assembly queue

Paid orders enter a warehouse view where employees can select a batch, inspect photographs, article numbers and quantities, and produce the documents needed for picking, packing, and cargo units. The exports are generated from current order data rather than copied into spreadsheets.

A controlled boundary before delivery

Payment does not automatically create a Yandex shipment. The employee picks the products, confirms assembly, and creates the Medusa fulfilment; only then does the backend send verified data to Yandex and store the tracking details.

Catalogue management without a developer

Administrators manage categories, content, characteristics, variants, images, prices, stock, installation instructions, and the Ozon link. Category-specific fields keep catalogue, logistics, and SEO data aligned. Warehouse, rewards, and broader administrative permissions are separated by role.

Search engines receive complete pages

Categories and product pages are rendered on the server, exposing names, prices, descriptions, and links without requiring a crawler to run the interactive interface. Dedicated category landing pages cover meaningful assortment directions.

Stable URLs and controlled indexation

Legacy URLs redirect permanently to corresponding current content. Filtered and sorted combinations are excluded from indexing and point to the canonical category, while paginated pages remain crawlable so deeper products can be discovered.

Current structured product data

Product pages generate titles, descriptions, canonical URLs, breadcrumbs, and Product JSON-LD from current store data. Sitemap, robots.txt, Google Merchant, and Yandex YML feeds are generated from the catalogue; service pages are excluded. Confirmed purchases, rather than unverified checkout visits, are sent to Yandex Metrica.

Protected sessions and ownership checks

The site uses HTTPS and an HttpOnly session cookie with protective attributes. Yandex ID login validates the one-time state and allowed return address. The backend checks ownership whenever an account opens, repeats, cancels, or returns an order, and applies the same boundary to carts, rewards, addresses, and tracking.

Server-controlled totals and payment confirmation

Before payment, the server recalculates the cart and stores a fixed checkout state. Card details remain on the official Robokassa form. A browser redirect does not establish payment: the backend verifies the signed server notification, invoice, exact amount, and payment-session relationship.

Idempotent financial workflows

Payments, rewards, cancellations, and refunds use idempotency and server-side locking. Conflicting financial data stops automatic processing for reconciliation. Public APIs expose only the customer-facing order fields, while sensitive endpoints have dedicated rate limits.