Datenschutzerklärung für Kartuu

Kartuu ist eine Shopify-App der KYTH. Systems UG (haftungsbeschränkt). Sie erzeugt aus bezahlten Shopify-Bestellungen personalisierte Geschenkgutscheine als PDF. Die Zustellung an Käufer und Beschenkte läuft über den Mailzugang, den der Händler selbst hinterlegt — nicht über einen Versandweg von KYTH. Siehe Abschnitt 4.2.

Diese Erklärung beschreibt, welche Daten Kartuu verarbeitet. Sie beschreibt den tatsächlichen Stand der Software, nicht das, was irgendwann geplant ist. Wo die App heute weniger tut, als ihre Beschreibung im Shopify App Store vermuten lässt, steht das hier ausdrücklich.

Warum der abgebildete Quelltextstand jünger ist als die Fassung: Fassung 1.1 ist nie ausgeliefert worden und hat deshalb keinen einzigen Zustimmenden — die Begründung steht in Abschnitt 14. Die Kennung bleibt darum unverändert, während der Inhalt dem heutigen Programm nachgeführt wird.

⚠ Hinweis: nicht anwaltlich geprüft

Dieses Dokument wurde aus dem Quelltext und der Betriebsdokumentation von Kartuu erstellt und stellt keine Rechtsberatung dar. Es trägt seit dem 01.08.2026 keine offenen Stellen mehr; was aus dieser Zeit noch nachzuhalten ist, steht in Abschnitt 12.

Vor der Einreichung im Shopify App Store sollte es anwaltlich geprüft werden.

1. Auf einen Blick

• Kartuu speichert Daten Ihrer Kundschaft und der Beschenkten — seit dem Bestellablauf, und das ist neu. Kauft jemand in Ihrem Shop einen Gutschein, meldet Shopify uns die bezahlte Bestellung (orders/paid), und daraus entsteht je gekauftem Stück eine Zeile in der Datenbank: Empfängername, E-Mail-Adresse des Beschenkten, Absendername und Grußtext — verschlüsselt —, dazu die Shopify-Kundennummer des Käufers, Bestell- und Positionskennung, Betrag, Währung und der Gutscheincode, ebenfalls verschlüsselt. Frühere Fassungen dieser Erklärung sagten an dieser Stelle „keine Daten Ihrer Kundschaft, keine Tabelle dafür". Das war für den Stand von damals richtig und ist es seit dem Bestellablauf nicht mehr. Einzelheiten in 5.1 und 6.1.
• Gespeichert wird pro Shop außerdem: die myshopify-Domain, ein Suchhash darüber, die verschlüsselten Shopify-Zugangstoken, der zuletzt bei Shopify gelesene Abonnementstand, einige technische Zeitstempel und — sobald Sie ein Gutscheinprodukt anlegen lassen — dessen Shopify-Produktkennung.
• Der Gutschein-Editor im Adminbereich bleibt daneben bestehen: Was Sie dort selbst eintippen, wird in eine Vorschau und in ein PDF gesetzt und Ihnen zurückgegeben. Davon wird nichts gespeichert.
• Die Datenschutz-Webhooks von Shopify werden vollständig eingelesen und enthalten dabei auch E-Mail-Adresse und Telefonnummer. Ausgewertet werden davon zwei Angaben: die Kundennummer und die E-Mail-Adresse. Die Adresse wird gebraucht, weil ein Beschenkter keine Kundennummer hat — ohne sie wäre eine Löschung für ihn technisch unmöglich. Gespeichert wird der Webhook-Inhalt nicht. Einzelheiten in 6.4.
• Eines wird sehr wohl dauerhaft gespeichert: Bilder, die Sie hochladen. Laden Sie ein Motiv für Ihre Karte hoch — Ihr Logo, ein Produktfoto —, bewahren wir es auf, bis Ihr Shop gelöscht wird. Es ist der einzige Inhalt, den Sie liefern und den wir behalten; alles andere aus dem Gutschein-Editor geht durch und bleibt nicht. Aufnahmedaten in einem Foto entfernen wir nicht — steht ein Standort in einem Handyfoto, bleibt er im Bild und im daraus erzeugten PDF. Einzelheiten in 5.1 und 11.2.
• Kartuu ruft von sich aus zwei fremde Adressen auf, beide bei Ihrem eigenen Shop bei Shopify: den Token-Endpunkt und die Admin-API. Über die Admin-API laufen heute sechs verschiedene Aufrufe: die Frage nach dem Abonnementstand, das Anlegen einer Shopify-Geschenkkarte mit unserem Code, und vier rund um die Einrichtung Ihres Gutscheinprodukts. Bestellungen fragt Kartuu dort nicht ab — die Bestelldaten kommen aus dem Webhook, nicht aus einer Abfrage. Einzelheiten in 4.1 und 7.
• Ihr Browser lädt beim Öffnen der App eine Programmbibliothek direkt von Shopify (cdn.shopify.com). Shopify sieht dabei Ihre IP-Adresse — dieselbe Stelle, die Ihnen ohnehin den Shopify-Adminbereich anzeigt. Einzelheiten in Abschnitt 5.4.
• Bei der Installation fragen wir Sie einmal nach einer E-Mail-Adresse, unter der wir Sie erreichen können, und nach Ihrer Zustimmung zum Auftragsverarbeitungsvertrag. Beides ist Pflicht — ohne Zustimmung wird die App nicht verbunden. Einzelheiten in 5.3.
• Der Mailversand läuft über IHREN Mailserver, nicht über unseren. Sie hinterlegen Ihren SMTP-Zugang in der App; Kartuu liefert die Mail darüber ein. Benutzername und Passwort liegen verschlüsselt in unserer Datenbank und werden nie wieder angezeigt. Hinterlegen Sie nichts, verschickt Kartuu nichts — der Gutschein bleibt abrufbar, und Sie übergeben ihn selbst. Einzelheiten in 4.2.
• Kein Tracking, keine Analytics, keine Cookies, keine Schriftarten oder Symbole von fremden Servern.
• Server und Datenbank stehen in Berlin. Die täglichen Datenbanksicherungen liegen ebenfalls in Berlin, im Objektspeicher der IONOS — und seit der Bildablage liegen dort auch die hochgeladenen Motive, in einem eigenen Eimer. Einzelheiten in 7 und 9.6.

2. Verantwortlicher

KYTH. Systems UG (haftungsbeschränkt) Prof.-Mederer-Straße 4 92348 Berg Deutschland

Vertreten durch die Geschäftsführer Stefan Grasse und Stephan Wittmann Registergericht: Amtsgericht Nürnberg, HRB 46313

Kontakt in Datenschutzfragen: datenschutz@kyth.systems Allgemeiner Kontakt: hello@kyth.systems Telefon: 0157 51603446

Die angegebene Telefonnummer ist die Geschäftsnummer der Gesellschaft; sie wird von der Geschäftsführung persönlich betrieben.

Eine Umsatzsteuer-Identifikationsnummer ist der Gesellschaft bislang nicht erteilt. Für diese Erklärung ist sie kein Pflichtbestandteil; für das Impressum wird sie es, sobald eine vorliegt.

Datenschutzbeauftragter: Ein Datenschutzbeauftragter ist nicht bestellt. Nach § 38 BDSG besteht dazu bei der derzeitigen Unternehmensgröße keine Pflicht. Für alle Anliegen ist die oben genannte Adresse zuständig.

3. Drei Rollen — bitte auseinanderhalten

Diese Erklärung richtet sich an drei Gruppen, und für jede gilt etwas anderes.

Die dritte Spalte umfasst zwei Personen, und das ist seit dem Bestellablauf keine Feinheit mehr: die Person, die den Gutschein gekauft hat, und die Person, für die er bestimmt ist. Von der zweiten speichert Kartuu Name, E-Mail-Adresse und den an sie gerichteten Grußtext — obwohl sie nie etwas bestellt hat und Shopify sie nicht kennt. Für sie gilt dasselbe wie für die Käuferin: Wir sind Auftragsverarbeiter, verantwortlich ist der Shop. Was von ihr verarbeitet wird, steht in 6.1; wie sie zu ihrem Recht kommt, in 10.2.

Wir entscheiden nicht selbst über Zwecke und Mittel der Verarbeitung von Kundendaten eines Shops. Wir setzen um, was der Shop uns aufträgt. Grundlage dafür ist ein Auftragsverarbeitungsvertrag nach Art. 28 Abs. 3 DSGVO, den der Händler mit uns schließt.

Dieser Vertrag liegt als eigenes Dokument vor (Fassung 1.1, Stand 26.07.2026, intern geführt unter der Kennung 1.1-2026-07-26). Er enthält in § 12 eine kurze Liste dessen, was der Händler selbst zu tun hat.

Wie der Vertrag zustande kommt. Beim Verbinden der App im Shopify-Adminbereich zeigen wir Ihnen beide Dokumente — diese Erklärung und den Auftragsverarbeitungsvertrag — und fragen Ihre Zustimmung als bewusste Handlung ab. Ohne Zustimmung wird die App nicht verbunden: Es entsteht kein Datensatz zu Ihrem Shop, und es werden keine Zugangstoken bei Shopify abgeholt. Was wir dabei als Nachweis speichern, steht in 5.3.

Ändert sich einer der beiden Texte inhaltlich, erhöhen wir die Fassungskennung; beim nächsten Öffnen der App werden Sie erneut gefragt. Eine reine Tippfehlerkorrektur führt nicht zu einer neuen Kennung — ein Zustimmungsfenster ohne Anlass entwertet die Zustimmung.

Beide Dokumente liefert die App unter https://kartuu.kyth.systems/rechtliches/ aus (/rechtliches/datenschutz und /rechtliches/auftragsverarbeitung), ohne Anmeldung und in derselben Fassung, der Sie zustimmen. Unabhängig davon erhalten Sie sie jederzeit auf Anfrage an datenschutz@kyth.systems.

Zum Auslieferungsriegel. Die App liefert einen Rechtstext in der Produktivumgebung nur aus, wenn er keine offenen Stellen mehr trägt; andernfalls verweigert sie dort den Start (kaspar/routes/rechtliches.py). Eine Zustimmung zu einem Text, den man nicht lesen kann, wäre unwirksam.

Diese Erklärung und das Impressum sind seit dem 01.08.2026 vollständig. Der Auftragsverarbeitungsvertrag trägt weiterhin offene Stellen und hält den Riegel damit geschlossen — die Produktivumgebung startet also nach wie vor nicht. Was dort noch fehlt, steht in seinem eigenen Schlussabschnitt.

4. Stand der Software — was Kartuu heute wirklich tut

Kartuu befindet sich im Aufbau. Der Funktionsumfang, der in dieser Erklärung beschrieben wird, entspricht dem Quelltext mit Stand 27.07.2026.

Zur Zeitform dieses Dokuments. Wir beschreiben im Präsens ausschließlich das, was das Programm tatsächlich tut. Alles, wozu wir nur berechtigt sind oder was für spätere Ausbaustufen vorgesehen ist, steht ausdrücklich als solches gekennzeichnet daneben — niemals im Präsens. Die Trennung zieht sich durch das ganze Dokument: Abschnitte 5 und 6.1 beschreiben die tatsächliche Verarbeitung, Abschnitt 4.2 zählt auf, was das Programm nicht tut, und Abschnitt 4.3 sagt zu jeder erteilten Berechtigung, ob sie ausgeübt wird.

4.1 Was heute geschieht

Kartuu nimmt Ihre Shop-Domain und Ihre Zustimmung entgegen, holt bei Shopify Zugangstoken ab und erneuert sie, prüft eingehende Webhooks auf ihre Echtheit, bedient die drei von Shopify vorgeschriebenen Datenschutz-Webhooks, liest bei Shopify den Abonnementstand Ihres Shops, nimmt von Ihnen hochgeladene Bildmotive entgegen, prüft sie und bewahrt sie auf, und erzeugt aus Angaben, die Sie im Adminbereich eintippen, eine Vorschau und ein PDF der Gutscheinkarte.

Dazu gekommen ist der Bestellablauf, und er ist die weitreichendste Änderung seit dem ersten Entwurf dieser Erklärung:

• Gutscheinprodukt einrichten. Auf Ihren Klick hin legt Kartuu in Ihrem Shop ein Gutscheinprodukt mit Varianten und Metafeldern an — je einmal für Wert- und für Leistungsgutscheine. Ohne Ihren Klick geschieht das nicht: kein Aufruf bei der Installation, keiner beim ersten Öffnen, keiner im Hintergrund. Ein einmal angelegtes Produkt wird danach nicht mehr verändert.
• Bezahlte Bestellungen entgegennehmen. Kartuu ist auf den Webhook orders/paid abonniert. Trifft eine bezahlte Bestellung mit einer Gutscheinposition ein, entsteht je gekauftem Stück eine Zeile in der Datenbank — drei Gutscheine über je 50 Euro sind drei Zeilen, nicht eine über 150 Euro.
• Die Angaben des Kunden übernehmen. Empfängername, E-Mail-Adresse des Beschenkten, Absendername und Grußtext reisen als Zusatzangaben der Bestellposition mit und werden verschlüsselt gespeichert.
• Eine Shopify-Geschenkkarte anlegen. Bei einem Wertgutschein erzeugt Kartuu einen Gutscheincode und legt damit über die Admin-API eine echte Shopify-Geschenkkarte an. Der Code wird sofort verschlüsselt gespeichert — Shopify gibt ihn genau einmal heraus.
• Die Karte rendern. Aus einem eingefrorenen Abbild der Vorlage und den gespeicherten Werten entsteht das PDF.

Das ist der vollständige Umfang. Einzelheiten in den Abschnitten 5 und 6.1.

4.2 Was heute nicht geschieht

Es gibt im Programm keine Stelle, die

• Bestellungen bei Shopify abruft — die Bestelldaten kommen ausschließlich aus dem Webhook, den Shopify uns zustellt. Über die Admin-API fragt Kartuu weder eine Bestellung noch ein Kundendatenfeld ab; die sechs Aufrufe, die es dort gibt, sind in Abschnitt 7 aufgezählt,
• Guthabenstände von Geschenkkarten liest oder speichert — was auf einer Karte noch drauf ist, führt allein Shopify. Kartuu verwahrt von einer Geschenkkarte nur deren Kennung,
• ein erzeugtes PDF speichert oder aufbewahrt — es entsteht im Arbeitslauf und wird nach dem Rendern verworfen. Aus dem gespeicherten Vorlagenabbild und den gespeicherten Werten lässt es sich jederzeit erneut erzeugen,
• eine E-Mail versendet (es existiert keine Mailfunktion und kein Mailanbieter),
• den Abruflink bedient. Zu jedem Gutschein wird ein Abruf-Token erzeugt und verschlüsselt gespeichert, weil der Link später in einer Bestellbestätigung stehen soll, die sich nachträglich nicht ändern lässt. Die Route dahinter gibt es noch nicht; heute führt der Link ins Leere.

Die Liste der Tabellen mit personenbezogenen Kundendaten, die die Auskunfts- und Löschfunktion durchsucht, ist nicht mehr leer: Sie enthält die Gutscheintabelle. Frühere Fassungen dieser Erklärung sagten hier das Gegenteil.

4.3 Welche Berechtigungen erteilt sind — und welche davon ausgeübt werden

Kartuu fordert bei der Installation drei Berechtigungen an sowie den Zugriff auf die geschützten Kundendatenfelder „Name“ und „E-Mail-Adresse“. Shopify zeigt Ihnen das bei der Installation an, und Sie erteilen es damit.

read_all_orders ist ausdrücklich nicht angefordert: Kartuu braucht nur Bestellungen ab dem Zeitpunkt der Installation. Ebenso wenig write_publications — ob Ihr Gutscheinprodukt in Ihrem Onlineshop sichtbar wird, entscheiden Sie.

Bis zu dieser Fassung stand hier, die Berechtigung sei erteilt, aber an keiner Stelle ausgeübt. Das galt, solange es den Bestellablauf nicht gab, und gilt seither nicht mehr. Die Erklärung ist deshalb nachgeführt worden, statt den Unterschied zwischen „darf“ und „tut“ weiter zu behaupten, wo es ihn nicht mehr gibt.

5. Daten der Händlerinnen und Händler (wir sind Verantwortliche)

Wozu wir Ihre Daten nicht verwenden. Eine Verarbeitung zu eigenen Zwecken — insbesondere zu Werbung, Profiling, Weiterverkauf, zum Training von Modellen oder zu Auswertungen über Händler hinweg — findet nicht statt.

5.1 Was gespeichert wird

Ein Personenbezug entsteht hier nur mittelbar: die Shop-Domain identifiziert einen Betrieb, und bei Einzelunternehmen steht dahinter eine natürliche Person. Wir behandeln diese Daten deshalb wie personenbezogene Daten.

Das Zugriffsprotokoll für geschützte Kundendaten enthält bewusst keine Spalte, die einen Namen, eine Adresse, eine E-Mail-Adresse oder eine Gutscheinnummer aufnehmen könnte. Die zulässigen Werte für Akteur und Feldkategorie sind in der Datenbank per Prüfregel auf ein festes Vokabular begrenzt.

Erforderlichkeit der Bereitstellung. Die Bereitstellung der Shop-Domain und der Shopify-Zugangstoken ist weder gesetzlich noch vertraglich vorgeschrieben, für die Installation und den Betrieb von Kartuu aber zwingend erforderlich. Diese Daten entstehen automatisch, wenn Sie die App in Ihrem Shop verbinden.

Wo die Bildmotive liegen — und wo nicht. Alle übrigen Zeilen dieser Tabelle stehen in der Datenbank auf dem Server in Berlin. Bei den Bildmotiven gilt das nur für die Angaben darüber; der Bildinhalt liegt im Objektspeicher der IONOS in Berlin, in einem eigenen Eimer je Umgebung und nicht öffentlich lesbar (Abschnitt 7). Er ist deshalb auch nicht Teil der Datenbanksicherung — was das bedeutet, steht in 9.6.

Stand der Einrichtung, damit diese Zeilen nicht mehr behaupten, als gilt. Der Adminbereich bietet den Upload inzwischen an — im Gutschein-Editor gibt es ein Feld, über das ein Motiv hochgeladen wird. Bis zu dieser Fassung stand hier, es gebe keine solche Oberfläche; das traf zu, als der Satz geschrieben wurde, und trifft seither nicht mehr zu. Wohin die Bytes gehen, entscheidet weiterhin die Konfiguration der jeweiligen Umgebung: Ohne Angabe gilt ein Verzeichnis im Dateisystem, und das ist die Voreinstellung. Welche Umgebung auf den Objektspeicher umgestellt ist, steht nicht im Programm und lässt sich diesem Dokument deshalb nicht entnehmen; die Zeilen oben beschreiben die Verarbeitung, für die diese Erklärung und der Auftragsverarbeitungsvertrag die Grundlage schaffen — in dieser Reihenfolge und nicht umgekehrt: Erst der Text, dann die Umstellung. Läge es andersherum, läge ein Händlerbild in einem Speicher, den kein Dokument nennt.

Was ein hochgeladenes Bild enthält, bestimmen Sie. Wir prüfen es auf Format, Maße und Ungefährlichkeit (11.2), sehen den Inhalt aber nicht durch und entfernen die Aufnahmedaten nicht. Ein Foto aus einem Mobiltelefon kann Aufnahmezeitpunkt, Gerät und Standort tragen; diese Angaben bleiben im gespeicherten Bild und im daraus erzeugten PDF. Wenn Sie das nicht wollen, entfernen Sie die Aufnahmedaten vor dem Hochladen. Wir sagen es hier ausdrücklich, weil ein Gutschein weitergegeben wird und wir Ihnen die Entscheidung nicht abnehmen können, ohne Ihr Bild neu zu berechnen und dabei sichtbar zu verschlechtern.

Ihre Kontaktadresse müssen Sie dagegen selbst eingeben, und sie ist ein Pflichtfeld: Ohne sie können wir Ihnen weder eine Datenpanne melden noch eine Vertragsänderung ankündigen, und die Angaben nach Art. 30 Abs. 2 lit. a DSGVO ließen sich nicht führen. Geben Sie keine Adresse an oder stimmen Sie dem Auftragsverarbeitungsvertrag nicht zu, wird die App nicht verbunden — es kommt dann kein Vertrag zustande und es wird kein Datensatz zu Ihrem Shop angelegt (Art. 13 Abs. 2 lit. e DSGVO). Vollständig verarbeitungsfrei ist dieser Fall dennoch nicht: Deinstallieren Sie danach, nimmt Kartuu den Webhook app/uninstalled entgegen, den Shopify unabhängig von Ihrer Zustimmung sendet. Was dabei geschieht, steht in der letzten Zeile der Tabelle oben.

Für das Zugriffsprotokoll über geschützte Kundendaten besteht keine Wahlmöglichkeit; es ist Voraussetzung der Shopify-Freigabe.

5.2 Was ausdrücklich nicht gespeichert wird

• Ihr Session-Token (der von Shopify signierte Nachweis Ihrer angemeldeten Sitzung, fachlich ein JSON Web Token, kurz JWT) wird nur im Arbeitsspeicher geprüft und danach verworfen. Nicht in der Datenbank, nicht im Protokoll, nicht im Browserspeicher, nicht in der Adresszeile. Aus dem Token liest das Programm nur die Zielangabe (Shop-Domain), die Kennung unserer App als Empfänger sowie die Gültigkeitszeitpunkte; die übrigen Felder — darunter die von Shopify vergebene Benutzerkennung — bleiben unbenutzt. Siehe auch 5.6.
• Zugangsdaten landen nie im Protokoll — weder Access-, Refresh- noch Session-Token, auch nicht gekürzt. Im Fehlerfall wird nur die Art der Ausnahme geschrieben, nie deren Meldungstext, weil dieser Teile der Nutzdaten zitieren könnte. Das gilt seit dem 26.07.2026 auch für den Fehlerpfad des Zugriffsprotokolls über geschützte Kundendaten; dort wurde zuvor die vollständige Fehlermeldung samt Aufrufkette geschrieben.
• Eine benannte Ausnahme, und nur diese eine: Scheitert der Tokenabruf bei Shopify vorübergehend, steht im Protokoll zusätzlich der Meldungstext dieser einen Fehlerklasse. Er stammt nicht von Shopify, sondern wird von uns selbst zusammengesetzt und besteht ausschließlich aus eigenem Text, einem HTTP-Statuscode, einer Ausnahmeart, einer Zeilenzahl und der Shop-Domain — die ohnehin in derselben Zeile steht. Ein Token oder ein Geheimnis kann darin nicht auftauchen. Ohne diese Angabe ließe sich im Störungsfall nicht unterscheiden, ob das Netz ausgefallen war, ob unser Anwendungsgeheimnis nicht passt, ob Shopify gedrosselt hat oder ob der Datensatz zu Ihrem Shop fehlte.
• Ihre Kontaktadresse landet nicht im Protokoll. Sie wird verschlüsselt gespeichert und in keiner Protokollzeile ausgegeben.

5.3 Ihre Kontaktadresse und der Zustimmungsnachweis

Was wir erheben. Im Zustimmungsschritt beim Verbinden der App fragen wir eine E-Mail-Adresse ab, unter der wir Sie erreichen können. Das Feld ist ein Pflichtfeld. Zusammen mit Ihrer Zustimmung speichern wir genau drei Angaben zu Ihrem Shop:

Die Fassungskennung setzt ausschließlich der Server. Eine vom Browser mitgeschickte Angabe wird nicht übernommen — sonst ließe sich eine Zustimmung zu einer Fassung protokollieren, die Ihnen nie angezeigt wurde.

Die drei Angaben stehen entweder alle oder gar nicht: Die Datenbank lässt einen halben Nachweis nicht zu. Zu Ihrer Kontaktadresse wird kein Suchhash gebildet — nach der Adresse sucht niemand, sie wird über Ihre Shop-Domain gefunden.

Was wir damit tun. Wir schreiben Ihnen an diese Adresse, wenn es einen Anlass gibt: eine Verletzung des Schutzes personenbezogener Daten, eine Änderung des Auftragsverarbeitungsvertrages, ein Wechsel eines Unterauftragsverarbeiters, oder die Weiterleitung einer Anfrage, die eine betroffene Person an uns statt an Sie gerichtet hat. Werbung senden wir nicht.

Was wir damit nicht tun. Die Adresse wird nicht an Dritte weitergegeben, nicht ausgewertet und nicht mit anderen Händlern in Beziehung gesetzt.

Wenn Sie uns schreiben. Verarbeiten wir Ihre Nachricht und Ihre Absenderadresse, um sie zu beantworten. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO, soweit es um den Nutzungsvertrag geht, sonst Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: an uns gerichtete Anfragen zu beantworten.

Adresse ändern. Schreiben Sie an datenschutz@kyth.systems. Eine Änderung in der App ist noch nicht vorgesehen.

Abrechnung. Kartuu setzt die von Shopify verwalteten App-Tarife ein: Die Tarife sind im Shopify Partner Dashboard hinterlegt, die Auswahl und die Bezahlung finden auf einer Seite von Shopify statt, nicht bei uns. Im Programm steht keine Abrechnungslogik — kein Preis, keine Testphasenlänge, kein Buchungsvorgang. Wir lesen bei Shopify ausschließlich die Antwort auf eine Frage: ob für Ihren Shop ein aktives Abonnement besteht (siehe die Zeile Abonnementstand in 5.1). Zahlungsdaten — Karten-, Konto- oder Rechnungsdaten — verarbeiten wir nicht; sie liegen bei Shopify.

Kein eigener Bezahlweg. Die Abrechnung läuft ausschließlich über die von Shopify verwalteten Tarife; bei uns fallen dabei keine Zahlungs- oder Abrechnungsdaten an. Wird die Abrechnung eines Tages an Shopify vorbeigeführt — etwa über einen eigenen Zahlungsdienstleister —, ist dieser Abschnitt vor der Umstellung um die dann tatsächlich verarbeiteten Daten zu ergänzen und die Fassungskennung zu erhöhen.

5.4 App Bridge aus dem Shopify-CDN

Die eingebettete Oberfläche von Kartuu lädt die Bibliothek „App Bridge“ direkt von cdn.shopify.com. Dieser Aufruf geht aus Ihrem Browser, nicht von unserem Server. Shopify erhält dabei die üblichen Verbindungsdaten Ihres Browsers, also IP-Adresse und User-Agent, sowie die Herkunftsangabe.

Mitgegeben wird dabei nur die öffentliche Kennung unserer App. Es werden keine Kunden-, Bestell- oder Gutscheindaten und kein Token übertragen. Shopify erfährt durch die Herkunftsangabe nur, dass der Aufruf von https://kartuu.kyth.systems kommt — nicht, von welcher Unterseite, und nicht, um welchen Shop es geht. Dafür sorgt eine Referrer-Richtlinie, die den Parameter mit Ihrer Shop-Domain abschneidet.

Empfänger ist Shopify selbst, also dieselbe Stelle, die die umgebende Admin-Oberfläche ausliefert und Ihre IP-Adresse ohnehin sieht. Ein zusätzlicher Empfängerkreis entsteht dadurch nicht.

5.5 Keine Cookies, kein Tracking

Kartuu setzt keine eigenen Cookies und verwendet weder localStorage noch sessionStorage (zwei Speicher, die eine Website im Browser anlegen kann). Es sind keine Analyse-, Statistik-, Werbe- oder Tag-Dienste eingebunden. Schriftarten liegen lokal im Container; es wird kein externer Schrift- oder Symboldienst aufgerufen. Eine Einwilligung nach § 25 TDDDG — dem deutschen Gesetz über Cookies und Zugriffe auf Endgeräte — ist deshalb nicht erforderlich.

5.6 Wenn Sie für einen Händler im Shopify-Adminbereich handeln

Diese Angaben gelten für Personen, die Kartuu für einen Händler öffnen, ohne selbst der Händler zu sein — Beschäftigte des Shops, Agenturen, technische Dienstleister. Für Sie gilt Art. 14 DSGVO, weil wir Ihre Daten nicht von Ihnen bekommen.

• Welche Daten. Öffnen Sie die App, schickt Ihr Browser den von Shopify signierten Sitzungsnachweis (Session-Token) mit. Er enthält die Shop-Domain, die Kennung unserer App, Gültigkeitszeitpunkte und eine von Shopify vergebene Benutzerkennung. Gelesen werden davon nur Shop-Domain, App-Kennung und Gültigkeitszeitpunkte; die Benutzerkennung wird nicht ausgewertet.
• Woher. Von Shopify, nicht von Ihnen (Art. 14 Abs. 2 lit. f DSGVO). Shopify stellt den Sitzungsnachweis aus, wenn Sie im Adminbereich angemeldet sind.
• Wozu und auf welcher Grundlage. Prüfung, dass ein Aufruf echt ist und zu welchem Shop er gehört. Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse: Aufrufe an unsere Schnittstelle zu authentifizieren und fremde Shops voneinander abzuschirmen.
• Wie lange. Gar nicht. Der Sitzungsnachweis wird im Arbeitsspeicher geprüft und danach verworfen; er landet weder in der Datenbank noch im Protokoll (siehe 5.2).
• Wie Sie informiert werden. Über die Veröffentlichung dieser Erklärung. Eine einzelne Benachrichtigung ist uns nicht möglich, weil wir Ihre Kontaktdaten nicht kennen und den Sitzungsnachweis nicht speichern (Art. 14 Abs. 5 lit. b DSGVO).
• Ihre Rechte. Es gelten dieselben Rechte wie in Abschnitt 10.1, gerichtet an datenschutz@kyth.systems.

6. Daten der Kundschaft eines Shops (wir sind Auftragsverarbeiter)

6.1 Heutiger Stand: Kartuu speichert Bestell-, Kunden- und Empfängerdaten

Bis zu dieser Fassung stand hier: „Kartuu speichert derzeit keine personenbezogenen Daten von Endkundinnen und Endkunden oder von Beschenkten." Dieser Satz ist mit dem Bestellablauf falsch geworden, und er war die tragende Aussage des ganzen Abschnitts. Was heute gilt, steht hier.

Wer betroffen ist — drei Personen an einer Bestellung

Die beschenkte Person hat dabei zwei Rollen zugleich, und beide gehören genannt:

• Sie ist betroffene Person: Ihr Name, ihre Adresse und der Grußtext liegen verschlüsselt in unserer Datenbank, solange der Shop besteht.
• Sie ist Empfängerin des Gutscheins: Genau dafür wird ihre E-Mail-Adresse gespeichert. Die Mail geht über den Mailzugang des Händlers hinaus und trägt den Gutschein als PDF im Anhang sowie einen Abruflink (4.2). Hat der Händler keinen Zugang hinterlegt, wird nichts verschickt — er übergibt den Gutschein dann selbst.

Erhält sie die Karte, erfährt sie damit auch den Namen der schenkenden Person und den Grußtext. Für die Information dieser Personen ist der Shop zuständig, nicht wir — und weil eine beschenkte Person ihre Daten nicht selbst gegeben hat, gilt dafür Art. 14 DSGVO (siehe 6.3).

Was gespeichert wird

Je gekauftem Stück entsteht eine Zeile. Kauft jemand drei Gutscheine über je 50 Euro, sind das drei Zeilen mit drei Codes — nicht eine über 150 Euro; ein zusammengefasster Gutschein ließe sich nicht einzeln verschenken und nicht einzeln einlösen.

Was ausdrücklich nicht gespeichert wird: Anschrift und Telefonnummer der Kundschaft, Zahlungsdaten, der Bestellinhalt jenseits der Gutscheinpositionen, das gerenderte PDF und das Wunschversanddatum, das im Bestellformular angegeben werden kann. Für keines davon gibt es eine Spalte.

Was weiterhin flüchtig bleibt

Der Gutschein-Editor. Im Adminbereich tippt der Händler Empfängername, Absendername, Grußtext, Gutscheincode, Betrag, Shopname und Gültigkeitsdatum ein und lässt sich daraus eine Vorschau und ein PDF erzeugen. Kartuu setzt die Werte in die gewählte Kartenvorlage, gibt Vorschau und PDF an denselben Händler zurück und behält nichts davon: keine Tabelle, keine Datei, kein Protokolleintrag mit Inhalt — im Protokoll steht im Fehlerfall nur der Name des beanstandeten Feldes, nie dessen Inhalt. Diese Angaben stammen nicht aus Ihrem Shop, sondern aus der Eingabe des Händlers.

Die Datenschutz-Webhooks. Ihr Inhalt wird zur Signaturprüfung vollständig eingelesen und danach verworfen. Ausgewertet werden Kundennummer und E-Mail-Adresse, mehr nicht. Einzelheiten in 6.4.

Das gerenderte PDF. Es entsteht im Arbeitslauf und wird nach dem Rendern verworfen. Gerendert wird trotzdem, denn „bereit" heißt „die Karte lässt sich drucken" — eine Vorlage, die an einem langen Grußtext zerbricht, soll hier auffallen und nicht beim Beschenkten.

Entgegennehmen, Auslesen und Verwerfen sind Verarbeitung im Sinne von Art. 4 Nr. 2 DSGVO. Wo unten „speichert nicht" steht, heißt das nicht „verarbeitet nicht" — die beiden Wörter sind an dieser Stelle nicht austauschbar.

Hochgeladene Bilder

Was auf einem hochgeladenen Motiv zu sehen ist und welche Aufnahmedaten darin stehen, entscheidet allein der Händler. Bildet ein Motiv Personen ab, sind deren Daten gespeichert, solange der Shop besteht (5.1).

Kartuu kann das nicht verhindern und prüft es nicht — eine Software, die Bilder auf abgebildete Personen durchsieht, wäre selbst die weitergehende Verarbeitung. Die Verantwortung dafür, ein Motiv nur mit der nötigen Rechtsgrundlage hochzuladen, liegt deshalb beim Händler; Kartuu ist dabei Auftragsverarbeiter und handelt auf seine Weisung. Der Upload ist diese Weisung (§ 3.2 Nr. 3 des Auftragsverarbeitungsvertrages).

6.2 Wie lange diese Daten liegen

Eine Grenze der ersten Zeile, offen benannt. Shopifys customers/redact trägt die Kundennummer und die Adresse genau einer Person — der Person, die Shopify kennt. Eine beschenkte Person, die nie in dem Shop gekauft hat, erscheint dort nie. Ihre Daten sind für uns über den Suchwert ihrer Adresse auffindbar, und die Löschung dafür ist gebaut; was fehlt, ist der Auslöser. Verlangt eine beschenkte Person die Löschung, geschieht sie deshalb heute von Hand, nach einer Nachricht an datenschutz@kyth.systems (Abschnitt 10.2). Ein Weg, über den ein Händler sie in der App selbst auslösen könnte, besteht nicht.

Die letzte Zeile der Tabelle ist eine benannte Lücke und keine Zusage. Sie steht so in 12.2, weil sie eine Entscheidung braucht: Wie lange ein eingelöster Gutschein als Beleg über eine erfüllte Verpflichtung aufzubewahren ist, folgt nicht aus dem Quelltext, sondern aus handels- und steuerrechtlichen Fristen und aus der Verjährung des Anspruchs. Solange diese Frist nicht festgelegt ist, liegen die Daten, bis der Shop verschwindet.

6.3 Auf wessen Weisung wir dabei handeln

Die Verarbeitung der Bestell-, Kunden- und Empfängerdaten geschieht ausschließlich auf Weisung des Shops. Die Rechtsgrundlage gegenüber der betroffenen Person schafft der Shop, nicht wir — in der Regel Art. 6 Abs. 1 lit. b DSGVO für die Erfüllung des Kaufvertrags. Wir prüfen diese Rechtsgrundlage nicht und können sie nicht prüfen.

Beschenkte erhalten ihre Daten typischerweise nicht selbst gegeben, sondern von der schenkenden Person. Die Informationspflicht gegenüber Beschenkten nach Art. 14 DSGVO trifft daher den Shop.

6.4 Die drei Datenschutz-Webhooks von Shopify

Shopify verpflichtet jede App, drei Webhooks zu bedienen. Kartuu tut das:

Bis zu dieser Fassung stand hier, diese Liste sei leer und die Abfrage treffe nachweislich null Zeilen. Das galt, solange es keine Kundendaten gab. Seit dem Bestellablauf trifft sie Zeilen, und wer sich auf den alten Satz gestützt hat, hat sich auf einen Stand gestützt, den es nicht mehr gibt.

Shopify sendet in den ersten beiden Webhooks weitere Kundendaten mit, unter anderem Telefonnummer und Anschrift. Ausgewertet werden nur Kundennummer und E-Mail-Adresse. Der Inhalt der Webhook-Nachricht wird zur Signaturprüfung vollständig eingelesen und danach verworfen; nichts davon wird gespeichert.

Für diese Verarbeitung gilt:

Jeder eingehende Webhook wird vor jeder Verarbeitung anhand seiner Signatur geprüft (HMAC-SHA256, ein Prüfwert, den nur Shopify mit dem gemeinsamen Geheimnis erzeugen kann). Ohne gültige Signatur passiert nichts.

7. Empfänger und Unterauftragsverarbeiter

Cloudflare — für die App nur DNS, kein Auftragsverarbeiter

Die Zone kyth.systems wird bei Cloudflare geführt. Für Kartuu ist Cloudflare damit ausschließlich autoritativer DNS-Dienst: Cloudflare beantwortet die Frage, welche IP-Adresse zu kartuu.kyth.systems gehört, und ist an der Verbindung selbst nicht beteiligt.

Nachgemessen am 26.07.2026: kartuu.kyth.systems und kartuu-staging.kyth.systems lösen unmittelbar auf die IP-Adresse unseres Servers in Berlin auf (85.215.155.92). Der Datenverkehr zwischen Ihrem Browser und Kartuu läuft also nicht über Cloudflare. Cloudflare sieht weder Ihre Verbindungsdaten noch Inhalte und ist deshalb für die App kein Auftragsverarbeiter — weder von Händler- noch von Kundendaten.

Anders liegt es bei unserer Unternehmenswebsite kyth.systems und www.kyth.systems: Diese Namen lösen auf Cloudflare-Adressen auf, laufen also im Proxy-Modus. Dort verarbeitet Cloudflare Verbindungsdaten. Das betrifft nicht Kartuu und ist Gegenstand der Datenschutzerklärung der Website, nicht dieser Erklärung.

Diese Unterscheidung hängt an einer DNS-Einstellung und kann sich mit einem einzigen Klick ändern. Wird kartuu.kyth.systems künftig auf den Proxy-Modus umgestellt, wird Cloudflare damit Auftragsverarbeiter — dann sind dieser Abschnitt, Abschnitt 8 und § 6 des Auftragsverarbeitungsvertrages vor der Umstellung zu ändern und die Händler nach § 6.6 des Vertrages zu informieren.

Ausdrücklich nicht beteiligt

Gesucht und nicht gefunden: kein Mailversanddienst von KYTH, kein externer Schrift- oder Symboldienst, kein Analyse- oder Tag-Dienst, kein externer Dienst zur Fehlererfassung.

Der Mailversand verdient dabei einen eigenen Satz, weil er leicht misszuverstehen ist: Kartuu verschickt Gutscheine über Ihren Mailserver, den Sie selbst hinterlegen. Ihr Mailanbieter ist damit Ihr Auftragsverarbeiter und nicht unserer — wir wählen ihn nicht aus, wir beauftragen ihn nicht, und wir haben keinen Vertrag mit ihm. Wir liefern die Nachricht lediglich über den Zugang ein, den Sie uns dafür geben. Die einzige HTTP-Bibliothek im Anwendungscode wird an genau zwei Stellen verwendet, und beide sprechen dieselbe Gegenstelle an: den Token-Endpunkt und die Admin-API Ihres eigenen Shops. Objektspeicher wird ausschließlich bei IONOS benutzt, in den beiden oben genannten Eimern: Mit dem Sicherungseimer spricht die Anwendung nicht, das tut ein eigenes Sicherungsskript auf dem Server; mit dem Eimer für Ihre Bildmotive spricht sie sehr wohl — sie legt dort ab, liest wieder und löscht beim Löschen Ihres Shops. Bis zu dieser Fassung stand hier, die Anwendung spreche mit keinem Objektspeicher; seit der Bildablage trifft das nicht mehr zu.

Die Empfänger mit vollständiger Anschrift. Ermittelt am 01.08.2026 aus den öffentlichen Angaben der jeweiligen Anbieter; die Fundstellen stehen in Abschnitt 12.3.

Der Objektspeicher wird unter s3.eu-central-3.ionoscloud.com erbracht; die Anbieterkennzeichnung dieses Dienstes nennt die IONOS Cloud GmbH. Welche Gesellschaft der IONOS-Gruppe im Einzelfall Vertragspartnerin ist, ergibt sich aus dem jeweiligen Vertrag; beide sind unter derselben Anschrift erreichbar.

Diese Tabelle und § 6.3 des Auftragsverarbeitungsvertrages beschreiben denselben Empfängerkreis. Ändert sich einer, ist der andere mitzuändern — sonst laufen sie auseinander, und die ältere Fassung wird stillschweigend zur falschen Auskunft.

8. Übermittlung in Drittländer

Ein Drittlandbezug entsteht nicht durch unser Hosting — Server, Datenbank und Sicherungen liegen in Berlin —, sondern über Shopify.

Shopify. Vertragspartnerin für Händler im EWR ist Shopify International Limited mit Sitz in Irland. Der Konzern hat seinen Ursprung in Kanada und unterhält Gesellschaften unter anderem in den USA. Wir können nicht bestimmen und nicht überprüfen, in welchem Land Shopify die an den Token-Endpunkt und an die Admin-API gesendeten Daten und die von Shopify an uns gesendeten Webhooks verarbeitet.

Kanada gilt als sicheres Drittland, allerdings nur für private Unternehmen, die dem kanadischen Datenschutzgesetz PIPEDA unterliegen. Die Europäische Kommission hat das mit ihrer Entscheidung 2002/2/EG festgestellt (Angemessenheitsbeschluss nach Art. 45 DSGVO). Für Übermittlungen dorthin ist damit keine weitere Garantie nötig.

Die Grundlage. Shopify bezieht in sein Data Processing Addendum (Fassung vom 07.07.2026) die EU-Standardvertragsklauseln ein — die Klauseln aus dem Durchführungsbeschluss (EU) 2021/914 der Europäischen Kommission vom 4. Juni 2021. Auf sie stützen sich Übermittlungen an Shopify-Stellen außerhalb des Europäischen Wirtschaftsraums, also auch an Stellen in den USA.

Für Kanada besteht daneben ein Angemessenheitsbeschluss der Europäischen Kommission (Entscheidung 2002/2/EG) für dem PIPEDA unterliegende Organisationen.

Eine Kopie der Standardvertragsklauseln erhalten Sie auf Anfrage an datenschutz@kyth.systems; das Addendum selbst ist unter https://www.shopify.com/legal/dpa öffentlich abrufbar.

Was hier bewusst NICHT steht. Eine Zertifizierung der beteiligten Shopify-Gesellschaften unter dem EU-US Data Privacy Framework wird nicht behauptet: Das Addendum nennt keine, und ohne Beleg gehört sie nicht in eine Datenschutzerklärung. Die Standardvertragsklauseln tragen die Übermittlung auch ohne sie.

GitHub. Sitz in den USA. Dorthin fließen ausschließlich Quelltexte, keine Händler- und keine Kundendaten.

Cloudflare. Kein Drittlandbezug für Kartuu. Cloudflare ist für die App reiner autoritativer DNS-Dienst; der Datenverkehr läuft nicht über Cloudflare, und personenbezogene Daten aus Kartuu werden dorthin nicht übermittelt. Siehe Abschnitt 7.

IONOS Object Storage. Kein Drittlandbezug. Sowohl die Sicherungen als auch die hochgeladenen Bildmotive liegen in der Region eu-central-3, Rechenzentrum Berlin.

9. Speicherdauer und Löschung

9.1 Bei Deinstallation der App

Erhält Kartuu den Webhook app/uninstalled, werden sofort beide Zugangstoken gelöscht (auf NULL gesetzt) und der Deinstallationszeitpunkt vermerkt. Die Zeile mit Shop-Domain, Suchhash, Zeitstempeln, Berechtigungen, Abonnementstand, Ihrer Kontaktadresse und dem Zustimmungsnachweis bleibt zunächst bestehen — damit verspätete Webhooks noch korrekt zugeordnet werden können und damit Sie bei einer Neuinstallation innerhalb der Frist nach 9.3 nicht erneut zustimmen müssen.

9.2 Endgültige Löschung

Shopify sendet in der Regel 48 Stunden nach der Deinstallation den Webhook shop/redact. Daraufhin löscht Kartuu zuerst Ihre hochgeladenen Bildmotive im Objektspeicher und danach in einer einzigen Transaktion alle Zeilen sämtlicher Tabellen, die eine Shop-Kennung tragen, und anschließend den Shop-Datensatz selbst. Entweder verschwindet der Shop vollständig oder gar nicht.

Warum die Bilder zuerst. Umgekehrt ließe sich der Fehler nicht heilen: Wären die Zeilen weg und scheiterte danach der Objektspeicher, meldeten wir einen Fehlschlag, Shopify wiederholte den Webhook — und die Wiederholung fände den Shop nicht mehr, meldete „nichts zu löschen" und ließe die Bilder für immer liegen. Gelöscht wird dabei alles unter dem Namensraum Ihres Shops und nicht Bild für Bild nach Liste; so verschwindet auch ein Objekt, dessen Zeile wegen eines Abbruchs während des Hochladens nie geschrieben wurde.

Welche Tabellen dabei geleert werden, wird zur Laufzeit aus dem Datenbankschema ermittelt und nicht aus einer von Hand gepflegten Liste. Erfasst werden alle Tabellen im Hauptschema, die eine Spalte mit dem Namen shop_id tragen; eine neu hinzugefügte Tabelle dieser Art wird dadurch automatisch mitgelöscht. Die Tabellen des Bestellablaufs sind auf genau diesem Weg mitgekommen — Gutscheine, die Zuordnung ihrer Bildmotive und die Gutscheinprodukte tragen alle eine Shop-Kennung, es musste nichts nachgetragen werden. Genau dafür ist der Mechanismus da.

Was der Mechanismus nicht erfasst — der Quelltext benennt diese Grenzen selbst: Tabellen in einem anderen Schema, Tabellen mit abweichend benannter Shop-Spalte, Views sowie Tabellen, die nur mittelbar über einen Fremdschlüssel an einer Shop-Tabelle hängen. Für diese muss die Löschung gesondert sichergestellt werden. Der heutige Datenbestand fällt vollständig in den erfassten Bereich; mit jeder neuen Tabelle wird die Einschränkung wichtiger.

Zwei benannte Grenzen bei den Bildmotiven. Sie stehen hier, weil sie eine Zusage begrenzen, und nicht in einer Fußnote:

1. Der Aufräumlauf löscht die Bilder mit — solange er läuft. Bleibt shop/redact aus, entfernt der Lauf nach 9.3 nach 30 Tagen zuerst die Bilder im Objektspeicher und danach die Datenbankzeilen, in derselben Reihenfolge wie der Webhook. Bis zu dieser Fassung stand hier, er nehme die Bilder nicht mit; das traf zu und ist behoben. Was bleibt: Dieser Lauf hat noch keinen Auslöser (9.3). Solange das so ist, hängt die Löschung der Bilder an der tatsächlichen Zustellung des Webhooks — für den Regelfall ist das erfüllt, für den Ausfallfall nicht.
2. Ein einzelnes Bild können Sie in der App nicht löschen, und es gibt keinen Lauf, der ungenutzte Motive sucht und entfernt. Ein hochgeladenes Bild bleibt liegen, solange Ihr Shop besteht. Wollen Sie ein bestimmtes Motiv entfernt haben — etwa weil eine abgebildete Person widersprochen hat —, genügt eine Nachricht an datenschutz@kyth.systems; wir entfernen es von Hand und bestätigen das.

9.3 Wenn der Löschwebhook ausbleibt: 30 Tage

Bleibt shop/redact aus — die Zustellung geht verloren, unser Endpunkt ist vorübergehend nicht erreichbar, Shopify meldet ihn nie —, entfernt ein Aufräumlauf die Shop-Zeile 30 Tage nach der Deinstallation vollständig, über denselben Löschpfad wie shop/redact. Es gibt genau eine Löschlogik, nicht zwei.

Warum nicht kürzer: Wer die App versehentlich deinstalliert und in derselben Woche neu installiert, soll seine Zustimmung und seine Kontaktadresse nicht verloren haben. Warum überhaupt: Eine Shop-Zeile, die ohne Zweck stehen bleibt, verstößt gegen Art. 5 Abs. 1 lit. e DSGVO — und sie fällt niemandem auf, weil dabei nichts fehlschlägt.

Der Fall ohne Deinstallationszeitpunkt: 90 Tage. Die Frist oben rechnet ab dem Zeitpunkt der Deinstallation. Es gibt eine Lage, in der es diesen Zeitpunkt nie gibt: Sie stimmen zu, wir legen den Datensatz zu Ihrem Shop an, und der unmittelbar folgende Abruf des Zugangstokens bei Shopify scheitert. Eine Deinstallationsmeldung kommt für diesen Datensatz nie, weil die App gar nicht mehr installiert ist. Derselbe Aufräumlauf löscht ihn deshalb nach 90 Tagen — vorausgesetzt, es ist weder ein Zugangs- noch ein Erneuerungstoken hinterlegt, denn dann ist belegt, dass kein Zugriff auf Ihren Shop mehr möglich ist. Die Frist ist länger als die 30 Tage oben, weil sie von einem schwächeren Anhaltspunkt ausgeht als von einer gemeldeten Deinstallation.

Was auch das nicht erfasst: einen Datensatz, dessen Token noch hinterlegt sind, obwohl der Shop längst deinstalliert ist. Er ist von dem eines arbeitenden Shops nicht zu unterscheiden, und eine Regel, die ihn erfasste, träfe auch arbeitende Shops. Möglich wird das, wenn die Deinstallationsmeldung den Shop wegen eines nach einem Schlüsselwechsel veralteten Suchwertes nicht auflösen konnte.

Der Auslöser läuft. Seit dem 01.08.2026 ruft die Anwendung diesen Aufräumlauf selbst auf — einmal täglich, gestartet mit dem Anwendungsprozess (kaspar/aufraeumlauf.py). Bis dahin war die Löschung zwar gebaut und geprüft, aber von nichts aufgerufen: Die Frist stand in dieser Erklärung und war eine Absicht. Das gilt ebenso für die Frist in 9.4, die derselbe Lauf abarbeitet.

9.4 Webhook-Kennungen: 30 Tage

Die Tabelle mit den Webhook-Kennungen (Duplikatschutz) trägt keine Shop-Kennung und wird deshalb vom Löschpfad des Shops nicht erfasst. Inhaltlich sind das ausschließlich von Shopify vergebene technische Kennungen ohne Personenbezug.

Ein eigener Aufräumlauf entfernt einen Eintrag 30 Tage nach Abschluss der Verarbeitung des jeweiligen Webhooks. Shopify wiederholt einen Webhook über höchstens 48 Stunden; die 30 Tage sind Puffer für die Frage „kam dieser Webhook je an?“.

Einträge, deren Verarbeitung nie abgeschlossen wurde (etwa weil ein Prozess abgebrochen ist), bleiben stehen. Sie zu löschen hieße, eine Wiederholung desselben Webhooks ein zweites Mal durchlaufen zu lassen. Personenbezug haben sie nicht.

9.5 Löschung einzelner Personen

Über customers/redact. Dieser Vorgang trifft seit dem Bestellablauf tatsächlich Zeilen: Er anonymisiert in der Gutscheintabelle Empfängername, E-Mail-Adresse samt ihrem Suchwert, Absendername und Grußtext, und die Kundennummer dann, wenn sie zu der gesuchten Person gehört. Der Gutschein selbst bleibt — die Begründung und die Grenzen stehen in 6.2. Protokolliert wird zusätzlich, dass die Anfrage bearbeitet wurde, und wie viele Datensätze betroffen waren.

Bis zu dieser Fassung stand hier, der Vorgang treffe keine einzige Zeile, weil keine Kundendaten gespeichert seien.

9.5a Gutscheindaten nach Zweckfortfall

Für die Gutscheinzeilen gibt es keine eigene Frist. Sie werden aufbewahrt, solange der Shop besteht, und verschwinden mit ihm über 9.2 oder 9.3. Ein Gutschein, der eingelöst oder abgelaufen ist, wird von keinem Lauf entfernt; ein Gutschein, dessen Bestellung storniert wurde, ebenfalls nicht.

Das ist eine benannte Lücke und keine Zusage. Welche Frist nach Zweckfortfall gilt, folgt nicht aus dem Programm: Ein ausgestellter Gutschein ist der Beleg über eine eingegangene Verpflichtung, und wie lange dieser Beleg zu führen ist, richtet sich nach handels- und steuerrechtlichen Aufbewahrungspflichten und nach der Verjährung des Anspruchs. Der offene Punkt steht in 12.2.

9.6 Sicherungen — 30 Tage lokal, 90 Tage im Objektspeicher

Was gesichert wird. Von der Datenbank wird täglich nachts (03:20 Uhr UTC) eine vollständige Sicherung erstellt, verschlüsselt, auf dem Server abgelegt und an den Objektspeicher der IONOS in Berlin übertragen (Eimer kaspar-kyth-db-backup, Region eu-central-3). Seit dem 26.07.2026 ist eine tägliche Sicherung eingerichtet und mit einem tatsächlichen Lauf belegt; seit dem 01.08.2026 ist sie verschlüsselt.

Dass sie sich einspielen lässt, ist geprüft. Am 01.08.2026 haben wir eine Sicherung aus dem Objektspeicher geholt, entschlüsselt und in eine leere Wegwerfdatenbank eingespielt; anschließend haben wir Tabellenzahl, Datenbestand und Versionsstand verglichen. Die Wegwerfdatenbank wurde danach gelöscht. Wir nennen das, weil eine Sicherung, die noch nie eingespielt wurde, eine Vermutung ist und keine Maßnahme.

Ob sie überhaupt läuft, wird überwacht. Ein täglicher Prüflauf schlägt Alarm, wenn seit mehr als 26 Stunden keine erfolgreiche Sicherung mehr vermerkt wurde — er meldet damit nicht nur fehlgeschlagene Läufe, sondern auch ausgebliebene.

Was nicht gesichert wird: Ihre hochgeladenen Bildmotive. Gesichert wird die Datenbank, und dort stehen von einem Bild nur die Angaben darüber (5.1). Der Bildinhalt liegt im Objektspeicher und geht in keine Sicherung ein. Geht dieser Eimer verloren, sind die Motive weg; Ihre übrigen Daten wären davon nicht berührt, und die mitgelieferten Motive der Kartenvorlagen ebenfalls nicht — die kommen aus dem Programm selbst. Das ist eine Verfügbarkeitslücke, und wir nennen sie hier, statt sie unter der allgemeinen Sicherungszusage verschwinden zu lassen.

Wie lange sie liegt.

Zusätzlich löscht eine Lebenszyklusregel im Eimer selbst jede Sicherung auf Speicherebene (Regel sicherungen-nach-90-tagen-loeschen, gesamter Eimer, Ablauf 90 Tage nach Erstellung). Der Unterschied ist kein Detail: Die Aufbewahrung des Betriebswerkzeugs ist ein Aufräumjob, und Aufräumjobs fallen still aus. Die Lebenszyklusregel wirkt unabhängig davon.

Verschlüsselung — was wir zusagen und was nicht.

• Die Sicherungsdatei als Ganzes: symmetrisch mit AES-256 verschlüsselt, bevor sie den Server verlässt (GnuPG). Das Kennwort dafür liegt auf dem Server und nicht im Objektspeicher. Wer den Eimer erlangt, hat damit nichts als eine unlesbare Datei. Bis zum 01.08.2026 war das anders — die Sicherung ging unverschlüsselt in den Eimer, und wir haben das an dieser Stelle auch so beschrieben. Die damals vorhandenen unverschlüsselten Sicherungen sind nachträglich verschlüsselt und in ihrer offenen Fassung gelöscht worden.
• Auf dem Übertragungsweg: TLS 1.3 zum IONOS-Endpunkt.
• Ruhend bei IONOS: IONOS verschlüsselt ruhende Objekte mit AES-256. Wir sagen das nicht als eigene Maßnahme zu: Die Dokumentation von IONOS beschreibt die Standardverschlüsselung für Uploads über die Weboberfläche. Ob unser Sicherungslauf über die S3-Schnittstelle dieselbe Verschlüsselung anfordert, haben wir nicht belegt, und eine Standardverschlüsselung auf Ebene des Eimers bietet IONOS nicht an. Wir behaupten hier deshalb nichts, was wir nicht geprüft haben — es ist seit dem 01.08.2026 auch nicht mehr tragend, weil die Datei bereits verschlüsselt ankommt.
• Zusätzlich, und davon unabhängig: Die personenbezogenen und geheimhaltungs- bedürftigen Felder — Zugangstoken und Ihre Kontaktadresse — liegen innerhalb der Sicherung noch einmal feldweise mit AES-256-GCM verschlüsselt. Dieser Schlüssel steht in der Umgebung der Anwendung, nicht in der Sicherung und nicht bei IONOS, und er ist ein anderer als das Kennwort der Sicherungsdatei. Selbst wer beides erlangte, was getrennt verwahrt wird, bräuchte noch den dritten Teil.

Was das für eine Löschung bedeutet — bitte ausdrücklich zur Kenntnis nehmen. Löschen wir Ihre Daten in der Datenbank — auf Ihr Verlangen, über shop/redact oder über den Aufräumlauf nach 9.3 —, dann sind sie in bereits erstellten Sicherungen weiterhin enthalten. Sie verschwinden von dort erst mit dem Ablauf der oben genannten Fristen, also spätestens 30 Tage später auf dem Server und 90 Tage später im Objektspeicher. Ein gezieltes Herausschneiden einzelner Datensätze aus vorhandenen Sicherungen findet nicht statt; es würde die Sicherung als Wiederherstellungspunkt entwerten. Solange sie dort liegen, werden sie ausschließlich zur Wiederherstellung im Störungsfall verwendet und zu keinem anderen Zweck.

9.7 Anwendungs- und Containerprotokolle: 14 Tage

Anwendungs- und Containerprotokolle werden 14 Tage aufbewahrt und danach verworfen. Ihr Inhalt ist in 5.1 beschrieben: Shop-Domain, interne Shop-Kennung und die Art einer aufgetretenen Ausnahme — keine Zugangsdaten, keine Kontaktadresse, keine Kundendaten.

Diese Frist wird im Betriebswerkzeug eingestellt, nicht im Programm. Sie steht hier, weil sie gilt, nicht weil sie im Quelltext nachlesbar wäre.

9.8 Der vorgelagerte Proxy

Es gibt keine serverseitigen Zugriffsprotokolle. Dem Anwendungscontainer ist ein Reverse-Proxy vorgelagert (Traefik, betrieben über Coolify auf demselben Server in Berlin). Seine Zugriffsprotokollierung ist ausgeschaltet — sie ist bei Traefik standardmäßig aus und in dieser Installation nirgends eingeschaltet. Der Proxy speichert damit keine IP-Adressen, keine Browserkennungen und keine Abfrageparameter.

Was er schreibt, ist sein eigenes Betriebsprotokoll: Startmeldungen und Fehler beim Ausstellen von TLS-Zertifikaten. Darin stehen Domainnamen, keine Angaben zu Besucherinnen und Besuchern. Es liegt ausschließlich auf diesem Server, wird nicht ausgewertet und nicht weitergegeben, und es besteht kein Zugriff Dritter darauf. Die Container-Umgebung begrenzt es auf drei Dateien zu je zehn Megabyte und überschreibt die älteste, sobald es voll ist; eine Frist in Tagen gibt es dafür nicht, weil es keine personenbezogenen Daten enthält.

Rechtsgrundlage für das Betriebsprotokoll ist Art. 6 Abs. 1 lit. f DSGVO — das berechtigte Interesse am sicheren und störungsfreien Betrieb.

Bis zum 03.08.2026 stand hier etwas anderes, und es war zu unseren Lasten falsch: „Er protokolliert Verbindungen technisch mit", dazu die Ankündigung, die Aufbewahrungsdauer auf 14 Tage zu begrenzen. Nachgemessen an der laufenden Installation trifft beides nicht zu — die Protokollierung war nie eingeschaltet. Eine Datenschutzerklärung, die mehr Datenerhebung behauptet als stattfindet, ist genauso falsch wie eine, die zu wenig nennt; sie beschreibt nur einen Fehler in die andere Richtung.

Wer die Zugriffsprotokollierung später einschaltet, muss diesen Abschnitt vorher ändern: Dann werden IP-Adressen verarbeitet, und dann braucht es auch die Frist.

10. Ihre Rechte

10.1 Wenn Sie Händlerin oder Händler sind

Ihnen stehen uns gegenüber die folgenden Rechte zu:

• Auskunft (Art. 15 DSGVO) — welche Daten wir zu Ihnen verarbeiten
• Berichtigung (Art. 16 DSGVO) — Korrektur unrichtiger Daten
• Löschung (Art. 17 DSGVO) — Entfernung Ihrer Daten
• Einschränkung der Verarbeitung (Art. 18 DSGVO)
• Datenübertragbarkeit (Art. 20 DSGVO) — Herausgabe in einem gängigen Format
• Widerspruch (Art. 21 DSGVO) gegen Verarbeitungen, die wir auf ein berechtigtes Interesse stützen (in Abschnitt 5.1 als Art. 6 Abs. 1 lit. f gekennzeichnet)

Schreiben Sie dafür an datenschutz@kyth.systems. Wir antworten unentgeltlich und innerhalb eines Monats (Art. 12 Abs. 3 DSGVO).

Der schnellste Weg zur vollständigen Löschung ist die Deinstallation der App: Shopify löst dann automatisch den Löschvorgang aus, siehe 9.2.

10.2 Wenn Sie in einem Shop eingekauft haben — oder beschenkt worden sind

Wenden Sie sich bitte an den Shop, bei dem bestellt wurde. Der Shop ist für Ihre Daten verantwortlich; wir handeln nur in seinem Auftrag und dürfen ohne seine Weisung keine Auskunft erteilen und nichts löschen.

So unterstützen wir den Shop dabei:

• Fordert der Shop über Shopify eine Auskunft an, empfängt Kartuu den Webhook customers/data_request und stellt die zu dieser Person gespeicherten Daten zusammen — Empfängername, E-Mail-Adresse, Absendername und Grußtext, entschlüsselt. Bis zu dieser Fassung stand hier, das Ergebnis sei nachweislich leer. Das galt, solange es keine Kundendaten gab, und gilt seit dem Bestellablauf nicht mehr. Zugestellt wird diese Auskunft nicht von selbst, und das gehört an dieselbe Stelle: Der Webhook hält fest, dass die Anfrage kam und wie viele Datensätze es gibt; eine Seite, auf der der Shop den Inhalt abrufen könnte, gibt es nicht. Der Shop fordert ihn bei datenschutz@kyth.systems an und bekommt ihn von Hand — er ist es, der Ihnen die Antwort schuldet, nicht wir. Bis zum 27.07.2026 stand hier, die Angaben würden herausgegeben; der Weg dorthin war und ist der über den Shop.
• Fordert der Shop eine Löschung an, empfängt Kartuu customers/redact und anonymisiert die betroffenen Zeilen. Was dabei bleibt und warum, steht in 6.2.
• Wird der Shop bei Shopify gelöscht oder die App deinstalliert, entfernt Kartuu über shop/redact sämtliche Daten dieses Shops.

Wenn Sie beschenkt worden sind, gilt eine Besonderheit. Sie haben in dem Shop nie etwas bestellt, Shopify kennt Sie deshalb nicht, und die beiden Webhooks oben erreichen Sie nur zufällig — nämlich dann, wenn Ihre E-Mail-Adresse dieselbe ist wie die der Person, über die Shopify die Anfrage stellt. Ihre Daten sind bei uns über den Suchwert Ihrer Adresse auffindbar, und die Löschung dafür ist gebaut; was fehlt, ist ein Weg, über den der Shop sie auslösen kann. Schreiben Sie deshalb an datenschutz@kyth.systems: Wir leiten Ihr Anliegen an den Shop weiter und führen die Löschung auf seine Weisung von Hand aus.

Erreichen Sie den Shop nicht, können Sie sich auch direkt an datenschutz@kyth.systems wenden. Wir leiten Ihr Anliegen an den Shop weiter und informieren Sie darüber. Der Kanal dafür steht: Jeder Shop hinterlegt beim Verbinden der App eine Kontaktadresse (siehe 5.3), und diese Adresse zu benennen und aktuell zu halten ist eine Pflicht des Shops nach § 2a Nr. 4 des Auftragsverarbeitungsvertrages.

Antworten können wir Ihnen inhaltlich nicht: Der Shop entscheidet über Ihre Daten, nicht wir.

10.3 Beschwerde bei der Aufsichtsbehörde

Sie können sich unabhängig davon jederzeit bei einer Datenschutz-Aufsichtsbehörde beschweren (Art. 77 DSGVO), insbesondere in dem Mitgliedstaat Ihres Aufenthaltsorts, Ihres Arbeitsplatzes oder des mutmaßlichen Verstoßes.

Für uns zuständig ist:

Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) Promenade 27, 91522 Ansbach poststelle@lda.bayern.de

10.4 Keine automatisierte Entscheidungsfindung

Eine automatisierte Entscheidungsfindung einschließlich Profiling im Sinne von Art. 22 Abs. 1 und Abs. 4 DSGVO findet nicht statt. Kartuu trifft keine Entscheidungen, die Ihnen gegenüber rechtliche Wirkung entfalten oder Sie in ähnlicher Weise erheblich beeinträchtigen.

11. Technische und organisatorische Maßnahmen

Die folgenden Maßnahmen sind im Quelltext bzw. in der Betriebsdokumentation belegt. Es besteht keine Zertifizierung nach Art. 42 DSGVO und keine ISO-Zertifizierung; wir behaupten auch keine.

Kurz und ohne Fachsprache: Die Zugangstoken liegen nur verschlüsselt in der Datenbank. Die Anwendung arbeitet mit einem Datenbankkonto, das absichtlich wenig darf. Die Daten verschiedener Shops sind voneinander getrennt. Eingehende Nachrichten werden auf Echtheit geprüft, bevor irgendetwas passiert. Und Zugangsdaten landen nicht in Protokollen. Die Absätze darunter sagen dasselbe mit den Fachbegriffen, damit eine Prüferin die Angaben nachvollziehen kann.

11.1 Vertraulichkeit

• Verschlüsselung im Ruhezustand. Verschlüsselt gespeichert werden (Verfahren AES-256-GCM): Access- und Refresh-Token, Ihre Kontaktadresse und — seit dem Bestellablauf — der Gutscheincode, das Abruf-Token, der Empfängername, die E-Mail-Adresse des Beschenkten, der Absendername und der Grußtext. Jeder verschlüsselte Wert trägt eine Schlüsselkennung, die kryptografisch an ihn gebunden ist — ein nachträgliches Umschreiben der Kennung fällt beim Entschlüsseln auf. Diese Feldverschlüsselung wirkt bis in die Sicherungen hinein, siehe 9.6.
• Die Datenbank lässt Klartext in einer verschlüsselten Spalte nicht zu. Jede dieser Spalten trägt eine Prüfregel auf das Format eines Chiffrats, jede Suchwertspalte eine auf 64 Hexzeichen. Ein Wert, der versehentlich im Klartext geschrieben würde, scheitert damit beim Schreiben — statt jahrelang unbemerkt dort zu liegen, weil Lesen und Schreiben weiterhin funktionieren.
• Der Gutscheincode wird auch gegenüber Shopify nicht preisgegeben, wo es nicht nötig ist. Kartuu erzeugt ihn selbst und übergibt ihn beim Anlegen der Geschenkkarte; die Notiz, die dabei an der Karte hinterlegt wird, enthält keine Personendaten. Wer beschenkt wird, steht in unserer verschlüsselten Spalte und nicht in einem Freitextfeld bei Shopify.
• Getrennte Schlüsselableitung. Der Suchhash nutzt nicht den rohen Verschlüsselungsschlüssel, sondern einen daraus abgeleiteten eigenen Schlüssel.
• Keine optionale Verschlüsselung. Die Anwendung startet ohne gültigen Schlüssel nicht. Es gibt keinen Betriebsmodus, in dem die Verschlüsselung abgeschaltet wäre.
• Mandantentrennung auf Datenbankebene. Jede Tabelle mit einer Shop-Kennung (shop_id) hat eine Zeilenfilterung in der Datenbank aktiviert und erzwungen (Row-Level-Security). Ohne gesetzten Mandanten liefert die Datenbank für diese Tabellen keine Zeile — kein Mandant, kein Zugriff.
• Ausnahme: die Tabelle shops selbst. Sie trägt keine Zeilenfilterung, denn sie ist die Shop-Tabelle und hat keine shop_id-Spalte. Dort wirkt die Trennung ausschließlich über die Anwendung — jede Abfrage läuft über den Suchhash der Shop-Domain — und über spaltenweise vergebene Rechte. Das ist heute die einzige Tabelle mit produktiven Händlerdaten; wir nennen es deshalb ausdrücklich statt es unter der allgemeinen Zusage zu verstecken. Siehe auch Abschnitt 12.
• Entrechtete Datenbankrolle. Die Anwendung verbindet sich mit einem Datenbankkonto, das die Zeilenfilterung nicht umgehen kann und nicht Eigentümer der Tabellen ist. Fällt diese Trennung im Betrieb weg, bricht die Anwendung den Start ab, statt ohne wirksame Mandantentrennung weiterzulaufen.
• Rechte spaltenweise statt tabellenweit. Schreibrechte bestehen nur auf den Spalten, die tatsächlich geschrieben werden. Auf dem PCD-Zugriffsprotokoll gibt es bewusst kein Änderungsrecht, damit Einträge nachträglich nicht veränderbar sind. Bei den Gutscheinen wirkt dasselbe Mittel an zwei Stellen: Die Anwendung darf beim Anlegen weder den Zustand noch den Zeitpunkt setzen — ein neuer Gutschein kann deshalb gar nicht als „bereit" entstehen —, und Bestellung, Position, laufende Nummer und Abruf-Token lassen sich nachträglich nicht ändern. Auf der Zuordnungstabelle der Bildmotive und auf der Tabelle der Gutscheinprodukte gibt es überhaupt kein Änderungsrecht: Welche Bilder in einer ausgestellten Karte stecken, ist eine Tatsache über die Vergangenheit, und ein Produkt, das der Händler in Shopify verändert hat, gehört ihm.
• Mandantentrennung auch im Objektspeicher. Der Schlüssel eines Bildes beginnt mit der Kennung seines Shops. Zwei Händler, die dasselbe Motiv hochladen, bekommen deshalb zwei getrennte Objekte — ohne diesen Anfang wären es zwangsläufig dasselbe, und das Löschen des einen Shops nähme dem anderen sein Bild weg. Jeder Schlüssel wird an jeder Stelle gegen ein festes Muster geprüft, bevor daraus ein Pfad wird. Die Objekte sind nicht öffentlich lesbar; sie erreichen Ihren Browser nur eingebettet im gerenderten Dokument. Test- und Produktivbetrieb schreiben in getrennte Eimer — dieselbe interne Nummer kann in beiden Datenbanken vergeben sein, ein gemeinsamer Eimer brächte damit zwei Shops in denselben Namensraum.
• Keine Zugangsdaten in Protokollen. Siehe 5.2.
• Trennung von Test und Produktion. Zwei getrennte Umgebungen mit je eigener Datenbank, eigenem Verschlüsselungsschlüssel, eigener Datenbankrolle, eigener Domain und eigener Shopify-App.
• Container ohne Administratorrechte, eigener unprivilegierter Benutzer.

11.2 Integrität

• Signaturprüfung vor jeder Arbeit. Eingehende Webhooks werden anhand eines Prüfwerts über den unveränderten Nachrichteninhalt geprüft (HMAC-SHA256), und zwar mit einem Vergleich, dessen Laufzeit keine Rückschlüsse zulässt — und vor jeder weiteren Verarbeitung, damit niemand ohne gültige Signatur den Duplikatschutz blockieren kann.
• Strenge Prüfung des Session-Tokens. Erzwungenes Signaturverfahren, Vergleich in konstanter Zeit, enge Zeittoleranzen, Schutz gegen das erneute Einspielen eines bereits benutzten Tokens, Prüfung von Empfänger und Aussteller gegeneinander.
• Sicherheitskopfzeilen für die eingebettete Oberfläche: Content-Security-Policy mit geprüftem Shop-Parameter (bei Mehrdeutigkeit wird abgelehnt statt geraten), X-Content-Type-Options: nosniff, restriktive Referrer-Richtlinie.
• Keine API-Dokumentation in der Produktion. Schema und Oberflächen unter /docs und /redoc sind dort abgeschaltet.
• Schutz vor SQL-Injektion durch Bauart. Die Datenzugriffsschicht kann ohne Shop-Kennung keine Abfrage bilden; Tabellennamen werden gegen eine Freigabeliste geprüft, Werte ausschließlich als Parameter übergeben. Ein rohes SQL-Fragment lässt sich nicht übergeben.
• Begrenzter Anfragekörper. Jede Anfrage, die Daten mitschickt, trägt einen Deckel: 4 Kilobyte beim Zustimmungsschritt — mehr braucht er nie, er trägt eine E-Mail-Adresse und ein Häkchen —, 8 Kilobyte bei Vorschau und PDF-Abruf. Die Grenze wirkt vorab gegen die angekündigte Länge und, entscheidend, während des Einlesens: Es wird abgebrochen, sobald die Grenze überschritten ist. Eine Anfrage, die ihre Länge verschweigt, kann den Arbeitsspeicher damit nicht mehr füllen. Es gibt dafür genau eine Umsetzung, die alle drei Anfragen benutzen.
• Geprüfte Eingaben im Gutschein-Editor. Alles, was der Händler für eine Karte eintippt, wird serverseitig geprüft, bevor es in ein Dokument gelangt: feste Erlaubnislisten statt freier Werte (Vorlage, Ebenentyp, Fläche, Ausrichtung, Schrift, Platzhaltername), Farben nur als Hexwert oder „transparent“, Längengrenzen je Feld, Zahlen nur innerhalb benannter Grenzen, und Steuerzeichen werden entfernt. Ein unbekannter Wert wird abgelehnt und nicht stillschweigend ersetzt. Einzelheiten stehen in Anlage 2 Abschnitt 2.5 des Auftragsverarbeitungsvertrages.
• Geprüfte Bilder. Ein hochgeladenes Bild ist die einzige Datei, die von außen in die App gelangt, und wird deshalb einmal beim Hochladen vollständig geprüft — nicht bei jedem Zeichnen, denn dann läge die Rohdatei bereits im Objektspeicher. Angenommen werden nur JPEG, PNG, WebP und SVG; welches Format vorliegt, entscheidet der Inhalt und nicht Ihre Angabe (der angegebene Typ wird gar nicht gelesen, einen Dateinamen kann die Anfrage nicht mitschicken). Die Größe ist auf 5 Mebibyte gedeckelt, und der Deckel wirkt auch während des Einlesens. Gegen Bilder, die beim Entpacken den Arbeitsspeicher sprengen, greifen Pixelgrenzen (höchstens 6000 Bildpunkte je Kante, höchstens 12 Millionen insgesamt), und zwar bevor das Bild entpackt wird. Ein SVG wird um alles Ausführbare bereinigt — Skript, eingebettetes HTML, Formatvorlagen, jeder Verweis nach draußen —, und gespeichert wird die bereinigte Fassung; was danach nichts mehr zeichnen würde, wird abgelehnt statt leer gespeichert. Einzelheiten in Anlage 2 Abschnitt 2.6 des Auftragsverarbeitungsvertrages. Nicht entfernt werden die Aufnahmedaten eines Fotos — siehe 5.1.
• Ratenbegrenzung des Renderers. Je Shop und Minute sind zwölf Vorschauen und sechs PDF-Abrufe zugelassen. Damit kann ein einzelner Shop die Anwendung nicht für die übrigen lahmlegen. Der Zähler hängt an der Shop-Domain aus dem geprüften Session-Token und nicht an einer Angabe aus der Anfrage. Das Hochladen hat ein eigenes Kontingent von zehn Bildern je Shop und Minute — getrennt, damit ein Upload nicht das Kontingent aufbraucht, mit dem Sie anschließend Ihre Karte ansehen wollen.
• Der Bestellablauf verliert nichts und verdoppelt nichts. Drei Maßnahmen greifen ineinander, und jede verhindert einen benannten Fehler:
• Ein Idempotenzschlüssel je Stück. Shop, Bestellung, Bestellposition und laufende Nummer bilden zusammen einen eindeutigen Index in der Datenbank. Shopify wiederholt einen Webhook über bis zu 48 Stunden; eine Wiederholung trifft damit auf dieselben Zeilen und erzeugt keine zweiten Gutscheine. Das ist keine Sorgfalt des Programms, sondern eine Bedingung der Datenbank.
• Der Zustandslauf steht an einer Stelle. Ein Gutschein durchläuft zehn benannte Zustände, und welche davon es gibt, erzwingt eine Prüfregel in der Datenbank. Der Wechsel selbst hängt die erlaubten Vorgängerzustände an die Schreibanweisung an — zwei gleichzeitig laufende Arbeiter können denselben Gutschein damit nicht zweimal weiterschalten. Ein Gutschein gilt außerdem erst dann als ausgestellt, wenn Code und Vorlagenabbild vorhanden sind; die Datenbank lässt einen ausgestellten Gutschein ohne beides gar nicht zu.
• Der Code steht in unserer Zeile, bevor die Geschenkkarte bei Shopify entsteht. Das Anlegen einer Geschenkkarte kennt bei Shopify keinen Wiederholungsschutz — jeder Aufruf legt eine neue Karte mit neuem Guthaben an. Kartuu schreibt deshalb zuerst den Code und ruft Shopify danach. Bricht etwas dazwischen ab, wiederholt der nächste Anlauf den Aufruf mit demselben Code; weil ein Gutscheincode je Shop eindeutig ist, entsteht entweder die fehlende Karte oder Shopify lehnt den Code als vergeben ab. Am Ende existiert genau eine bezahlte Karte, nicht zwei.
• Ein Bild, das in einer ausgestellten Karte steckt, lässt sich nicht löschen. Die Zuordnung ist ein Fremdschlüssel in der Datenbank, keine Absichtserklärung. Beim Löschen eines ganzen Shops wird die Prüfung bis zum Abschluss der Transaktion aufgeschoben — sonst scheiterte shop/redact ausgerechnet bei den Händlern, die die App am meisten benutzt haben.
• Keine Geheimnisse im Quellcode-Repository. Ein automatischer Prüfhaken sucht vor jedem Commit nach Zugangsdaten; Konfigurationsdateien mit Geheimnissen sind vom Repository und vom Container-Abbild ausgeschlossen.

11.3 Verfügbarkeit

• Tägliche Datenbanksicherung, mit AES-256 verschlüsselt, bevor sie den Server verlässt, abgelegt auf dem Server (30 Tage) und im Objektspeicher der IONOS in Berlin (90 Tage, zusätzlich abgesichert durch eine Lebenszyklusregel im Eimer). Damit liegt eine Kopie außerhalb des Servers: Ein Ausfall des Datenträgers nimmt nicht mehr Datenbank und Sicherung zugleich mit. Einzelheiten in 9.6.
• Die Sicherung prüft sich selbst und wird überwacht. Ein zu kleiner Abzug führt zum Abbruch; vor dem Hochladen wird die verschlüsselte Datei probeweise wieder geöffnet, nach dem Hochladen beim Speicher zurückgefragt. Ein täglicher Prüflauf meldet ausgebliebene Sicherungen. Dass sich eine Sicherung einspielen lässt, ist am 01.08.2026 durch eine tatsächliche Wiederherstellung geprüft worden.
• Zeitlimit bei Sperrkonflikten, damit ein Konflikt in einer sauberen Fehlermeldung endet statt in einem hängenden Prozess.
• Schemaänderungen laufen vor dem Start in einem eigenen Prozess; kein Arbeitsprozess sieht ein halbfertiges Schema.

11.4 Belastbarkeit der Löschung

• Der Löschpfad ermittelt die betroffenen Tabellen aus dem Datenbankschema statt aus einer gepflegten Liste und läuft in einer einzigen Transaktion.
• Automatische Prüfungen im Testlauf erzwingen, dass jede neue Tabelle mit Shop-Bezug über den Löschpfad erreichbar ist und ein Löschrecht trägt, und dass jede Spalte mit personenbezogen klingendem Namen in der Liste der Kundendatentabellen eingetragen ist.
• Grenze beider Punkte: Sie arbeiten auf demselben Ergebnis wie der Löschpfad und tragen deshalb dieselben Einschränkungen wie in 9.2 beschrieben — anderes Schema, abweichender Spaltenname, Views, nur mittelbar verknüpfte Tabellen. Die Tabelle shops ist von diesen Prüfungen ausdrücklich ausgenommen, weil sie keine shop_id-Spalte hat.
• Weitere Grenze: Der Löschpfad kennt nur die Datenbank. Die Bytes Ihrer hochgeladenen Bildmotive liegen nicht dort, sondern im Objektspeicher. Sie werden auf einem eigenen Weg gelöscht — über den Namensraum Ihres Shops, vor den Zeilen und nur über shop/redact. Die automatischen Prüfungen oben erfassen diesen Weg nicht; die beiden Folgen davon stehen in 9.2.
• Eine benannte Ausnahme: Ihre Kontaktadresse steht in der Tabelle shops und trägt einen Spaltennamen, den die Prüfung sonst als Kundendatum beanstanden würde. Die Ausnahme ist eingetragen und begründet: Es sind Händlerdaten, keine Kundendaten; sie tragen keine Kundenkennung, und sie verschwinden über shop/redact und über den Aufräumlauf nach 9.3. Sie gilt genau für diese eine Spalte und nicht für die Tabelle: Käme eine weitere Spalte mit einem solchen Namen hinzu, schlüge die Prüfung an. Bis zum 26.07.2026 war die Ausnahme tabellenweit gefasst und hätte jede künftige Spalte dieser Tabelle mitverdeckt.

11.5 Umgang mit Vorfällen

Es besteht ein Verfahren für Datenschutzvorfälle mit Eskalationsstufen, der 72-Stunden-Meldefrist nach Art. 33 DSGVO, benannter Aufsichtsbehörde und einem ausdrücklichen Hinweis auf die Informationspflicht nach Art. 14 DSGVO gegenüber Beschenkten.

11.6 Verfügbarkeit — und was daran offen ist

Die Sicherungen sind verschlüsselt und liegen getrennt vom laufenden System (9.6). Der Schlüssel, mit dem Zugriffstoken und Kontaktadressen verschlüsselt sind, wird außerhalb der Datenbank verwahrt.

Am 01.08.2026 geschlossen: Der Wiederherstellungstest ist durchgeführt und die Überwachung der Sicherungen eingerichtet (Einzelheiten in 9.6). Ebenfalls angelegt sind die Zweitkopien der Schlüssel — sowohl des Schlüssels, mit dem Token und Kontaktadressen verschlüsselt sind, als auch des Kennworts der Sicherungsdateien. Sie werden außerhalb des Servers verwahrt. Ohne sie wären Ihre Daten auch aus einer vorhandenen Sicherung nicht mehr lesbar gewesen.

Zwei Punkte sind an dieser Stelle noch nicht abgeschlossen, und sie stehen hier, weil eine Sicherheitsbeschreibung, die nur die gelungenen Maßnahmen nennt, keine ist:

• Der Herausgabeweg der Schlüssel im Vertretungsfall ist nicht geregelt. Die Zweitkopien gibt es; wer sie herausgeben darf, wenn die technische Leitung ausfällt, entscheidet die Geschäftsführung und ist offen. Getrennte Verwahrung der beiden Geheimnisse bleibt dabei Bedingung — beide an einem Ort hebt die Trennung auf, die sie erst wirksam macht.
• Eine Verfügbarkeitsüberwachung von außerhalb des Servers fehlt. Die Überwachung der Sicherungen läuft auf demselben Server wie die Sicherung selbst und schweigt daher, wenn dieser Server ausfällt. Ein solcher Ausfall fällt derzeit dadurch auf, dass die Anwendung nicht erreichbar ist.

Beides betrifft die Verfügbarkeit Ihrer Daten und nicht ihre Vertraulichkeit: Es gibt keinen Weg, auf dem einer dieser Punkte zu einem Zugriff Unbefugter führen könnte. Beide sind in der Betriebsdokumentation als offene Aufgaben geführt.

12. Offene Punkte in diesem Entwurf

12.1 Seit dem vorherigen Entwurf geschlossen

Damit niemand einer überholten Fassung folgt, hier zuerst, was nicht mehr offen ist:

• Sicherungen. Sie liegen nicht mehr nur lokal. Seit dem 26.07.2026 gehen sie zusätzlich in den Objektspeicher der IONOS in Berlin; Fristen 30 Tage lokal, 90 Tage im Objektspeicher. IONOS ist damit Unterauftragsverarbeiter auch für die Sicherungen. Siehe 9.6 — dort auch, was zur Verschlüsselung zugesagt wird und was nicht.
• Cloudflare. Nachgemessen: für Kartuu reiner autoritativer DNS-Dienst, kein Proxy, kein Auftragsverarbeiter. Siehe Abschnitt 7.
• Aufbewahrungsfristen. Festgelegt: Sicherungen 30/90 Tage, verwaiste Shops 30 Tage, nie verbundene Shops 90 Tage, Webhook-Kennungen 30 Tage, Protokolle 14 Tage. Das PCD-Zugriffsprotokoll verschwindet mit dem Shop und fällt damit unter dieselbe 30-Tage-Regel.
• Zustimmung und Vertragsschluss. Der Auftragsverarbeitungsvertrag kommt durch Zustimmung im Installationsablauf zustande, mit Nachweis in der Datenbank. Siehe Abschnitt 3 und 5.3.
• Kontaktadresse des Händlers. Wird als Pflichtfeld erhoben. Siehe 5.3.
• Deinstallation ohne shop/redact. Ein Aufräumlauf löscht die Shop-Zeile nach 30 Tagen. Siehe 9.3.
• Datensätze, für die es nie einen Deinstallationszeitpunkt gab. Ein gescheiterter Verbindungsversuch nach einer Deinstallation hob den Zeitpunkt zuvor auf; der Datensatz war danach für die 30-Tage-Regel unsichtbar und wäre dauerhaft stehen geblieben. Der Zeitpunkt wird jetzt erst nach einem erfolgreichen Tokenabruf aufgehoben, und eine zweite Regel im selben Aufräumlauf greift nach 90 Tagen. Siehe 9.3.
• Fehlerpfad des Zugriffsprotokolls. Angeglichen: nur noch der Ausnahmetyp, keine vollständige Meldung mit Aufrufkette. Siehe 5.2.
• Webhooks zu Shops ohne Zustimmung. Früher hieß es, ohne Zustimmung finde überhaupt keine Verarbeitung statt. Das traf für den Datensatz zum Shop zu, nicht aber für die von Shopify unabhängig davon gesendeten Webhooks. Der Fall steht jetzt mit Inhalt, Zweck, Rechtsgrundlage und Frist in der Tabelle in 5.1.
• Hilfstabelle test_notizen. Aus dem Produktivschema entfernt.
• Zeitform. Geklärt: Präsens nur für das, was das Programm tut. Was nur vorgesehen ist — die Zustellung, der Abruf über den Link, das Deaktivieren einer Geschenkkarte — steht ausdrücklich getrennt davon. Siehe Abschnitt 4.
• Route für die beiden Rechtstexte. Gebaut. Beide Adressen liefern den Text aus, ohne Anmeldung. In der Produktivumgebung bleibt die Auslieferung gesperrt, solange dieser Entwurf offene Stellen trägt — die App startet dort nicht, statt einen Entwurf wie einen fertigen Vertragstext auszuliefern. Siehe Abschnitt 3.
• Bezahlmodell. Eingeführt, und zwar über die von Shopify verwalteten App-Tarife: Auswahl und Zahlung laufen bei Shopify, Kartuu liest nur, ob ein aktives Abonnement besteht, und verlangt es für den PDF-Abruf. Zahlungsdaten verarbeiten wir nicht. Siehe 5.1 und 5.3.
• PDF-Erzeugung. Es gibt sie seit dem 26.07.2026, zunächst nur für Angaben, die der Händler selbst eintippt. Seit dem Bestellablauf entsteht ein PDF auch aus einer bezahlten Bestellung. Gespeichert wird es in beiden Fällen nicht. Siehe 4.2 und 6.1.
• Der Bestellablauf war in diesen Texten nicht abgebildet — und zwar in ihren Kernaussagen. Diese Erklärung sagte „Kartuu speichert heute keine Daten Ihrer Kundschaft", „orders/paid ist nicht abonniert", „genau eine Frage an die Admin-API" und „das Ergebnis einer Auskunft ist nachweislich leer". Die Software nahm zu diesem Zeitpunkt bereits bezahlte Bestellungen entgegen, speicherte Empfänger-, Absender- und Codedaten verschlüsselt und legte Geschenkkarten bei Shopify an. Nachgeführt sind jetzt: die neuen Datenkategorien und die drei betroffenen Personen (6.1), die Löschwirkung nach Zweckfortfall (6.2, 9.5, 9.5a), die tatsächliche Ausübung der Berechtigungen samt der beiden neuen Scopes write_gift_cards und write_products (4.3), die sechs Aufrufe an die Admin-API (4.2, Abschnitt 7) und die Maßnahmen des Bestellablaufs (11.1, 11.2).
• Die Ablage hochgeladener Bilder war in diesen Texten nicht abgebildet. Diese Erklärung sagte für alles, was der Händler eingibt, „keine Speicherung", und der Objektspeicher stand nur als Sicherungsablage. Die Software konnte zu diesem Zeitpunkt bereits Bilder annehmen, prüfen und ablegen. Die Bildmotive stehen jetzt mit Herkunft, Zweck, Rechtsgrundlage und Löschung in 5.1, der Objektspeicher mit beiden Zwecken in Abschnitt 7, die Löschung in 9.2, die Prüfung beim Hochladen in 11.2 — und die nicht entfernten Aufnahmedaten in 5.1 und 12.3.

12.2 Weiterhin offen

Im Text dieser Erklärung ist nichts mehr offen. Die Punkte unten sind entweder am 01.08.2026 entschieden worden — dann steht die Entscheidung in der Spalte „Was" — oder sie sind Aufgaben außerhalb dieses Textes, die an ihrer Sachstelle beschrieben sind und in der Betriebsdokumentation nachgehalten werden. Die Nummern 7, 12 und 13 sind als offene Stellen weiterhin im Auftragsverarbeitungsvertrag markiert und halten den Auslieferungsriegel geschlossen (siehe Abschnitt 3).

12.3 Bekannte Grenzen, die keine Entscheidung erfordern

Diese Punkte sind keine offenen Fragen, sondern benannte Eigenschaften des heutigen Stands. Sie stehen hier, damit sie nicht in Vergessenheit geraten:

• Kein Zeilenschutz auf der Tabelle shops. Die einzige Tabelle mit produktiven Händlerdaten trägt keine Zeilenfilterung in der Datenbank; die Trennung wirkt dort über die Anwendung und über spaltenweise Rechte. Siehe 11.1.
• Löschpfad mit vier Grenzen (anderes Schema, abweichender Spaltenname, Views, nur mittelbar verknüpfte Tabellen). Heute ohne Auswirkung, mit jeder neuen Tabelle relevanter. Siehe 9.2 und 11.4.
• Nur die zuletzt erteilte Zustimmung wird gespeichert, keine Historie. Gebraucht wird eine Verlaufstabelle, bevor eine Fassung erhöht wird, zu der bereits ein Händler zugestimmt hat. Beim Schritt von 1.0 auf 1.1 traf das nicht zu: Zu 1.0 lag keine einzige Zustimmung vor, weil die Produktions-App nie ausgerollt war. Beim nächsten Mal wird es sehr wahrscheinlich zutreffen.
• Gelöschtes bleibt in Sicherungen bis zum Ablauf der Fristen aus 9.6.
• Aufnahmedaten hochgeladener Bilder werden nicht entfernt. Trägt ein Foto aus einem Mobiltelefon einen Standort, bleibt er im gespeicherten Bild und reist in das erzeugte PDF mit. Der Grund ist benannt: Ein Entfernen hieße, das Bild neu zu berechnen — bei JPEG mit sichtbarem Qualitätsverlust bei jedem Hochladen, und der Inhalt entspräche danach nicht mehr der Prüfsumme, unter der er abgelegt ist. Solange die Bilder vom Händler stammen, ist das vertretbar; sobald eine Kundin oder ein Beschenkter selbst ein Bild hochladen kann, ist es das nicht mehr, und diese Entscheidung steht dann neu an. Siehe 5.1.
• Bilder werden mit dem Shop gelöscht — über shop/redact und, wenn der ausbleibt, über den Aufräumlauf nach 9.3, der seit dem 01.08.2026 täglich läuft. Es gibt keinen Aufräumlauf für ungenutzte Motive und keine Löschfunktion in der App. Beides ist in 9.2 ausgeführt; die Löschung eines einzelnen Bildes auf Verlangen erfolgt von Hand.
• Für die Bildmotive gibt es keine Sicherung. Siehe 9.6.
• Die Auskunft nach Art. 15 wird nicht zugestellt. Kartuu stellt sie beim Eingang des Webhooks zusammen, hält die Anfrage und die Anzahl der Datensätze fest und verwirft den Inhalt. Es gibt keine Seite, auf der ein Shop sie abrufen könnte, und keinen Versand an ihn; die Herausgabe erfolgt auf Anforderung in Textform und von Hand. Siehe 6.4 und 10.2.
• Ein Datensatz mit hinterlegten Token nach einem Schlüsselwechsel wird von keiner der beiden Aufräumregeln erfasst: Er ist von dem eines arbeitenden Shops nicht zu unterscheiden. Zu beheben durch Neuberechnen der Suchwerte nach jedem Schlüsselwechsel. Siehe 9.3.
• Derselbe Schlüsselwechsel träfe auch die Suchwerte der Gutscheindaten. Der Wert, über den eine beschenkte Person gefunden wird, hängt am Verschlüsselungsschlüssel. Wird er gewechselt, ohne die Suchwerte neu zu berechnen, fände eine Löschung nach Art. 17 ihre Zeilen nicht mehr — und meldete trotzdem Vollzug. Ein Lauf zum Neuberechnen ist als Pflichtschritt einer Rotation im Quelltext festgehalten, aber nicht gebaut. Solange nur ein Schlüssel im Einsatz ist, tritt der Fall nicht ein. Siehe 5.1 und 6.2.
• Der Abruflink wird erzeugt, bevor es die Seite dahinter gibt. Zu jedem Gutschein entsteht ein Abruf-Token, weil der Link später in einer Bestellbestätigung stehen soll, die sich nachträglich nicht mehr ändern lässt. Die Route dafür ist nicht gebaut; der Link führt heute ins Leere. Siehe 4.2.
• Ein Gutscheincode, den Shopify als vergeben abweist, endet in einem sichtbaren Fehlzustand und nicht in einer zweiten Karte. In dieser Lage kann eine Geschenkkarte bei Shopify existieren, deren Kennung wir nicht kennen — der Händler sieht das im Statusbildschirm.
• Was noch aussteht und den Datenkatalog erneut verändern wird — vorgesehen sind das Wunschversanddatum und das Deaktivieren einer Geschenkkarte beim Storno. Gespeichert wird davon heute nichts, und es gibt keine Spalte dafür. Der Versand per E-Mail samt SMTP-Zugangsdaten des Händlers stand bis zum 01.08.2026 ebenfalls in dieser Liste; er ist gebaut, die Zugangsdaten liegen verschlüsselt in der Datenbank, und diese Erklärung führt ihn oben. Sie und der AVV müssen mit jeder weiteren Erweiterung erneut gegen den Quelltext geführt werden.

12.4 Belege der Angaben über Dritte

Die Angaben über Shopify und IONOS in den Abschnitten 7 und 8 sind nicht geschätzt, sondern am 01.08.2026 aus den öffentlichen Angaben der Anbieter entnommen. Wer sie prüfen will, findet sie hier — und wer sie ändert, sollte sie hier erneut prüfen:

Was diese Belege nicht leisten. Sie zeigen, was die Anbieter öffentlich erklären. Sie ersetzen nicht die Vertragsunterlagen, die für Kartuu tatsächlich gelten — welche Gesellschaft im Einzelfall Vertragspartnerin ist und welche Fassung eines Addendums vereinbart wurde, steht im jeweiligen Vertrag. Die Punkte 7 und 12 der Liste in 12.2 bleiben deshalb offen.

13. Änderungen dieser Erklärung

Kartuu wird weiterentwickelt. Ändert sich der Umfang der Verarbeitung, ändern wir diese Erklärung vorher und erhöhen die Fassungskennung. Die jeweils geltende Fassung steht unter https://kartuu.kyth.systems/rechtliches/datenschutz; solange sie dort nur in den Testumgebungen ausgeliefert wird (siehe Abschnitt 3), erhalten Sie sie auf Anfrage an datenschutz@kyth.systems.

Steigt die Fassungskennung, werden Sie beim nächsten Öffnen der App erneut um Zustimmung gebeten. Eine reine Tippfehlerkorrektur löst das nicht aus.

Verarbeitung zu einem anderen Zweck. Beabsichtigen wir, Ihre Daten zu einem anderen als dem ursprünglich erhobenen Zweck zu verarbeiten, informieren wir Sie vorab über diesen anderen Zweck und über alle weiteren Angaben nach Art. 13 Abs. 2 DSGVO (Art. 13 Abs. 3 DSGVO). Die Information erfolgt in Textform an die Kontaktadresse, die Sie uns nach 5.3 hinterlegt haben.

14. Stand

Fassung 1.1, 26.07.2026; abgebildeter Quelltextstand 01.08.2026. Gegenüber Fassung 1.0 desselben Tages sind der Admin-API-Client, der Abonnementstand, der Webhook app_subscriptions/update, der PDF-Renderer mit seiner Vorlagenauswahl und die Auslieferung dieser Texte unter /rechtliches/ hinzugekommen; die Angaben dazu stehen in 4.1, 5.1, 6.1 und 7.

Am 01.08.2026 sind alle offenen Stellen dieses Textes geschlossen worden — Anschriften der Empfänger (7), Grundlage der Drittlandübermittlung (8), Auslöser der Löschfristen (9.3, dafür wurde kaspar/aufraeumlauf.py gebaut), Zugriffsprotokolle (9.8) und die Verfügbarkeitspunkte (11.6). Die Belege stehen in 12.4.

Warum die Fassungskennung dabei nicht gestiegen ist. Sie zu erhöhen hat genau einen Zweck: jeden Händler erneut zu fragen, der einer älteren Fassung zugestimmt hat. Fassung 1.1 ist nie ausgeliefert worden — die Produktionsumgebung startet nicht, solange der Auftragsverarbeitungsvertrag offene Stellen trägt —, es gibt also keine einzige Zustimmung dazu. Eine Erhöhung fragte niemanden und nutzte die Regel ab, die sie durchsetzen soll. Die ausführliche Begründung steht im Kopf von kaspar/rechtstexte.py; sie kippt mit der ersten echten Zustimmung.

Zweiter Nachtrag innerhalb derselben Fassung: die Ablage hochgeladener Bildmotive — neue Datenkategorie in 5.1, Einschränkung der Aussage über Kundendaten in 6.1, der Objektspeicher als produktive Ablage in Abschnitt 7 und 8, die Löschung samt ihren zwei Grenzen in 9.2, die fehlende Sicherung in 9.6, die Prüfung beim Hochladen in 11.2 und die nicht entfernten Aufnahmedaten in 5.1 und 12.3.

Dritter Nachtrag innerhalb derselben Fassung — der Bestellablauf. Er ist der weitreichendste: Er hat die Kernaussage dieser Erklärung umgekehrt. Nachgeführt sind - die Verarbeitung von Bestell-, Kunden- und Empfängerdaten samt der drei betroffenen Personen (1, 3, 6.1), - die tatsächliche Ausübung von read_orders und die beiden neuen Berechtigungen write_gift_cards und write_products (4.3), - der Webhook orders/paid und die sechs Aufrufe an die Admin-API (4.1, 4.2, 5.1, 7), - die Löschung und Anonymisierung dieser Daten samt der fehlenden Frist nach Zweckfortfall (6.2, 9.2, 9.5, 9.5a), - die tatsächlich getroffenen Zeilen der beiden Datenschutz-Webhooks (6.4, 10.2), - die Maßnahmen des Bestellablaufs: verschlüsselte Codes und Empfängerangaben, Idempotenzschlüssel, Zustandslauf (11.1, 11.2), - und zwei neue offene Punkte in 12.2.

Was dabei nicht nachzuführen war, weil es sich damals nicht geändert hatte: Es gab zu jenem Zeitpunkt keinen Mailversand, kein gespeichertes PDF, keinen Abruf über den erzeugten Link und keine Abfrage von Bestellungen über die Admin-API. Der erste dieser vier Punkte gilt nicht mehr — die Zustellung ist gebaut und läuft seit dem 01.08.2026 über den Mailzugang des Händlers; diese Erklärung führt sie oben.

Warum die Fassungskennung dabei nicht gestiegen ist. Fassung 1.1 ist nie ausgeliefert worden: Die Produktions-App ist nicht ausgerollt, und die Route für die Rechtstexte verweigert dort den Dienst, solange offene Stellen im Text stehen. Es hat ihr also niemand zugestimmt, und es gibt keine Zeile in der Datenbank, die auf sie verweist. Eine Erhöhung auf 1.2 wäre eine Fassungshistorie ohne Leser — und sie würde die Regel entwerten, dass eine steigende Kennung jeden Händler erneut fragt.

⚠ Hinweis: nicht anwaltlich geprüft

Dieses Dokument wurde aus dem Quelltext und der Betriebsdokumentation von Kartuu erstellt und stellt keine Rechtsberatung dar.

Vor der Veröffentlichung — insbesondere vor der Einreichung im Shopify App Store — sollte es anwaltlich geprüft werden. Offene Stellen trägt es seit dem 01.08.2026 nicht mehr; der Auslöser der Aufräumläufe, der dafür zuerst gebaut werden musste, läuft seither (kaspar/aufraeumlauf.py). Was außerhalb dieses Textes noch aussteht, steht in 12.2.