Shopify Scripts haben am 30. Juni 2026 aufgehört zu funktionieren. Das können Sie jetzt tun.
Wenn Ihr Shop einen individuellen Rabatt-, BOGO- oder Bundle-Script verwendet hat, wurde dieser am 30. Juni 2026 stillschweigend deaktiviert. Keine Fehlermeldung, kein Hinweis, nichts in Ihren Protokollen. Hier erfahren Sie genau, was passiert ist, was die Migration zu Shopify Functions tatsächlich bedeutet, und eine ehrliche Antwort darauf, was Stackable für Sie wiederherstellen kann.
- Shopify Scripts wurden am 30. Juni 2026 für alle Shops eingestellt, die sie noch verwendet haben.
- Jede individuelle Rabatt-, BOGO- oder Bundle-Logik, die in einem Script hinterlegt war, wurde ab diesem Datum nicht mehr angewendet.
- Dieser Ausfall ist bewusst stillschweigend: Eine Shopify Function, deren Bedingungen nicht auf einen bestimmten Warenkorb zutreffen, wird einfach nicht ausgelöst. Es gibt keine Fehlermeldung, und Shopify benachrichtigt Sie nicht.
Händler, die diese Migration durchlaufen, beschreiben in den Shopify-Community-Foren dieselbe Gefahr:
“Mein altes Script hat stillschweigend aufgehört, einen Rabatt anzuwenden, und ich habe es nur bemerkt, weil sich ein Kunde beschwert hat, den vollen Preis bezahlt zu haben. Es gab keine Fehlermeldung, keinen Hinweis, nichts in den Bestellprotokollen. Ich hatte wochenlang mit einer defekten Einrichtung gearbeitet, bevor ich es bemerkte.”
Das ist das Kernrisiko beim Wechsel von Scripts zu Functions: Eine Function ist entweder korrekt aufgebaut und aktiv, oder sie ist falsch konfiguriert und bleibt stumm. Einen sichtbaren Zwischenzustand gibt es nicht. Eine nicht passende Bedingung, ein Tippfehler in einem Schwellenwert oder eine Regel, die auf die falsche Kollektion beschränkt ist, erzeugt genau dieselbe Stille wie eine korrekt funktionierende Function. Der einzige Weg, das zu erkennen, ist ein gezielter Test in beide Richtungen, bevor Sie der Function im Live-Betrieb vertrauen.
Vier Dinge, die es sich zu wissen lohnt, bevor Sie beginnen
Aus einem Script werden oft drei Migrationen
Eine einzelne Script-Datei konnte gleichzeitig Rabattlogik, Versandtarife und Zahlungsanpassungen betreffen. Functions teilen das in getrennte Function-Typen auf: Rabatt, Versand und Zahlung, jeweils unabhängig konfiguriert und bereitgestellt. Die Migration "meines Scripts" bedeutet in der Regel, bis zu drei unterschiedliche Dinge zu migrieren, und das ist die Beschwerde, die Händler zu diesem Wechsel am häufigsten äußern.
No-Code-Baukästen decken in der Regel nur Rabatte und BOGO ab
Wenn Ihr Script auch Versandkosten oder Zahlungsmethoden betroffen hat, reicht ein No-Code-Baukasten für Rabatt-Functions, Stackable eingeschlossen, dafür nicht aus. Versand- und Zahlungsanpassungen erfordern einen Entwickler, der die entsprechende Function direkt schreibt.
Sichern Sie jetzt Ihren alten Script-Quellcode
Sobald der Script Editor vollständig abgeschaltet ist, ist der gespeicherte Code nicht mehr wiederherstellbar. Exportieren oder kopieren Sie Ihren alten Script-Quellcode noch heute, auch wenn Sie noch nicht bereit für die Migration sind, damit Sie eine Referenz für den Ersatz haben.
Testen Sie einen Warenkorb, der auslösen soll, und einen, der nicht auslösen soll
Bevor Sie einer neuen Function vertrauen, erstellen Sie zwei Test-Warenkörbe: einen, der sie auslösen soll, und einen, der es bewusst nicht soll. Eine Function, die auslöst, obwohl sie es nicht sollte, ist genauso kostspielig wie eine, die stillschweigend nie auslöst.
Die drei Fakten, die jede Migrationsentscheidung erklären
Fast jede Diskussion darüber, was sich neu aufbauen lässt und was nicht, lässt sich auf drei Fakten zurückführen: Scripts gab es in drei Typen mit jeweils einem Slot, Functions verteilen diese drei Typen auf vier unterschiedliche APIs, und eine Function muss jedes Datenfeld, das sie jemals liest, vorab deklarieren, bevor sie ausgeführt wird. Sind diese drei Fakten klar, ist der Rest dieser Seite reine Rechenarbeit.
Shopify Scripts gab es in drei Typen
Der Script Editor verlangte, dass Sie einen Typ auswählen, bevor Sie auch nur eine Zeile Ruby schrieben, und dieser Typ legte fest, was Ihr Code überhaupt verändern durfte.
Line-Item-Scripts
Die Scripts, die veränderten, was Produkte kosteten. Sie gingen den Warenkorb Zeile für Zeile durch und passten die Preise an, genau dort steckten alle gestaffelten Rabatte, BOGO-Angebote, Bundle-Preise und Preisnachlässe.
Versand-Scripts
Die Scripts, die mit Versandtarifen arbeiteten. Sie konnten einen Tarif rabattieren, ausblenden, umbenennen oder die Reihenfolge der Liste ändern, die der Kunde sah. Nur die erste dieser vier Möglichkeiten ist ein Rabatt.
Zahlungs-Scripts
Die Scripts, die mit Zahlungsmethoden arbeiteten, mit denselben vier Möglichkeiten: eine Methode ausblenden, umbenennen, die Reihenfolge ändern oder in der Praxis meistens sie für bestimmte Warenkörbe ausblenden.
Nun zur Einschränkung, die jedes echte Script geprägt hat, das Sie je lesen werden: Es konnte immer nur ein Script pro Typ gleichzeitig veröffentlicht sein. Ein einziger Line-Item-Slot für den gesamten Shop. Ein Händler, der einen VIP-Rabatt, einen Ausverkaufspreis, eine Ausgabenschwelle und eine Saisonaktion gleichzeitig betrieb, schrieb also nicht vier Scripts. Er schrieb eine einzige Datei, in der alle vier zusammengeführt waren, meist mit einer selbst gebauten Regel am Ende, die festlegte, welcher Preis gewinnt. Deshalb wirken echte Scripts so verworren. Es handelt sich nicht um eine schlecht geschriebene Regel, sondern um mehrere Regeln, die nie getrennt sein durften.
Ein echtes Script mit vier zusammengeführten Kampagnen ansehenVier Function-APIs haben sie ersetzt
Shopify hat Scripts nicht durch eine einzige Sache ersetzt, sondern durch vier, unterteilt danach, was der Code verändern darf, statt wo im Warenkorb er läuft.
Discount Function API
Geld sparen. Produktrabatte, Bestellrabatte und Versandrabatte leben jetzt alle hier, in einer einzigen, einheitlichen API. Wenn Ihr Script einen Preis verändert hat, gehört es hierher.
Shopifys DokumentationDelivery Customization API
Versandoptionen ausblenden, umbenennen und neu anordnen. Shopify stellt ausdrücklich klar, dass dies die einzige API ist, die Versandoptionen an der Kasse anpassen kann, sodass eine Rabatt-App sie unabhängig von ihrer Bauart nicht erreichen kann.
Shopifys DokumentationPayment Customization API
Zahlungsmethoden ausblenden, umbenennen und neu anordnen, dazu Zahlungsbedingungen und ob eine Bestellung geprüft werden muss. Die Zahlungshälfte des alten Script Editors an einem Ort.
Shopifys DokumentationCart and Checkout Validation API
Die Kasse mit einer Meldung blockieren. Kauflimits, Altersprüfungen und Mindestbestellregeln landen hier. Sie gibt Fehler zurück, kann also eine Bestellung stoppen, aber keine stillschweigend verändern.
Shopifys DokumentationStackable ist eine Discount Function App, und nur das. Wir bauen Discount Functions, also können wir alles neu aufbauen, was Ihr Script an einem Preis verändert hat, einschließlich Versandrabatten. Wir liefern keine Delivery Customization, keine Payment Customization und keine Validation Function, daher lehnen wir das Ausblenden eines Versandtarifs, das Umbenennen einer Zahlungsmethode oder das Begrenzen einer Kaufmenge nicht ab, weil wir es nicht gebaut haben. Es ist einfach eine andere Art von App.
Setzt man beide Hälften zusammen, ergibt sich der Satz, den Händler oft schmerzhaft selbst herausfinden: Aus einem Script werden oft drei Migrationen. Ein Line-Item-Script, das zusätzlich einen Versandtarif ausgeblendet und eine Zahlungsmethode blockiert hat, ist jetzt eine Discount Function, eine Delivery Customization und eine Payment Customization, jede für sich geschrieben und bereitgestellt. Wir möchten lieber, dass Sie das hier lesen, als es erst nach dem Neuaufbau zu entdecken.
Ein Versand-Script ansehen, das sich als gar kein Rabatt entpupptFunctions sind pur, und jedes Feld wird vorab deklariert
Ein Script lief als gewöhnliches Ruby gegen das, was der Warenkorb gerade enthielt. Eine Function läuft in einer Sandbox, und Shopify garantiert, dass ihr Folgendes fehlt:
- Kein Netzwerk. Eine Function kann während des Checkouts weder Ihr ERP noch Ihren Treueprogramm-Anbieter noch einen anderen Dienst aufrufen.
- Keine Uhr. Eine Function kann nicht abfragen, wie spät es ist, daher muss aus "halber Preis dienstags" ein geplanter Rabatt werden statt einer Bedingung im Code.
- Kein Zufall. Nichts kann für jeden zehnten Kunden würfeln.
- Kein Dateisystem, und kein Zugriff auf ein Feld, das nicht angefragt wurde. Jedes Datenfeld, das eine Function liest, muss vorab in einer Input-Query benannt werden, und diese Query hat eine feste, von Shopify festgelegte Kostenobergrenze.
Diese letzte Regel kostet Händler am meisten, und es lohnt sich, genau zu sagen, wen sie was kostet. Shopify verbirgt die Daten nicht. Unsere eigene Checkout-Query liegt bereits an der von Shopify erlaubten Kostenobergrenze, ein weiteres Feld anzufragen bedeutet also, ein anderes aufzugeben. Neun der Script-Muster, die wir heute ablehnen, lehnen wir genau aus diesem Grund ab und aus keinem anderen, darunter das Überspringen bereits reduzierter Artikel, das Auslesen einer Provinz oder Postleitzahl und die Prüfung, wie viele Bestellungen ein Kunde bereits aufgegeben hat. Shopify bietet jedes einzelne davon an. Wir haben dafür bislang keinen Platz geschaffen. Das ist unsere Lücke, und sie als Plattform-Limit zu bezeichnen wäre gelogen.
Nur zwei Ablehnungen in der gesamten Bibliothek sind echte Shopify-Limits, und beide beruhen auf derselben Tatsache: Alle Discount Functions eines Shops laufen im selben Moment, und keine kann sehen, was die andere getan hat. Ein Script, das fragte "Wurde dieser Artikel bereits rabattiert?" oder das einen Schwellenwert gegen eine bereits reduzierte Zwischensumme prüfte, kann deshalb weder von uns noch von irgendjemand anderem heute zu irgendeinem Preis neu aufgebaut werden. Alles andere auf unserer Ablehnungsliste liegt in unserer Verantwortung, das zu beheben, und so kennzeichnen wir es auch in der App und auf jeder Seite der Bibliothek.
Die zwei Ablehnungen lesen, die wirklich Shopify-Limits sindEinen Preis festzusetzen ist nicht dasselbe wie Geld abzuziehen
Wenn Sie vor dem manuellen Neuaufbau eines Scripts nur eines lesen, dann dieses. Zwei Dateien können dieselbe Methode mit derselben Konstante und derselben Meldung aufrufen und trotzdem das Gegenteil bedeuten. Beide der folgenden Beispiele sind real, beide sind häufig, und der Unterschied zwischen ihnen ist ein Minuszeichen.
Dies SETZT den Preis auf $9.99
FIXED_PRICE = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
line_item.change_line_price(FIXED_PRICE * line_item.quantity, message: "Clearance $9.99 each")
end
Output.cart = Input.cartBei einem Artikel für $79.00 beträgt der Rabatt $69.01, und der Kunde zahlt $9.99. Neu aufgebaut als Mengenangebot mit der Prämie Festpreis, gezählt pro Variante und wiederholend, sodass jede Einheit neu bepreist wird.
Das durchgerechnete Beispiel mit Warenkorb und EinstellungenDies zieht $9.99 AB
DISCOUNT = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
new_price = line_item.line_price - (DISCOUNT * line_item.quantity)
line_item.change_line_price(new_price, message: "$9.99 off each")
end
Output.cart = Input.cartBei demselben Artikel für $79.00 beträgt der Rabatt $9.99, und der Kunde zahlt $69.01. Neu aufgebaut als Mengenangebot mit der Prämie Rabattbetrag pro Einheit, gezählt pro Produkt und nur einmal ausgelöst.
Das durchgerechnete Beispiel mit Warenkorb und EinstellungenGleiche Methode, gleiche $9.99, gleicher Wortlaut in der Meldung. Der einzige Hinweis: Die zweite Datei zieht vor der Zuweisung etwas von `line_item.line_price` ab. Lesen Sie es bei einem Artikel für $79.00 falsch herum, liegen Sie um $59.02 pro Einheit daneben, egal in welche Richtung es wehtut. Und die beiden Neuaufbauten unterscheiden sich nicht nur im Betrag: Der eine zählt pro Variante und wiederholt sich, der andere zählt pro Produkt und löst nur einmal aus, sodass sie auch auseinanderlaufen, sobald der Kunde zwei Stück kauft.
Das ist der Fehler, den der übliche Rat nicht erkennt. Ein neu aufgebautes Angebot, das die Datei falsch herum liest, löst bei einem Warenkorb, der es auslösen soll, trotzdem aus und bleibt bei einem, der es nicht soll, trotzdem still, der Test in beide Richtungen lässt es also durchgehen. Scripts Rescue schließt diese Lücke, indem es eine andere Frage stellt: Bevor es Sie veröffentlichen lässt, will es den Betrag wissen, den Ihr altes Script für einen Warenkorb berechnet hat, den Sie noch nachbilden können, und vergleicht ihn mit dem, was das neu aufgebaute Angebot berechnet. Schon ein Cent Abweichung, und die Veröffentlichung bleibt gesperrt. Von den fünf Apps, die heute Scripts-Migrationen anbieten, hat unsere Recherche keine einzige gefunden, die einen Händler auffordert, das Geld zu belegen.
Was aus jedem Stück Ruby in einer Kampagne wird
Ein Neuaufbau geht immer an denselben wenigen Stellen schief, und das sind fast nie die offensichtlichen. Die Prämie ist meist einfach. Bei der Zählweise und der Wiederholung verschiebt sich das Geld unbemerkt, denn ein Script drückt sie in Arithmetik aus, eine Kampagne in einer Einstellung.
| In Ihrem Script | In einer Kampagne | Wo es schiefgeht |
|---|---|---|
change_line_price(PRICE * qty) | Ein Mengenangebot mit der Prämie Festpreis. | Zuweisung, keine Subtraktion. Das ist die Falle von oben. Der Einzelpreis wird zur Konstante, sodass ein Artikel für $79 für $9.99 verkauft wird. |
line_price - (AMOUNT * qty) | Ein Mengenangebot mit der Prämie Rabattbetrag pro Einheit. | Die Subtraktion ist das ganze Signal. Gleiche Konstante wie in der Zeile darüber, aber eine völlig andere Rechnung. |
line_price * 0.9 | Eine prozentuale Prämie von 10. | Der Multiplikator gibt an, was der Kunde behält, nicht was er spart. Direkt als 90 eingetragen verschenkt er neun Zehntel des Katalogs. |
next unless line_item.quantity >= 3 | Eine Staffel mit einer Mindestmenge von 3. | Staffeln sind an der Grenze inklusiv, und es löst immer nur die höchste erfüllte Staffel aus. Scripts, die eine Regel auf eine andere gestapelt haben, haben keine Entsprechung in einem einzigen Angebot und brauchen jeweils ein eigenes. |
line_items.size > 1 | Eine Mindestmenge von 2. | Nicht dieselbe Regel. Scripts zählten hier getrennte Warenkorbzeilen, Kampagnen zählen Einheiten, sodass eine Zeile mit zwei gleichen Artikeln jetzt qualifiziert, wo das Script sie ignoriert hätte. |
sets = quantity / (BUY + GET) | Kaufe X, erhalte Y, wobei die Gratiseinheiten als zusätzlich gezählt werden. | Teilt man stattdessen nur durch BUY, werden die Gratiseinheiten inklusiv gezählt. Bei neun Einheiten eines Kaufe-3-erhalte-1-Angebots sind das zwei oder drei Gratiseinheiten. Ein Zeichen Unterschied, die Hälfte mehr verschenkt. |
customer.tags.include?("vip") | Kundenberechtigung, begrenzt auf Tags. | Shopify vergleicht Tags exakt, Großbuchstaben eingeschlossen, während viele Script-Varianten vorher beide Seiten kleingeschrieben haben. Prüfen Sie die Schreibweise vor der Veröffentlichung, nicht danach. |
product.tags / product_type / vendor | Zielbereich auf Tags, Produkttypen oder Anbieter eingestellt. | Eine übersehene Zielbereich-Zeile ist der teuerste Fehler in dieser Tabelle, denn sie macht aus "20 % auf den Sale-Tag" ein "20 % auf alles, was Sie verkaufen". |
Eine Sache, die Sie in dieser Tabelle nicht finden, sind Kollektionen. Ein Script konnte die Tags, den Typ und den Anbieter eines Produkts auslesen, aber nie seine Kollektionen. Jedes Ruby, das vorgab, eine Kollektion zu prüfen, tat also nicht das, wonach es aussah. Kampagnen können Kollektionen als Ziel verwenden, Ihr altes Script konnte das nicht.
Schlagen Sie Ihr Script nach, statt es zu erraten
Jedes von uns katalogisierte Script-Muster hat eine eigene Seite: das originale Ruby, wie es erkannt wird, die genaue Konfiguration, zu der es wird, einen Warenkorb aus unserem öffentlichen Demo-Shop mit dem Rabatt, den die echte Engine dafür berechnet, und den Warenkorb, der still bleiben muss. Die Ablehnungen sind genauso ausformuliert, jede gekennzeichnet als Shopify-Limit, unsere eigene Lücke oder eine Aufgabe für eine andere Art von App. Es ist die Referenz, die wir uns zu Beginn gewünscht hätten, deshalb ist sie öffentlich.
- Script-Formen
- 42
- Heute nachgebaut
- 38
- Abgelehnt, mit Grund
- 21
Eine ehrliche Antwort zum Umfang
Stackable rekonstruiert regelbasierte Rabattlogik auf nativen Shopify Functions. Es führt keinen beliebigen individuellen Code aus.
Das rekonstruiert Stackable
- Gestaffelte / Mengenrabatte (z. B. "ab 3 Stück 15 % sparen")
- Buy-X-Get-Y- und BOGO-Logik, einschließlich wiederholbarer Staffeln
- Explizite Regeln zur Rabattkombination zwischen Angeboten
- Geplanter Start, geplantes Ende und sofortige Pausierung für jede Kampagne
Dafür brauchen Sie weiterhin einen Entwickler
- Beliebiger individueller Code, den Ihr altes Script ausgeführt hat (maßgeschneiderte Preisformeln, einmalige Bedingungen, die kein Baukasten abdeckt)
- Versand-/Lieferanpassungen (ein separater Function-Typ)
- Zahlungsanpassungen (ein separater Function-Typ)
- Alles, was sich nicht auf eine regelbasierte Rabattkonfiguration reduzieren lässt
Wenn Ihr altes Script etwas aus dieser Liste tat, kann ein No-Code-Builder, Stackable eingeschlossen, das nicht erreichen. Das ist eine von einem Entwickler geschriebene Function, kein Konfigurationsbildschirm.
Häufige Fragen
Sind meine alten Scripts verloren?
Scripts wurden am 30. Juni 2026 eingestellt, das ist jedoch nicht zwangsläufig derselbe Zeitpunkt, an dem der im Script Editor gespeicherte Quellcode gelöscht wird. Exportieren oder kopieren Sie Ihren alten Script-Code trotzdem jetzt: Sobald Shopify den Editor vollständig abschaltet, ist er nicht mehr wiederherstellbar.
Erhalte ich eine Fehlermeldung, wenn eine Function falsch konfiguriert ist?
Nein. Eine Function, deren Bedingungen nicht auf einen Warenkorb zutreffen, wird einfach nie ausgelöst, stillschweigend, ohne Fehlermeldung und ohne Hinweis. Testen Sie immer mit einem Warenkorb, der sie auslösen soll, und einem, der es nicht soll, bevor Sie ihr im Produktivbetrieb vertrauen.
Ersetzt Stackable alles, was mein altes Script konnte?
Nur den regelbasierten Teil: gestaffelte Rabatte und Mengenrabatte, BOGO, Rabattkombination und Terminierung, alles neu aufgebaut auf nativen Shopify Functions. Stackable führt keinen beliebigen individuellen Code aus. Wenn Ihr Script etwas wirklich Maßgeschneidertes getan hat, eine individuelle Preisformel oder eine Bedingung, die kein Baukasten abdeckt, benötigen Sie weiterhin einen Entwickler, der die Function direkt schreibt.
Was ist mit der Versand- oder Zahlungslogik, die mein Script übernommen hat?
Das sind separate Function-Typen (Versand und Zahlung), die Stackable nicht berührt. Diese müssen von einem Entwickler unabhängig von Ihrer Rabattlogik migriert werden.
Auf welchem Plan ist Scripts Rescue enthalten?
Scripts Rescue, das Tool, das Ihr altes Ruby liest und neu aufbaut, ist im Pro-Plan enthalten. Stackable selbst ist kostenlos installierbar, und die zentrale Rabatt-Engine, einschließlich Mengenstaffeln, Kaufe X, erhalte Y, Ausgabenzielen, kostenlosem Versand, Terminierung und dem Simulator, ist in jedem Plan kostenlos. Nur die Ruby-Rettung nicht: Sie ist zusammen mit Multi-Store und Shopify Flow im Pro-Plan enthalten.
Woher weiß ich, dass der neu aufgebaute Rabatt genauso viel berechnet wie der alte?
Weil Sie es beweisen müssen, bevor Sie veröffentlichen können. Einen Warenkorb zu testen, der auslösen soll, und einen, der es nicht soll, ist der übliche Rat, und er erkennt den schlimmsten Fehler nicht: ein Angebot, das korrekt auslöst, aber den falschen Betrag berechnet. Scripts Rescue fragt Sie nach dem Betrag, den Ihr altes Script für einen Warenkorb berechnet hat, den Sie noch nachbilden können, vergleicht ihn mit dem, was das neu aufgebaute Angebot berechnet, und hält die Veröffentlichung gesperrt, bis beide Beträge auf den Cent genau übereinstimmen. Unsere Recherche unter den fünf Apps, die Scripts-Migrationen anbieten, hat keine gefunden, die das verlangt.
Warum sah mein Script so kompliziert aus?
Weil immer nur ein Script pro Typ veröffentlicht sein konnte. Ein Shop mit vier Aktionen konnte nicht vier Scripts schreiben, also schrieb er eine Datei, in der alle vier zusammengeführt waren, mit einer Regel am Ende, die entschied, welche gewann. Die meisten unleserlich wirkenden Ruby-Dateien sind eigentlich mehrere einfache Regeln, die sich einen Slot teilen, und jede davon lässt sich für sich genommen meist sauber neu aufbauen.
Wo finde ich die vollständige Migrationsanleitung?
Unser erster Blogbeitrag erläutert die Einstellung von Scripts und den Migrationspfad im Detail, und die Script-Beispielbibliothek hat für jedes Script-Muster eine eigene Seite mit dem originalen Ruby und dem genauen Neuaufbau.
Verwandte Funktionen
Discount Stacking
How to stack discounts in Shopify comes down to settings the platform hides by default: every discount belongs to a class (product, order, or shipping), and whether two discounts combine is decided per offer, per class. Stackable puts those combine switches on every offer, so a volume tier, a spend goal, and free shipping add up exactly the way you configured them, every time.
BOGO / Buy X Get Y
Running BOGO beyond the 100-product cap isn't possible with Shopify's native Buy X Get Y discount: it stops letting you add eligible products once you pass 100, and it only applies once per order. Stackable removes both limits and adds cheapest-item-free logic on top.
Scheduled Sales
Shopify scheduled sales fail two ways in the wild: campaigns that silently never start, and live campaigns with no pause button. Stackable's scheduler runs on the same reliability guarantee as its checkout math, and pausing takes effect storefront-wide in under a minute.
Installieren Sie Stackable und rekonstruieren Sie Ihre regelbasierten Rabatte
Mengenstaffeln, BOGO, Stapelung und Planung, laufend auf nativen Shopify Functions vom ersten Tag an.
Scripts Rescue ist im Pro-Plan enthalten. Stackable selbst ist kostenlos installierbar, keine Kreditkarte erforderlich.