What's new – Shop

Icon-only buttons in the customer storefront are now read out by name (#3693)

Affected were 22 buttons that show nothing but an icon and that a screen reader therefore announced as "button" and nothing else: the grid and list toggles and the pager of the product list, the pagers of the blog and of the brand page, the quantity steppers in the cart and when creating a subscription, clearing the search on the search page, in the app store and in the language picker, closing the language picker and the image gallery, the arrows of the scrolling card row, the add button of the cross-sell suggestions, the star rating, and the high-contrast toggle of the shop's own accessibility toolbar. All of them now carry a spoken name in German and English. Nothing changes visually.

Icon-only buttons in the storefront page builder are now read out by name (#3694)

Affected were 33 buttons that show nothing but an icon and that a screen reader therefore announced as "button" and nothing else: the switches of the block editors for accordion, button, category grid, gallery, hero banner, logo strip, product slider, testimonials and video, the section settings switches for FAQ, testimonials, full width and page status as well as the display switches of the page editor, the drag handle of the section list, the switches, the add and the remove actions of the header and footer editors and of the section settings, and in the template store the carousel, the thumbnail picker and the close buttons of both preview windows. All of them now carry a spoken name in German and English - the very caption that already stood beside them. Nothing changes visually.

Returns, credit notes and the template store show their text

In 14 places the screen carried not the label but the internal name the interface looks it up by. In the returns drawer that affected the condition selector, the "restock items" checkbox, the refund method selector and the return reason "damaged in shipping"; in the credit note drawer the invoice reference and the change date; in a product's pricing section the hint under the cost price. In the template store the whole install dialog - title, question, note and the button shown while installing - plus the "Active" and "Installed" badges and the rating share on the template card carried the same defect. The install dialog was the quietest case of all: the source carries an English fallback next to every call, and it never rendered. All 14 places are now written down in German and English.

A coupon code entered in the cart now actually lowers the total (#3427)

Entering a coupon

A new address in the customer account can be saved again (#3421)

The new-shipping-address

Cancelled orders now release their stock again

A product's stock is reserved as soon

Checkout now completes orders successfully (#3424)

The regular checkout (non-marketplace purchases) sent an incomplete data package when placing an order - among other things the cart reference and billing address were missing, and the country field carried the wrong name. Any one of these gaps on its own caused the order to be rejected before it could even be checked. The checkout now sends the data package complete and in the expected format.

Create gift card: the maximum amount is now checked, and the dialog closes with Escape

The admin gift-card creation form used to check only that the amount was at least 1.00 EUR - an amount above 1,000.00 EUR was only rejected by the server, shown as a generic error. The form now flags an amount that is too high right at the amount field. The dialog also now closes with the Escape key and is correctly announced as a dialog to screen readers.

Discounts are now calculated correctly when multiple promotions apply

Combined promotions could sum the shipping discount beyond the actual shipping cost and accidentally subtract an item discount twice from the grand total. Both are fixed - the displayed grand total is now correct in every case.

Error messages in the withdrawal form and checkout are now translated

When submitting the

Failed webhook deliveries are now retried reliably (#3400)

When a webhook delivery to your receiving address failed, a retry used to be scheduled (after 30s, 5min, 50min) - but only for as long as the server process kept running without interruption. A restart or deployment inside that window lost the scheduled retry, and the delivery stayed on "retrying" forever, never actually retried. A recurring background run now regularly checks for due retries and delivers them automatically, independent of restarts. The manual per-delivery retry button in the delivery log remains available as before.

Order and customer lists now show a fault message on a load error (#3406)

If loading the order or customer list failed (for example a server error), the same empty table used to appear as for a genuinely empty list - an outage was not visually distinguishable from "no records". Both lists now show a visible notice that loading failed.

Orders paid entirely by gift card can now be refunded (#3349)

When a gift card covered

Per-customer coupon limits now work at checkout for signed-in customers (#3397)

The per-customer usage check referenced a column that never existed on the order table - checking such a coupon for a signed-in customer failed with an error every time, regardless of the order's status. On top of that, cancelled orders and orders with a failed payment were wrongly counted as usage. Both are fixed: the check now reads the codes actually applied to the order, and cancelled or payment-failed orders no longer count.

Plan product limit is now enforced

Once the number of products included in a plan is reached, creating another product is now rejected with a clear error message instead of allowing unlimited products.

Product dimensions reject negative values right in the form (#3415)

Width, height and

Product list now shows a fault message on a load error (#3406)

Like the order and customer lists before it, a failed product list request used to render the same empty table used for genuinely zero products. The list now shows a visible notice that loading failed.

Product prices are now split into gross/net correctly (#3350)

Creating, editing, or bulk

Shipping cost at checkout now matches the cart's real weight

For weight-tiered

Subscription billing dates now follow the calendar month/year instead of a fixed day count (#3373)

Monthly and yearly subscriptions used to advance by a flat 30 or 365 days each cycle. That made the billing date drift away from the originally chosen calendar day with every renewal, and yearly subscriptions lost a day in every leap year. The next billing date is now set to the same calendar day in the following month/year (or, when that day does not exist in a shorter month, to that month's last day).

Translation changes for categories and tags are no longer lost (#3363)

If you changed a translation field in the category or tag dialog and the dialog quietly reloaded the same data in the background shortly after, it silently discarded your unsaved change and showed the old value again. The dialog now keeps an unsaved change through such a background reload; only a deliberate language switch reloads the form.

A "once per customer" discount code can no longer be redeemed twice (#3297)

If the same customer redeemed a discount code limited to one use per customer twice at the same time (for example by double-clicking), the discount used to be granted both times even though the limit only allowed one use. Redemption now checks the allowance in a single, guarded step: once it is used up, the second attempt is rejected.

A discounted bundle's price and the tax it shows agree again

When a bundle is priced through a percentage discount, its gross and net price used to be rounded independently of each other. In roughly one out of four combinations of price, tax rate and discount the two values ended up a cent apart, so the tax derived from them no longer matched the tax rate of the items in the bundle. The net price is now calculated from the discounted gross price and the items' tax rate; if a bundle mixes items with different tax rates, each rate is calculated separately. The gross price on display is unchanged - it was never affected.

A newly created shop can add products right away

Creating the very first product used to stop with an error. The cause was in the setup: a freshly created shop started without a tax class and without a language, and a product needs both - the tax class for the product itself, the language for its title and description. Every new shop now brings both along from the start: the standard tax class at 19 percent and German as the default language. Existing shops missing either one are topped up automatically on the next start; anyone who has already created their own tax classes or languages keeps them unchanged - the entry is only added where there was nothing at all.

A refund now pays back gift cards that were used (#3349)

When an order was paid

Variant prices are now checked against the tax rate

Creating or editing a product variant used to store the gross and net price independently of each other - a pair like €100.00 gross / €84.00 net could be saved even though no tax rate produces that combination at 19% tax. That led to an incorrect tax breakdown in the cart and on the order. Variant management (single edit, bulk edit, variant generation) now rejects a price pair that doesn't match the product's configured tax rate, and names the expected net amount in the error message. A rounding difference of up to 1 cent is still allowed.

Old account erasures are now finished off automatically (#2480)

Before the erasure feature from #2436 was introduced, deleting an account still left seven leftover fields on the customer record, four related tables with personal data, and the IP address, browser identifier and search parameters in the audit trail - among other things, the search key derived from the e-mail address survived, so the person stayed findable by their own address. An automatic background run now brings those already-erased accounts to the same state as a present-day erasure: leftover fields are cleared, the related tables are emptied, and the personal trace is stripped from the audit trail. There is nothing for you to do - the run recognises affected accounts by the fingerprint of the old erasure and leaves newly created or already fully erased accounts untouched. Orders and the audit trail itself stay traceable, just as with a present-day erasure.

Order edits and stock bookings are now atomic (#3275)

If the totals recalculation that follows adding, changing or removing an order line item failed, the line item change stuck anyway - the order then showed a grand total that no longer matched its own line items. During checkout and on cancellation, stock for several articles was booked one at a time: if the booking for one article failed, the earlier articles stayed deducted (or restored) regardless - a stock count that no longer matched the order, with nothing surfacing the mismatch. And saving several changes at once could hand back a half-applied batch: if the third of four changes failed, the first two were already saved although the message reported a failure. All three now run inside a single transaction each, a batch of edits included: if any step fails, the order is left completely unchanged and no entry is written to the edit history either.

The last unit in stock can no longer be sold twice (#3297)

If two customers checked out the last available unit of a product at the same time, both orders could be paid and completed even though only one unit was in stock - checkout deducted stock without a lock. Checkout now deducts stock in a single, guarded step: if stock has run out, the second order is rejected with an error before payment is initiated.

Toggling a shipping template's active status no longer deletes its shipping zones (#2757)

Switching a shipping template active/inactive in the shipping overview used to remove all of its zones and rates and reset the template's default flag and processing times - visible only the next time the template was opened. The cause was that every partial edit was internally treated as a complete replacement. The switch now changes only the active status; zones, rates, the default flag and processing times stay untouched.

Theme editor, CMS editor, tags and marketplace categories are now usable on a phone (#1405)

On a 390-pixel-wide screen, the theme and CMS editors left their fixed side panel (up to 380 pixels) standing, leaving almost no room for the preview; the tags and marketplace categories overviews either squeezed their columns to unreadable widths or pushed the whole page sideways. Below 640 pixels both side panels now live in a slide-out panel, and both tables scroll horizontally in their own box - the page itself stays put. Customize theme,

Digital downloads are now checked before they are stored

A download file for a digital

The media library now checks uploaded files by their content (#3119)

Until now the browser's type declaration alone decided whether a file was accepted - the content itself was never read. Every upload is now identified by its actual bytes, and a file whose content disagrees with the declaration is refused before it reaches storage. The media library also no longer accepts SVG files: an SVG is a document that can carry executable code, and your media library images are served publicly. SVG files already stored are from now on delivered as a download instead of as a page, so they can no longer execute anything. Please use JPEG, PNG, WebP, AVIF or GIF for product images.

Orders and returns in the customer account report a failure instead of showing an empty list (#3006)

When the shop answered the order or return list in a shape the customer account could not read, the page said "no results" or "no returns" - so a customer with a full order history was told they had never ordered, and had no reason to report anything. The account overview, the "Orders" tab, the returns page and the order picker in the return form were all affected. All four now show an unreadable answer as a visible error. An account that genuinely has no orders or no returns still says exactly that. There is nothing for you to configure.

The product page's review tab stays up instead of going blank (#3003)

When the shop answered the list of approved reviews in a shape the storefront could not read, the entire review area collapsed - the average rating, the distribution, the form for writing a review and the reviews themselves disappeared together, with no notice. The storefront now reads the list in the shape the shop actually sends, and shows an unreadable answer as a visible error instead of claiming "no reviews". A product that genuinely has no reviews still says exactly that. There is nothing for you to configure.

A newly created shop brings its own currency (#2950)

A freshly created workspace carried no currency at all. The cart needs one in order to exist, so it answered with an error as soon as a visitor tried to put the first article in - however many sellable articles the shop held. Newly created workspaces now receive the euro as their default currency, and existing ones have it added where they carry no currency at all. Anyone already maintaining their own currencies keeps them unchanged - nothing is overwritten and nothing is added. Further currencies are created in the settings as before.

Prices, ratings and related articles are back in the shop (#2967, #2968, #2969)

The product page, the product tiles, the cross-sell strip of the cart and the wishlist showed "NaN €" instead of a price. The cause was the shape in which the storefront received the price; it now always arrives as an amount. In the same pass three pieces of information reach the storefront that were never delivered before: the struck-through reference price with its discount share, the star rating with the number of published reviews, and the category assignment that feeds the "Related products" section. All three displays existed in the shop but could never appear. You do not have to configure anything for this.

Product tiles always show an amount (#2952)

Product tiles could show "NaN €" instead of a price. The cause of that was already fixed (#2967) - what is new is that the tile now guards the price itself against every shape it can arrive in, and stays exact to the cent while doing so: an article at 49.90 € reads "49,90 €" on the tile, not "0,49 €" and not "4.990,00 €". The same applies to the struck-through reference price and the discount share calculated from it, which used to disappear entirely in those cases. You do not have to configure anything for this.

The customer account shows orders again

"My account", the order list and the order detail page of your storefront showed "Something went wrong" instead of the orders as soon as a signed-in customer had even a single order. Every customer with an order history was affected; only a freshly created account without any order saw a working page, which is why the failure never showed up on test accounts. The cause was a drift between what the order endpoint delivers and what the storefront reads from it. The three pages show position counts, amounts and positions again, and the "Returns" page - which reads the same data and failed the same way - walks through the selection of the items to send back once more. Two things are better than before: the order detail page now names the payment and shipping method instead of leaving the panel blank, and the customer's view of an order no longer hands out internal details that only concern your team - internal comments, tags and promotion codes now stay on the admin side.

The status route stays for repayments settled outside the system - and is labelled as such

Payment methods with no payment service provider attached (invoice, prepayment, SEPA direct debit) carry no reference a refund could be issued against. When you have repaid such a case outside the system, you still book it through the status list. What is new is that this list asks first and names the action for what it is: "Set to 'Refunded' - bookkeeping only, no money moves". Until now that change went through on a single click, with no prompt and no indication that no money was involved.

API documentation: the "Sandbox" tab no longer fakes a request (#1663)

The tab used to show a made-up sample response and report "request sent successfully" - even though no connection was ever made, no matter what address was entered. It now links directly to the real, code-generated interactive reference (/api/docs) instead, which sends actual requests with your own credentials. The base URL shown now reflects your real API address instead of a fixed example, and the rate-limit table on the "Auth" tab lists the values actually enforced (100/600/60 requests per minute depending on the surface) instead of invented pricing tiers.

GDPR erasure now covers wishlists and reviews too, marketplace erasure names what stays

An erasure under Article 17 GDPR used to skip two record classes: the person's wishlists remained untouched, and their product reviews still carried their name and customer reference. An erasure now removes the wishlists entirely and, for reviews, replaces only the author information - the rating and text stay visible to other shoppers, the same as an anonymously submitted review. The erasure receipt now reports both counts. Erasure in the marketplace customer account used to answer with a bare success flag; it now names the retained orders with their legal basis and retention period, matching what the shop customer account already does. The billing address inside a retained order itself is unchanged by this erasure - it stays part of the commercial document.

Order list: switching pages now actually shows different orders (#1662)

Paging to page 2 (or any later page) used to show the same first page again - the admin queried the interface with limit/offset, but the interface expects page/pageSize and silently dropped the unknown fields with no error. Paging now genuinely works. Two other limitations measured in the same pass are unchanged and were already documented on this help page: search still only matches order numbers (not customer name or email), and "Refund" still does not trigger an actual repayment with the payment provider.

Reviews and recommendations show the product name again (#1993)

The review list

The "Google Reviews" App Store listing now describes only real features

The listing used to advertise a "configurable sync interval" (hourly or daily), an "automatic import" of Google reviews, and a "social proof widget for the storefront" - none of which exist: there is no schedule, no interval setting, and no review widget in the shop. Since #1813's fix, clicking "Sync" already answers honestly with "not available" instead of inventing reviews. The description, short text and highlights now name only what the app actually does: view a review list, filter it by minimum star rating, and delete individual entries. No action is needed on your part.

Dropdowns across the shop and the storefront are now read out by name (#2859)

Affected were the product list, reviews and Google reviews, blog and content pages, menus, promotion combination settings, the app area, the rule builder with its field, operator and value, and the bounce overview. In the storefront the sort order on the brand page and in the product list, plus the return reason, are included. Anyone using them with a screen reader heard nothing but "combo box" there - with no hint of what was being selected. All of them now carry a spoken name in German and English, and in all 44 storefront languages. Nothing changes visually. Products · Promotions ·

Your shop pages now stay in one language throughout, even with simultaneous visitors

When a German-speaking and an English-speaking visitor opened your shop at the same moment, one of the two pages could be delivered in mixed languages. Header and footer were right, but the blocks in between were not: a German visitor might see "Your email address" and "Subscribe" in the newsletter block while the rest of the page was German. The fault depended purely on the chance of simultaneity - the same page was fine again seconds later, which made it hard to pin down, and it happened more often the more visitors were browsing your shop at once. The cause was that all pages being delivered at the same time shared a single language setting: the most recent request overwrote the language of every page still being built. Each page now carries its own language, for all of its blocks, and what other visitors do at the same time no longer affects it. Affected were all sections of a page as well as the entries in the page head; header and footer were already correct. Nothing changes about your own texts and settings.

Nine templates promised something no shop had agreed to

As shipped, their announcement bar above the header carried promises such as "Free shipping on orders over €50!", "Free returns on all orders!" or "Spring Sale - 20% off all seeds!". Those bars have been removed with nothing put in their place. If you want to show an announcement, enter it in the editor in your own words.

Product pages stay reachable even when something is missing in the workspace

In an incompletely set up workspace, a product page in the shop could answer with a server error although only an extra was missing - images, variants, translations, brand, keywords or the frequently asked questions. The shop had planned for that case but never recognised it: the check looked at the wording of the error message, and the database layer does not put that wording there at all. The case is now recognised by the database error code. The product page still appears, the missing extra simply stays empty, and the failure is recorded as an open incident for operations so that somebody fixes it instead of overlooking it. Every other database error still leads to a clear error message: a real failure is not quietly turned into an empty list.

Templates that are already active are carried along

Shops that activated a template before this change carry the English copy in their stored page data. It is cleaned up automatically at the next service start, with nothing for you to do. Your own text set in the editor is left untouched - only the part taken over from the template is cleaned up.

The cart accepts articles again, and the currency switch tells the truth (#2814)

Putting an article into the cart failed - the shop answered with a server error instead of creating the line. The same path was affected when raising a quantity and when checking a filled cart before checkout, so the purchase path ended before the checkout. The cause was a query that read two product fields the database never had. It now reads the ones that exist: whether an article may be sold is still decided by its active switch, and the line label comes from the maintained product name of the respective language. A deactivated article is still refused. On top of that, switching the cart currency kept reporting the old currency although the new one had already been stored; display and stored state now agree.

The cart now stays visible on a phone in shops without a template

In shops where no template has been activated yet - the shipping state of a freshly created shop - the header icon row pushed the page past the right edge at 390 px. Measured with a 47-character shop name the page was 825 px wide and the cart button started at 721 px, so anyone shopping on a phone found it only after scrolling sideways. The icon row now stays fully visible, the shop name gives way and is shortened where needed, and the wishlist moves into the menu at phone width, where it already had an entry. Cart, search and language stay in the header. Nothing changes from 768 px upwards.

The Google Shopping product feed can be fetched again (#2841)

Generating the feed, downloading it and the public feed address that Google Merchant Center fetches all ended in a server error instead of the feed - in every workspace, which left the feed permanently empty for Google. The cause was a query reading an article's readable link segment from a field the database never had. It now reads it from the same maintained translation row it already took the name and the description from, in the language configured on the feed. An article without a maintained translation falls back to its identifier, so its link stays valid instead of being empty.

The newsletter block in the footer now speaks the language of the shop

In shops with an active template, four texts in the footer were fixed to English: the heading of the newsletter block, the line below it, the hint inside the input field and the button. They stayed English even after the visitor picked another language in the header, because they never passed through the translation at all. All four now come from the translation and change with the language; they are filled in for all 44 shop languages. As the footer sits on every shop page but the home page, this affected nearly the whole shop. The wording shifts slightly: "Newsletter" is replaced by the heading the shop already uses for its newsletter elsewhere.

The section preview now follows your language, not that of your last shop visitor

In the template editor, a section's sample texts did not appear in the language of your admin, but in the language your shop had last served a page in. As long as nobody was browsing the shop, a German-language account saw German and everything looked right. But once an English-speaking visitor had opened a page, your preview went back to showing "Your email address" and "Subscribe" instead of "Ihre E-Mail-Adresse" and "Abonnieren" - without you changing anything, and with no visible cause. Affected were the placeholder texts of the newsletter block and the product count on category lists and category tiles ("12 products" instead of "12 Produkte"). The preview now answers every request on its own: it takes the language you set for your admin, and what happens in your shop at the same time no longer affects it. Your own texts are untouched by this - only the sample texts a section brings along while you have not entered your own are translated.

The shipped page templates no longer force a language

All 31 templates in the template store wrote their visible copy into the shop in English the moment a template was activated - headings such as "Trending Now", "Our Story" or "You May Also Like", plus subheadings and button labels, 332 places in total. Because that copy sat in the layout as a value of its own, it beat the translated default of the sections, and a German-language shop stayed English even after switching languages. That copy has now been removed from the shipment: the sections show the translated default until you enter your own text in the editor. What makes a template a template is unchanged - the order and choice of sections, column counts, heights, image placement, colors and fonts. The same applies to the 27 default values of the section templates in the page editor: text fields now start empty instead of with an English suggestion.

The shop header now fits a phone, and the cart has a name again

On screens 390px wide, shops with an active template had two rows reaching past the right edge, which let the page be scrolled sideways: the icon bar in the header and the newsletter row in the footer. The icon bar now stays fully visible while the shop name gives way, and the wishlist icon moves into the menu on phone widths, where it already had an entry; the newsletter field may shrink and takes the full width on narrow screens. On top of that, all six header icons - search, wishlist, account, cart, language and menu - now carry a spoken name, so a screen reader can find and operate them.

The template previews now speak your language, and promise nothing

In the template store, the live preview of every template carried an announcement bar reading "Free shipping on orders over $50". No operator ever made that shipping promise, and it named a foreign currency; the bar has been removed outright. So have the four invented tile labels "Free Shipping", "Secure", "24/7 Support" and "Returns" shown for an icon row without texts of its own - empty placeholders now stand there until you enter your own points. Everything else in the preview - header, menu entries, "Add to cart", "Shop now", "Subscribe", footer and copyright line - now appears in the language of your admin instead of fixed English, and the copyright line names the current year instead of 2024. In the section preview of the template editor, the newsletter block showed a fixed "Your email address" and "Subscribe" even in a German-language account; both now follow your language setting. The note below the field read "We respect your privacy. Unsubscribe at any time." - a statement about how customer data is handled that nobody asked you about. It has been cut back to the factual half: "You can unsubscribe at any time." The same blocks are also delivered in the shop itself, where category lists and category tiles used to count "12 products" instead of "12 Produkte".

The template sections now speak the visitor's language

Twelve sections of the page editor - hero, announcement bar, call to action, newsletter, featured products, product grid, product carousel, collections, categories, image with text, testimonials and gallery - showed their default copy in fixed English whenever no heading of your own was set in the editor. A German-language shop therefore greeted its visitors with "Welcome to Our Store", and the language switch in the header made no difference. That copy now goes through the translation layer and exists in German and English; the same applies to the spoken names of the carousel arrows and the dismiss cross, and to the product count under a category. Two of those defaults lost a statement no shop had ever made: the announcement bar promised "Free shipping on orders over $50!" out of the box and now names neither an amount nor a currency, and the image-with-text section claimed sustainable materials and ethical processes. Replaced as well are the three invented customer testimonials with star ratings that the testimonials section showed when no entries of your own existed: it now shows a placeholder that reads as one, and no rating. Anyone who entered their own copy in the editor keeps seeing it unchanged.

Your shop's homepage shows your own header and footer again - including the cart

The homepage (/) always displayed the platform's marketing bar, no matter whether you had activated a template or built your own homepage in the page editor. That bar carries no cart, so the path to purchase broke on the very first page; on top of that it showed the logo, navigation and advertising copy of SELLERLOGIC SCS instead of yours. The cause was a built-in sample page that the system mistook for a homepage maintained by you. From now on: if you have built a homepage in the page editor with sections and content blocks, exactly that page is shown - which did not work before either, because the sample page covered it. Otherwise the header and footer of your active template appear, and the cart is reachable from the homepage. Nothing needs to be changed on your side.

Your shop's buttons and input fields now follow your theme throughout

Until now the shop's controls took their look from a style sheet of the shop's own, separate from the building blocks the other surfaces are made of. At 99 call sites the building block had to be switched off and redrawn by hand - every one of them could drift away from your theme on its own without anyone noticing. Primary color, border color, corner radius, font weight, text transform and the focus ring now come from one shared value layer that your theme fills in at runtime: a primary button carries your color, a secondary one additionally carries your border color, and every input field in sign-in, account, checkout, newsletter and returns carries your border, your corner radius and your color when focused. If you have not set a value of your own, your design preset's value still applies. The only visible change is the height of the controls: they now follow one shared scale of 44 and 36 pixels instead of a height derived from their content.

"Cancel" in the order detail view now asks first - and names the order number

The button in the order header used to cancel the order on the first click. That is final: there is no way back out of the "cancelled" state, and the status change goes out as an order.cancelled event to the webhook addresses you configured and to marketing automation, so it can trigger a message to the customer. A prompt now appears before it fires, naming the order number and the receiving party; cancelling the prompt cancels nothing. The same applies to the second route into a cancellation, the status selector under "Manual status override" - only the "Cancelled" entry is diverted there, the other status changes run unprompted as before. In addition, the server now rejects a cancellation that arrives without a confirmation, even when it does not come from the interface.

Customers can now have their account erased themselves (#2436)

Until now your customers could request a data export from their account but could not request an erasure - exactly the half that Article 17 GDPR requires was missing. Under Account › Settings › My data both now sit side by side: download data export, and erase the account for good, the latter behind an explicit confirmation. The erasure reaches through: addresses, consent history, marketing confirmations, internal notes and attributes are removed, and the customer profile is irreversibly anonymized - including the search key derived from the e-mail address, so the customer can no longer be found by their own address either. Orders stay attributable and the audit trail stays traceable, but loses the erased person's IP address, browser identifier and search parameters. After the erasure your shop tells the customer explicitly what is retained and for how long: orders and invoices for ten years under section 147 AO and section 257 HGB, the audit trail for twelve months.

E-mails now show injected markup as text (#2458)

Values that SCS puts into an e-mail - customer name, address, order number, free text from a form - used to be carried into the message unchanged. If such a value contained HTML markup, it acted like the template's own markup in the recipient's inbox. From now on that markup appears as visible text; the look of your templates does not change. Where a template outputs markup on purpose - the billing and shipping address in the order confirmation, the file list in the download mail - it is preserved unchanged. Existing tenants are converted automatically at the next service start, nothing to do.

Payment methods in checkout are shown completely and correctly again (#2356)

The list of available payment methods is filtered by order value and delivery country. Two parsing faults produced wrong results: a lower-case country code (de instead of DE) matched no method, so country-restricted payment methods were never offered to the customer. And an order value in scientific notation was read as 1 cent, so methods with an amount limit appeared when they should not. Both are fixed, and an unreadable order value is now rejected instead of silently switching the amount filter off.

Security: customer addresses are now fully encrypted (#1875)

On a customer address, the name, street and phone number were already stored encrypted, while postcode, city, additional line, company and region were kept in plain text. Postcode and city together identify a person just as much as the name next to them, so from now on all of these are stored encrypted with the same method. Nothing changes in how you work with them: you still see, enter and edit addresses exactly as before, invoices and shipping labels are produced unchanged, and tax and shipping cost resolution keep working as usual. Addresses already on file are migrated automatically - there is nothing for you to do. The country code deliberately stays unencrypted: on its own it is not personal data, and it is needed for tax and shipping resolution.

Security: your customers' VAT ID is now stored encrypted (#1878)

A customer account's VAT ID used to be stored in plain text. For sole traders and self-employed people it is personal data, so from now on it is stored encrypted with the same method already used for the email address and for the tax number in the company area. Nothing changes in how you work with it: you still see, enter and edit the number exactly as before, verification against the EU VIES system is unchanged, and it appears on the invoice as usual. Numbers already on file are migrated automatically - there is nothing for you to do.

Shop pages now reject nonsensical addresses cleanly

Following yesterday's fix to the three affected shop pages, every other publicly reachable shop address has now been brought in line - product, category, blog, content and legal pages, the cart, the checkout, reviews, menus, currencies, languages and the action links from ticket emails. Until now a value in the address bar that obviously cannot be one - a 400-character product key, say - could travel all the way to the database and cause a server error there. It is now rejected beforehand. What you will notice: a link with a nonsensical key still shows the familiar "not found" page rather than an error message, and an incomplete action link from a ticket email still shows the friendly note that the link is incomplete. Nothing changes for valid addresses. Also fixed: requesting a single language could return a response that was not a language at all, via a technical special term.

Smart collections no longer hand out their rules (#2463)

A smart collection assembles itself from a filter rule, such as "every item from this manufacturer over 50 euros". Until now the storefront interface gave that rule to anyone who asked, with no login required - along with the collections you had not published yet. That made your curation criteria, and what you were planning next, readable from the outside. It is closed: the storefront path now returns published collections only, and of those only what a display needs - name, description and item count. The filter rule and your own extension fields stay in the admin area. Nothing changes for your shop: resolving a collection into items and showing them works exactly as before, and now returns active items only, in line with every other part of the shop. In the admin area you still see everything, including the filter rule and the collections that are not published yet.

The "Paragraph" block now filters embedded HTML as strictly as every other block (#1871)

If you paste your own HTML into a Paragraph in the page editor, you were protected less well than in any other text block: the paragraph did strip scripts and event attributes, but it left links with javascript: and data: addresses, embedded <svg> graphics and <style> blocks in place. Those leftovers are enough to run someone else's code in a visitor's browser - and the paragraph is shown in the shop to everyone, signed in or not. The block now uses the same filter as Text, HTML, Image with text and Accordion. Ordinary content is unaffected. If you deliberately placed your own formatting via <style> or a graphic via <svg> inside a paragraph, it will no longer appear; set the formatting through your shop's design instead, and place graphics with the Image block.

The sitemap shows categories and blog articles again (#1082)

Your shop's automatically generated sitemap.xml previously broke on the category section, so search engines received no sitemap at all - and blog articles were silently missing entirely. Both are fixed: category and blog pages now appear reliably in the sitemap. A single broken section no longer takes down the rest of the sitemap either. Categories ·

Deleting a customer address now asks first (#1916)

In the customer record (Sales → Customers, then open a customer) the bin icon in the Addresses card removed the address on the first click. It is gone afterwards - including for orders that do not yet carry their own copy of the address. A confirmation now appears first, naming the street, postcode and town of the address concerned. Adding and editing an address are unchanged.

Sales lists now honour the requested number of rows per page (#2350)

Several lists asked the server for a specific number of rows per page - Redirects under Settings asked for 25, for example - but silently got the server's own default back instead, 20 in the case of redirects. The only sign was a page that was shorter than expected; nothing ever reported it. The server now understands the request and returns exactly as many rows as the page asks for. Besides redirects this affected brands, coupons, promotions, reviews, rules, tags, tax rules, newsletters, blog articles, gift cards, wishlists, abandoned carts and fraud screening. Filters, sorting and page navigation are unchanged.

The shop no longer prints foreign input as code

Three public shop pages - search, the customer account and the password reset page - copied a value from the address bar into the page unchecked. Anyone who slipped a prepared link to a customer could have foreign program code run inside your shop. That is closed: the shop's page templates now escape every inserted value by default, and the three pages additionally check their input up front - an unknown account tab, an unreadable reset key or an excessively long search term are now refused instead of displayed. Nothing changes for your content: texts from the content system, blog posts, product and category descriptions and text sections in the page builder still appear as formatted text. Only in fields that are explicitly plain text - the caption of an announcement banner, for instance - pasted HTML is now shown as text instead of being interpreted. Email templates are not affected by this change.

Category and customer permissions now actually take effect (#2222)

Under Staff & Roles you could grant the category permissions view and edit and the customer permission delete without the server ever checking them - a role carrying only those still ran into an error, and revoking them locked nothing. The category and customer endpoints now check both spellings that the permission editor and the public API offer. The shipped roles carry both and will notice nothing.

Four buttons in the sales area now ask before they fire

Delete order note (in the order detail view) removed the note at once - often the only written record of what was agreed with the customer by phone. Send reminder under Sales › Abandoned checkouts mailed a real person with one click, from a row in a list people click through for reading - and stayed clickable even after a reminder had already gone out. On the product, Delete currency price and Delete download removed their entry with no question; with a download, customers who already bought the product lose their file too. All four now open a confirmation window that names the consequence - for the reminder, including the recipient address. "Cancel" means nothing happened. Plain saving stays question-free - writing a note, entering a currency price or uploading a file still goes straight through.

Publishing and unpublishing a content page now ask first

In the page editor (Sales › Content pages), the "Publish" / "Unpublish" button switched over at once. Both directions change what your visitors see the moment they land: publishing puts the page in front of every visitor of your storefront, unpublishing takes a live page away from anyone holding its link. A confirmation window now appears first, naming the page title and saying which of the two is about to happen. Saving is unchanged - you still store your edits without a question.

Refunds now recognise the "Refund orders" permission (#2222)

Granting Refund orders under Staff & Roles allowed nothing until now: refunding a payment asked exclusively for Refund payments. Both now open the same action. No existing role loses anything - in the shipped roles both permissions sit with super administrator and administrator anyway.

Review moderation, product streams and custom product fields now demand a permission

Until now anyone who was logged in could approve, reject, answer or delete any review and create, change or remove product streams and custom product fields - regardless of the permissions their role carried. The server now checks: moderating reviews requires Moderate reviews, product streams and custom product fields require Edit products. The shipped super-administrator, administrator and editor roles already carry both permissions and will notice nothing; a viewer can no longer change these areas. If you created a role of your own, grant it the respective permission once under Staff & Roles.

Catalogue and customer screens now ask before anything is deleted or leaves the house

Across 24 flat administration pages - products, categories, brands, properties, shipping methods, Google Shopping feeds, CMS pages, customer segments, business customers, subscriptions, marketplace vendors, email campaigns, saved reports, notifications and the customer inbox - 29 buttons fired on the first click. Each is now preceded by a prompt that names the consequence and names the affected record; where something goes out of the house, it also names the recipient. 20 native browser windows have disappeared - prompts here are now consistently dialogs of the interface and therefore behave the same in dark mode and with screen readers. Three places deliberately get no extra dialog, because you have already typed text there and the send button itself is the prompt: the reply in the customer inbox, the reply in the support inbox and the vendor invitation. Those three now also respond to the Enter key. One button was split: "Publish" and "Unpublish" of a CMS page sat on the same control; only publishing puts the page in front of every visitor of the website and now sits behind the prompt - unpublishing takes exactly that back and needs none.

Confirmation and invoice emails now carry dates in your language

Order confirmations, payment confirmations, withdrawal confirmations, invoice dispatches and the subscription emails had their text rendered in the recipient's language for a long time - but the dates and amounts underneath were always formatted German. An English order confirmation therefore said “5. Januar 2026” and quoted an amount with German separators. Both now follow the language of the email: in English it reads “5 January 2026” with English separators. German emails are unchanged. Where no language is recorded for a recipient, the tenant's default language still applies.

Email templates: test send and branding now respond to the Enter key

In the Send test email window you could type a recipient address but not send it with Enter - only the button worked. The window is a real form now: Enter sends, and an incomplete address is rejected by the browser before anything goes out. The same applies to both Save buttons under Branding (general and per language). These three deliberately get no extra confirmation - you fill in fields there and send them off on purpose, and that send button is the confirmation. Resetting a language version now does ask, naming the language concerned, and the browser's own window has disappeared from it.

Field captions in order and email editing are now linked to their field

In a customer's contact details, in the order detail (add line item, capture payment, edit line item, order flow), in the email campaign builder and in the email templates (block editing, branding, translation matrix) the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "Subject, edit box". That link is now in place. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Some places sound different: where the caption sits above a group of several controls - alignment, social links and column widths in the campaign builder, a block's background, text and divider colour, and the primary and secondary colour plus the social links in the template branding - a screen reader now announces a group with that name; the same goes for the two rich text editors (block content and footer), which are not ordinary input fields. In two places there is no control underneath at all: the net price when adding and when editing an order line item is a computed value. It is now read out as ordinary text instead of as the caption of a field that does not exist.

Field captions in shop administration are now linked to their field

Across the shop's admin pages - products, categories, brands, properties, tags, navigation menus, blog, streams, the theme editor, template customisation, coupon codes, promotions and discounts, shipping, payments, redirects, Google reviews, Trusted Shops, webhooks and OAuth clients - the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "Product name, edit box". 81 captions now carry that link. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Eleven places sound different: there the caption does not sit above a single input field but above a group of several controls - the colour swatches of a tag, the coupon type picker, a promotion's code type, a webhook's event list, an OAuth client's client type, scopes and grant types, the tag picker of a blog post, the from/to pair for delivery time in shipping, and the input fields for a new menu entry. A screen reader now announces a group with that name.

Field captions in the shop admin are now linked to their field

In the content page editor - block editors (heading, text, image, image with text, gallery, video, button, divider, spacer, HTML, accordion, product card, product slider, category grid, logo strip, stats banner, process steps, testimonial, newsletter, animated hero, feature grid, feature showcase, scrolling cards, call to action), section settings, page settings, page meta and SEO - in discounts and coupon codes, in product translations, currency pricing, product FAQ, the variant table and the variant wizard, in the category, property and tag translation dialogs, in the rule builder, in shipping templates, and in app configuration (OAuth credentials and API keys), the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name. That is fixed. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Some of these places sound different: where what follows the caption is a group of several controls - a row of choice buttons such as text alignment, card style or display variant, a colour pair of swatch and hex field, a repeater list such as features, testimonials or process steps, a media picker, or a rich-text editor - a screen reader now announces a group with that name instead of reading out a caption with no field behind it.

Field captions in the shop are now linked to their field

On sign-in, registration, checkout, the customer account, forgotten password, returns and withdrawal, the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "First name, edit box". 50 fields now carry that link. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. One place sounds different: the "Account type" heading above the private/business toggle in registration was marked up as a field caption even though what sits below it is two buttons, not an input field. It is now read out as ordinary text instead of as the caption of a field that does not exist.

The close button of the shop's filter drawer now has a name

On a phone the shop's filters open as a drawer from the side, and a cross button at the top right closes it again. That button carried no label - a screen reader read it out without a name, so all you heard was “button” instead of “Close, button”. It is now called “Close”. Nothing changes visually.

The shop formats prices and dates in the shop's language, not the browser's

Price, number and date output in the shop came from helpers that read their language from a stored preference - but from the admin interface's, which the shop never writes. The lookup therefore never found anything and fell through to the next step: the browser's language setting. In practice the browser decided how a price looked for every visitor - a German shop opened on an English-configured device showed English-formatted prices. The shop's actual language is now read instead, and with none stored the shop's default applies. English shop pages show English formats, German ones German.

The shop now asks before something is deleted

Six buttons in the shop screens used to fire on the first click - the section in the page editor, the multi-select in a product's variant table, the Buy X Get Y rule of a promotion, a promotion's unredeemed discount codes, a shipping template, and a review in the app store. Each of these now shows a confirmation that names the consequence: which record, and how many for bulk actions. Every browser window has disappeared from these screens - confirmations are now dialogs of the interface, which makes them consistent in the dark appearance and with screen readers. The variant table loses its red confirmation strip: deleting now asks in the same dialog as everywhere else instead of revealing a second button. The Buy X Get Y rule sits in two screens at once - under Promotions and under Automatic Discounts - and the confirmation now applies in both.

The storefront loads its content again

A shop's public storefront page did come up, but stayed empty - no categories, no products, no settings, no shop-specific appearance and no cookie notice. What visitors saw instead was a generic page. The cause was a wrong address baked into the shipped storefront package: it requested its data from an address that does not exist (/api/... instead of /api/v1/...), so every data request came back empty-handed. The data itself was there and intact the whole time - it was simply never fetched. The address is corrected; products, categories, settings, appearance and the cart load again. There is nothing you need to do. To keep the same mistake from happening again, an automated check now verifies on every change that the address in the storefront package matches the interface's actual address.

CMS page editor moved to the shared interface controls (technical)

In the page editor - block editors, section settings, the media picker, and the preview/structure tools on the left - buttons as well as text, choice and multi-line fields now come from the shared interface toolkit instead of each component carrying its own code. Look and handling stay the same; what becomes consistent is keyboard focus, contrast in dark appearance and the behaviour of disabled fields.

Connecting an app through a sign-in window works again

Apps you connect by signing in with the provider (Google, for example) came back from the consent step to an empty page reading "404 Not Found" - so the connection could never be completed. The cause was a routing rule in the delivery layer that sent the return address to the API instead of to the user interface. Fixed: the window now returns correctly, reports "Successfully connected" and closes by itself. Two improvements shipped alongside it: the provider's response is now checked against the sign-in you actually started and rejected if it does not match - so nobody else's account can be slipped in. And the one-time token the provider appends to the return address is removed from the address bar immediately after processing; it therefore appears neither in your browser history nor in our access logs. There is nothing you need to do - simply start the connection again.

Customer addresses are now consistently encrypted at rest

When someone created a customer account in your shop with a billing address, the first name, last name, street and phone number of that address were stored as plain text - even though the very same fields were stored encrypted whenever the address was created or edited later from the customer account area. Nothing about this was visible from the outside: the display was correct either way. From now on, every path that creates an address encrypts the same four fields. Addresses already stored are re-encrypted once, automatically, with no action on your part and no downtime; addresses that were already encrypted are left untouched. Nothing changes for you or your customers in day-to-day use - the GDPR data export still returns the address in readable form. Postal code, city, country and address supplement are not covered; that is technically prepared but not yet switched over.

Email Log opens again instead of reporting "Could not load email log"

In newly set-up shops the Email Log page stayed empty and only reported that it could not be loaded. Cause: the page assembles its list from four data sources (Transactional, CRM, Workflow, Suppression list) and fetched them in one go; if even one of those sources was not yet set up or not readable in your shop, the entire query aborted - even though the other three were perfectly available. From now on the page checks up front which sources it can read, shows everything that is there, and states explicitly at the top which source is missing ("This list is incomplete"). If none of the four sources is readable, that is now spelled out instead of a meaningless error, and in the error case the message names the technical reason you can quote to support. There is nothing you need to do.

Product editing and shipping templates moved to the shared interface controls (technical)

In product editing (pricing, variants, FAQ, translations, digital downloads) as well as in shipping templates, buttons as well as text, choice and multi-line fields now come from the shared interface toolkit instead of each page carrying its own code. Look and handling stay the same; what becomes consistent is keyboard focus, contrast in dark appearance and the behaviour of disabled fields. The tables in these areas have not been moved yet and will follow later.

Unique page titles

Several help pages carried exactly the same name as a page of the same name in another area, which made them impossible to tell apart in search results and listings. Affected in this area: Payments (Shop), Subscriptions (Shop) and Webhooks (Shop). The page addresses do not change, so saved links and bookmarks keep working.

Every email now identifies the provider

Until now none of the automated emails carried a provider identification - neither the order confirmation to your customers nor the registration or password emails. German law requires this for commercial email (§ 5 DDG, § 18 (2) MStV). From now on, every outgoing email ends with a short footer carrying the legal company name, postal address, managing director, register court and number, VAT identification number, and a contact route. It appears in the HTML and the plain-text part (so text-only mail clients see it too), follows the language of the email - German or English, German when the language cannot be determined - and comes from the same maintained source as the legal notice on our website, so the two cannot drift apart. The details cover SELLERLOGIC as the operator of the platform, not your own; your footer text from the "Branding" tab is unchanged and still appears above it. You do not have to do anything, not even for templates you create later: the footer is appended at send time and is not stored in the template.

Google Reviews no longer shows fabricated reviews

The sync under "Google Reviews" used to accept any Place ID/API key combination and permanently write five hardcoded sample reviews with fabricated, named authors (including "Maria S.", "Thomas M.") to the database - regardless of whether a real Google Business Profile existed behind it. Those were fabricated reviews that looked like real customer feedback, not a real sync - and more serious than a display-only issue, because they were stored permanently. The page now shows only an honest notice that the Google Places connection has not been set up yet; "Sync" no longer writes anything to the database. Any fabricated reviews that already existed were automatically removed from all tenant databases.

The Features page trust bar now shows only claims we can back up

Your shop's public features page used to advertise a "SOC 2 Type II" seal, a PCI-DSS certification presented as complete ("PCI-DSS SAQ A-EP certified"), and the bare mention "PCI-DSS" as a seal on its own - none of them had a supporting audit report behind them. The trust bar and the security block on the storefront home page now list only what we can point to evidence for: server location Germany, GDPR, CCPA, and that no card data is stored on our servers (payments are processed exclusively by the payment service provider). Also removed: an App Store listing and a storefront badge (never actually shown in any shop) that both implied a Trusted Shops connection we did not have. There is nothing you need to do.

The Trusted Shops page no longer shows fabricated results

The connection check under "Trusted Shops" used to report a green "Connected" badge, a "Valid" seal, and a fixed rating (4.82 stars, 1247 reviews) for any Trusted Shops ID that merely looked correctly formatted - regardless of whether a real Trusted Shops account existed behind it. That was a fabricated display, not a real check. The page now shows only an honest notice that the Trusted Shops connection has not been set up yet; there is currently no real connection check and no real reviews.

CMS editor tree view, template store cards, and more drop zones now keyboard-operable

In the CMS editor's tree/structure view, section and block rows as well as expanding/collapsing a section previously only worked with the mouse; the same applied to a card in the template store and its detail image preview, the drop zone for uploading product images, clearing a selection in the translation dialogs' language field, and, on the storefront, zooming the image in the product detail page's fullscreen view. All of these can now also be reached with the Tab key and triggered with Enter or Space.

More click targets in the Shop area now reachable without a mouse

Several admin pages had individual elements that could previously only be clicked with a mouse. Fixed: the page title in CMS Pages (opens editing), a group's header row in Properties (expands or collapses it), the main image in the Template Store detail view (opens the fullscreen view), and the drop zone in the Media Library (opens the file picker) can now be reached with the Tab key and triggered with Enter or the Space bar.

Registration and password emails are now available in English too

When a shop was first set up, text strings were only created in German - English-speaking recipients received a German email through the language fallback. The "Customer registration" and "Password reset" templates now ship a maintained English version as well, marked as reviewed text rather than an AI draft. For all other templates you continue to maintain English via the translation matrix.

Your welcome email now names your shop, not the platform

Anyone creating a customer account in your shop received an email with the subject "Willkommen bei SELLERLOGIC SCS". For your customers that was simply wrong - they bought from you, not from us. The subject now reads "Welcome to your shop name", and the password reset email likewise carries your shop name in the subject ("Reset your password for your shop name"). Both templates offer the new {{shopName}} variable for this, which you can also use elsewhere in the editor. Existing templates were converted once; a subject you edited yourself is left untouched. The footer of the email shell no longer names the platform either, but your shop. There is nothing you need to do.

Last traces of the old platform name "V3NDR" removed from your e-mails

In long-standing shops, automatic e-mails to your customers could still carry traces of the old platform name: the footer showed "V3NDR" as the fallback while no company name was set under "Design > E-mail branding", the welcome e-mail after a customer registration was titled "Willkommen bei V3NDR", and the sender name could still show the old default "Mein V3NDR Shop". All three spots were cleaned up once: the footer now falls back to "SELLERLOGIC SCS", the welcome subject accordingly, and a never-changed sender name is derived from your shop name again. Your own texts, a company or sender name you chose yourself, and your translations remain untouched; an existing translation of the welcome subject is merely flagged for review.

A typo in your shop address now visibly leads nowhere - instead of to a page that does not exist

When someone opened an address under …scs.sellerlogic.com that belongs to no shop - because they mistyped the name, for example - a complete page still opened. It was empty, but it looked real. That was unfortunate for two reasons: in support a typo could not be told apart from an outage, and an invented, official-looking address was useful for abuse in forged e-mails. From now on a visitor in that situation is sent to the main address automatically. If someone opens an administration address with an unknown name, a clear notice naming the address that was not found appears instead of the sign-in form - previously there was a sign-in form for a shop that does not exist. Your own shop address and your administration are unaffected.

Some address names can no longer be used as a shop name

The names appointment, ws and platform are now reserved, because fixed services are already reachable under them - appointment booking among others. Had one of them been issued as a shop name, that shop would have been permanently unreachable. Existing shops are unaffected; when creating a new shop such a name is now rejected with a notice.

Your shop is now usable on a phone

On narrow screens your shop was hard to operate - content stuck out beyond the edge, so the whole page had to be pushed sideways, and many controls were too small to hit reliably with a finger. That is fixed. In detail: the product list shows items in one or two columns, and the page numbers wrap onto a second line instead of widening the page. On the product page the delivery, returns and payment notes sit below one another, the thumbnail strip can be swiped sideways, and the technical data scrolls inside its own box - long codes such as EAN or GTIN no longer shift the page. In the basket and at checkout the quantity controls, the remove button and the place-order button are large enough to tap, all address fields sit below one another, and the checkout step indicator gets a line of its own on narrow screens. The header keeps the basket and the menu visible, and every icon there now carries a label for screen readers. You do not have to change anything.

Downloads with meaningful file names

The Google Shopping feed is now named after the feed name instead of the generic “google-shopping-feed.xml”. Purchased digital downloads are saved under their file name instead of the internal storage name, and product exports use the system-assigned name including the date.

"Cancellation reason" with consistent capitalisation

The field shown when cancelling a subscription is now labelled Cancellation reason everywhere.

Checkout and customer account: address field now says "Company name"

The field for the company entry in addresses now consistently reads Company name (following the German DIN 5008 addressing standard). The storefront also had a few remaining untranslated German-interface labels replaced with proper German wording (for example "Bestellverwaltung" instead of "Order Management").

Consistent wording in orders, invoices, returns and subscriptions

The rows of a document are now called line items everywhere - previously the same thing was labelled "Items" in one view and "Line Items" in another, and the capitalisation varied. "Article number" (SKU) and physical goods, for instance in the warehouse, keep their names. Nothing changes in behaviour, only in labels.

Consistently "Refund"

In returns and in the API documentation, the German interface used two different words for the same thing, "Rückerstattung" in some places and "Erstattung" in others. It is now Erstattung everywhere (refund amount, refund fees). The English interface is unaffected.

Marketplace: consistently "Vendor"

Your marketplace vendors are now called Vendor throughout menu, lists and detail views - previously "seller" and "vendor" alternated. Suppliers in procurement remain suppliers.

The German interface no longer shows English leftovers

Labels such as "Orders/Monat" or "Order Management" in the German interface have been translated properly. The English interface is unaffected.

The product area no longer shows German in the English interface

When uploading product images, the progress text, the hint about image order, the image and video counts and the messages about unsupported formats and failed uploads appeared in German even with the language set to English. The same applied to the rich-text editor toolbar ("Insert emoji", "Text style", "Clear formatting") and the input example when creating a redirect. All of those texts are now maintained in both languages.

A link without an address is no longer sent silently

If no valid address can be determined for a message, sending is now aborted and recorded in the error monitor instead of delivering a message with an unusable link.

Customer tags can be opened and created again

In the customer detail view the tag picker stayed empty and creating a new tag failed - the list could not be loaded at all. The cause was an older state of the data store in which a tag was still tied to exactly one customer, whereas today's version keeps tags as a list of their own and then assigns them to any number of customers. That data state is now brought up to date automatically. The picker shows the standalone tags from now on; older entries attached directly to a customer through customer segmentation are kept unchanged and still shown there. There is nothing you need to do.

Customer views without initials circles

The colored initials circle shown before the customer name has been removed - in the customer list, on the customer detail page, in reviews, in subscriptions, and in your customers' account overview in the shop. The views show the name directly and take up less space.

Emails that were never sent are now visible

When sending was aborted because the customer has no email address on file, no entry was created at all; an email that was never sent looked exactly like one that was. Such cases now appear with the status Not sent and the reason in plain language. You can filter for them in the Email Log.

Links in emails are built per tenant again

For a number of notifications the address was not taken from your shop settings but from a central default that was empty in practice. In concrete terms: signature invitations contained a link with no address at all, and confirmation links from self-registration pointed at the recipient's own machine instead of SCS. Also affected were ticket reminders and reopen links, CSAT surveys, escalation alerts to team leads, HR requests, the review digest, the account links in subscription and download emails, the embedded appointment booking window, sitemap.xml, robots.txt and the blog RSS feed. All of these now take the address from Settings → Domains & URLs; if nothing is stored there, your public shop address is used automatically. You do not need to do anything.

Still outstanding: the confirmation link from self-registration.

At the time of a new registration your shop does not exist yet, so no shop address can be used. The link therefore now points at the general sign-in address admin.scs.sellerlogic.com instead of, as before, the recipient's own machine. That one address is not being served yet; the routing addition required for it has been commissioned and will follow separately. Until then the confirmation link cannot be opened.

The Email Log now shows your sending service's reference

The detail view of an email now includes the delivery path actually used and the identifier your provider filed the email under. That makes an email unambiguously findable at the provider when in doubt.

Your shop shows data again on its public address

When a visitor opened your shop at your-name.scs.sellerlogic.com, the page could not load its content - products, cart and customer account stayed empty, because the requests to our system went nowhere there. This is fixed; you do not have to change anything. Only the public address of your shop was affected, not the admin area.

Outgoing emails now carry your shop name

Until now your customers saw the sender name "Shop" in their inbox whenever no custom name was stored in the email delivery settings. From now on SCS automatically uses your shop name from the shop settings in that case. A sender name you entered yourself is untouched and still takes precedence. You can now also clear the field again to go back to the shop name.

Payroll and master-data exports are sent in your company's name too

Exports to your payroll office used to carry a technical sender name. They now arrive under your shop name as well.

Webhooks: new SCS headers, the old ones keep going

Every notification we send to your own software carries technical headers with the event, the signature, a delivery number and the timestamp. These used to be called X-V3NDR-... and will be called X-SCS-... from now on. So that nothing breaks, we send both sets at the same time during a transition period, with identical values and the same signature. You do not have to do anything for your existing integration to keep working. When you get the chance, please switch your signature check to X-SCS-Signature, or accept either name. The old names will only go away after that transition period, and we will announce it beforehand. The example under Shop → API documentation → Webhooks now shows both sets exactly as they arrive at your end.

Blog articles in the shop open reliably

An article could break into a blank page while loading. Fixed.

The error page stays usable even when translations fail to load

Until now the page meant to show an error could itself crash in exactly that situation. It now shows a message even without translations.

Security: social sign-in protected against account takeover

When a customer signs in with Google, Apple, Microsoft, or GitHub and an account with the same email address already exists, the social account is now only linked to the existing account automatically if the provider confirms the email address as verified. Otherwise the customer is asked to log in with their password and link the provider themselves from their account settings. This prevents taking over someone else's account via an unverified email address. Brand-new accounts are still created as usual.

Security: shop page content sanitized consistently

CMS blocks (including text, image-text, accordion, and free-form HTML), blog articles, and legal pages (terms, refund policy, privacy, etc.) are now consistently sanitized when displayed in the shop. Nothing changes in look or usage for you.

Stronger safeguard for payments via your own merchant account

Payments made through Stripe Connect or Mollie Connect are now only recorded as successful, captured, or refunded once the payment provider has actually confirmed it. If the technical connection isn't fully set up, the payment now fails visibly instead of being incorrectly marked as paid.

Bounce rate & order metrics explained

The Email Bounces and Orders manual pages now show exactly how bounce rate, order totals and the fraud-risk score are calculated - and how to improve them.

Faster shop loading

The customer-facing shop now loads only the language actually needed instead of all 44 language packs at once - the first page load transfers about 60% less code. When switching the shop language, the respective language pack is loaded automatically; functionality and usability remain unchanged.

Country as a searchable dropdown across more areas

In further areas you now pick the country from a searchable list instead of typing the code by hand - type "Fran", for example, and choose "France (FR)". This covers draft-order addresses, tax rules (the rule's country), the embargo country list and country check in sanctions screening, and the Google Shopping feed's target country. The internationally standard country code is still what gets stored, and values already on file are preserved.

Technical refresh of the shop screens

Products, orders, customers, coupons, discounts, shipping, payments, domains and subscriptions were switched internally to the shared SCS UI kit. How you use them stays the same - forms, tables and buttons may look a touch more consistent in a few places.

Interactive tour "Create a product"

The products manual page now offers Start tour - a guided step-by-step walkthrough directly in the interface.