Store wizard

The “Store” wizard assembles an online store in one run: a seven-step form, a fifty-operation plan, and a storefront with a catalog, cart, YooKassa payments, and a customer account opens at your address. This page covers the form fields, exactly what appears in the project, and the four items left to the owner.

A store built by the wizard is an ordinary platform project: products and orders live in content types, storefront pages are assembled from templates, and server-side logic runs in scenarios. Nothing in this assembly is closed off; every corner can be edited by hand. The installation takes about twenty seconds, and no step requires writing code.

Where to find the wizard

Admin panel → “Site” → the “Scenarios” tab → “Create scenario”: the “What are we building?” gallery opens, and in it the “Store” card. The installation runs in the current project; a first run is best done in a separate project, so you can look at the result calmly.

Requirements

The owner or admin role in the project: only they can see the “Site” section.
The storefront’s public address comes from the “Site” add-on (hosting for a site on a subdomain or your own domain); it works with any plan. Without the add-on the installation goes through and the store appears in the project, but a customer cannot open the page.
The plan sets the API limits. Free allows 25 writes per hour, and the cart and checkout share that quota; a store with real customer traffic needs Starter or above.

The seven-step form

Field	What to enter
Store name *	Goes into the storefront header
Site address *	The full address of the storefront, for example `https://shop.example.ru`; the customer returns here after payment
Store path	`/shop`, `/catalog`, or `/store`, `/shop` by default
YooKassa Shop ID *	The numeric store identifier from the YooKassa dashboard; the test shop’s values work for a first check
YooKassa secret key *	Also from the dashboard; the wizard immediately hides it in the project Secrets
Notification token *	A random string of at least eight characters: Latin letters, digits, a hyphen, or `_`; it becomes part of the webhook receiver address
Catalog page size	12 or 24 products, 12 by default

Fields without an asterisk have defaults. Every field is validated on the spot: the wizard will not proceed without a name and will reject a key containing letters.

The wizard does not take over the site root: until you build your own page for it, the bare address leads into the store. This start fits a launch where the store is the first section and a landing page arrives later.

What the wizard creates

Before running, the wizard shows the “What will be created” plan: a list of fifty operations, with the owner checklist on the last line. After “Apply” the project contains:

Artifact	Role
The “Products”, “Categories”, “Orders”, “Carts” content types	Ordinary project content types; the wizard fills the first two with examples: three categories and four products
The storefront on the store path	A catalog with category chips and pagination, a product page with a “Related” block, checkout, an order status page, a 404 page, a sitemap
The root redirect	The bare address leads into the store until you build your own page for the root
The customer account at the root	`/login`, `/register`, `/account`: sign-in, registration, and the shopper’s “My orders”
13 scenarios	Nine run the store: catalog, product page, cart, order, payment, webhook, status, 404, root redirect; four power the account: sign-in, registration, sign-out, “My orders”
14 routes	Scenario-to-path bindings for the storefront and the account, the root redirect included

How it works

Catalog and product page. The storefront reads products from the “Products” type: only published records reach the catalog, newest first. Edit a record, and a couple of seconds later the storefront shows the change: the platform drops the page cache on its own. The sitemap at /sitemap.xml refreshes on its own too.

Cart. The cart lives on the server: for a guest it is a record in “Carts” plus a tag in a cookie valid for 30 days, and the platform computes totals from current prices. At sign-in the guest cart moves to the shopper: items fold into one list, and a duplicate keeps the larger quantity. Checking out empties the cart.

Payments. The chain is the same one behind the “YooKassa payments” preset: an order is created with a stock check, the payment goes to YooKassa, and the customer returns to the order page. The payment notification arrives at the address carrying your token; the storefront matches the order by payment identifier and amount and asks the YooKassa server directly before setting the status to “paid”. The secret key sits in the project Secrets under the name yookassa_basic and never appears in scenario texts or in the operation log.

Account. A shopper registers with an email and a password, and the account is created right away. Without a configured mail server registration still works: the account-creation note simply never goes out, and the a_mail node in the register scenario can be removed. The account lists the twenty most recent orders with their statuses.

The owner checklist

The last line of the installation plan shows four items the wizard cannot do for you:

copy the notification URL and paste it into the YooKassa dashboard; the ready-made URL sits right in the checklist; until it is pasted, payments go through but orders stay “new”;
upload product photos to the media library and attach them to products;
do not rename the sign-in tag, it is what ties a cart to its owner;
point the registration scenario at your mail server, or remove the email step.

If the YooKassa secret key is reissued, no reinstall is needed: open the “Site” section, the “Secrets” tab, and save the new value over the yookassa_basic record. The next payment already goes out with the new key.

A repeated run on the same project does not touch existing records: a second run is for a clean project.

Frequent questions

Question	Answer
Do I need a programmer?	No. The installation and all further filling happen in the admin panel; storefront templates are edited as site files, scenarios in the scenario editor.
Can the store path be changed?	Yes, in step three of the first installation: `/shop`, `/catalog`, or `/store`. The order status page path adjusts on its own.
What about test payments?	Enter the test shop’s values from your YooKassa dashboard: the chain is identical and no money moves. For live payments, repeat the installation with the live values.
Where do I look at orders?	“Content” → the “Orders” type: line items, total, status, contacts, and the YooKassa payment identifier.
How long does installation take?	About twenty seconds: a plan of fifty operations, from creating the content types to publishing the routes.