What you need to start an online store splits by owner: the unit you sell and its price are yours, the store and the wiring of its payment step are a software team’s work, payment rules stay with a provider, and the registrations and legal texts come from regulation. Settled at setup, ownership tells you which lines you prepare and which a software quote covers. This article names no provider and quotes no price.
What you need to start an online store, and who each item belongs to
Each item on an online store’s setup list belongs either to the business, to the software team, to the payment provider or to the regulation that defines it. Read any list of what you need and you get the items without their owners, which is why a complete-looking list still leaves you unsure who moves next.
Sorted by owner, the list looks like this:
- The definition of the unit you sell, with a price and a stock figure behind every unit. Owner: the business.
- The domain registration and the certificate. Owner: the business, bought from a provider.
- The store software and the wiring of its payment step. Owner: the software team.
- The choice of payment and shipping provider, and whose name the account is opened in. Settled between the business and the provider.
- Tax registration and ETBİS registration. Owner: the business and its accountant.
- The text of the distance sales contract and of the preliminary information form, plus the contact details reachable from the home page. Owner: the business and its lawyer; where that text sits in the flow is the software team’s.
Read the list this way and the odd cells show up first. Tax and ETBİS registration have nothing at all in the software column, because neither produces a deliverable anybody can hand over; those lines name an institution and a regulation, and their detail is read at the source. The payment line has the opposite shape: its ownership is divided inside the line, with the business choosing a provider, the provider keeping its rules, and the software team carrying that choice into the payment step. An empty cell and a divided cell are both information, and each keeps an item out of what you expect a software quote to cover.
Renewal stays on the business’s side, because the account holding a certificate is the account that renews it. The certificate sits in the same line as the registration for a related reason: the document is written against a name, not against the pages underneath it, so until an address is registered there is no certificate question to answer. Why a certificate attaches to an address rather than to a page is set out separately.
On our own proposals the domain sits as a line of its own, paid to the registrar instead of to us, and the invoice reaches the business directly. The split is not a framing device invented for an article, then: it already shows up on a price list. Treating the address as an item separate from the site is unpacked elsewhere.
Where the price is not published, and terms and payment get settled between people, the payment and distance-selling lines never appear in this shape at all. The list above assumes the other case: a store where a screen closes the sale.
The business writes down what it sells: the sellable unit comes before the product list
The business defines the unit a store actually sells, because every price and every stock figure attaches to that unit. Our e-commerce page opens a store project with that question rather than a technical one, and it stays ahead of both the catalogue and the checkout.
Listing every bottle size as a product of its own would fill a catalogue with the same scent over and over. Kokudankokuya drew the boundary at bottle size: the scent occupies a single catalogue row, and a price and a stock figure attach to the size underneath it.
What the business brings to the table is short and specific: the unit being sold, the price on it, and the place its stock sits. Once that arrives in writing, the software team’s share is to attach rather than to choose, with price, sales conditions and stock written onto the same record, and search, navigation and the basket all reading from it. None of it originates on the software side, because whatever level the record is kept at, the data has to exist at that level first.
Which record carries the price and the stock figure is what fixes the variant boundary, and it gets chosen before a catalogue exists. Changing the answer afterwards means rebuilding everything written on top of it, so the decision does not retrofit. The test that settles it belongs to which record price and stock hang from, not here.
A seller whose catalogue carries no breakdown, with the price sitting directly on the item, closes this line in a sentence, and the weight of the list moves to the payment and regulatory rows.
The business picks the payment provider; the software team wires the payment step
The payment line has no single owner: the business chooses the provider, the provider keeps its own rules, and the software team carries that choice into the checkout step. Keeping the sale in a single flow is not the same as taking the payment step in-house; it means the configuration a visitor built reaches that step undamaged. A business hoping to own that screen is reading the split backwards.
The KGM SsangYong Online Store opens checkout as the continuation of its configurator, so the trim and colour a visitor picked stay in the same session and travel into the purchase step as a record. The payment step answering to a bank and to a payment provider is written up in the article on configurators and quotes, and we do not set that part.
None of that moves the rules off the provider’s side. What the software team owes at the checkout step is not a change to the rules but the visitor’s choices arriving without loss. Because the choice sits with the business, a planning call names no brands, and the connection gets built around whatever has already been chosen.
Your own agreement carries whose name the account is in, and logging into the account with your own credentials confirms it. That question sits on the list as a line of its own. Ownership and operation also come apart inside it: the primary account can stay with the business while limited access goes to the software side.
A contract can name the business as owner while access remains with whoever created the login; how outside service accounts are tested at handover is walked through line by line in the handover article. Shipping rates, delivery times and return logistics are outside this article, and what does belong here is that the business signs the shipping agreement and that the providers already in use connect at the same point in the sales flow.
Tax registration and ETBİS registration are opened by the business
Tax registration and ETBİS registration sit with the business and its accountant, and neither produces anything a software team delivers. Those lines belong on an accountant’s desk and in the text of the source, and the work this article does with them is to name whose items they are. Thresholds, deadlines and application steps are not its subject.
The place that assigns the invoice number being the source of the record is taken apart in the e-invoicing article. Where the invoice record is born is the single face this item turns towards software. Moving onto the e-Fatura system depends on the gross sales revenue threshold set in the communiqué.
A sale made over the internet also puts fields of its own on the document: the web address it was made from, the payment method and the payment date, plus a statement that the sale took place over the internet. Where documents are not tied to a job and matching them by hand tires nobody, building software to produce the invoice inside your own system takes away more than it returns. So this item has a face that points away from software as well.
ETBİS itself, the Electronic Commerce Information System, is the register the Ministry of Trade set up for electronic commerce service providers and intermediary service providers. The Ministry of Trade’s own ETBİS page states in its own words who is asked to register. Service providers trading in an e-commerce environment of their own register before activity starts, and registrations and notifications are filed through the e-Government gateway.
Notifying the tax office that a business has started trading is governed by the Tax Procedure Law. The order the records fall in comes out of the registration form itself, which asks for a tax identification number and so puts tax registration ahead of the ETBİS record.
The business prepares the distance sales texts; the software team places them in the flow
What the distance sales texts say is written by the business and its lawyer, while where those texts appear in the sales flow is built by the software team.
Immediately before an order is confirmed, the consumer is told that placing it means taking on an obligation to pay. The Distance Contracts Regulation also wants preliminary information given before a contract comes into being, and wants the seller to secure the consumer’s confirmation that the information was received; where confirmation is not secured, the contract counts as never formed. Everything beyond that belongs to the regulation’s own text.
A text with an ordering condition attached gets planned as a step inside the sale rather than as a document waiting on a page somewhere else. Confirming needs somewhere to happen, which is what turns placement into a question for whoever designs the flow. The KGM SsangYong sales channel shows what it is worth to settle in advance which record moves from step to step, and the same discipline settles where a confirmation is taken before any screen is drawn.
Whether a “contact” heading opens directly from the home page is the page’s line; the information under it is the business’s. The Regulation on Electronic Commerce Intermediary Service Providers and Electronic Commerce Service Providers wants that heading reachable from the home page without a detour, carrying a trade name or a personal name, a head office address, an electronic mail address and a telephone number in full. This is where the list turns straight into page design.
A permanent marker on a customer card carries an answer from yesterday into today while nobody watches it happen. The record of a confirmation therefore belongs to the order rather than to the party: what the order record holds is the text and the version the consumer confirmed, and the moment the confirmation happened. That is a record-design decision rather than something read off a regulation. Where a confirmation is stored is a separate question from which messages need consent at all. Order messages and marketing messages are not the same channel in software: commercial electronic messages need consent taken in advance, and that consent is recorded in İleti Yönetim Sistemi (İYS), the register the regulation points to, while messages about changes, use and maintenance of something the recipient has already bought need no separate consent. The same mail infrastructure therefore answers to consent regimes kept apart.
The right of withdrawal appears here as a heading in those texts and nothing more; why it exists is another article’s subject. Content and placement answering to different owners is the sharpest edge of this list.
On a site where no contract is formed on screen, there is no preliminary information step to place.
The items side by side: owner and the software team’s share
Choosing a packaged product changes only who builds the store software; the items owned by the business and by regulation stay exactly where they were. Written down, the owner of an item answers in a step; left unwritten, each party points at the next. The table below puts that single question to every row: if this item is missing on launch day, who gets the call.
| Item | Owner | The software team’s share | Where the detail is read |
|---|---|---|---|
| The unit sold, with a price and a stock figure per unit | The business | Attaching rather than choosing: price, sales conditions and stock are written onto that unit’s record | The product variants article, on which record price and stock hang from |
| Domain registration and certificate | The business; registration and renewal stay in the business’s account | Building what the address and the certificate point at | The domain article and the certificate article |
| Choice of payment provider; whose name the account is in | Choice with the business, rules with the provider | Carrying the choice into the payment step intact; not setting payment rules | The payment boundary section of the configurator article and the accounts section of the handover article |
| Agreement with a shipping provider | Between the business and the provider | Connecting the provider at the same point in the sales flow | The payment and shipping connections heading on the e-commerce service page |
| Tax registration and ETBİS registration | The business and its accountant | None; this row produces no software deliverable | The page of the institution that runs the register |
| Distance sales texts and the contact details reachable from the home page | The business and its lawyer; the frame is in regulation | Building the step the text appears at, the place the information sits and the record the confirmation is kept on | The official texts of the regulations |
No single contract covers this list. A row with nothing in the software column can still hold the store shut: registration is asked for before trading starts, and producing no deliverable does not take a line off the list. That column measures the work a software team owes, not the weight of a row: a filled cell delays only what gets built on top of it. Where the price is read off a product row and a catalogue’s breakdown fits a packaged product’s record, the decision guide that writes out when a packaged product is the right answer points that way; the test is not the package but where the price is formed.
Which item waits on which: the product model before the screen, the screen before the payment step
Neither the catalogue nor the checkout step can be built before the product model is decided. A screen can be redrawn later; a foundation with price and stock written on it cannot, which is why the order follows the record and not the screen. What is sold, and which breakdown price and stock attach to, gets settled ahead of both.
Migrating from an existing store follows the same order, where the weight of the move is in rebuilding the product model rather than in copying rows, and what is sold gets answered before any data travels.
Writing down which record travels between steps before any screen is drawn is described in sequence in the configurator article. The rule for that order is already published.
The payment step also needs a party to connect to, and because the choice rests with the business, the software team’s work on that line does not start until the choice is made. That is a dependency rather than an order read out of a regulation; between the regulatory items only the dependency written in the source gets stated, and beyond that, which registration comes before which is not this article’s claim.
For a store selling to consumers in the European Union, accessibility becomes an item settled ahead of the screen as well: the scope test and where the cost of compliance is created are opened up separately.
Owners differ, so most of the items move in parallel; what waits is the item that touches the record. The order is not a calendar.
What to write on the quote form
A quote form only needs these lines: the unit you sell, what your price hangs on, whether you have already chosen a payment and shipping provider, and any store you run today. The unit is not ours to pick, and what we attach is the unit you wrote down; describing the axes your catalogue divides along is enough to begin.
On the price line the question is whether the price sits on a single record or comes out of the combination a visitor assembles, because the answer shapes how the catalogue is divided and which record we build. On the provider line what helps us is not a name but whether a choice has been made, since the scope of a quote is written against that fact rather than against a brand.
Any store you run today goes on the form as well: what we need is not its name but what counts as a sellable unit in it now, since that is where the weight of a migration sits.
What it costs belongs to a separate guide, not to this article. A line left blank is information too, because it shows which item does not have an owner settled yet, and not every line has to be filled in.
Write down the unit you sell, what the price hangs on, and whether a payment and shipping provider has been chosen on the quote form, and whose line each of the rest is comes out of that conversation.
