E Commerce Standards

E-commerce standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when designing, choosing a platform for, or reviewing an online store as a system: catalogue, inventory, cart, price, taxes, shipping, checkout, order, return, promotions, product search, catalogue SEO, traffic peaks and abuse. It also covers the prior decision — whether building your own store is worth it at all — and the replatform decision.

Triggers: SKU, variant, product attribute, catalogue, stock, inventory reservation, overselling, cart, checkout, guest versus registration, order, order state machine, fulfillment, shipping, return, RMA, VAT, OSS, IOSS, coupon, promotion, schema.org/Product, JSON-LD, canonical, 301 redirect, redirect map, facets, noindex, sitemap.xml, robots.txt, Black Friday, scalping, bot, CNP, Shopify, WooCommerce, Magento, Adobe Commerce, PrestaShop, Saleor, Medusa, commercetools, VTEX, headless, composable, MACH.

Thesis of this skill: a store is an inventory and accounting system with a website in front of it. The website is rebuilt every three years; the catalogue, the stock, the order history and the URL map outlive every fashion — and they are what breaks at every replatform. Design for that, not for the visual theme.

Second thesis: almost every "store problem" is a concurrency problem or a URL identity problem in disguise. Overselling is a race condition; coupons stacked up to 100% are a race condition with business logic; the traffic drop after a migration is an incomplete redirect map. None of the three is fixed with more cache.

Not applicable: see fintech-payments-standards (sister skill of this batch and a hard dependency: PCI DSS scope and SAQ selection, tokenisation, SCA/PSD2 and its exemptions, 3-D Secure, the authorisation and capture state machine, charge idempotency, reconciliation and settlement, chargebacks, accounting in minor units and the immutable ledger. Exact boundary: the amount to charge is decided here; from POST /payments onwards it is theirs. Rule that avoids duplication: how much and why → this skill; what happens to that amount → payments), gaming-infrastructure-standards and game-development-standards (a game's store is a store and belongs here: catalogue, price, virtual currency as a SKU, tax and cart, with the charge delegated just like any other to fintech-payments-standards. What does not belong here: receipt validation on the game server and signature verification of its webhook, which are theirs because the client lies), web-performance-standards (measurement and the performance budget are theirs: Core Web Vitals, field data, 75th percentile, budgets in CI. Here only where it hurts in a store — product page and checkout — and what gets prioritised when you must choose. Do not duplicate metrics or thresholds: delegate them), caching-cdn-standards (cache policy, key, purging and CDN; here only what is cacheable in a store and what never is: catalogue yes, cart and personalised price no), search-engines-standards (the search engine, indexing, relevance, synonyms and technical facets are theirs; here what is expected of product search and why a badly exposed facet creates a crawl trap), accessibility-standards (the technical WCAG/EN 301 549 criterion, auditing and tooling are theirs; here only that e-commerce is a covered service under Directive (EU) 2019/882 and what that implies for the project — §3.10), appsec-standards (threat modelling and OWASP; here only domain-specific abuse: coupons, scalping, catalogue enumeration), privacy-engineering-standards (legal basis, consent, retention and rights; here only the concrete friction point with commerce analytics — §3.11), analytics-bi-standards (the dashboard and its governance are theirs; here which commerce event must be emitted and why the funnel is measured on the server), cms-jamstack-standards (editorial content modelling and editing, headless CMS, preview and revalidation after publishing; here the catalogue as transactional data, which is not content), frontend-web-platform-standards and frontend-frameworks-standards (building the storefront), i18n-standards (language, price and date formatting, hreflang, multi-market catalogue), data-warehouse-modeling-standards (the order fact for analytics), message-brokers-standards (order and inventory events and their at-least-once delivery), microservices-architecture-standards (the criterion for when to split — key to judging the composable pitch in §3.2), sre-practice-standards and observability-standards (SLOs, telemetry, capacity and campaign peak readiness), opensource-licensing-standards (the platform's licence decides what you can do with your own store: Magento's and PrestaShop's OSL-3.0 is not MIT and carries copyleft and network conditions — §3.1), grc-compliance-standards (consumer, marketplace and sanctions obligations as a programme), ai-governance-standards (recommender and dynamic pricing: transparency and classification).

2. Default decisions

Verify prices, licences, versions and regulatory status on the web before fixing them in a real project (§8). Data as of August 2026.

2.1 Platforms: licence and cost model

Licences verified from the raw LICENSE file (August 2026); prices from the vendor's page:

Honest comparison rule: total cost is subscription + per-transaction fee + extensions + hosting + people. A "free" platform with 0.5 points more in fees is more expensive than a paid one from a surprisingly low volume onwards — do the maths with your average order value and your volume before choosing, not with the feature table.

3. Technical criteria

3.1 When NOT to build your own store

Cases where the store is the wrong answer, said without diplomacy:

• Fewer than ten SKUs and no recurrence: a PSP payment link solves 100% of the problem with 2% of the code.
• The real channel is a marketplace: if your sales come from a third party, your own store is a fixed cost with vanity traffic. The decision is a business one and must be taken explicitly.
• Digital product or pure subscription: the problem is billing and access entitlements, not catalogue or logistics.
• Nobody to operate it: a store is a 24×7 production system handling money. Without someone responsible for patches, incidents and discrepancies, self-hosting is a breach with a date on it.
• B2B with negotiated pricing and rep-placed orders: that is an ERP with a portal, not a store.

And the licence trap discovered too late: OSL-3.0 (Magento, PrestaShop core) is not MIT. Before assuming you can distribute a fork, package a multi-store SaaS or publish derived modules, run the decision through opensource-licensing-standards.

3.2 Monolith versus composable / MACH

The composable pitch is real but badly sold. Honest criterion:

The platform monolith wins when the catalogue fits the standard model, the team is small, and the competitive advantage is not in the storefront. A well-built theme on a mature platform solves 90% of stores.

Composable is justified when: there are several channels or markets with different rules and the same catalogue; the product model does not fit the standard (configurators, contract pricing, units of measure); there are separate teams that need to deploy without blocking each other; or the current platform is the measured bottleneck, not the suspected one.

Cost omitted from the pitch deck: every piece has its own contract, version, billing, latency and failure mode — and consistency across catalogue, price and stock stops being a database transaction and becomes a distributed problem. That leap is exactly the one in microservices-architecture-standards: if you are not willing to pay for outbox, idempotency and eventual consistency, you are not ready for composable. Splitting a store does not make it faster; it makes it harder to leave inconsistent without noticing.

3.3 Catalogue, variants and attributes

• Distinguish product from variant in the model: the product is what is described and ranked; the variant (SKU) is what has price, stock and weight. Modelling them as a single entity is the structural mistake that forces a catalogue rebuild.
• The SKU is a business identifier, opaque and stable. Do not encode attributes inside it (SHIRT-RED-XL becomes a lie the day the colour changes).
• Typed attributes (number with unit, boolean, enumeration), not free strings: facets, filters and the product feed come out of them. A free-text attribute is neither filterable nor comparable.
• Media is catalogue too: a stable identifier per image, with size variants generated, not uploaded by hand.
• Attribute schema versioning: adding a mandatory attribute to a live catalogue is a migration, with its default value and its backfill plan.

3.4 Inventory: the race condition that defines the domain

"Check then subtract" is a guaranteed bug under concurrency. This pattern, in any language, oversells:

stock = SELECT quantity FROM inventory WHERE sku = ?
if stock >= n:  ->  UPDATE inventory SET quantity = quantity - n WHERE sku = ?

Another request fits between the SELECT and the UPDATE. It is not unlikely: in a launch, it is the norm. Correct alternatives, in order of preference:

1. Atomic conditional decrement: the check travels inside the write, and the database guarantees only one wins. UPDATE ... SET quantity = quantity - :n WHERE sku = :sku AND quantity >= :n, and if it affects zero rows, there is no stock. One statement, no prior read, no explicit lock.
2. Reservation with expiry: for long checkouts, stock is reserved on entering checkout and converted into consumption on confirmation, or it expires. It requires a process that releases expired reservations — and that process is part of the design, not an extra.
3. A database constraint as a safety net: CHECK (quantity >= 0). It does not replace the above; it turns a silent oversell into a visible error.

Associated decisions:

• Reservation is a business decision, not a technical one: reserving on add-to-cart protects the buyer and enables bot hoarding (§3.8); reserving on payment maximises sales and produces cancellations. Choose explicitly, with an expiry.
• Controlled overselling (accepting an order without stock, restocking later) is a legitimate strategy if it is explicit and communicated, with its timeframe. Accidental overselling is a customer-support and reputation incident.
• A single source of truth for stock. If the ERP and the store each have their own number, the question is not which is right but which one wins and with what latency. Write it down.
• Multi-warehouse changes the problem: available stock depends on the destination and the shipping method. Do not model it as a global integer if you are going to need it.

3.5 Cart, order and their states

• The cart lives on the server with its own identifier, tied to the user when there is one and to a first-party cookie when there is not. Merging a guest cart with a user cart on login is a case that must be decided and tested (does it add up? does the most recent win?), not left to chance.
• The price is recalculated on the server at confirmation time. Any amount arriving from the client is a hostile suggestion. It is the oldest store vulnerability there is and it still shows up.
• The order is immutable once confirmed; changes are subsequent events (amendment, partial cancellation, return), not edits. This is what lets you explain to a customer — or to an inspector — why they were charged what they were charged.
• Explicit state machine, with allowed transitions declared: created → paid → picked → shipped → delivered, plus cancelled and returned with their rules. A free-text status column with no valid transitions ends up with orders in impossible states.
• The order state is not the payment state (fintech-payments-standards, §3.4). An order paid and not shipped and an order shipped and not charged are both possible and both need representation.

3.6 Price, taxes and VAT in the EU

• Price with and without tax, separated in the model, with the presentation criterion decided per market (B2C tax-inclusive, B2B usually exclusive).
• The destination rules. In the EU, for distance sales to consumers, the place of taxation is the customer's. The threshold is in Art. 59c of the VAT Directive (introduced by Directive (EU) 2017/2455), verbatim: the exception only applies if "the total value, exclusive of VAT, of the supplies referred to in point (b) does not in the current calendar year exceed EUR 10 000" — and also the previous year. Above €10,000 total intra-EU, the destination country's rate applies.
• OSS (one-stop shop) allows declaring all of that in a single Member State instead of registering in each one. IOSS covers imports: it applies to consignments "in consignments of an intrinsic value not exceeding EUR 150" (Art. 369l, verbatim). Above that, a full customs declaration.
• Engineering consequence: the VAT rate is a function of (product category, destination country, date). A fixed rate in configuration is correct exactly until the first cross-border sale. And rates change: store the applied rate on the order, do not recompute it from the current configuration when reprinting an invoice from two years ago.
• Price reductions: Directive (EU) 2019/2161 introduced Art. 6a into Directive 98/6/EC, verbatim: "Any announcement of a price reduction shall indicate the prior price applied by the trader", and "The prior price means the lowest price applied by the trader during a period of time not shorter than 30 days prior to the application of the price reduction." Translated into product terms: you need the 30-day price history as queryable data, not as an audit log buried somewhere. If your platform does not store it, you have to add it.
• Verify in §8 rates, thresholds and national transposition: this skill fixes the mechanics, not the rates.

3.7 Checkout: where the money is lost

• Guest by default. Forcing registration before payment is the most expensive self-inflicted friction in the funnel. Offer account creation after confirmation, with the password as the only extra field.
• Fewer fields and fewer steps, with inline validation and messages that say how to fix things. Browser autofill working (correct autocomplete on every field) is worth more than any redesign.
• Total cost visible early. Shipping charges that show up in the last step are the abandonment cause that appears in every study; it is also what Art. 8(3) of Directive 2011/83/EU requires (indicating delivery restrictions and accepted means of payment at the latest at the beginning of the ordering process).
• Confirmation button with an obligation to pay. Art. 8(2), verbatim: "the button or similar function shall be labelled in an easily legible manner only with the words 'order with obligation to pay' or a corresponding unambiguous formulation", and if it is not complied with, "the consumer shall not be bound by the contract or order". A button saying "Continue" in the final step is not a copywriting detail: it can invalidate the contract.
• No pre-selected extras. Art. 22, verbatim: if the trader infers consent "by using default options which the consumer is required to reject", the consumer is entitled to a refund of that amount. Insurance, premium shipping and donations ticked by default are illegal, not aggressive.
• Performance: the product page and the checkout are the two paths where performance turns into money — but how it is measured and which threshold is required is set by web-performance-standards. Here only the priority: if you have to choose where to spend the performance budget, spend it there, not on the home page.
• Figures you must NOT cite (§4 of intellectual hygiene, and see §8):
  • "Every 100 ms of latency costs 1% in sales". It comes from a blog post by Greg Linden (2006) and from a later slide of his about an internal Amazon experiment that was never published: there is no experimental design, no sample size, no definition of "sales". It has been repeated ever since by circular citation, with the figure applied to revenue bases that differ by four orders of magnitude. It is folklore, not evidence. Measure your funnel.
  • "70% of carts are abandoned". Baymard publishes 70.22% as the arithmetic mean of 50 third-party studies (2006-2025), with individual values between ~55% and ~84%, from different vendors and with no common definition of "abandoned cart". The methodology is published and is honest about what it claims to be: an average of averages. Using it as a target for your store is a category error.
  • "The industry average conversion rate is X%": it depends on the product type, the order value, the traffic channel and whether you count sessions or users. Without those four variables the figure means nothing. Compare yourself with yourself.

3.8 Promotions, abuse and bots

Coupons are the most profitable business vulnerability there is, because it requires exploiting nothing: it is enough for the rules to compose in a way nobody modelled.

Defences, all server-side:

• Non-stackable by default. Stacking is an exception enabled per rule, with a defined and deterministic application order (is the percentage applied before or after the fixed amount? The answer changes the result).
• Hard cap per order: absolute maximum discount and maximum percentage, applied after combining everything. It is the net that catches what the logic did not foresee.
• A discount can never make an amount negative — not the line, not the shipping, not the total. Also check the case of a partial return of an order with a coupon: how much of a distributed discount is refunded is a decision, not an obvious calculation.
• Usage limits per coupon and per customer, applied with the same atomic discipline as stock (§3.4): a counter read and then incremented is bypassed with concurrent requests.
• Unguessable codes for personal coupons; sequential codes or ones based on the campaign name are enumerated in minutes.
• A record of every discount application with its rule and its amount, so you can later explain what happened and what it cost.

Bots and resale (scalping): in limited launches the attacker breaks nothing — they use your store faster than a person. Defensive stance:

• Reservation on add-to-cart is the hoarder's ammunition. If you reserve, use a short expiry and a limit per identity.
• A limit per identity unit (account, payment method, shipping address), knowing that each one can be multiplied and that a per-IP limit annoys legitimate users behind NAT.
• A waiting queue for launches: it turns a race into an order, and protects capacity along the way.
• Behavioural detection, not user-agent based: time to cart, absence of prior browsing, retry patterns. Feed telemetry, do not block blindly.
• Honest metric: the false-positive rate. An anti-bot that blocks real customers costs more than the resale it prevents.

Card-not-present fraud: screening, risk scoring and liability shift belong to fintech-payments-standards. What this skill contributes: commerce signals are the model's best inputs (mismatch between billing and shipping, an order far above the average value, a just-created account, urgency for express shipping, high-resale items). Export them to the fraud engine instead of reimplementing it.

3.9 Catalogue SEO and the URL migration

URL migration is the most common way to destroy an online business, and it is entirely avoidable. In a replatform:

1. Export the full inventory of live URLs BEFORE touching anything: a crawl of the current site
   • sitemap.xml + server logs from the last few months + pages with inbound links or organic traffic. The logs are the source nobody looks at and the one containing the URLs that still get visits.
2. A 1:1 map from source to destination, hand-reviewed for the highest-traffic ones. A redirect to the home page is not a redirect: it is a loss.
3. 301 (permanent), not 302, and no chains: source → final destination, in one hop.
4. Automated post-deploy verification: walk the whole map and check status code and destination. It is a test, and it runs in CI.
5. Parameters migrate too: filters, pagination and campaign identifiers.
6. Keep the redirects forever. Removing them "because nobody uses them any more" is doing the migration again a year later.

The rest of the catalogue criteria:

• Explicit canonical on every product page, pointing at the reference URL. The same product reachable from several categories is a duplicate if you do not declare it.
• Facets: noindex by default. Every filter combination is a URL; N filters produce combinatorial growth and a crawl trap that eats crawl budget and produces near-identical content. Specific cases with demonstrated search demand are opened to indexing.
• Out-of-stock or discontinued product: the worst option is 404. Keep the page with a clear status and alternatives, or redirect to the successor product or its category. Deleting accumulates errors and throws away the ranking you earned.
• Structured data schema.org/Product with offer, price, currency and availability, in JSON-LD. They must match what the user sees: marking a price different from the real one is grounds for a penalty, not an optimisation. Verify the search engine's current requirements in §8: they change and give no notice.
• Pagination and infinite scroll: if the listing is infinite, guarantee an equivalent crawlable path exists. Content that only appears after interaction does not exist for a crawler.

3.10 Accessibility and consumer obligations

E-commerce is a service expressly covered by Directive (EU) 2019/882 (European Accessibility Act): Art. 2(2)(f) lists "e-commerce services" among the services provided to consumers after 28 June 2025, and Art. 31(2) sets that application date. Two verified nuances that avoid false statements in either direction:

• Microenterprise exemption (Art. 4(5), verbatim): "Microenterprises providing services shall be exempt from complying with the accessibility requirements referred to in paragraph 3 […]". Microenterprise is defined in Art. 3(23): fewer than 10 persons and an annual turnover or balance sheet total not exceeding EUR 2 million. The exemption covers services, not products.
• Transitional regime (Art. 32): Member States provide for a period until 28 June 2030 during which services may continue to be provided using products lawfully used before; and service contracts agreed before 28-6-2025 may continue unaltered until they expire, for a maximum of five years.

The technical conformance criterion — WCAG, EN 301 549, auditing, tooling — belongs to accessibility-standards. What this skill contributes: it is mandatory and it affects the checkout, which is exactly where it is usually worst (error messages not announced, focus lost after validation, reservation timers with no warning, variant selectors unreachable by keyboard).

Other consumer obligations that constrain the design (Directive 2011/83/EU, verbatim in §3.7): a 14-day right of withdrawal in distance contracts (Art. 9(1)), with its exhaustive exceptions in Art. 16 — customised goods, sealed goods opened for hygiene reasons, perishable goods, digital content already performed with express consent. And Regulation (EU) 2023/988 (GPSR), applicable since 13 December 2024, which imposes product information and traceability obligations on online sellers and marketplaces. The concrete implementation and the transpositions are verified in §8; here only their existence and their effect on the data model: you need manufacturer and EU responsible person data as product attributes, not as loose text in the description.

3.11 Analytics, consent and personal data

• The funnel is measured on the server. Client events are systematically incomplete because of blockers, consent refusal and network failures — and the bias is not random, so rates computed only from client data are skewed in a way you cannot correct. Server events (order created, payment confirmed, shipment) are complete by construction.
• No consent, no non-essential analytics. The correct design is: the store works fully without consent, and analytics is additive. If your funnel breaks when the user says no, the problem is architectural. The legal basis, consent design and retention belong to privacy-engineering-standards.
• Minimise what you keep from the order. Shipping address and contact details are necessary; reconstructing an indefinite behavioural profile is not. And beware: mandatory accounting and tax retention sits badly with the right to erasure — that collision is resolved by separating the mandatory transactional data from the behavioural data, and it is documented.
• The recommender and dynamic pricing are automated decisions with impact: run them past ai-governance-standards before personalising prices, which is where the real regulatory and reputational risk lives.

4. Quality and testing

• Concurrency test on stock: N simultaneous purchases of the last unit ⇒ one sale and N−1 rejections. In real parallel, against the real database. It is the test that defines whether the system is correct.
• Concurrency test on a single-use coupon: same pattern.
• Promotion composition test: a combination of rules that tries to push the total below zero or above the cap; it must fail in a controlled way.
• Price tampering test: a request with an amount altered from the client ⇒ rejection.
• Tax matrix test (category × country × date), with at least one rate-change case and one old-invoice reprint case.
• Redirect map test after every deploy touching URLs: every source returns 301 to the expected destination, in one hop.
• Structured data test against the search engine's validator and against the real rendered price.
• Automated accessibility test on the product page and checkout as a gate, with a manual audit of the checkout — the automated one does not see what breaks a checkout (delegated to accessibility-standards).
• Load test of the full purchase flow before each campaign, not of the catalogue alone.
• CI gates, increasing cost: linters and types → unit tests for price, tax and discount → concurrency tests for stock and coupon → redirect map validation → automated accessibility → performance budget (web-performance-standards) → integration with the PSP sandbox.

5. Stack security

• Every amount and every rule is validated on the server. Price, discount, shipping, tax, quantity. No exception.
• Object-level authorisation on every customer resource: order, invoice, address, return. GET /orders/{id} without an ownership check exposes complete purchase histories, and it is the most repeated finding in stores.
• Frontend supply chain: every third-party script on the payment page is a card skimming risk (and a PCI DSS requirement, see fintech-payments-standards §3.2). Inventory, CSP and integrity control; marketing does not add pixels to the checkout without review.
• Extension ecosystem: on self-hosted platforms, the third-party plugin is the dominant vector. Policy: minimum number, known origin, kept updated, and none abandoned. Treat them as dependencies with SCA (appsec-standards).
• Enumeration: non-sequential order identifiers; rate limiting on search, login, password recovery and coupon validation.
• Account takeover: order history, addresses and the stored payment method are the loot. MFA available, an email alert on address or password change, and reauthentication before sensitive operations.
• Returns and refunds as a business control: who can issue one, up to what amount and with what second signature. Internal fraud lives here.
• Card data: never in your system. Delegated and non-negotiable (fintech-payments-standards §3.1).

6. Performance and operability

• What is cacheable: catalogue, product page, listings and static assets, yes — under the rules of caching-cdn-standards. Cart, personalised price, exact availability and any session page, no. Caching a personalised response at the edge is a data leak, not an optimisation.
• Published availability versus exact stock: the product page may serve a cached value at coarse granularity ("in stock" / "few left"), and the truth is checked at reservation time. Trying to serve the exact real-time number from the catalogue is what takes the database down in a campaign.
• Store SLIs: conversion rate per funnel step, checkout error rate, latency of shipping and tax calculation (external dependencies), shipping-provider failure rate, age of the oldest unprocessed order, oversell rate.
• Campaign peaks: the pattern is catalogue × 20, checkout × 5, and everything concentrated in minutes. Preparation: load test with the real profile, an activatable waiting queue, rate limits agreed with the PSP and the carrier, a degradation plan (disable recommendations and personalisation before payment), and a deployment freeze during the window.
• External dependencies with a timeout and a fallback: if real-time shipping calculation does not respond, serve a fallback rate; do not block the checkout waiting for a third party.
• Asynchronous work: emails, marketplace feeds, ERP synchronisation and search indexing go into a queue, never in the purchase request.
• An order is never lost because of a failure after payment. Persisting it is the operation that cannot fail; everything else is retriable.

7. Sustainability and prohibitions

• Cadence: platform and extension patches within their support window (see lifecycle dates in §2.1 and verify them in §8); an annual review of the extension catalogue to remove what is unused; a review of the redirect map on every URL structure change.
• Planned exit: before marrying a platform, check how catalogue, customers, orders and payment tokens are exported. A store with no exit route is a hostage.
• ADR for: platform choice, monolith/composable architecture, stock reservation policy, promotion stacking policy, and URL strategy.

Prohibitions:

• ❌ FORBIDDEN: the read-check-subtract pattern on stock, balance or coupon counter. The condition goes inside the atomic write.
• ❌ FORBIDDEN: trusting any amount, quantity, discount or tax sent by the client.
• ❌ FORBIDDEN: touching the PAN. See fintech-payments-standards §3.1.
• ❌ FORBIDDEN: replatforming without a verified redirect map, and forbidden to redirect everything to the home page.
• ❌ FORBIDDEN: deleting the URL of a discontinued product leaving a 404.
• ❌ FORBIDDEN: exposing indexable facets without control: it is a crawl trap.
• ❌ FORBIDDEN: an order confirmation button that does not express the obligation to pay, and forbidden pre-selected extras (Art. 8(2) and Art. 22 of Directive 2011/83/EU).
• ❌ FORBIDDEN: announcing a price reduction without the lowest prior price of the previous 30 days.
• ❌ FORBIDDEN: caching at the edge any response that depends on the session.
• ❌ FORBIDDEN: forcing registration in order to buy without a written business justification.
• ❌ FORBIDDEN: adding third-party scripts to the payment page without review — it is a PCI DSS requirement, not a preference.
• ❌ FORBIDDEN: justifying a decision with "100 ms costs 1%" or "70% abandon the cart" without measuring your own funnel (§3.7).
• ❌ FORBIDDEN: letting the funnel stop being measured when the user refuses consent: that means you depend on the client for data that should have been server-side.
• ❌ FORBIDDEN: installing an abandoned extension on a self-hosted platform.

8. Mandatory web verification

Check before fixing anything:

1. Platform prices and fees: each vendor's official page, with the date. Those in §2.1 are from shopify.com/pricing in EUR (the page itself is dated 2026-08-04) and vary by country and currency. Declared gaps: commercetools and VTEX publish no figures — their pages point to sales; any number you find on a blog is an unverified leak.
2. Licences: the LICENSE/LICENSE.md file raw from the repository, never the GitHub label nor an article. Verified that way: Magento OSL-3.0, PrestaShop OSL-3.0 + AFL-3.0 for modules, Saleor BSD-3-Clause, Medusa MIT, WooCommerce GPL-3.0-or-later. Check it again: this catalogue has already disproved sixteen licence assumptions.
3. Adobe Commerce / Magento lifecycle: Adobe's released versions page (last verified update: 2026-06-02). End-of-support dates move.
4. EU VAT: the Art. 59c threshold (€10,000), the IOSS limit (€150), rates by country and category and the status of the ViDA package — which modifies the regime and whose timetable is not asserted here. Primary source: EUR-Lex and the Commission's taxation portal.
5. Consumer rights: Directive 2011/83/EU (Arts. 8, 9, 16, 22), Directive (EU) 2019/2161 (Art. 6a of Directive 98/6/EC) and their national transposition, which is what applies to you.
6. Accessibility: Directive (EU) 2019/882 (Arts. 2, 3(23), 4(5), 31, 32) and the national transposing law, plus the harmonised standard in force. In Spain the reference is Ley 11/2023 — verify it, this skill has not checked it raw (declared gap).
7. GPSR: Regulation (EU) 2023/988, applicable since 2024-12-13, and its application guidance.
8. Structured data: the search engine's current requirements for product listings (mandatory properties, price and availability policies). They change without notice and a listing that complied yesterday may not today.
9. Industry figures: distrust by default. Before citing an abandonment, conversion or latency-impact rate, demand a published methodology. The two most repeated ones are dismantled in §3.7: the 100 ms one has no primary source (a 2006 blog post and slide about an unpublished internal experiment) and the 70% one is an average of 50 vendor studies with a range of ~55% to ~84% and no common definition.
10. PCI DSS applied to the payment page (requirements 6.4.3 and 11.6.1, SAQ A eligibility): verify it in fintech-payments-standards §8, which is where that check lives.

If the web contradicts this document, the web wins — flag the discrepancy.