ECCO Commerce — Multi-tenant webáruház platform

Funkcionális és technikai specifikáció

1. Vezetői összefoglaló

Az ECCO Commerce egy bérelhető (SaaS) webáruház platform: a kereskedők regisztrálnak, csomagot választanak, és percek alatt kapnak egy teljes értékű, saját domainen futó webshopot. A platform három, egymástól élesen elválasztott felületből áll:

1. Publikus SaaS oldal — marketing, funkciólista, csomagok, árak, sablongaléria, tudástár, regisztráció, ingyenes próba.
2. Store admin — a bérlő (kereskedő) teljes webshop-adminisztrációja: katalógus, rendelés, vásárló, marketing, megjelenés, beállítások.
3. Superadmin — a platform üzemeltetőjének felülete: bérlők, előfizetések, számlázás, csomagdefiníciók, sablontár, integrációk, naplók, támogatás, és a publikus főoldal teljes tartalmi szerkesztése.

Alapelv: minden adat, amit a rendszer megjelenít vagy tárol, szerkeszthető a superadmin felületről — beleértve a marketing főoldal szövegeit, a csomagok árait és korlátait, az integrációk kapcsolóit, a jogi dokumentumokat és a bérlők cégadatait.

1.1 Üzleti célok

1.2 Hatókör (scope)

Benne van: multi-tenant webshop motor, 3 felület, témarendszer, csomag/limit rendszer, előfizetés és számlázás, magyar fizetési/szállítási/számlázási integrációk, B2B modul, termékfeedek, API, naplózás.

Nincs benne (1. körben): natív mobilalkalmazás, saját fizetési szolgáltatás (PSP), saját logisztika, marketplace mint önálló üzletág, AI-alapú termékfotó-generálás.

2. Szereplők és szerepkörök

2.1 Platform oldal (superadmin)

2.2 Bérlő oldal (store admin)

A szerepkörök egyedileg is testreszabhatók (jogosultság-mátrix modul/művelet szinten), a Pro csomagtól felfelé.

2.3 Vásárló oldal (storefront)

Vendég vásárló · Regisztrált B2C vásárló · B2B partner (cégként, vásárlói csoportba sorolva, egyedi árlistával) · Viszonteladó / affiliate partner.

3. Versenytárs-elemzés

3.1 Shoprenter (2026. augusztusi állapot)

3.2 UNAS (2026. augusztusi állapot)

3.3 Tanulságok a saját csomagszerkezethez

1. Az online bankkártyás fizetés a legerősebb upgrade-motor — mindkét versenytárs a második szintre teszi. Mi is így tesszük.
2. API a felső csomagokban — nálunk a Pro-tól teljes REST + GraphQL.
3. Több nyelv/deviza a felső csomagban — nálunk Pro-tól.
4. A termékszám a fő skálázási dimenzió. A UNAS a csomagon belül is bont termékszám szerint — mi ezt kapacitás-bővítménnyel (add-on) oldjuk meg, hogy a mátrix egyszerű maradjon.
5. Hiányzó dolgok, amiben előrébb lehetünk: vizuális design-token szerkesztő (nem csak színválasztó), saját téma feltöltése, valódi B2B mód kapcsolóval, GraphQL Storefront API, headless mód, akadálymentesség (EAA/WCAG 2.2 AA), beépített PWA, staging környezet.

4. Csomagok és funkciómátrix

4.1 Árazás

Éves fizetésnél 2 hónap ajándék. Minden ár nettó, ÁFA nélkül. Ingyenes próba: 7 nap, teljes Pro funkcionalitással, bankkártya nélkül. A próbaidő hossza a superadminban csomagonként állítható (plans.trial_days), és egyedileg is meghosszabbítható bérlőnként — így kampányidőszakban vagy egy konkrét érdeklődőnél változtatható anélkül, hogy kódot kellene módosítani.

4.2 Erőforrás-korlátok

4.2.1 Kiegészítő modulok (add-on)

Bármelyik csomaghoz külön előfizethetők, havidíjas alapon. A modulok az előfizetés részei: ha az előfizetés felfüggesztésre kerül, a modulok is.

Egyszeri díjak

A visszaállítási díj egyedi elbírálás alapján elengedhető — a szabályokat lásd a 8.4.1 pontban.

4.3 Funkciómátrix

Jelmagyarázat: ● = benne van · ○ = korlátozott · ★ add-on = feláras modulként bármelyik csomaghoz megvehető · — = nincs

Katalógus

Rendelés és pénztár

Fizetés

Szállítás

Marketing és értékesítés

B2B modul

Megjelenés

> A modulok csomagonkénti elérhetősége a superadminban szerkeszthető. A Builder és a Labor is közönséges funkciókulcs (theme.builder, env.labor) a plan_features táblában, három lehetséges értékkel csomagonként: nincs · add-on ként megvehető · a csomag része, díjmentesen. Így ha később az a döntés születik, hogy a Labor minden csomagban díjmentesen jár, az egy kapcsoló a superadminban, nem fejlesztés. A meglévő bérlők a grandfathering szabály szerint nem esnek el a már megvásárolt hozzáféréstől.

Platform, fejlesztés

5. Rendszerarchitektúra

5.1 Technológiai stack

5.2 Multi-tenancy stratégia

Választott modell: hibrid — közös alkalmazás, bérlőnként külön adatbázis.

Központi (landlord) adatbázis          Bérlői (tenant) adatbázisok
├── tenants                            tenant_kavebolt/
├── domains                            ├── products
├── companies (cégadatok)              ├── categories
├── plans, plan_features               ├── orders
├── subscriptions, invoices            ├── customers
├── platform_users (superadmin)        ├── discounts
├── themes (sablontár)                 ├── theme_settings
├── integrations (katalógus)           ├── integration_settings
├── cms_pages (publikus oldal)         └── activity_log
├── audit_log
└── support_tickets

Miért adatbázis-per-bérlő?

• Adatszigetelés: nincs esély rá, hogy egy hiányzó where tenant_id miatt egyik bolt lássa a másik adatait. Ez SaaS-ban a legdrágább hibatípus.
• Mentés/visszaállítás bérlőnként: egy bolt önállóan visszaállítható, exportálható, migrálható másik szerverre.
• Törlés (GDPR): a bérlő adatbázisának eldobása teljes és bizonyítható törlés.
• Teljesítmény: a nagy bérlők nem lassítják a kicsiket; a 186 000 termékes bolt táblái külön indexelődnek.

Kompromisszum: a migrációkat minden bérlői adatbázison le kell futtatni (tenants:migrate, ütemezetten, batch-elve), és a keresztbérlői riportokhoz külön aggregáló táblák kellenek a központi DB-ben (tenant_daily_stats, éjszakai job tölti).

Bérlőazonosítás: domain / aldomain alapján, middleware-ben. Minden bolt aldomainnel jön létre (<slug>.polcra.hu), amely a bolt élete végéig megmarad és mindig működik; a saját domain (kavebolt.hu) bármikor rákapcsolható, és onnantól az lesz az elsődleges, az aldomain pedig 301-gyel átirányít rá. Az admin felület admin.polcra.hu/<slug> útvonalon vagy a bolt saját domainje alatt /admin-on érhető el.

Miért marad meg mindig az aldomain: ez a tartalék belépési út. Ha a bérlő domainje lejár, a DNS-e elromlik, vagy vitába kerül a domain-kezelőjével, az adminja és a boltja akkor is elérhető marad — ez évente több támogatási esetet old meg.

5.3 Alkalmazásrétegek

                         nginx (TLS, Let's Encrypt wildcard + per-domain)
                                      │
        ┌─────────────────────────────┼─────────────────────────────┐
        │                             │                             │
  Publikus SaaS oldal           Store admin                   Storefront
  (Blade + Alpine)          (Inertia + Vue SPA)          (Blade téma + Turbo)
        │                             │                             │
        └─────────────────────────────┼─────────────────────────────┘
                                      │
                          Laravel 13 alkalmazásmag
     ┌──────────┬──────────┬──────────┼──────────┬──────────┬──────────┐
  Catalog    Order      Customer   Pricing    Theme      Billing   Integration
  modul      modul      modul      modul      modul      modul     modul
     └──────────┴──────────┴──────────┼──────────┴──────────┴──────────┘
                                      │
        ┌──────────────┬──────────────┼──────────────┬──────────────┐
     MariaDB         Redis      Meilisearch     Hetzner S3     Horizon
    (landlord +    (cache,      (termékindex)    objektum-      (sorok)
     tenant DB-k)   session,                     tároló
                    sor)

Modul-alapú kódszervezés (app/Modules/Catalog, app/Modules/Order, …): minden modulnak saját modelljei, service-ei, eseményei, policy-jai és teszterei vannak. Így a csomag-alapú funkciókapcsolás modul szinten tud működni.

5.4 Funkciókapcsolás (feature gating)

Minden csomagfunkció egy kulcs (b2b.price_lists, theme.custom_upload, api.graphql), amit a plan_features tábla köt a csomaghoz. A kód három helyen ellenőrzi:

// 1. Route middleware
Route::middleware('feature:b2b.price_lists')->group(...);

// 2. Blade / Vue
@feature('theme.custom_upload') ... @endfeature

// 3. Service réteg (hard gate)
Feature::ensure('api.graphql');   // FeatureNotAvailableException

A limitekre (termékszám, tárhely) külön QuotaService figyel, ami puha figyelmeztetést ad 80%-nál és kemény tiltást 100%-nál — az adatvesztés soha nem opció: limit felett a bolt olvasható és értékesít, csak új termék/kép nem tölthető fel.

Minden funkciókulcs felülírható bérlőnként a superadminból (tenant_feature_overrides) — ez kell az egyedi megállapodásokhoz és az Enterprise csomaghoz.

5.5 Felkészítés a fehércímkés (white-label) működésre

A fehércímkés mód a 2. körben indul, de az architektúrát már most úgy építjük, hogy később ne kelljen átírni. Ez néhány konkrét megszorítást jelent a kezdetektől:

brands   id, key, name, legal_name, tax_number, domain, logo_path,
         colors (json), support_email, support_phone, from_email,
         invoice_provider_config (encrypted), terms_page_id, is_default

Ha ezt a hét pontot betartjuk a Fázis 0–1 alatt, a fehércímkés mód később konfigurációs feladat lesz, nem újraírás. Ha nem tartjuk be, a márkanév utólagos kiszedése a kódból tapasztalat szerint több hét.

6. Adatmodell (kivonat)

6.1 Központi adatbázis

tenants            id, uuid, name, slug, db_name, status(trial|active|past_due|
                   suspended|cancelled), plan_id, trial_ends_at, created_at
domains            id, tenant_id, domain, is_primary, ssl_status, verified_at
companies          id, tenant_id, legal_name, tax_number, eu_tax_number,
                   registration_number, address_*, bank_account, contact_*,
                   invoicing_email, is_verified
platform_users     id, name, email, password, role, two_factor_secret, last_login_at
plans              id, key, name, price_monthly, price_yearly, currency,
                   trial_days, is_public, sort_order
plan_features      id, plan_id, feature_key, value (bool|int|json)
plan_limits        id, plan_id, limit_key, value        -- products, storage_mb, …
tenant_feature_overrides  id, tenant_id, feature_key, value, note, expires_at
subscriptions      id, tenant_id, plan_id, billing_cycle, status, current_period_*,
                   stripe_id, cancel_at_period_end, discount_id
subscription_items id, subscription_id, addon_key, quantity, unit_price
platform_invoices  id, tenant_id, number, issued_at, due_at, net, vat, gross,
                   status(draft|issued|paid|overdue|void), pdf_path, external_id
payment_attempts   id, subscription_id, amount, status, gateway, error_code, attempt_no
coupons            id, code, type, value, applies_to_plan_ids, max_redemptions,
                   valid_from, valid_to
themes             id, key, name, version, author, preview_image, min_plan_id,
                   token_schema (json), is_active
theme_versions     id, theme_id, version, changelog, archive_path, published_at
integrations       id, key, name, category(payment|shipping|invoicing|marketing|
                   marketplace), min_plan_id, config_schema (json), is_active
cms_pages          id, slug, title, blocks (json), meta_*, locale, published_at
cms_menus          id, location, items (json)
audit_log          id, actor_type, actor_id, tenant_id, event, subject_type,
                   subject_id, properties (json), ip, user_agent, created_at
support_tickets    id, tenant_id, user_id, subject, status, priority, assigned_to
tenant_daily_stats id, tenant_id, date, orders, revenue, visitors, products,
                   storage_mb, bandwidth_mb
environments       id, tenant_id, type(production|labor), db_name, url, status,
                   storage_mb, last_sync_at, last_activity_at, sleeps_at,
                   anonymized
env_sync_jobs      id, environment_id, direction(pull|promote), scope (json),
                   status, snapshot_id, started_at, finished_at, log, actor_id
env_access         id, environment_id, user_id, invite_email, level, expires_at
env_snapshots      id, environment_id, reason, path, size, created_at, expires_at
reactivation_fees  id, tenant_id, trigger(suspended|archived), amount, status,
                   waived_amount, waive_reason_code, waive_note, proposed_by,
                   approved_by, invoice_id, auto_rule_matched, resolved_at
addon_subscriptions id, subscription_id, addon_key(builder|labor|capacity…),
                   quantity, unit_price, started_at, ends_at, is_trial

6.2 Bérlői adatbázis

products           id, sku, ean, name, slug, description, short_description,
                   status, type(simple|variable|bundle|digital|subscription),
                   price_net, vat_rate, unit, weight, dimensions (json),
                   min_qty, max_qty, qty_step, package_unit, meta_* , sort
product_variants   id, product_id, sku, option_values (json), price_net, stock
product_images     id, product_id, path, variants (json), alt, sort
product_params     id, product_id, param_id, value
params             id, key, name, type(text|tag|enum|enum_multi|number|range|
                   color|link|html|icon|image), is_filterable, is_comparable
categories         id, parent_id, name, slug, description, image, meta_*, sort
category_product   category_id, product_id, sort
warehouses         id, name, address, is_default, priority
stock              id, product_id, variant_id, warehouse_id, quantity, reserved
stock_movements    id, stock_id, type, quantity, reference, note, created_at
customers          id, email, name, phone, group_id, type(person|company),
                   tax_number, is_vat_exempt, credit_limit, balance, accepts_marketing
customer_groups    id, name, discount_percent, price_display(net|gross),
                   min_order_value, is_vat_exempt, requires_approval
customer_addresses id, customer_id, type, name, country, zip, city, street, note
price_lists        id, name, customer_group_id, valid_from, valid_to, priority
price_list_items   id, price_list_id, product_id, price_net, min_qty
orders             id, number, customer_id, group_id, type(b2c|b2b), status,
                   payment_status, fulfillment_status, currency, subtotal_net,
                   discount, shipping_net, vat_total, total_gross, notes,
                   billing_address (json), shipping_address (json), placed_at
order_items        id, order_id, product_id, variant_id, name, sku, qty,
                   unit_price_net, vat_rate, discount, total_net, status
order_status_log   id, order_id, from, to, actor, note, created_at
shipments          id, order_id, carrier, tracking_number, label_path,
                   pickup_point_id, status, shipped_at, delivered_at
payments           id, order_id, gateway, transaction_id, amount, status,
                   paid_at, raw_response (json)
invoices           id, order_id, provider, number, type(invoice|proforma|
                   storno|deposit), pdf_url, external_id, issued_at
returns            id, order_id, status, reason, items (json), refund_amount
discounts          id, name, type, value, conditions (json), starts_at, ends_at
coupons            id, code, discount_id, usage_limit, used, per_customer_limit
loyalty_points     id, customer_id, points, reason, order_id, expires_at
carts              id, token, customer_id, items (json), updated_at, reminded_at
reviews            id, product_id, customer_id, rating, title, body, images,
                   is_verified_purchase, status, admin_reply
theme_settings     id, theme_key, tokens (json), custom_css, draft_tokens,
                   published_at
page_layouts       id, page_type, name, is_default, status(draft|published),
                   published_at, publish_at, version, theme_key
layout_sections    id, layout_id, parent_id, type, sort, content (json),
                   style (json), style_tablet (json), style_mobile (json),
                   visibility (json), global_ref_id, is_hidden
layout_versions    id, layout_id, version, snapshot (json), author_id, note
global_sections    id, key(header|footer|announcement), name, snapshot (json)
section_presets    id, name, thumbnail, payload (json), scope(system|tenant)
checkout_layout    id, layout_key, options (json)
checkout_slots     id, slot_key, blocks (json), updated_at
media              id, folder_id, path, variants (json), alt, focal_point,
                   size, mime, used_in (json)
cms_blocks         id, page, position, type, content (json), conditions (json),
                   starts_at, ends_at
feeds              id, channel, format, filters (json), last_run_at, item_count
activity_log       id, user_id, event, subject_type, subject_id, changes (json),
                   ip, created_at

6.3 Ármeghatározás sorrendje

Egy termék ára a következő láncon fut végig (az első találat nyer, majd a kedvezmények halmozódnak a beállítás szerint):

1. Egyedi árlista tétel (price_list_items)         → B2B partner egyedi vételára
2. Mennyiségi sáv (price_list_items.min_qty)       → 10 db felett más ár
3. Vásárlói csoport kedvezménye (%)                → Gold partner −12%
4. Termékszintű akció (időszakos árváltozás)       → nyári akció
5. Kosárszintű kedvezmény (kupon, sávos, ajándék)  → NYAR2026 kupon
6. Deviza-konverzió + kerekítési szabály
7. ÁFA hozzáadása vagy elhagyása (B2B / OSS / fordított adózás)

Ez egy önálló, jól tesztelt PricingEngine, mert itt keletkezik a legtöbb hiba, és minden lépés naplózható (price_explain debug mód az adminban).

7. Publikus SaaS oldal

7.1 Oldalszerkezet

7.2 Regisztráció és onboarding

1. Regisztráció        e-mail + jelszó, vagy Google / Microsoft belépés
                       ↓ e-mail megerősítés
2. Bolt alapadatok     bolt neve → slug javaslat, iparág, várható termékszám
                       ↓
3. Aldomain            <slug>.polcra.hu azonnal él (SSL-lel);
                       saját domain bármikor rákapcsolható
                       ↓
4. Sablon választás    6 ajánlott sablon iparág szerint, azonnali előnézet
                       ↓
5. Márkázás            logó feltöltés → automatikus színpaletta-javaslat
                       ↓
6. Első lépések        checklist: termék felvitele / szállítás / fizetés /
   (dashboard widget)  jogi szövegek / domain kötése / bolt élesítése

Próbaidőszak: 7 nap, teljes Pro funkcionalitás, bankkártya nélkül. Az 1., 3., 5. és 7. napon automatikus e-mail. A hossz a superadminban csomagonként állítható, és bérlőnként egyedileg meghosszabbítható (a hosszabbítás naplózva). Lejárat után a bolt 7 napig „csak olvasható” állapotba kerül (a storefront „hamarosan” oldalt mutat), majd 30 nap után archiválódik, 90 nap után törlődik — mindezt e-mailben előre jelezve.

Bolt élesítése: a storefront addig „építés alatt" jelszóvédett oldalt mutat, amíg a tulajdonos meg nem nyomja a „Bolt élesítése" gombot. Ez ellenőrzi: van-e legalább 1 aktív termék, szállítási mód, fizetési mód, ÁSZF és adatkezelési tájékoztató.

7.3 Domainstratégia

A platform fődomainje: polcra.hu — a regisztráció elindítva, 2026.08.28. A márkanév továbbra is ECCO Commerce; a polcra.hu a technikai gazdadomain, amely alatt a bérlői boltok élnek.

A polcra.hu 6 karakter, ami itt gyakorlati érték: a bolt slugja elé kerül, a Labornál pedig még egy szint. A kavebolt.labor.polcra.hu így még kényelmesen kimondható és leírható.

7.3.1 Amit a domainszerkezet technikailag megkövetel

Két wildcard tanúsítvány kell, nem egy. A Let's Encrypt wildcard csak egy szintre érvényes: a *.polcra.hu tanúsítvány nem fedi le a kavebolt.labor.polcra.hu címet. Ezért két külön, DNS-01 kihívással kiállított tanúsítvány szükséges:

Mindkettő DNS-01 kihívással újul meg, automatizálva, a polcra.hu DNS-szolgáltatójának API-ján keresztül — ezért a DNS-szolgáltató kiválasztásánál API-hozzáférés követelmény. A bérlők saját domainjei ettől függetlenül, HTTP-01 kihívással kapnak egyedi tanúsítványt.

A slug egyszerre foglalódik mindkét névtérben. A <slug> az éles bolt és a Labor címét is meghatározza, ezért kiosztáskor mindkettőt ellenőrizni és foglalni kell. A slug a bolt élete végéig változatlan; átnevezés csak a superadminból, átirányítás beállításával.

Fenntartott slugok — regisztrációkor nem választhatók, mert ütköznének a platform saját címeivel:

admin  api  app  auth  blog  cdn  dev  docs  ftp  help  img  labor  login  mail
media  ns1  ns2  panel  pay  search  shop  smtp  static  status  store  support
test  webmail  www  polcra  ecco  eccocommerce

A lista a superadminban szerkeszthető, mert később új platform-aldomainek jöhetnek.

Egy dolgot érdemes ellenőrizni indulás előtt: az „ECCO" szó bejegyzett EU-védjegy a dán ECCO Sko A/S cipőmárka nevében. Más árujegyzéki osztályban (szoftver, SaaS) ez általában nem ütközik, de mivel a platformon cipőt is árulhatnak a bérlők, egy védjegyügyvéddel érdemes egy órát átbeszélni, mielőtt a márkanév köré épül a kommunikáció.

Jó hír, hogy a polcra.hu mint technikai domain ettől teljesen független: a védjegykockázat csak a márkanevet érinti, a bérlői URL-eket nem. Ha a márkanév valaha változna, egyetlen bolt URL-je sem érintett — ez pontosan az a rugalmasság, amiért érdemes volt a márkanevet és a gazdadomaint szétválasztani.

8. Superadmin felület

8.1 Áttekintés (dashboard)

MRR, ARR, ARPA, aktív bérlők, próbaidőszakban lévők, próba→fizető konverzió, churn, LTV, késedelmes fizetők, új regisztrációk trendje, bevétel csomagonként, rendszerállapot (válaszidő, sorok, DB, külső API-k).

8.2 Bérlők (áruházak)

Lista: szűrés státuszra (próba / aktív / késedelmes / felfüggesztett / lemondott / archivált), csomagra, cégformára, forgalomra, erőforrás-kihasználtságra. Oszlopok: domain, cég, adószám, csomag, havi díj, termékszám, tárhely, sávszélesség, 30 napos forgalom, számlázási státusz, utolsó belépés. Tömeges műveletek és CSV-export.

Bérlő adatlap fülei:

Belépés a bérlő nevében (impersonate): indoklás kötelező, max. 60 perc, minden művelet külön jelöléssel naplózódik, a bérlő tulajdonosa e-mail értesítést kap róla. Ez GDPR- és bizalmi szempontból egyaránt szükséges.

8.3 Csomagok és funkciók

Csomagok CRUD-ja, árak (havi/éves, devizánként), próbanapok száma csomagonként, láthatóság, sorrend. A kiegészítő modulok (Builder, Labor, kapacitás) csomagonként háromállású kapcsolóval szabályozhatók: nincs · add-onként megvehető (áras) · a csomag része, díjmentesen. Az add-onok ára és a hozzájuk tartozó próbaidő is itt állítható. Funkciómátrix-szerkesztő: minden funkciókulcshoz csomagonként be/ki/érték. Limitek szerkesztése. Add-onok definiálása. Verziózás: egy csomag módosítása nem érinti a már rajta lévő bérlőket, amíg meg nem történik a migráció — a régi feltételek („grandfathering") megmaradnak, és a superadmin dönti el, mikor és kit léptet át.

8.4 Előfizetés és számlázás

Számlázási folyamat:

Ciklus vége  →  Számlatétel-összeállítás (csomagdíj + add-onok + túlhasználat
                − kedvezmény − kupon)
             →  Terhelés (Barion token → tartalék: Stripe → átutalás)
             →  Siker: számla kiállítása (Billingo API, tartalék: Számlázz.hu),
                        PDF a bérlő adminjába + e-mail
             →  Hiba:  1. újrapróba +3 nap, 2. +5 nap, 3. +7 nap
                        → figyelmeztető e-mailek → 15. nap: felfüggesztés
                        → 45. nap: archiválás

Kezelt esetek: arányosított csomagváltás (up/downgrade), év közbeni add-on hozzáadás, devizás számlázás, ÁFA-kezelés (belföldi 27%, EU B2B fordított adózás VIES-ellenőrzéssel, EU B2C OSS), sztornó és helyesbítő számla, díjbekérő, csoportos számlázás (egy cég több boltja), viszonteladói / ügynökségi számlázás.

8.4.1 Bolt-életciklus, felfüggesztés és visszaállítási díj

Az előfizetés elmaradása esetén a rendszer fokozatosan szűkíti a szolgáltatást, minden lépés előtt értesítéssel. A cél nem a büntetés, hanem hogy a bérlőnek legyen ideje reagálni, és hogy a nem fizető boltok ne terheljék korlátlanul az infrastruktúrát.

A visszaállítási díj

A díj indoka valós: a felfüggesztett bolt visszaállítása kézi ellenőrzést igényel (domain, SSL, integrációk újraélesztése, feedek újraindítása), az archivált boltnál pedig a leállított adatbázis és a hidegtárolóból visszahozott média visszatöltése is.

A díj elszámolása: alapértelmezetten a visszaállítás előtt fizetendő, egy külön díjbekérőn (a bolt addig nem áll vissza). A superadmin bérlőnként átállíthatja arra, hogy a következő rendes számlára kerüljön külön tételként — ezt bizalmi ügyfeleknél érdemes használni.

Egyedi elbírálás — a díj elengedése

A díj a superadmin felületén, a bérlő adatlapján elengedhető vagy csökkenthető:

• Kötelező indoklás szabad szöveggel, előre definiált okok közül választva (technikai kártyahiba · hosszú távú ügyfél első késedelme · ügyfélszolgálati hiba · méltányosság · üzleti döntés · egyéb).
• Jóváhagyás: a támogatói szerepkör csak javasolhatja az elengedést; a tényleges elengedést pénzügyes vagy owner szerepkör hagyja jóvá. Az 50 000 Ft feletti összegeknél kötelező az owner jóváhagyás.
• Részleges elengedés is lehetséges (fix összeg vagy százalék).
• Minden elengedés az audit naplóba kerül (ki javasolta, ki hagyta jóvá, mennyit, miért), és megjelenik a havi pénzügyi riportban.

Automatikus elengedési szabályok (a superadminban szerkeszthetők, kikapcsolhatók). Ha egy szabály illeszkedik, a rendszer nem szabja ki a díjat, csak jelzi a naplóban:

1. A sikertelen terhelés oka technikai volt (issuer decline, lejárt kártya, 3D Secure időtúllépés) — nem fedezethiány —, és a bérlő 5 napon belül rendezte.
2. A bérlő legalább 24 hónapja folyamatosan fizet, és ez az első késedelme.
3. A késedelem oka a platform hibája volt (számlázási hiba, kiesés, hibás értesítés).
4. A bérlő aktív Enterprise szerződéssel rendelkezik, amelyben ezt kizárták.

Jogi feltétel: a visszaállítási díj mértékének, a fizetési feltételeknek és a felfüggesztési ütemezésnek szerepelnie kell az ÁSZF-ben, és a bérlőnek a regisztrációkor el kell fogadnia. A díj mértéke a superadminban szerkeszthető, de a módosítás csak a jövőre nézve, 30 napos előzetes értesítéssel léphet hatályba a meglévő bérlőknél.

Adatmodell (központi adatbázis):

reactivation_fees  id, tenant_id, trigger(suspended|archived), amount,
                   status(pending|invoiced|paid|waived|partially_waived),
                   waived_amount, waive_reason_code, waive_note,
                   proposed_by, approved_by, invoice_id, auto_rule_matched,
                   created_at, resolved_at

8.5 Sablontár

Sablonok feltöltése, verziózása, minimális csomag beállítása, előnézeti képek, changelog, kompatibilitási jelzés. Bérlők egyedi témáinak jóváhagyása: feltöltés után automatikus statikus ellenőrzés (tiltott PHP-függvények, méret, struktúra), majd kézi jóváhagyás — ez biztonsági kapu.

8.6 Integrációk

Integrációkatalógus szerkesztése: név, kategória, leírás, logó, konfigurációs séma (JSON Schema), minimális csomag, be/kikapcsolás globálisan, tesztkapcsolat futtatása, hibastatisztika bérlőnként.

8.7 Publikus oldal (CMS)

Blokkalapú oldalszerkesztő a marketing oldalhoz: hero, funkciórács, ártáblázat, referencia, GYIK, CTA, logófal, videó, szövegblokk. Menük, lábléc, SEO mezők, átirányítások, A/B teszt (Pro fázisban). Blog és tudástár. E-mail és SMS sablonok szerkesztése, változólistával és tesztküldéssel.

8.8 Naplók és megfigyelés

Audit napló: ki, mikor, honnan, mit csinált — szűrhető szereplőre, bérlőre, eseménytípusra, időszakra; export. Kiemelt események: pénzügyi művelet, jogosultságváltozás, impersonate, adatexport, törlés, integrációs kulcs megtekintése. Rendszernapló: hibák (Sentry-integráció), lassú lekérdezések, sorok állapota, külső API-k válaszideje és hibaaránya, cron-futások. Riasztások: e-mail / Slack értesítés kritikus eseményekre (fizetési hiba tömegesen, integráció leállt, sor feltorlódott, tárhely 90%).

8.9 Támogatás

Ticketrendszer bérlőhöz kötve, prioritás, SLA-óra, hozzárendelés, belső jegyzet, sablonválaszok, bérlő adatainak megjelenítése a ticket mellett.

9. Store admin felület

9.1 Modulok

9.2 Kiemelt UX-döntések

• Mentett nézetek minden listán (pl. „Ma feladandó”, „B2B fizetésre vár”), megosztható a csapaton belül.
• Globális parancsablak (Ctrl/Cmd+K): ugrás bárhová, rendelés/termék/vásárló keresés, gyors műveletek.
• Tömeges szerkesztés mindenütt, visszavonás lehetőségével (30 mp-es „visszavonás" sáv).
• Piszkozat + publikálás minden tartalmi és megjelenési változtatásnál — az éles bolt soha nem törik el félkész állapottól.
• Kontextusos upsell: ha egy zárolt funkcióra kattint a felhasználó, nem hibaüzenetet kap, hanem egy rövid magyarázatot és egy „mit kapok a Pro-val" panelt.
• Akadálymentesség: WCAG 2.2 AA az admin felületen is (billentyűzet-navigáció, fókusz-jelölés, kontrasztarányok, képernyőolvasó-címkék) — az EAA (európai akadálymentesítési irányelv) miatt ez 2025 óta jogi elvárás a webshopokra is.

10. Storefront és témarendszer

10.1 A téma felépítése

themes/aurora/
├── theme.json          # metaadat: név, verzió, szerző, min. csomag, képességek
├── tokens.json         # design-tokenek sémája + alapértékek
├── screenshot.png
├── layouts/            # app.blade.php, checkout.blade.php
├── sections/           # hero, product-grid, banner, newsletter, footer …
├── templates/          # home, category, product, cart, checkout, account,
│                       # search, blog, page, 404
├── partials/
├── assets/             # css, js, fonts, images
└── translations/       # hu.json, en.json

Design-tokenek (a tokens.json sémája vezérli, milyen szerkesztőelem jelenik meg az adminban):

{
  "color": { "primary":"#2563eb", "ink":"#0f172a", "bg":"#ffffff",
             "surface":"#f1f5f9", "border":"#e2e8f0", "sale":"#dc2626",
             "success":"#059669", "b2b":"#7c3aed" },
  "font":  { "heading":"Inter:700", "body":"Inter:400",
             "size_base":16, "scale":1.25 },
  "shape": { "radius":12, "border_width":1, "shadow":"soft" },
  "layout":{ "container_max":1280, "products_per_row":4,
             "card_style":"bordered", "header":"sticky" }
}

A tokenek CSS custom property-kké fordulnak, bérlőnként cache-elt CSS fájlba. Egy szín módosítása az egész boltra konzisztensen hat — nem kell 40 helyen átírni.

10.2 Testreszabási szintek

A 3–6. szintek biztonságos kipróbálásához a Labor teszt környezet ad helyet (lásd 12. fejezet). Részletes leírás: 11. fejezet — Design Builder.

Egyedi téma feltöltés folyamata: ZIP feltöltés → automatikus ellenőrzés (struktúra, méret < 50 MB, tiltott PHP-hívások szűrése, Blade-sandbox) → staging URL-en előnézet → publikálás. Verziózva, egy kattintással visszaállítható. A Blade sablonok korlátozott környezetben futnak: csak whitelistelt direktívák és view-modellek érhetők el, @php blokk tiltott.

10.3 Beépített sablonok (14 db, 6 az alapcsomagban)

Aurora (univerzális), Onyx (sötét, prémium), Terra (kézműves), Bold (D2C), Atelier (divat), Market (élelmiszer/nagy katalógus), Technica (műszaki cikk, sok paraméter), Bloom (szépségápolás), Trade (B2B/nagyker), Studio (bútor/lakberendezés), Sprint (sport), Pharma (egészség), Kids (gyermek), Minimal (letisztult egytermékes).

Mindegyik: reszponzív, WCAG 2.2 AA, Core Web Vitals optimalizált, RTL-kész, PWA-kompatibilis.

10.4 Storefront teljesítmény

• Full-page cache Redisben, bérlő + nyelv + deviza + vásárlói csoport kulccsal; készletváltozásnál célzott invalidálás.
• Képek: automatikus WebP/AVIF, több méret, srcset, lazy loading, CDN-barát URL-ek.
• Kritikus CSS inline, a többi késleltetve; JS csak ahol kell (Alpine + Turbo).
• Meilisearch a keresésre és a fasettes szűrésre (nem SQL LIKE).
• Célszám: LCP < 2,0 s, INP < 200 ms, CLS < 0,1 mobilon, 4G-n.

11. Design Builder (feláras modul)

11.1 Pozicionálás és üzleti modell

A Builder nem része az alapcsomagnak — külön havidíjas modul (4 990 Ft/hó), amely bármelyik csomaghoz megvehető, és az Enterprise csomagban alapból benne van. 14 napos ingyenes próba jár hozzá.

Miért így: a sablonválasztás és a színszerkesztés minden bérlőnek kell (különben nem indul el a bolt), de a szabad szerkesztés fejlesztői és támogatási költsége nagyságrendekkel nagyobb — ezt külön kell finanszírozni. Emellett ez egy jól kommunikálható, önmagában érthető értékajánlat, ami a Start csomagos bérlőknél is konvertál, anélkül hogy csomagot kellene váltaniuk.

Fontos garancia: ha a bérlő lemondja a Buildert, a vele készített oldalak továbbra is kiszolgálásra kerülnek — csak szerkeszthetetlenné válnak. A bolt soha nem esik szét egy add-on lemondásától. A bérlő ilyenkor két dolgot tehet: visszaáll a sablon alapelrendezésére, vagy újra előfizet. A szerkesztetlen állapot a Builder újra-előfizetésekor változatlanul folytatható.

Mit tud a Builder nélkül a bérlő (minden csomagban):

• sablont választani a 14 közül,
• design-tokeneket állítani (színek, betűtípusok, méretek, rádiusz, rács),
• a sablon előre definiált szekcióit be-/kikapcsolni és sorrendezni,
• a szekciók tartalmi mezőit kitölteni (cím, szöveg, kép, link),
• bannereket és boxokat elhelyezni a sablon által megadott helyekre.

Mit ad hozzá a Builder:

• tetszőleges szekció hozzáadását a szekciótárból, bárhová,
• elem szintű szerkesztést (szöveg, kép, gomb, ikon, elválasztó, térköz) drag-and-droppal,
• oszlopelrendezés és rácsszerkezet szabad kialakítását,
• szekciónkénti stílusfelülírást (háttér, térköz, szélesség, animáció),
• eszközönként eltérő beállításokat (desktop / tablet / mobil),
• feltételes megjelenítést (dátum, vásárlói csoport, nyelv, belépési státusz),
• globális szekciókat (fejléc, lábléc egy helyen szerkesztve),
• saját szekciósablonok mentését és újrafelhasználását,
• verziótörténetet és ütemezett publikálást.

11.2 Szerkesztési hierarchia

Oldal (page)                     főoldal, kategória, termék, kosár, blog, landing, 404 …
 └── Szekció (section)           teljes szélességű sáv, saját háttérrel és térközzel
      └── Sor (row)              1–4 oszlop, állítható aránnyal és igazítással
           └── Oszlop (column)
                └── Elem (element)   szöveg, kép, gomb, ikon, videó, termékrács,
                                     űrlap, elválasztó, térköz, egyedi HTML

Minden szinten három beállításcsoport: Tartalom · Stílus · Láthatóság.

11.3 Szerkeszthető oldaltípusok

11.4 Szekciótár (induló készlet, ~30 szekció)

Bemutató: Hero (statikus / slider / videó háttér) · Kiemelt banner · Banner rács (2–4 elem) · Szöveg + kép · Idézet · Visszaszámláló · Bejelentő sáv

Kereskedelmi: Termékrács (kézi / kategória / automatikus válogatás) · Termék carousel · Kiemelt egytermék · Kategóriarács · Márkalogó-fal · Összehasonlító táblázat · Ajánlott termékek (cross-sell) · Legutóbb megtekintett

Bizalom: USP ikonsor · Vélemények / értékelések · Ügyfél-logók · Statisztika-sáv · GYIK (accordion) · Blogajánló

Kapcsolat: Hírlevél feliratkozás · Kapcsolatűrlap · Térkép · Nyitvatartás · Instagram fal · Videó beágyazás

Szerkezeti: Elválasztó · Térköz · Egyedi HTML (Pro-tól) · Tabok · Rejtett/feltételes konténer

11.5 A szerkesztő felület

• Bal panel — szekciófa: drag-and-drop sorrendezés, duplikálás, rejtés, törlés. A globális szekciók (fejléc, lábléc) külön jelöléssel. Alul a szekciótár és a saját mentett sablonok.
• Középső vászon: valós, élő renderelés (nem absztrakt doboz-előnézet). Kattintásra kiválasztás, lebegő eszköztár a kijelölt szekció felett (fel / le / duplikálás / rejtés / törlés), szövegre duplán kattintva helyben szerkeszthető WYSIWYG.
• Jobb panel — inspector: a kijelölt elem beállításai, Tartalom / Stílus / Láthatóság füleken.
• Felül: oldalválasztó, eszközváltó (desktop / tablet / mobil), visszavonás–újra, verziótörténet, „Előnézet a Laborban", „Piszkozat mentése", „Publikálás".

Használhatósági alapelvek: minden művelet visszavonható (Ctrl+Z, korlátlan mélységig a munkamenetben) · autosave 10 másodpercenként piszkozatba · a publikálás mindig tudatos, külön gomb · a szerkesztő soha nem ír élesbe.

11.6 Reszponzív viselkedés és feltételes megjelenítés

Minden stílusérték eszközönként felülírható (desktop az alap, tablet és mobil örököl, amíg felül nem írják). A szekciók külön el is rejthetők eszközönként.

Feltételes megjelenítés (szekció és elem szinten is):

11.7 Pénztár — a szándékos kivétel

A pénztár (kosártól a fizetés visszaigazolásáig) nem szerkeszthető szabadon. Helyette a bérlő előre elkészített, hitelesített elrendezések közül választ, és definiált beszúrási pontokat (slot) tölt fel saját tartalommal.

Miért:

1. Konverzió — a pénztár minden eleme mért; egy rosszul elhelyezett blokk közvetlen bevételkiesés.
2. Jogi megfelelés — a kötelező tájékoztatások (ÁSZF, elállási jog, adatkezelés, ÁFA-bontás, végösszeg) nem törölhetők és nem rejthetők el.
3. Fizetésbiztonság — PCI DSS SAQ-A: a fizetési mezők közelébe nem kerülhet idegen, bérlő által írt kód.
4. Akadálymentesség — a vásárlási folyamatra a WCAG 2.2 AA megfelelést a platform garantálja.
5. Integrációk — a csomagpont-választó, a fizetési átirányítás és a szállítási díjszámítás állapotfüggő; szabad szerkesztés mellett nem tesztelhető.

Választható elrendezések (induláskor 4):

Beszúrási pontok (slot):

A slotokba engedélyezett blokkok: szöveg, ikonsor, kép/banner, bizalmi jelvény, értékelés-widget. Egyedi HTML csak Pro csomagtól, és ott is szűrt (script tag és külső erőforrás-betöltés tiltott). A pénztár színeit és tipográfiáját mindig a téma design-tokenjei adják — így a fizetési folyamat vizuálisan illeszkedik, de szerkezetileg stabil marad.

Kosár: a kosároldal nem része a zárt folyamatnak, ezért teljesen szerkeszthető.

11.8 Adatmodell (bérlői adatbázis)

page_layouts       id, page_type, name, is_default, status(draft|published),
                   published_at, publish_at, version, theme_key
layout_sections    id, layout_id, parent_id, type, sort, content(json),
                   style(json), style_tablet(json), style_mobile(json),
                   visibility(json), global_ref_id, is_hidden
layout_versions    id, layout_id, version, snapshot(json), author_id, note,
                   created_at
global_sections    id, key(header|footer|announcement), name, snapshot(json)
section_presets    id, name, thumbnail, payload(json), scope(system|tenant)
checkout_layout    id, layout_key, options(json)
checkout_slots     id, slot_key, blocks(json), updated_at
media              id, folder_id, path, variants(json), alt, focal_point,
                   size, mime, used_in(json)

11.9 Technikai megvalósítás

• A szerkesztő Vue 3 + Inertia alkalmazás, a vászon iframe-ben rendereli az éles Blade témát — így amit a bérlő lát, az bitre azonos azzal, amit a vásárló látni fog.
• A szerkesztő és az iframe postMessage-en kommunikál (kijelölés, hover, görgetés, frissítés).
• A mentett elrendezés JSON, amit a téma renderelője dolgoz fel. Nincs generált HTML tárolva — a téma frissítése így nem töri el a bérlő oldalait.
• Sanitizálás: minden szövegmező HTML Purifier-en megy át; a szekciók sémavezérelten (JSON Schema) validálódnak; ismeretlen szekciótípus renderelése kihagyásra kerül, nem hibázik.
• Teljesítmény: a publikált elrendezés renderelt HTML-je Redisbe cache-elődik (bérlő + oldal + nyelv + deviza + vásárlói csoport + eszköz kulccsal). Publikáláskor célzott invalidálás.
• Képek: a médiatárból, automatikus WebP/AVIF variánsokkal, focal point alapú vágással.
• A Builder minden módosítása az activity_log-ba kerül (ki, mikor, melyik oldalon, mit).

11.10 Sablonok szerkeszthetősége

Mind a 14 beépített sablon ugyanazt a szekció-interfészt valósítja meg, ezért a Builder mindegyiken ugyanúgy működik, és sablonváltáskor a tartalom nem vész el: a szekciók típusa és tartalma megmarad, csak a megjelenítésük változik. Ahol egy sablon nem támogat egy szekciótípust, ott a rendszer a legközelebbi megfelelőt használja, és erről a bérlő figyelmeztetést kap a váltás előtti előnézetben.

12. Labor — teszt (staging) környezet

12.1 Mi ez

A Labor az éles bolt teljes, működő másolata külön URL-en, amelyben a bérlő bármit kipróbálhat anélkül, hogy a vásárlói bármit észlelnének belőle.

A Labor címe: <slug>.labor.polcra.hu — ugyanazzal a sluggal, amivel a bolt létrejött:

éles bolt   boltom.polcra.hu      →   Labor   boltom.labor.polcra.hu
            kavebolt.polcra.hu    →           kavebolt.labor.polcra.hu

A cím automatikusan létrejön a Laborral együtt, DNS-beállítás nélkül, a *.labor.polcra.hu wildcard tanúsítvány alatt. Akkor is működik, ha a bérlő időközben saját domaint kötött az éles boltjához (kavebolt.hu) — a Labor mindig a platform aldomainjén marad. Ez szándékos: így a Labor soha nem függ a bérlő DNS-ének állapotától, és a külső fejlesztő akkor is tud dolgozni, ha az éles domain körül épp probléma van.

Opcionálisan a bérlő beállíthat saját labor.<bolt-domain> CNAME-et is, ha ez arculati okból fontos neki — de ez nem alapértelmezés, és a platform-aldomain ilyenkor is elérhető marad.

Mire használják:

• új sablon vagy Builder-elrendezés kipróbálása élesítés előtt,
• nagyobb kampányoldal (Black Friday, ünnepi arculat) összerakása előre,
• termékimport és tömeges árváltoztatás próbája,
• új szállítási vagy fizetési mód beállításának végigtesztelése,
• külső fejlesztő vagy ügynökség munkája az éles bolt kockáztatása nélkül,
• egyedi téma (ZIP) feltöltése és hibakeresése,
• API- és webhook-integráció fejlesztése.

12.2 Létrehozás és szinkronizálás

[Éles bolt]  ──── „Friss másolat” ────►  [Labor]
   adatbázis-pillanatkép + médiafájlok (copy-on-write hivatkozással)
   + opcionális vásárlói adat-anonimizálás

• A másolat készítése háttérfeladat (Horizon), tipikusan 1–5 perc. Alatta a Labor „építés alatt" állapotban van, az éles bolt érintetlen.
• A média nem duplikálódik fizikailag: a Labor olvasásra az éles fájlokra hivatkozik, és csak a benne módosított/feltöltött fájlok kerülnek külön tárolásra. Így a Labor tárhelyigénye töredéke az élesének.
• A frissítés bármikor újrafuttatható — a Laborban lévő módosítások ilyenkor elvesznek, ezért a rendszer megerősítést kér, és a Labor állapotáról előtte pillanatképet ment.

12.3 Átemelés élesbe (promote)

A visszairány szelektív, nem teljes adatbázis-visszaállítás. A bérlő kiválasztja, mit vigyen át:

Az átemelés előtt automatikus mentés készül az éles boltról, és az átemelés 7 napig visszavonható. Az eltérések előre megtekinthetők (diff nézet), a művelet az audit naplóba kerül.

12.4 Biztonsági korlátok a Laborban

Ezek nem kikapcsolhatók, mert nélkülük a teszt környezet valós kárt okozhatna:

A Labor felületén állandó, elmozdíthatatlan sáv jelzi, hogy teszt környezetben vagy — mind az adminban, mind a storefronton.

12.5 Adatvédelem

A másolat készítésekor a vásárlói személyes adatok alapértelmezetten anonimizálódnak (név, e-mail, telefon, cím, IP maszkolása determinisztikus álnevesítéssel, hogy a kapcsolatok megmaradjanak). Ez GDPR-szempontból lényeges: a teszt környezet más hozzáférési körrel bír (pl. külső fejlesztő), ezért nem szabad valós személyes adatot tartalmaznia.

Az anonimizálás kikapcsolható, de csak a bolt tulajdonosa által, kifejezett nyilatkozattal, és az esemény naplózásra kerül.

12.6 Erőforrás és alvó állapot

• A Labor tárhelye a csomag kvótájának 50%-ával számít bele (mert a média nagy része megosztott).
• 30 nap tétlenség után a Labor alvó állapotba kerül: az adatbázisa tömörítve leáll, az URL-je egy „alvó, ébresztés egy kattintással" oldalt mutat. Az ébresztés ~20–30 másodperc. Ez a platform infrastruktúra-költségének nagy részét megspórolja, mert a Laborok többsége az idő 95%-ában nincs használatban.
• Az alvó Labor tartalma megmarad; törlésre csak a bérlő kérésére vagy az előfizetés végleges megszűnésekor kerül sor.

12.7 Hozzáférés

• A bolt admin felhasználói szerepkör szerint férnek hozzá.
• Külső fejlesztői hozzáférés: meghívható olyan felhasználó, aki csak a Labort éri el, az éles boltot nem — lejárati dátummal.
• Megosztható előnézeti link jelszóval és lejárattal, belépés nélküli véleményezéshez (pl. az ügyfél marketingesének).

12.8 Az előfizetéshez kötöttség

A Labor az aktív előfizetés része. Az életciklusa szigorúan követi az előfizetését, és a felfüggesztési sorrendben elsőként esik ki — így a bérlő először egy fájdalommentes figyelmeztetést kap, mielőtt az éles bolt bármit érezne:

A Labor tartalma a felfüggesztés alatt nem vész el, csak nem elérhető.

Csomaghoz kötés: a Labor elérhetősége csomagonként szabályozott (env.labor funkciókulcs), és a superadminban bármikor átállítható — beleértve azt is, hogy minden csomagban díjmentesen járjon. Az induló beállítás: Start — add-onként (2 900 Ft/hó) · Business — 1 db a csomagban · Pro — 2 db · Enterprise — 5 db. A további környezetek mindenhol add-onként vásárolhatók.

12.9 Adatmodell (központi adatbázis)

environments    id, tenant_id, type(production|labor), db_name, url, status
                (building|active|sleeping|suspended|archived), storage_mb,
                last_sync_at, last_activity_at, sleeps_at, anonymized(bool)
env_sync_jobs   id, environment_id, direction(pull|promote), scope(json),
                status, snapshot_id, started_at, finished_at, log, actor_id
env_access      id, environment_id, user_id|invite_email, level, expires_at
env_snapshots   id, environment_id, reason, path, size, created_at, expires_at

12.10 Technikai megvalósítás

A Labor a bérlői adatbázis-per-bérlő modellben természetesen adódik: a Labor egyszerűen egy másik bérlői adatbázis (tenant_kavebolt_labor), ugyanazon alkalmazáskód alatt, egy environment=labor kontextusjelzővel. Ez az egyik legerősebb érv a választott multi-tenancy modell mellett — közös adatbázis + tenant_id oszlop mellett a staging lényegesen bonyolultabb és kockázatosabb lenne.

A környezetjelző hatásai a kódban: config('env.is_labor') alapján a fizetési, e-mail, futár és számlázó szolgáltatók automatikusan a sandbox implementációjukra váltanak (service container binding), a feed- és webhook-kibocsátó pedig no-op implementációt kap. Ez egy helyen dől el, nem szórva szét feltételekkel a kódbázisban.

13. B2B modul

A store admin egyetlen kapcsolóval választ üzemmódot: B2C, B2B, vagy vegyes (ugyanaz a bolt mindkettőt kiszolgálja, a látogató típusától függően).

13.1 Amit a B2B mód megváltoztat

13.2 Vegyes üzemmód

Ugyanaz a katalógus, két arc: a vendég és a B2C vásárló bruttó árat lát akciókkal, a belépett B2B partner nettót az egyedi árlistája szerint. A termékek külön jelölhetők „csak B2B" vagy „csak B2C" láthatóságúra, és a szállítási/fizetési módok is köthetők vásárlói csoporthoz.

14. Integrációk

14.1 Fizetés

Egységes PaymentGateway interfész: authorize(), capture(), refund(), void(), webhook(), storeCard(), chargeStored(). Új szolgáltató bekötése = egy osztály + egy JSON konfigséma.

14.2 Szállítás

GLS · MPL (Magyar Posta) · Foxpost · Packeta (Zásilkovna) · DPD · Express One · Sameday (easybox) · Wolt Drive · GLS ParcelShop · MPL PostaPont · saját fuvar · személyes átvétel.

Egységes ShippingCarrier interfész: rates(), pickupPoints(), createLabel(), track(), cancel(), manifest(). Csomagpont-választó térképes felülettel a pénztárban, a futár API-jából élő adatokkal.

14.3 Számlázás

Billingo (elsődleges) · Számlázz.hu / Számla Agent (tartalék) · KBOSS · saját NAV Online Számla 3.0 közvetlen kapcsolat (Enterprise).

A platform saját előfizetési számláit is a Billingo állítja ki; a Számlázz.hu tartalékként be van kötve, és a superadminban egy kapcsolóval átváltható, ha a Billingo elérhetetlen.

Kezelt dokumentumtípusok: számla, díjbekérő (proforma), előlegszámla, végszámla, sztornó, helyesbítő, nyugta. Automatikus kiállítás konfigurálható státuszváltáskor, e-mailben csatolva, PDF a vásárló fiókjában.

14.4 Termékfeedek és marketplace

Google Shopping / Merchant Center · Árukereső.hu · Meta (Facebook/Instagram) katalógus · TikTok Shop · Pinterest · Pepita · eMAG Marketplace (rendelés-szinkron) · Vatera · Glami · Trendmall · egyedi XML/CSV feed generátor sablonnal.

14.5 Marketing és elemzés

Google Analytics 4 (+ Consent Mode v2) · Google Tag Manager · Google Ads (Enhanced Conversions) · Meta Pixel + Conversions API · Mailchimp / SalesAutopilot / Mailerlite · Klaviyo · Optimonk · Smartsupp / Tawk.to chat · Trustindex / Árukereső Megbízható Bolt · Hotjar · Sentry.

14.6 Egyéb

ERP/könyvelés: Kulcs-Soft, Novitax, RLB, MiniCRM, saját REST · WMS-kapcsolat (Enterprise) · Google Maps API (címellenőrzés, csomagpont-térkép) · reCAPTCHA v3 / Cloudflare Turnstile · DeepL / OpenAI-kompatibilis fordítás- és termékleírás-generálás.

15. API

15.1 Admin REST API (Pro-tól)

https://<bolt>/api/v1/... — OAuth2 client credentials vagy személyes hozzáférési token. Erőforrások: products, variants, categories, stock, orders, customers, customer_groups, price_lists, discounts, shipments, invoices, webhooks. Kurzoralapú lapozás, include paraméter kapcsolatokhoz, updated_since szűrő szinkronhoz, ETag. Rate limit csomagonként (600 kérés/perc Pro-n).

15.2 GraphQL Storefront API (Pro-tól)

Csak olvasás + kosár/pénztár mutációk, publikus tokennel. Headless frontendhez (Next.js, Nuxt) és mobilalkalmazáshoz. Perzisztált lekérdezések, mélységi limit, komplexitási pontszám.

15.3 Webhookok

order.created, order.updated, order.paid, order.shipped, order.cancelled, product.created/updated/deleted, stock.low, customer.created, invoice.issued, subscription.updated. HMAC-SHA256 aláírás, 3 újrapróbálkozás exponenciális visszalépéssel, kézbesítési napló az adminban.

15.4 Platform API (superadmin)

Bérlőkezelés, előfizetés, számlázás — belső eszközökhöz és a viszonteladói partnereknek.

16. Biztonság és megfelelőség

16.1 Biztonság

16.2 GDPR és jogi megfelelés

• Adatkezelői szerepek: a platform adatfeldolgozó a bérlő vásárlói adatai felett, és adatkezelő a bérlő saját adatai felett. Adatfeldolgozói szerződés (DPA) az ÁSZF mellékleteként, alvállalkozói lista nyilvánosan.
• Érintetti jogok: a store adminban egy kattintással vásárlói adatexport (JSON/PDF) és törlés (anonimizálás a számviteli kötelezettség miatt megőrzendő adatokon).
• Cookie: beépített, kategóriákra bontott hozzájárulás-kezelő (működéshez szükséges / analitikai / marketing / személyre szabás), Google Consent Mode v2 kapcsolattal.
• Megőrzés: rendelési adat 8 év (számviteli tv.), naplók 1 év, marketing hozzájárulás visszavonásig.
• Fogyasztóvédelem: kötelező tájékoztatások (elállási jog, 14 nap, szavatosság), ÁSZF-generátor, árfeltüntetési szabályok (akciós árnál a megelőző 30 nap legalacsonyabb ára — Omnibus irányelv), egységár kijelzése.
• Akadálymentesség: EAA / WCAG 2.2 AA — a storefront sablonok és az admin is. Akadálymentesítési nyilatkozat generálása.
• NAV Online Számla 3.0 kötelező adatszolgáltatás (a számlázó partneren keresztül vagy közvetlenül).
• Adattárolás helye: EU (magyar adatközpont), a bérlő adatai nem hagyják el az EGT-t.

17. Nem funkcionális követelmények

18. Fejlesztési ütemterv

Fázis 0 — Alapozás (3-4 hét)

Laravel 13 projekt, multi-tenancy (stancl/tenancy), központi és bérlői migrációk, hitelesítés, szerepkörök, CI/CD, staging környezet, monitorozás (Horizon, Sentry), alap design-rendszer (Tailwind 4 tokenek).

Fázis 1 — MVP, működő webshop (10-12 hét)

Katalógus (termék, kategória, kép, készlet) · kosár és pénztár · rendeléskezelés · vásárlók · 3 sablon token-szerkesztővel · alap szállítás és fizetés (utánvét, átutalás, Barion, SimplePay) · GLS + Foxpost · Billingo · e-mail értesítések · SEO alapok · store admin dashboard · superadmin bérlőkezelés · Start és Business csomag.

Ez a fázis végén már élesíthető az első fizető bérlő.

Fázis 2 — Kereskedelmi érettség (8-10 kt)

Termékváltozatok és paraméterek · összetett szűrés, Meilisearch okoskereső · kedvezmények, kuponok, hűségpont · elhagyott kosár, hírlevél · termékfeedek (Google, Árukereső, Meta) · további futárok és fizetési módok · visszáru · jelentések · vizuális oldalszerkesztő · 14 sablon · PWA · előfizetés-kezelés és automata számlázás (Barion recurring + Billingo) · publikus oldal CMS.

Fázis 3 — Pro képességek és a Labor (8-10 hét)

B2B modul (csoportok, árlisták, hitelkeret, ajánlatkérés) · több nyelv és deviza · több raktár · REST + GraphQL API, webhookok · egyedi téma feltöltése · Labor teszt környezet (klónozás, szelektív átemelés, sandbox integrációk, alvó állapot) · marketplace (eMAG, Pepita, TikTok) · haladó jelentések · automata folyamatok · Pro csomag indítása.

A Labort tudatosan a Fázis 3-ba tettük: az egyedi téma feltöltése és az API-fejlesztés nélküle kockázatos, tehát a kettőnek együtt kell megjelennie.

Fázis 3,5 — Design Builder (6-8 hét, párhuzamosítható)

A Builder önálló, jól körülhatárolt termék, és önálló bevételi forrás — ezért külön fázisként, akár párhuzamos csapattal érdemes vinni. Tartalma: szekció-interfész bevezetése mind a 14 sablonban · szerkesztő felület (iframe-alapú vászon, inspector, szekciófa) · szekciótár (~30 szekció) · reszponzív és feltételes megjelenítés · verziózás és ütemezett publikálás · pénztár-elrendezések és slotok · médiatár · add-on számlázás és 14 napos próba.

Előfeltétel: a Labor kész legyen, mert a Builder előnézete és a nagyobb átalakítások ott zajlanak.

Fázis 4 — Enterprise és skálázás (folyamatos)

Több áruház egy fiókban · ERP/WMS integrációk · dedikált erőforrás · SLA · A/B tesztelés · AI-funkciók (termékleírás, fordítás, keresés) · viszonteladói/ügynökségi program · alkalmazásbolt harmadik feleknek.

Becsült ráfordítás az MVP-ig

19. Kockázatok

20. Kiegészítések, amiket érdemes betervezni

Ezek nem szerepeltek az eredeti kérésben, de egy multi-tenant webshopnál előbb-utóbb mind előkerül:

1. Migrációs (import) eszköz Shoprenterről és UNAS-ról — ez a legerősebb akvizíciós eszköz. Termék, kategória, vásárló, rendelés, plusz URL-átirányítási térkép a SEO megőrzésére.
2. Sablon-előnézet a bérlő saját adataival: a sablonválasztó ne demó-tartalmat mutasson, hanem a bérlő valódi termékeit — így a döntés valós. (A Labor ezt már megoldja, de a választó felületen is kell.)
3. Alkalmazásbolt (marketplace) harmadik feleknek — hosszú távon ez tartja el az ökoszisztémát; már most úgy kell tervezni az integrációs interfészt, hogy később kinyitható legyen.
4. Viszonteladói / ügynökségi program: webshop-készítő ügynökségek több boltot kezelnek egy fiókból, jutalékkal és csoportos számlázással.
5. Rendszerállapot-oldal (status.polcra.hu, külön infrastruktúrán) és incidenskommunikáció — bizalomépítő.
6. Adatexport-garancia: a bérlő bármikor letöltheti minden adatát (termékek, rendelések, vásárlók, képek) egy ZIP-ben. Ez csökkenti a „bezártságtól" való félelmet, és jogi elvárás is.
7. Használati statisztika a superadminban bérlőnként (mely funkciókat használja): ebből derül ki, mit érdemes fejleszteni, és melyik bérlő van churn-veszélyben.
8. Számlázási próbaüzem („dry run"): minden ciklus előtt kilistázható, mi fog terhelődni — így a hibás számlázás még kiállítás előtt észrevehető.
9. Automata folyamatok (workflow): „ha rendelés > 100 000 Ft és B2B, akkor címkézd és értesítsd a kereskedelmi vezetőt". Ez a Pro csomag egyik legjobban eladható eleme.
10. Többszereplős jóváhagyás veszélyes műveleteknél (bérlő törlése, tömeges árváltoztatás).
11. Rendelés-összevonás és részszállítás — nagyobb boltoknál napi igény.
12. Készlet-előfoglalás a pénztárban, hogy két vásárló ne vegye meg ugyanazt az utolsó darabot.
13. Feature flag rendszer a fokozatos kivezetéshez (előbb 5% bérlőn, aztán mindenkin).
14. Beépített A/B tesztelés a storefront szekciókra (Pro-tól).

21. Döntési napló

A specifikáció 1.0 verziójában felvetett nyitott kérdések eldőltek. Az alábbi táblázat a véglegesített döntéseket rögzíti, dátummal — ez a dokumentum hivatkozási pontja minden későbbi vitánál.

21.1 Ami még nyitott

Dokumentum vége. Verzió 1.2 — 2026. augusztus 28. (fődomain: polcra.hu; Labor-cím pontosítva)