- or
No existing idea results
- ~ No ideas found ~
1447 results found
-
Add separate configuration options to distinguish between “allow payment method change after checkout” and “allow retry of an aborted paymen
To better support payment workflows, especially with PayPal, it would be highly beneficial to separate two currently combined behaviors:
At the moment, the option “Allow payment method change after checkout” also controls whether customers can retry a previously aborted payment (e.g., PayPal popup was closed by mistake).
However, enabling this option on PayPal unintentionally allows customers to change from any other payment method (e.g., Prepayment/Bank Transfer) to PayPal after the order is placed. This causes serious issues in ERP/WMS integrations where such changes are not allowed.Proposed improvement:
Introduce two independent configuration options per payment method:“Allow switching to this payment method after checkout”
“Allow retrying an aborted payment for this payment method”
Benefits:
Customers can still complete PayPal payments if they accidentally aborted the payment window.
Merchants can prevent unwanted payment method changes (e.g., Prepayment → PayPal) that break ERP workflows.
Provides clearer, more predictable, and more granular control over payment behavior.
This enhancement would significantly improve flexibility and avoid unintended side effects in multi-payment setups.
To better support payment workflows, especially with PayPal, it would be highly beneficial to separate two currently combined behaviors:
At the moment, the option “Allow payment method change after checkout” also controls whether customers can retry a previously aborted payment (e.g., PayPal popup was closed by mistake).
However, enabling this option on PayPal unintentionally allows customers to change from any other payment method (e.g., Prepayment/Bank Transfer) to PayPal after the order is placed. This causes serious issues in ERP/WMS integrations where such changes are not allowed.Proposed improvement:
Introduce two independent configuration options per payment method:“Allow switching to this…
1 vote -
Support for Spanish NIE Numbers in VAT/Tax ID Validation
In the merchant registration form (e.g., via the B2B Suite or customer registration), Spanish NIE numbers are currently rejected as invalid VAT/Tax IDs. However, the NIE (Número de Identidad de Extranjero) is the official fiscal identification number for foreigners in Spain and is accepted by the Spanish tax authorities.
A valid NIE follows this format:
Starts with X, Y, or Z → 7 digits → ends with a letter
Example: Y5432178PCurrently, the validation logic does not accept such values, blocking legitimate registrations from Spain-based users.
5 votes -
Add user friendliness to new language handling
Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to process bin/console translation:install --locales it-IT linked to the switch's setting? Perhaps in addition whether the snippets should be installed / uninstalled?Since Shopware 6.7.3.0 the language pack displays a warning, that it's recommended not to use it and that it will not work with 6.8.x anymore. Unfortunately the deinstallation of the language pack removes all translations included there (test with 6.7.4.0, with selection "Remove all data it even throws an exception).
The dev docs recommend this way https://developer.shopware.com/docs/resources/references/upgrades/core/translation/language-pack-migration.html. But not every customer is feeling comfortable being forced to use the command line. It is intended to activate / deactivate a language via the language itself. So why don't you add an install / uninstall routine in settings > language to…1 vote -
Settings > Log-in & sign-up: Add company name field required
Use Case: We have two sales channels (B2B and B2C) and could set this up in the B2B sales channel.
2 votes -
Native support of IndexNow
Whats this?
"IndexNow is an easy way for websites owners to instantly inform search engines and web crawlers used for information retrieval (“search engines”) about latest content changes on their website. In its simplest form, IndexNow is a simple ping so that search engines know that a URL and its content has been added, updated, or deleted, allowing search engines to quickly reflect this change in their search results."
Currently supports: Microsoft Bing, Naver, Seznam.cz, Yandex, YepWebsite: https://www.indexnow.org/index
4 votes -
Improve Safety and Flexibility for Promotion Code Configuration
Context
In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.Problem
Users may overlook that a promotion is configured without a code, because “No code required” is preselected
This can unintentionally trigger discounts for all customers
Currently, there is no system-level control or "safeguard" to prevent this
Proposed Solutions
We suggest adding configurability or safety mechanisms for the “Promotion code type” field to reduce user errors and increase administrative control.
There are three possible options that could be implemented independently or in combination:
Require explicit selection (no default preselection)
Remove the preselected value “No promotion code required.”System-wide default configuration
Add a configuration setting in system or admin preferences allowing administrators to define the default for new promotionsOptional warning before activation
Display a confirmation or warning when activating a promotion that has no promotion code set.
Example message:
“This promotion will be applied to all customers because no promotion code is required. Are you sure you want to activate it?”
Expected Benefits
Prevents accidental large-scale discount activations
Improves administrative control and safety
Reduces support incidents and potential financial losses
Aligns the promotion workflow with enterprise-level requirements
Context
In the current version of Shopware 6, when creating a new promotion, the field “Promotion code type” is automatically set to “No promotion code required”.
This UX choice was made intentionally to simplify creation of general cart-level discounts, which are the most common use case.However, this default selection can lead to unintended activation of promotions when a user forgets to change the option to “Fixed” or “Individual promotion code.”
In such cases, discounts may be applied to all customers instead of a limited target group, which can cause serious financial and operational issues.Problem
Users may overlook that…
1 vote -
Returns-Management: Dealing with multiple returns / partial cancellation per order
I can currently only create one return per order via the returns management. However, this means that if I have two partial returns per order (for which I create two separate partial cancellations), both returns are visible on the second partial cancellation. However, only the specified returned item should be visible for each partial cancellation.
3 votes -
Revision of list prices
The implementation of strikethrough prices has been poorly and even incompletely implemented. In the ITA shop, we don't have a proper way to display a sale category, as the default function here also goes to the first tab.
And independently, the in-house solution/rule for discounted items in the dynamic product groups is incredibly slow.
The host once sent me the Slow Query. If printed out, I could wallpaper at least half the room (high ceilings in an old Berlin building).
So please take a look at the topic. Anyone who has multiple sales channels and different prices within them will wish they were back in Shopware 5. It was all easy peasy and performant.
The implementation of strikethrough prices has been poorly and even incompletely implemented. In the ITA shop, we don't have a proper way to display a sale category, as the default function here also goes to the first tab.
And independently, the in-house solution/rule for discounted items in the dynamic product groups is incredibly slow.
The host once sent me the Slow Query. If printed out, I could wallpaper at least half the room (high ceilings in an old Berlin building).
So please take a look at the topic. Anyone who has multiple sales channels and different prices within them will…
2 votes -
Color recognition - Image Keyword Assistant
The Image Keyword Assistant should be able to recognize colors. This is particularly important for variant articles, where the same images are often used in a different color.
3 votes -
Add informal (Du) text snippets for German language
It would be useful to have an offical "Du"-Version of the de-DE snippets, either natively or through the language pack.
6 votes -
Backend: Product Filtering and Customization - Filter Value
The product filters section needs more customization and can be optimized.
Here is an example of the main shortcomings:
1 - Allow the addition of custom fields and properties.
2 - Allow the use of operators such as: "Like," "=", "And," "Or," "Starts with," etc.
3 - Allow filtering by entering multiple values in a search field.8 votes -
Dynamic pricing or promotions based on affiliate code
Currently, Shopware does not allow evaluating the affiliate code via the rule builder prior to ordering or registering a new customer account, making it impossible to have affiliate-specific pricing or discounts based on those affiliate codes. This functionality should be added to the rule builder.
3 votes -
Extended debugging e-mail/template dispatch
Many customers customize the email templates for their shop. It often happens that certain e-mail templates are no longer sent because, for example, variables are incorrect.
Troubleshooting the cause is then very difficult and time-consuming because:
- There are no errors in the log with indications of the cause.
- The e-mail test function still works with the e-mail template because variables are ignored.
As a result, the e-mail template and the variables have to be checked with a great deal of effort and there are a lot of support tickets for this, as customers quickly reach their limits.
In order to help customers and reduce the number of support tickets, it would therefore be useful to have extended debugging for sending emails. It should be possible to recognise from which line the e-mail dispatch fails.
This would allow the customer or the support team to name and recognise the line directly and, if necessary, find the error within seconds. This leads to less time for troubleshooting and frustration for customers.
Many customers customize the email templates for their shop. It often happens that certain e-mail templates are no longer sent because, for example, variables are incorrect.
Troubleshooting the cause is then very difficult and time-consuming because:
- There are no errors in the log with indications of the cause.
- The e-mail test function still works with the e-mail template because variables are ignored.
As a result, the e-mail template and the variables have to be checked with a great deal of effort and there are a lot of support tickets for this, as customers quickly reach their limits.
In order to…
21 votes -
Quotes: Shipping and payment
For offers, the shipping method and payment method used cannot be changed or edited. A shipping method and a payment method are still specified. It should be possible to change this data when editing.
Bei Angeboten kann die verwendete Versandart und die Zahlungsart nicht geändert oder bearbeitet werden. Deonnoch wid eine Versandart und eine Zahlungsmethode angegeben. Bei der Bearbeitung sollte die Möglichkeit bestehen diese Daten zu ändern.
4 votes -
Filters for Flow Builder
For bigger lists of any entity, it is super important to have filters in order to find efficiently what you are looking for. We have filters for the Products, Customers, Rule Builder overviews and probably in many other menus as well.
There for we should most definitely also have this kind of filtering also for the Flow Builder overview.
Finding the flow you are looking for only with the search is a pain. Try to search for the flow "Order placed". Since the string "order" is part in 90% of all flows out of the box, you will not be able to find it but will need to filter manually through the list of flows again.
For bigger lists of any entity, it is super important to have filters in order to find efficiently what you are looking for. We have filters for the Products, Customers, Rule Builder overviews and probably in many other menus as well.
There for we should most definitely also have this kind of filtering also for the Flow Builder overview.
Finding the flow you are looking for only with the search is a pain. Try to search for the flow "Order placed". Since the string "order" is part in 90% of all flows out of the box, you will not be…
1 vote -
Delivery time as Rule Builder condition
The Rule Builder is missing the option to use the delivery time of a product as a condition. This would be a useful improvement, for example to use this as an availability rule for shipping methods.
7 votes -
Logging of running flows
For monitoring the system and testing flows, it is extremely important that there is logging in the admin area.
The following information is important for logging:
- When did the flow run?
- Which trigger was activated?
- Which data was fed into the flow?
- Which data was decisive for the conditions?Zapier provides excellent logging for such systems.
2 votes -
Show detailed error message why a voucher could not be redeemed.
Regardless of whether a promotion is no longer valid (end date reached) or the maximum number of redemptions has already been reached, the error message in the offCanvas is always the same and therefore confusing for the customer.
Currently, the content from snippet ‘checkout.promotion-not-found’ is displayed per se.
It would be desirable if the exact reason why the voucher code cannot be used was given in relation to the above examples, i.e.
- ‘Promotion is no longer valid / expired’
- ‘Maximum number of redemptions already reached....’
5 votes -
"not specified" salutation handling
This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.
Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.
Also, sometimes like in the contact form the salutation is randomly required. You can delete it for addresses and the database has a default value of null, but then there is a non-configurable validator that won't let you through the checkout process if no salutation is given. And again, "given" can just mean that you set the "not_specified" salutation, which can have any meaning you assign to it.
This is an intransparent mess and should be changed. The very legality of requiring a salutation is now even in question. Just allow null values for all salutations in the application, it's already allowed in the DB structure, stop enforcing it in random places without a way to turn it off, and make the display name of a "null" salutation translatable via config.
This is handled rather inconsistently in Shopware. In some but not all places, if you leave out the salutation, Shopware searches the database for the "not_specified" entry that comes with the installation and inserts it if found. If also sometimes inserts it just for display in the Administration if the real salutation reference is null, so you wouldn't even know the real value without looking directly into the database, but again, not always.
Crucially, that "not_specified" entry can be changed and deleted at will, so there's no guaranteed meaning behind it.
Also, sometimes like in the contact form the salutation…
1 vote -
Keep admin menu open
Please stop auto collapsing the menu sidebar, when clicking on the page editor (Erlebniswelten). Its so annoying and completely unnecessary on large screens.
5 votes
- Don't see your idea?