Datenportabilität und Anbieterwechsel

Stand: 3. September 2026

Diese Seite beschreibt den derzeit verfügbaren Weg für einen Datenexport und die technischen Gegebenheiten der Plattform. Es gibt aktuell keine Exportfunktion im Kundenportal, keinen Downloadknopf für Kundendaten und keine automatisierte Übertragung zu einem anderen Anbieter.

Export anfragen

Der Export wird auf Anfrage durch den Anbieter zusammengestellt. Richten Sie die Anfrage in Textform an hello@stempelkarten.store. Teilen Sie mit, ob die Daten an Sie oder an einen anderen Anbieter bereitgestellt werden sollen. Passwörter, PINs oder Zugangsschlüssel gehören nicht in die Anfrage.

Fristen und weitere Voraussetzungen ergeben sich aus § 8 des mit Ihnen geschlossenen Hauptvertrags. Die Bereitstellung erfolgt nicht automatisch, sondern nach Bearbeitung der Anfrage durch den Anbieter.

Vor der Bereitstellung prüft der Anbieter die Berechtigung der anfragenden Person. Maßgeblich ist die im Konto hinterlegte Kontaktadresse des Betriebs: Der Anbieter antwortet ausschließlich an diese Adresse, auch wenn die Anfrage von einer anderen Adresse eingeht. Bestehen Zweifel an der Berechtigung, etwa bei einer kurz zuvor geänderten Kontaktadresse oder bei einer Anfrage im Namen eines Dritten, fragt der Anbieter über einen zweiten, bereits bekannten Weg nach; bis zur Klärung erfolgt keine Bereitstellung. Eine Bereitstellung an einen anderen Anbieter erfolgt nur nach ausdrücklicher Freigabe des Kunden in Textform von der hinterlegten Kontaktadresse aus. Die Bearbeitung beginnt, sobald die Anfrage vollständig ist und die zur Prüfung erforderlichen Angaben vorliegen.

Die Exportdateien werden in der Regel nicht als E-Mail-Anhang versendet. Der Anbieter stellt sie über einen gesondert erzeugten, nur für diese Anfrage gültigen HTTPS-Downloadlink bereit und teilt diesen an die hinterlegte Kontaktadresse mit. Der Link ist in der Regel 14 Kalendertage gültig; danach wird er ungültig und die bereitgestellte Kopie wird gelöscht. Innerhalb des Abrufzeitraums nach § 8 Abs. 7 des Hauptvertrags kann eine erneute Bereitstellung angefordert werden.

Verfahren und Formate

  • Strukturierte Daten werden als CSV-Dateien zusammengestellt. Bezüge zwischen Datensätzen können über die jeweiligen IDs nachvollzogen werden.
  • Gespeicherte Dateien werden in dem Format bereitgestellt, in dem sie im Dateispeicher vorliegen. Mehrere zusammengehörige Bestandteile können in einem ZIP-Archiv gebündelt werden.
  • Logos liegen als PNG, JPEG oder WebP vor. Speisekarten werden als PDF gespeichert. Streifenbilder und Hintergrundbilder der Landingpage werden beim Hochladen aufbereitet und als JPEG gespeichert; die ursprüngliche Uploaddatei bleibt nicht erhalten.
  • Ist eine Speisekarte nur über eine externe HTTPS-Adresse eingebunden, liegt auf der Plattform keine dazugehörige Datei vor. In diesem Fall kann der gespeicherte Linkwert exportiert werden.

Vorhandene Datenstrukturen

Der Datenbestand ist nach Betrieb und Konto zugeordnet und umfasst insbesondere:

  • Konto und Betrieb: Konto-ID und E-Mail-Adresse sowie Geschäftsname, Rechtsträger, Anschrift, Kontaktadresse, Slug, Tarif, Betriebsstatus, Standortdaten und die Konfiguration von Karte, Landingpage, Prämie, Nachrichten und Bewertungs-Erinnerung.
  • Karten: interne ID und Kartennummer, Zuordnung zum Betrieb, Stempelstand, Zahl eingelöster Prämien, Zeitpunkte sowie Einwilligungs- und Erinnerungsstatus. Dazu die freiwilligen Angaben der Endkunden, soweit der Betrieb sie eingeschaltet hat: der Anzeigename, der Bestätigungsstatus einer hinterlegten E-Mail-Adresse sowie Zeitpunkt und Wortlaut der dazu erteilten Einwilligung. Die E-Mail-Adresse selbst steht nicht in dieser Datei. Das interne Aktualisierungs-Token wird nicht exportiert.
  • E-Mail-Adressen von Endkunden: nur in einer gesonderten Datei und nur auf ausdrückliche Anforderung mit Angabe eines Grundes (Vertragsende, Anbieterwechsel oder Anfrage des Betriebs). Sie enthält Karten-ID, Kartennummer, Adresse und Bestätigungszeitpunkt, und zwar ausschließlich bestätigte Adressen. Hat der Betrieb die Abfrage der E-Mail-Adresse ausgeschaltet, wird die Datei nicht erstellt. Jede Bereitstellung wird mit Betrieb, Zeitpunkt, Grund und Zahl der Adressen protokolliert; das Protokoll enthält keine Adressen.
  • Stempelereignisse: Karten- und Mitarbeiterbezug, Ereignisart „Stempel“ oder „Einlösung“, Änderung des Stempelstands und Zeitpunkt.
  • Mitarbeiter: Name, Aktivstatus und die einzelne Berechtigung zum Versand von Nachrichten. PIN-Hashes werden nicht exportiert. Eine weitergehende Rollenstruktur gibt es derzeit nicht.
  • Nachrichten: Text, Versandzeitpunkt, Mitarbeiterbezug, Empfängerzahl und gegebenenfalls die Zuordnung zu einer einzelnen Karte.
  • Vertragsnachweise: Tarif, Vertrags- und AVV-Fassung, beim Abschluss festgehaltene Preise, Abschlusszeitpunkt und Zustellvermerk der Betreibermeldung.
  • Apple-Wallet-Registrierungen: Zuordnung zur Karte, Gerätebibliotheks-Kennung und Push-Token, soweit eine Übertragung technisch und rechtlich zulässig ist. Für Google Wallet speichert die Plattform keinen Geräte-Push-Token.
  • Dateien: Logos, aufbereitete Streifen- und Landingbilder im Bucket logos sowie hochgeladene Speisekarten-PDFs im Bucket menus.

Interne Sicherheits- und Missbrauchsprotokolle, Zugangsschlüssel, Zertifikate, Passwörter, PIN-Hashes und Daten anderer Kunden sind nicht Bestandteil des Exports. Das gilt ebenso für die internen Token der Endkunden-Funktionen (Verwaltung der eigenen Angaben, Bestätigung und Wiederherstellung einer Karte), für unbestätigte E-Mail-Adressen und für Angaben, deren Abfrage der Betrieb ausgeschaltet hat.

Beim Austausch eines Logos, Streifenbilds, Landingpage-Bilds oder einer Speisekarte legt die Plattform jeweils eine neue Datei an; die zuvor verwendete Datei bleibt im Dateispeicher erhalten. Der Standardexport enthält alle zum Betrieb gespeicherten Dateien einschließlich dieser früheren Fassungen. Welche Datei aktuell verwendet wird, ergibt sich aus der exportierten Betriebskonfiguration. Auf Wunsch beschränkt der Anbieter den Export auf die derzeit verwendeten Dateien.

Bekannte technische Grenzen

  • Es gibt keinen Selbstbedienungs-Export und keinen automatischen Wechselprozess.
  • Karten haben keinen eigenen Aktiv- oder Sperrstatus. Gespeichert sind Kartennummer, Stempelstand und Zeitpunkte; die öffentliche Verfügbarkeit wird auf Ebene des Betriebs gesteuert.
  • Mitarbeiterkonten besitzen keine frei definierbaren Rollen. Neben dem Aktivstatus gibt es nur die Berechtigung zum Nachrichtenversand.
  • Bereits ausgegebene Apple- und Google-Wallet-Karten sind an Pass-Type-ID, Zertifikate beziehungsweise Google-Issuer-ID des Betreibers gebunden. Diese Zugangsdaten werden nicht übertragen. Ein Datenexport überträgt daher keine funktionsfähige Wallet-Karte zu einem neuen Anbieter.
  • Für Streifen- und Landingbilder steht nur die gespeicherte, aufbereitete JPEG-Fassung zur Verfügung, nicht die ursprüngliche Uploaddatei.
  • Die Plattform erzeugt kein auf das Schema eines Zielanbieters abgestimmtes Importformat.

Offene Schnittstellen

Es gibt derzeit keine offene oder dokumentierte Schnittstelle für Datenexport, laufende Datensynchronisierung oder einen automatisierten Anbieterwechsel.

Die vorhandenen Schnittstellen dienen ausschließlich dem laufenden Betrieb: der Ausgabe und Aktualisierung von Apple-Wallet-Pässen, der serverseitigen Kommunikation mit Google Wallet sowie den geschützten Funktionen für Stempeln, Einlösen und Nachrichten. Sie sind keine allgemeine Exportschnittstelle.

IT-Infrastruktur und Schutzmaßnahmen

  • Die Anwendung läuft auf einem VPS der netcup GmbH in Deutschland. Der öffentliche Zugriff erfolgt über HTTPS; der interne Anwendungsport ist nur an die lokale Serveradresse gebunden.
  • Datenbank und Objektspeicher werden mit Supabase in der EU-Region Frankfurt betrieben.
  • Der Datenbankzugriff mit erhöhten Rechten erfolgt ausschließlich serverseitig. Der dafür verwendete Service-Role-Schlüssel wird nicht an den Browser ausgeliefert.
  • Zertifikate und Zugangsdaten liegen außerhalb des Anwendungsimages und sind auf dem Server durch Dateirechte beschränkt. Netzwerkzugriffe auf den VPS werden durch eine Firewall auf die erforderlichen öffentlichen Ports begrenzt.

Gerichtsbarkeit

Auf den Vertrag ist das Recht der Bundesrepublik Deutschland anwendbar (§ 12 Abs. 3 des Hauptvertrags). Die Anwendung läuft bei der netcup GmbH, Karlsruhe, auf Servern in Deutschland. Datenbank und Datei-Speicher betreibt die Supabase Pte. Ltd., Singapur; Serverstandort des Projekts ist Frankfurt am Main (AWS eu-central-1). Supabase setzt eigene Unterauftragsverarbeiter ein, unter anderem Amazon Web Services und Cloudflare. Ergänzende Fernzugriffe durch Supabase und deren Unterauftragsverarbeiter können auch außerhalb des Europäischen Wirtschaftsraums erfolgen. Maßgeblich sind § 5 und Anlage B des Auftragsverarbeitungsvertrags; dort steht auch die jeweils aktuelle Empfängerliste.

Schutz vor unzulässigen staatlichen Zugriffen

  • Die primäre Speicherung erfolgt in der Europäischen Union. Für Übermittlungen an die Supabase Pte. Ltd. gelten die EU-Standardvertragsklauseln (Durchführungsbeschluss (EU) 2021/914, Modul 3) nach dem Auftragsverarbeitungsvertrag von Supabase.
  • Nach Angaben von Supabase (Stand: September 2026) werden Kundendaten im Ruhezustand mit AES-256 und im Transport mit TLS verschlüsselt; Supabase ist nach ISO 27001 zertifiziert und SOC-2-Type-2-geprüft.
  • Zugangsschlüssel mit erhöhten Rechten liegen ausschließlich beim Anbieter und werden nicht an den Browser ausgeliefert.
  • Der Anbieter prüft behördliche Auskunfts- oder Herausgabeverlangen auf Zuständigkeit und Rechtsgrundlage und entspricht ihnen nur im rechtlich gebotenen Umfang. Ersuchen von Behörden aus Drittstaaten entspricht er nicht ohne ein zulässiges Rechtshilfe- oder Amtshilfeverfahren. Er unterrichtet den betroffenen Kunden, soweit ihm dies rechtlich erlaubt und tatsächlich möglich ist.
  • Zugriffe, die bei einem eingesetzten Dienstleister ohne Kenntnis des Anbieters erfolgen, kann der Anbieter nicht ausschließen.