06 Fashion brand online store: catalog, orders, payments, and customer account

The brand had a requirement that off the shelf platforms handle poorly: its own product logic. Clothing isn't just a product card with a price, it's a size grid, colors, height ranges, collections, and seasons. On a website builder this gets expressed through workarounds: 'size' becomes a product property, every combination becomes a separate item, and a catalog of a hundred models turns into thousands of cards that become impossible to maintain.

The second problem was the warehouse. The company kept its inventory in MoySklad and 1C, and that's the right place for it. But the store knew nothing about it: on-site availability was a separate list that someone maintained by hand. The mismatch was discovered in the most expensive way possible: a customer would place and pay for an order for something that was no longer in stock.

The mismatch between the warehouse and the site was discovered in the most expensive way possible: a customer would place and pay for an order for something that was no longer in stock.

The third problem: orders lived in a gap. Payment arrived in one place, the order was handed off for fulfillment in another, and the customer was told the status in a third. Between these places stood an employee who carried the data across and, like any person, sometimes didn't do it in time.

And the fourth: support turned into an information desk. Most inquiries weren't about problems, they were about 'where's my order,' 'what did I order last time,' 'what size was it.' Every one of these questions cost an employee's time, even though the system already had the answer, the customer simply couldn't see it.

A complete store, not a storefront layered on top of someone else's platform. The catalog is built around the brand's own product logic: a model, its colors, and its size grid are one entity with variants, not a scattering of independent cards. The customer picks a size inside the model's card, and the content manager maintains one item instead of twenty.

Checkout is kept short and reliable: cart, delivery, payment. Payment is accepted through YooKassa, and the order changes status once the payment is actually confirmed, not the moment a button is clicked, meaning the system knows the money has actually arrived and doesn't send an unpaid order to fulfillment.

A model with its colors and size grid is one entity with variants, not twenty independent cards. The content manager maintains an item, not a combinatorial explosion.

The customer account closes off that exact stream of support questions. A person sees their orders, their contents, statuses, and history without asking anyone. This isn't a 'nice to have,' it's a reduction in staff workload measured by the number of messages that never had to be written.

And the admin panel, the brand team's actual workspace. Products and collections, orders and their statuses, customers, storefront content. Built around how the brand actually works, not around a generic 'product, order, customer' template that they'd then have to adapt to.

The accounting systems stayed where they were: MoySklad and 1C remained the place where inventory and accounting are kept, and the store doesn't replace or duplicate them. It pulls from them whatever must exist in a single copy, and sends back whatever it generates itself.

Products, stock levels, and prices come in from the accounting systems. This closes the first problem from the first section: on-site availability stopped being a separate list that someone maintains. An item that's out of stock doesn't sell on the site, and not because someone noticed in time, but because there is only one source of availability data.

An item that's out of stock doesn't sell on the site, and not because someone noticed in time, but because there is only one source of availability data.

Orders flow the other way: a placed and paid order lands in the accounting system as a document ready for fulfillment. The employee who used to stand in the middle carrying data by hand has been removed from the chain, along with the delays and typos that work inevitably produced.

The sync runs as scheduled background tasks, not at the moment a button is clicked. This matters for reliability: the accounting system can be busy or unavailable, and an order must not disappear in that moment. A task that doesn't succeed on the first try goes back into the queue and retries.

Payment is where a mistake costs the most: this is where the customer's money meets the brand's obligations. That's why the order's status changes not when the customer returns to a 'thank you' page, but on notification from the payment system. A customer can close the browser tab right after paying, and the order will still be marked as paid.

The reverse situation is handled too: an order is placed, but the payment fails or is abandoned midway. That order doesn't go to the warehouse and doesn't hold the item indefinitely, it stays in its own status, visible to both the team and the customer in their account.

Notifications from the payment system are handled so that a repeat delivery doesn't create a second payment: payment providers resend a notification if they don't receive confirmation, and a system that doesn't account for this will eventually ship an order twice.

The brand got its own sales channel, built around its own product logic rather than someone else's template. This applies to the catalog with its size grids and to the admin panel the team works in every day.

The warehouse and the storefront stopped drifting apart. The question 'is this in stock' has one answer, because it has one source: the accounting system, not a spreadsheet someone forgot to update.

Manual order transfer disappeared as a task. A paid order reaches the accounting system on its own, and how fast that happens no longer depends on how busy an employee is.

And support stopped being an information desk: questions about an order's status and contents are now closed by the customer themselves in their account. Staff are left for the inquiries where a person is genuinely needed.