Von Swell zu einem eigenen Shop wechseln

Die Mail, mit der ein Swell Umzug beginnt

Die Nachricht kommt meistens von einer Gründerin, die genau weiß, wie ihr Shop funktioniert. Sie hat sich bewusst für Swell entschieden, einen eigenen Storefront gegen dessen API gebaut und läuft seit ein paar Jahren darauf. Die Klage ist selten, dass Swell schlecht wäre. Es ist, dass der Shop zu zwei Systemen geworden ist, die ein Vertrag zusammenhält: ein Storefront, der dem Unternehmen gehört, und ein Commerce Backend, das es mietet, jedes mit eigener Rechnung, eigener Roadmap und eigenen Leuten, die es verstehen. Die Frage in der Mail ist, ob das alles in einer Anwendung leben könnte, die dem Unternehmen selbst gehört, gebaut auf demselben Web Framework, das das Storefront Team ohnehin mag.

Das ist eine faire Frage, und die ehrliche Antwort lautet nicht immer ja. Swell ist eine fähige moderne Plattform, und viele Shops tun gut daran, zu bleiben. Dieser Artikel ist für das Unternehmen, das aus diesem Arrangement herausgewachsen ist und stattdessen eine einzige eigene Rails Anwendung will, und er versucht, genau zu sein bei dem, was ein Wechsel wirklich bedeutet. Für die Konzepte, die für jede Migration gelten, verweise ich auf die tiefen Leitfäden, statt sie zu wiederholen. Zuerst zu lesen ist was sich überträgt und was nicht.

Was Swell ist, und wer bleiben sollte

Swell ist eine headless Commerce Plattform. Du bekommst eine gehostete Datenbank mit den gängigen Ecommerce Modellen, ein Admin Dashboard und eine API, und den Storefront für die Kundschaft überlässt dir Swell.¹ Diesen Storefront baust du selbst, üblicherweise als eigene Frontend Anwendung, die mit Swell über dessen API spricht, und Swell betreibt das Commerce Backend auf eigener Infrastruktur, sodass du nie eine Datenbank oder einen Server dafür betreibst.¹ Das ist ein sinnvolles Modell. Es passt zu einem Team, das vorne die Kontrolle über eigenen Code will, ohne hinten die Arbeit, die Commerce Engine selbst zu betreiben.

Vor jedem Migrationsdetail also die Frage, wer nicht wechseln sollte. Wenn du zufrieden einen eigenen Storefront gegen ein gehostetes Backend betreibst, wenn dein Katalog und deine Regeln ohne Kampf in Swells Datenmodell passen und wenn die monatliche Rechnung in deiner jetzigen Größe angenehm ist, dann macht Swell seinen Job und eine Migration wäre Aufwand, um am selben Punkt anzukommen. Die headless Trennung ist für dich ein Vorteil, keine Last.

Das Unternehmen, für das dieser Artikel geschrieben ist, ist jenes, für das diese Trennung zur Last geworden ist. Es will eine Anwendung, ein Deployment, eine Codebasis und einen Verantwortlichen für das Ganze, statt einen Storefront an einer Stelle und eine Commerce Plattform, in die es nicht hineinsehen kann, an einer anderen. Oft läuft der Storefront schon in Ruby on Rails oder soll es, und Solidus, ein quelloffenes Commerce Framework auf Rails,² lässt Katalog, Checkout, Admin und Storefront ein einziges eigenes Ding sein. Der Hebel hier ist Passung und Eigentum, keine Rettung. Du kommst an deine Daten. Die Frage ist, ob dir der ganze Stack als Eigentum den Aufbau wert ist.

Was dir gehört und was auf Swells Infrastruktur liegt

Zieh die Linie klar, bevor du irgendetwas planst.

Dir gehört dein Storefront Code, weil du ihn geschrieben hast. Dir gehören deine Domain, dein Design und deine Inhalte. Dir gehören deine Daten in dem praktischen Sinn, dass die API sie dir vollständig zurückgibt. Was dir nicht gehört, ist der Ort, an dem sie liegen. Die Datenbank, die Commerce Logik, das Admin, der Kartenspeicher und die API, die das alles bedient, laufen auf Swells Infrastruktur, und dein Storefront hängt davon ab, dass diese Infrastruktur läuft und jedes Mal antwortet, wenn Kundschaft eine Seite lädt.¹ Diese Abhängigkeit ändert ein Umzug. Danach liegen die Daten in deiner eigenen Postgres Datenbank, in deiner eigenen Anwendung, auf Hosting, das du kontrollierst.

Was du mitnimmst	Wie es Swell verlässt	Wo es in Solidus landet
Produkte, Varianten, Kategorien, Attribute, Bilder	Backend API Lesen je Modell	Produkte, Varianten, Option Types, Taxons
Kundenkonten und Adressen	Backend API Lesen des Accounts Modells	Users und Adressen, ohne Passwörter
Bestell und Kaufhistorie	Backend API Lesen des Orders Modells	Bestellungen als nur lesbare Historie
Abonnements	Backend API Lesen plus Mitwirkung des Gateways	Solidus Abo Setup, neu auf dein Gateway verankert
Gespeicherte Karten	liegen in Swells Speicher, Transfer Gateway zu Gateway	Speicher deines eigenen Gateways
Der Storefront	gehört dir als Code bereits	neu gebaut oder gegen Solidus weiterverwendet

Hinter jeder Zeile, die Daten bewegt, steht ein tiefer Leitfaden: Kundenkonten und Adressen, Produkt und Katalogdaten, Bestell und Kaufhistorie, Zahlungstoken und gespeicherte Karten und Abonnements und wiederkehrende Zahlungen. Deren Mechanik erkläre ich hier nicht neu. Der Zweck dieses Artikels ist das, was spezifisch für Swell ist.

Export und API in der Realität

Swell sperrt deine Daten nicht weg, und das gehört klar gesagt, weil der ehrliche Hebel keine Daten Geiselnahme ist. Der Weg hinaus ist die Backend API. Sie gibt vollen Zugriff auf jedes Modell im Shop, sie ist eine schlichte REST Schnittstelle, die JSON annimmt und zurückgibt, unter der Basis https://api.swell.store, und es gibt offizielle Bibliotheken für Node und PHP.³ Die Standardmodelle decken die Commerce Objekte ab, die du erwartest, Produkte und Bestellungen darunter, und jedes eigene Modell, das du hinzugefügt hast, erscheint über dieselbe Schnittstelle, weil Swell die Endpunkte aus den Modelldefinitionen erzeugt.⁴ Du kannst auch das Schema selbst lesen, Modell für Modell, sodass ein Migrationsskript jedes Feld entdeckt, das du je hinzugefügt hast, statt zu raten.⁴

Dieser letzte Punkt zählt bei Swell mehr als bei einer starren Plattform. Swell lässt dich das Datenmodell erweitern: Du kannst Felder zu den Standardmodellen hinzufügen oder neue Modelle im Dashboard unter Developer und dann Models definieren, und installierte Apps haben vielleicht eigene hinzugefügt.⁴ Ein Produkt in deinem Swell Shop ist also kein generisches Produkt. Es kann Felder tragen, die es nur in deinem Shop gibt, und die Migration muss sie finden, verstehen, was jedes bedeutet, und entscheiden, wohin es im Solidus Modell gehört. Das Schema zu lesen ist die Art, wie du vermeidest, ein Feld stillschweigend fallen zu lassen, auf das sich das Geschäft stützt.

Zwei Grenzen sind einzuplanen. Die erste: Der Export ist ein API Lesen, kein einzelner Download Knopf, also ist die Migration eine Reihe von Skripten, die sich durch jedes Modell blättern, kein Nachmittag mit einer Tabelle. Die zweite ist das Rate Limit. Die Backend API ist pro Shop und getrennt pro Umgebung begrenzt, über Durchsatz und Gleichzeitigkeit, und Anfragen werden gewichtet statt eins zu eins gezählt, sodass eine Aggregation oder eine stark erweiterte Abfrage mehr kostet als ein schlichtes Lesen.⁵ Gehst du darüber, werden Anfragen eingereiht statt abgewiesen, und nur eine Anfrage, die länger als 60 Sekunden wartet, fällt mit einem HTTP 429 heraus.⁵ In der Praxis heißt das, der volle Export läuft als getaktete, fortsetzbare Aufgabe, die in Stapeln liest und keinen großen Katalog in einem Schub ziehen will. Leichte Lesezugriffe auf Produkte, Varianten, Kategorien, Attribute, Konten, Warenkörbe und Inhalte ziehen aus einem eigenen Topf, was hilft, aber der vernünftige Plan bleibt, den Export auf einer Kopie zu proben und ihn so lange dauern zu lassen, wie er dauert.⁵

Der Preis, der mit dir mitwächst

Das klarste Eigentumsargument für einen wachsenden Swell Shop steht auf der Preisseite. Swells Pläne reichen von Starter mit 29 USD im Monat bis Unlimited mit 2.250 USD im Monat, und jeder Plan hat zwei Dinge, die ein gemietetes Backend gern hat: eine jährliche Umsatzgrenze und einen Zähler.⁶

Die Grenze ist eine Zahl an Jahresumsatz, von 50.000 USD im Einstiegsplan bis 5 Millionen USD bei Unlimited, und Umsatz über der Grenze deines Plans wird mit einem Prozentsatz belegt, von 2 % im kleinsten Plan hinunter bis 0,4 % im größten.⁶ Das ist keine Transaktionsgebühr je Bestellung, und Swell sagt klar, dass es bei Zahlungen über ein externes Gateway keinen Anteil nimmt, aber es bedeutet, dass die Plattformkosten daran hängen, wie viel du verkaufst, also genau an der Linie, die ein Shop wachsen lassen will. Der Zähler sitzt auf der API selbst: Jeder Plan enthält ein monatliches Kontingent an API Anfragen, von 100.000 bis 2 Millionen, und Anfragen darüber kosten 5 USD je weitere 100.000, mit ähnlicher Mehrnutzung bei Funktionsaufrufen und Speicher.⁶ Für einen headless Shop ist das eine lebendige Zahl, weil dein eigener Storefront jene Anfragen bei jedem Seitenaufruf und jeder Suche stellt.

Nichts davon ist versteckt oder unfair, und in kleiner Größe ist es wenig. Der Punkt ist nur, dass es mit deinem Erfolg mitwächst statt mit deinen Kosten. Ein eigener Solidus Shop dreht diese Form um: höhere Baukosten am Anfang, dann Hosting und Wartung, die der Arbeit folgen, nicht dem Umsatz, ohne Lizenz und ohne Prozentsatz über einer Grenze.² Die volle Rechnung über fünf Jahre, mit durchgerechneten Zahlen, steht in den Gesamtkosten über fünf Jahre, und der Vergleich Plattform für Plattform in dem Vergleichsartikel.

Der Kartenspeicher ist der harte Teil, wie immer

Swell betreibt einen eigenen Kartenspeicher. Wenn jemand eine Karte speichert, tokenisiert Swell sie und legt die verschlüsselten Daten in diesem Speicher ab, und der Token hängt am Kundenkonto.⁷ Das ist ein wirklich gutes Design, solange du auf Swell bist, denn es bedeutet, dass du das Zahlungsgateway wechseln kannst, ohne dass die Kundschaft die Karten neu eingibt, und es ist das, was Swell Abonnements gegen jedes Gateway laufen lässt, das gespeicherte Karten unterstützt.⁷ Es ist zugleich das Eine, das vor dem Weggehen am meisten Planung braucht.

Die Feinheit lohnt sich richtig zu fassen, denn hier zählen Fairness und Genauigkeit am meisten. Der Speicher ist innerhalb von Swell zwischen Gateways beweglich, aber es ist Swells Speicher. Ganz von Swell weg zu gehen heißt, diese gespeicherten Karten in einen Speicher zu bringen, den du kontrollierst, und rohe Kartennummern reisen nie in einem Migrationsskript. Wenn dein Swell Shop schon über dein eigenes Gateway Konto abrechnet, liegen die gespeicherten Karten vielleicht bereits im Speicher dieses Gateways, dann verbindet sich der Solidus Shop mit demselben Konto und die Karten bleiben genau dort. Liegen sie in Swells Speicher, bist du bei einem Transfer von Gateway zu Gateway, den der empfangende Abwickler nur von einem annimmt, der nach PCI DSS Level 1 zertifiziert ist, und der weder Abonnements noch Zahlungshistorie mitträgt.⁸ Die tiefe Fassung davon, mit den Fragen, die du dem Gateway zuerst stellst, steht in dem Leitfaden zu Zahlungstoken. Markiere es in Woche eins, nicht in Woche zehn.

Abonnements liegen direkt daneben, weil Swells wiederkehrende Abrechnung von der gespeicherten Karte abhängt.⁷ Ein Abo ist nicht bloß eine Zeile, die monatlich sagt. Es ist eine lebende Abrechnungsvereinbarung mit einem nächsten Buchungstermin, einem Zeitplan und einer hinterlegten Zahlungsart, und es nimmt weiter Geld, während du umziehst. Du trägst die Zeitpläne und die Kundenabsicht hinüber, verankerst jedes Abo neu auf dem Gateway, über das der Solidus Shop abrechnet, und wählst einen Umzug, der nicht mitten in einen Abrechnungslauf fällt. Der Leitfaden zu Abonnements deckt die Mechanik ab. Ist dein Shop abogetrieben, entscheidet dieser Teil den Zeitplan.

Storefront, SEO und Weiterleitungen

Hier ist ein Swell Umzug leichter als das Verlassen eines geschlossenen Baukastens, und das sage ich gern. Weil Swell headless ist, gehört dir der Storefront bereits und gehören dir die URLs bereits. Es gibt kein Theme, das in einer Plattformsprache eingeschlossen ist und entwirrt werden muss, und dein Frontend Code lässt sich oft gegen Solidus weiterverwenden, mit der darunter getauschten Datenschicht, statt von null neu gebaut. Das ist eine echte Ersparnis, und einer der Gründe, warum ein Wechsel von Swell zu Solidus sauberer sein kann, als er klingt.

Die Kehrseite ist, dass SEO auf Swell immer dein Job war und auf Solidus dein Job bleibt. Die Plattform besaß deine URL Struktur nicht, es gibt also kein anbieterspezifisches Pfadschema zu übersetzen, aber jede Adresse, die dein Storefront veröffentlicht, muss nach dem Umzug auflösen. Bilde jede alte URL auf ihre neue ab, nutze dauerhafte serverseitige Weiterleitungen direkt zum Ziel statt über eine Kette, und halte sie mindestens ein Jahr.⁹ Bei einem headless Aufbau ist die Weiterleitungsliste meist kleiner und sauberer als bei einer Template Plattform, weil du die URLs selbst gewählt hast, aber eine fehlende Zeile ist trotzdem eine Seite, die am Umschalttag einen 404 liefert. Produkt URLs und kanonische Behandlung tragen das Detail in dem Leitfaden zu Produktdaten.

Eine Zeile gehört noch hierher. Kundendaten zu verschieben braucht keine frische Einwilligung von jeder Person, aber der Shop bleibt Verantwortlicher dieser Daten, und jeder Auftragsverarbeiter, die alte Plattform, der neue Host und der Entwickler, braucht einen schriftlichen Vertrag nach Artikel 28.¹⁰ Trage Marketingeinwilligungen mit ihrem Zeitstempel und Wortlaut hinüber statt als bloßes Ja oder Nein, und bitte Swell nach dem letzten Export schriftlich, die alte Kopie zu löschen. Wer was hält und warum Eigentum am Stack die Antwort ändert, ist das Thema von wem deine Geschäftsdaten gehören.

Ein durchgerechnetes Beispiel: eine Grazer Kaffee Marke zieht auf Solidus

Murtal Kaffeerösterei (murtalkaffee.example) ist ein erfundenes Grazer Unternehmen, das Kaffee im Abo röstet und versendet. Es macht rund 1,2 Millionen Euro Umsatz im Jahr, hat etwa 400 Produkte, sobald Mahlgrade und Packungsgrößen als Varianten zählen, und betreibt grob 3.000 aktive Abos in wöchentlichen, zweiwöchentlichen und monatlichen Takten. Vor zwei Jahren hat die Gründerin einen schnellen eigenen Storefront gebaut und Swell dahinter gesetzt, was damals richtig war. Heute will das Unternehmen, dass seine Röstereisoftware, seine Großhandelsbestellungen und sein Abo Shop eine Rails Anwendung sind, die der eigene Entwickler besitzt, und es ist müde, über ein Backend nachzudenken, dessen Quellcode es nicht lesen kann.

Der Umzug beginnt mit den Fragen, die teuer sind, wenn man sie falsch macht, und bei diesem Shop drehen sie sich alle um Geld in Bewegung. In Woche eins stelle ich fest, wo die gespeicherten Karten tatsächlich liegen. Murtal rechnet über das eigene Gateway Konto ab, die Karten liegen also im Speicher des Gateways, nicht in Swells Speicher gestrandet, was das härteste Problem in eine Verbindung statt einen Transfer verwandelt.⁷⁸ Dann die Abonnements: Ich lese jedes Abo über die Backend API mit seinem Zeitplan, seinem nächsten Buchungstermin und der Person, zu der es gehört, und plane den Umzug in das ruhigste Fenster des Abrechnungskalenders, sodass niemand doppelt belastet und niemand übersehen wird.⁵

Katalog und Kundschaft sind der ruhige Teil. Eine getaktete Reihe von Skripten liest Produkte, Varianten, Kategorien und die eigenen Felder, die Murtal für Röstdatum und Herkunft angelegt hat, entdeckt durch das Lesen des Schemas, sodass keines fallen gelassen wird, und schreibt sie als Produkte, Varianten und Option Types in Solidus.⁴ Kundenkonten und Adressen kommen genauso herüber, ohne Passwörter, sodass jede Person bei ihrem ersten Besuch nach dem Start ein Passwort setzt oder sich neu anmeldet. Drei Jahre Bestellungen ziehen als nur lesbare Historie um, damit Support und Kundschaft zurückblicken können, während der volle Export für die Buchhaltung archiviert wird. Der Storefront, bereits der eigene Code des Unternehmens, wird auf Solidus gerichtet, mit neu geschriebener Datenschicht, und das ist der Grund, warum dieser Aufbau Wochen statt Monate dauert.

Der Umzug ist ein ruhiger Dienstagvormittag außerhalb eines Abrechnungslaufs. Die Domain wandert auf die neue Anwendung, die Weiterleitungsliste wird von Hand gegen die wichtigsten Seiten geprüft, eine echte Abo Verlängerung und eine echte Einzelbestellung werden je Zahlungsart ausgeführt und erstattet, und der alte Swell Shop bleibt 30 Tage live und bezahlt als Weg zurück. Einen Monat später, nach einem sauberen Abrechnungszyklus und einem sauberen Monatsabschluss auf Solidus, wird der Swell Plan gekündigt und seine Löschung schriftlich verlangt. Murtal betreibt jetzt eine Anwendung: Rösterei, Großhandel, Abos und Shop, in eigenem Besitz, auf eigenem Hosting, ohne Umsatzgrenze und ohne API Zähler.

Der ehrliche Umzugsplan

Auf seine Form reduziert ist der Plan dieselbe Disziplin, die jede Migration braucht, mit den Swell Besonderheiten eingesetzt.

Entscheide zuerst die Frage zu Zahlungen und Abonnements, weil sie den Zeitplan setzt und der einzige Teil ist, der mit dem Geld der Kundschaft schiefgehen kann. Lies das Schema, bevor du einen Import schreibst, damit die eigenen Felder, die deinen Shop zu deinem machen, nicht still verloren gehen. Lass den Export als getaktete, fortsetzbare Aufgabe laufen, die das Rate Limit achtet, statt gegen es zu kämpfen. Verwende den Storefront weiter, wo du kannst, denn er gehört dir, und tausch die Datenschicht darunter. Bau die Weiterleitungsliste, auch wenn sie kleiner ist als sonst, und teste sie. Behalte drei Jahre Bestellungen, nicht alles. Lass beide Systeme parallel laufen, mit eingefrorenem Katalog, probe den letzten Import zweimal, schalte an einem ruhigen Vormittag außerhalb jedes Abrechnungslaufs um und halte Swell 30 Tage als Rückfall am Leben, bevor du kündigst.

Nichts davon ist einzig für Swell außer dem Schema Lesen, dem ratenbegrenzten Export und der Speicherfrage. Der Rest ist das Handwerk aus dem Pfeiler Leitfaden, und wenn dein Plan keinen Verantwortlichen im Unternehmen hat, der die Daten, die eigenen Felder und die Abonnements versteht, ist es noch kein Plan.

Wann Bleiben auf Swell das Richtige ist

Ich verliere diese Arbeit lieber, als sie dem falschen Shop zu verkaufen, also hier der Rat zu bleiben.

Bleib, wenn die headless Trennung dir hilft statt dich kostet, was für die meisten Shops in den meisten Größen gilt. Bleib, wenn dein Umsatz bequem unter der Grenze deines Plans sitzt und der API Zähler ein Rundungsfehler ist, denn dann ist der Preis, der im Großen wie eine Abgabe wirkt, schlicht eine faire Rechnung. Bleib, wenn dein Team klein ist und der Gedanke, Hosting, Updates und Sicherheit für den ganzen Stack selbst zu tragen, eher Last als Erleichterung ist. Bleib, wenn du eigentlich eine Änderung am Storefront willst, denn die kannst du auf Swell machen, ohne das Backend zu berühren. Eine Migration lohnt sich, wenn dir eine Anwendung von Ende zu Ende als Eigentum mehr wert ist, als der Aufbau kostet, und wenn du die Person benennen kannst, die sie besitzen wird. Kannst du das nicht, übergibt dir der Wechsel einen schönen neuen Shop voller Daten, für die niemand geradesteht.

Der Workshop

Wenn du das abwägst, biete ich einen kostenlosen Workshop an, und die ersten zwei Wochen Arbeit gehen auf mich. Bring deinen Swell Plan und seine aktuelle Rechnung mit, eine Notiz zu den eigenen Feldern und Apps, die du angelegt hast, und ob deine gespeicherten Karten in deinem eigenen Gateway oder in Swells Speicher liegen, und ich gehe mit dir durch, ob dir der ganze Stack als Eigentum etwas bringt. Manchmal bringt er es nicht, und dann sage ich es dir.

Footnotes

1. Swell, Platform overview (eine headless Commerce Plattform mit verwalteter Infrastruktur, einer gehosteten Datenbank mit gängigen Ecommerce Modellen pro Shop, einem Admin Dashboard und Storefronts, die der Händler baut und ausliefert), developers.swell.is, geprüft 14. November 2026, https://developers.swell.is/guides/core-concepts/platform-overview ↩ ↩² ↩³

2. Solidus, solidusio/solidus Repository auf GitHub (ein quelloffenes Commerce Framework auf Ruby on Rails unter der BSD 3 clause Lizenz), https://github.com/solidusio/solidus ↩ ↩²

3. Swell, Backend API introduction (REST Schnittstelle, die JSON annimmt und zurückgibt, unter der Basis https://api.swell.store, mit offiziellen Bibliotheken für Node und PHP), geprüft 14. November 2026, https://developers.swell.is/backend-api/introduction ↩

4. Swell, Backend API data models (voller Zugriff auf jedes Modell im Shop, Standardmodelle wie Produkte und Bestellungen, eigene Modelle unter Developer und dann Models, Modelle, die ein Elternmodell erweitern, und ein als Meta Modell lesbares Schema), geprüft 14. November 2026, https://developers.swell.is/backend-api/data-models ↩ ↩² ↩³ ↩⁴

5. Swell, Backend API rate limits (pro Shop und pro Umgebung begrenzt über Durchsatz und Gleichzeitigkeit, gewichtete Anfragen, Überschuss eingereiht und nach 60 Sekunden mit HTTP 429 verworfen, und ein eigener Topf für leichte Lesezugriffe auf Produkte, Varianten, Kategorien, Attribute, Konten, Warenkörbe, Purchase Links und Inhalte), geprüft 14. November 2026, https://developers.swell.is/backend-api/rate-limits ↩ ↩² ↩³ ↩⁴

6. Swell, Pricing (Pläne von 29 USD bis 2.250 USD im Monat, je mit einer jährlichen Umsatzgrenze von 50.000 USD bis 5 Millionen USD und einem Prozentsatz von 2 % bis 0,4 % auf Umsatz darüber, monatliche API Kontingente von 100.000 bis 2 Millionen und Mehrnutzung von 5 USD je weitere 100.000 API Anfragen), geprüft 14. November 2026, https://www.swell.is/pricing ↩ ↩² ↩³

7. Swell, Payments core concept (ein Speicher für verschlüsselte Kartendaten, Karten tokenisiert und in Swells Speicher abgelegt, mit dem Token am Kundenkonto, die Möglichkeit, Gateways zu wechseln, ohne dass Kundschaft Daten neu eingibt, und wiederkehrende Abrechnung mit jedem Gateway, das gespeicherte Karten unterstützt), geprüft 14. November 2026, https://developers.swell.is/guides/core-concepts/payments ↩ ↩² ↩³ ↩⁴

8. Stripe, Request a payment data export (gespeicherte Kartendaten nur an einen nach PCI DSS Level 1 zertifizierten Abwickler exportiert, und der Export enthält weder Abonnements noch Zahlungshistorie), geprüft 14. November 2026, https://docs.stripe.com/get-started/data-migrations/pan-export ↩ ↩²

9. Google Search Central, Site moves with URL changes (jede alte URL abbilden, dauerhafte Weiterleitungen direkt zum Ziel statt über eine Kette nutzen und sie mindestens ein Jahr halten), https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩

10. Datenschutz Grundverordnung, Artikel 28 (Auftragsverarbeiter), EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679 ↩