Data portability and switching providers

The provider puts the export together on request. Send the request in text form to hello@stempelkarten.store. Say whether the data should go to you or to another provider. Passwords, PINs and access keys do not belong in the request.

Deadlines and further conditions follow from § 8 of the main contract you signed. The export is not produced automatically; the provider prepares it after handling the request.

Before handing anything over, the provider checks that the person asking is entitled to it. What counts is the contact address stored for the location: the provider replies only to that address, even when the request comes from a different one. If there is doubt, for instance because the contact address was changed shortly before the request or because someone asks on behalf of a third party, the provider asks back over a second, already known channel and hands nothing over until that is settled. Data goes to another provider only after the customer has released it in text form, from the stored contact address. Handling starts once the request is complete and the details needed for that check are in.

Export files are normally not sent as an email attachment. The provider puts them behind an HTTPS download link created for this one request and sends that link to the stored contact address. The link is normally valid for 14 calendar days; after that it stops working and the prepared copy is deleted. Within the retrieval period under § 8 para. 7 of the main contract you can ask for it to be prepared again.

• Structured data is put together as CSV files. Relations between records can be followed through the respective IDs.
• Stored files are handed over in the format they have in the file storage. Several parts that belong together may be bundled in a ZIP archive.
• Logos are held as PNG, JPEG or WebP. Menus are stored as PDF. Strip images and landing page background images are processed on upload and stored as JPEG; the original upload file is not kept.
• If a menu is only linked through an external HTTPS address, there is no file for it on the platform. In that case the stored link value can be exported.

Data is held per location and per account and covers in particular:

• Account and location: account ID and email address, plus business name, legal entity, address, contact address, slug, plan, location status, location data and the setup of the card, the landing page, the reward, messages and the review reminder.
• Cards: internal ID and card number, the link to the location, the stamp count, the number of rewards redeemed, timestamps and the consent and reminder status. On top of that the details your customers gave voluntarily, as far as the location switched them on: the display name, whether a stored email address was confirmed, and the time and wording of the consent given for it. The email address itself is not in this file. The internal update token is not exported.
• Customer email addresses: only in a separate file and only on an explicit request that states a reason (end of contract, change of provider, or a request by the location). It holds card ID, card number, address and the time of confirmation, and only confirmed addresses. If the location switched off asking for an email address, the file is not created. Every handover is logged with location, time, reason and the number of addresses; the log holds no addresses.
• Stamp events: the card and the staff member involved, the kind of event (a stamp or a redemption), the change to the stamp count and the time.
• Staff: name, active status and the single permission to send messages. PIN hashes are not exported. There is no wider role structure at present.
• Messages: text, time of sending, the staff member, the number of recipients and, where it applies, the link to a single card.
• Contract records: plan, contract and data processing agreement version, the prices recorded at signing, the time of signing and the delivery note of the operator notification.
• Apple Wallet registrations: the link to the card, the device library identifier and the push token, as far as handing them over is technically and legally permissible. For Google Wallet the platform stores no device push token.
• Files: logos and the processed strip and landing images in the logos bucket, and uploaded menu PDFs in the menus bucket.

Internal security and abuse logs, access keys, certificates, passwords, PIN hashes and other customers’ data are not part of the export. The same goes for the internal tokens behind the customer functions (managing your own details, confirming an address and restoring a card), for unconfirmed email addresses, and for details the location switched off.

When a logo, strip image, landing page image or menu is replaced, the platform creates a new file; the file used before stays in the file storage. The standard export holds every file stored for the location, earlier versions included. Which file is in use follows from the exported location setup. On request the provider limits the export to the files currently in use.

• There is no self-service export and no automated switching process.
• Cards have no active or blocked status of their own. What is stored is the card number, the stamp count and timestamps; public availability is steered at the level of the location.
• Staff accounts have no freely defined roles. Besides the active status there is only the permission to send messages.
• Apple and Google Wallet cards already in circulation are tied to the pass type ID and certificates, and to the Google issuer ID, of the operator. Those credentials are not handed over. A data export therefore does not move a working wallet card to a new provider.
• For strip and landing images only the stored, processed JPEG version is available, not the original upload.
• The platform does not produce an import format tailored to another provider’s schema.

There is no open or documented interface for data export, running data synchronisation or an automated change of provider.

The interfaces that do exist serve day to day operation only: issuing and updating Apple Wallet passes, server side communication with Google Wallet, and the protected functions for stamping, redeeming and messages. They are not a general export interface.

• The application runs on a VPS operated by netcup GmbH in Germany. Public access is over HTTPS; the internal application port is bound to the local server address only.
• Database and object storage run on Supabase in the EU region Frankfurt.
• Database access with elevated rights happens on the server only. The service role key used for it is never delivered to the browser.
• Certificates and credentials live outside the application image and are restricted by file permissions on the server. A firewall limits network access to the VPS to the public ports that are needed.

Jurisdiction

The contract is governed by the law of the Federal Republic of Germany (§ 12 para. 3 of the main contract). The application runs at netcup GmbH, Karlsruhe, on servers in Germany. Database and file storage are operated by Supabase Pte. Ltd., Singapore; the server location of the project is Frankfurt am Main (AWS eu-central-1). Supabase uses sub-processors of its own, among them Amazon Web Services and Cloudflare. Supporting remote access by Supabase and its sub-processors can also happen outside the European Economic Area. What governs this is § 5 and Annex B of the data processing agreement; the current list of recipients is there as well.

Protection against unlawful access by public authorities

• Primary storage is in the European Union. Transfers to Supabase Pte. Ltd. are covered by the EU standard contractual clauses (implementing decision (EU) 2021/914, module 3) under Supabase’s data processing agreement.
• According to Supabase (as of September 2026), customer data is encrypted at rest with AES-256 and in transit with TLS; Supabase is certified to ISO 27001 and has been audited to SOC 2 Type 2.
• Access keys with elevated rights stay with the provider and are never delivered to the browser.
• The provider checks requests for information or disclosure from public authorities for jurisdiction and legal basis and complies only as far as it is legally obliged to. It does not comply with requests from authorities in third countries without a permissible mutual legal assistance or administrative assistance procedure. It informs the affected customer as far as it is legally allowed to and practically able to.
• The provider cannot rule out access that happens at a service provider it uses without its knowledge.