Data Processing Agreement (DPA)

under Art. 28 GDPR – for the Shopify app Kartuu

This is an English translation. The legally binding version is the German one, the Vertrag über die Auftragsverarbeitung. This translation is provided for your convenience; where the two differ, the German version prevails.

Parties

Controller

The merchant who installs Kartuu in their Shopify shop. The merchant decides on the purposes and means of processing the data arising in their shop.

The merchant is identified towards the processor by two details, both of which are recorded when the contract is concluded under § 0:

1. their myshopify domain – it identifies the shop unambiguously and comes from the session proof signed by Shopify, so it cannot be freely claimed;
2. an email address as contact address, which the merchant enters themselves in the consent step (mandatory field, § 2a no. 4).

This makes it possible to keep a record of the controller's name and contact details within the meaning of Art. 30(2)(a) GDPR. KYTH does not itself collect the complete company details (company name, address, representation); they follow from the merchant's Shopify account and are requested through the contact address named above if needed.

Processor

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

Data protection officer: No data protection officer has been appointed. Under section 38 of the German Federal Data Protection Act (BDSG) there is no obligation to do so at the company's current size. The point of contact for data protection matters is datenschutz@kyth.systems; this is not a data protection officer within the meaning of Art. 37 GDPR.

Hereinafter “KYTH”.

§ 0 Conclusion of the contract

0.1 Consent in the installation process

This contract is concluded when the merchant agrees to it in the app's installation process. The process is as follows:

1. The merchant opens Kartuu in their Shopify admin and triggers the connection.
2. If there is no consent for the current version, the app does not carry out the process but shows the consent step: references to this contract, to the privacy policy and to the terms of service, a field for the contact address (mandatory field) and a consent checkbox that is not pre-ticked.
3. Only when the merchant has filled in both is the process carried out.

Without consent, nothing happens. Before consent, neither a record of the shop is created nor an access token obtained from Shopify. The check whether consent to the current version exists comes before every write access and before every call to Shopify.

One exception lies outside KYTH's influence. With the installation managed by Shopify, the app is already installed and the webhooks are already subscribed before the merchant opens the embedded page for the first time at all. If the merchant dismisses the consent step and uninstalls again, Shopify nevertheless sends app/uninstalled; if they sell something in the meantime, Shopify also sends orders/paid. KYTH receives these signed webhooks: the shop domain is converted into the search hash, looked up in the database and – if no shop belongs to it – noted in the application log for 14 days. No record of the shop is created in the process, and no voucher line either: without a shop record there is no tenant in which one could be created, and the content of the order is not evaluated further after the signature check. Only the technical webhook identifier is stored in the duplicate protection. This processing therefore takes place without a concluded contract, and for this reason it is listed as a case of its own in Annex 1 section A. The legal basis is Art. 6(1)(f) GDPR – legitimate interest in receiving, with a signature check, a webhook to which Shopify obliges us to subscribe, and in not silently swallowing an unknown shop –, additionally Art. 6(1)(c) GDPR insofar as receiving the data protection webhooks serves to fulfil the obligations under Art. 12 et seq. GDPR.

A separate signature is not required (Art. 28(9) GDPR expressly permits the electronic format).

0.2 Record

KYTH records the conclusion of the contract in the database – three details, either all or none:

The version identifier is set exclusively by the server; a value sent along by the browser has no effect.

The record outlasts an uninstallation. If the merchant reinstalls the app before the shop's data has been deleted – as a rule within 48 hours (§ 9.1) –, they do not have to consent again: their consent to exactly this version exists. The record disappears together with the deletion of the shop.

History: In addition to the most recently given consent on the shop row, the table zustimmungen records every consent given – append-only and without UPDATE: a record once written can no longer be changed. It is deleted together with the shop (§ 9). This keeps the record of an older consent when a version is increased. An entry carries the shop assignment, version identifier and time; it contains no personal detail.

0.3 Version in force and changes

The contract applies in the version whose identifier was recorded on consent. If KYTH changes the content of the text, KYTH increases the version identifier. Whoever installs the app afterwards agrees to the new version. For a merchant who agreed to an earlier version, it takes effect after the notice under the following paragraph, or KYTH asks them for consent again when they open the app. A mere correction of typing errors does not lead to a new identifier.

Independently of this, KYTH informs the merchant of a change to this contract at least 30 days before it takes effect in text form at the contact address stored under § 2a no. 4. If the merchant does not object within 30 days of receipt of the notice in text form, the new version is deemed accepted; if the merchant objects, either party can end the use of the app – the merchant by uninstalling.

KYTH sends this notice automatically from its own mailbox and records on the shop row which version it announced when (Annex 1 A).

0.4 Publication

The app delivers all three documents at https://kartuu.kyth.systems/rechtliches/ (/rechtliches/auftragsverarbeitung, /rechtliches/datenschutz and /rechtliches/nutzungsvertrag), without login and from the same source from which the version identifier comes. Independently of this, KYTH provides them on request sent to datenschutz@kyth.systems.

§ 1 Subject matter, duration, nature and purpose of the processing

1.1 Subject matter

KYTH provides the merchant with the Shopify app Kartuu. Kartuu is intended to generate and deliver personalised gift vouchers as PDFs from orders in the merchant's shop.

The following has been implemented:

1. Designing the voucher card in the admin: the merchant designs the card, types in sample details and receives a preview and a PDF back. The sample details are not stored; a design is stored only if the merchant saves it as a draft.
2. Setting up the voucher product in the merchant's shop, on the merchant's click.
3. The card preview on the product page, if the merchant places the Kartuu block there (Annex 1 section B).
4. The order process: Kartuu is subscribed to the orders/paid webhook. From a paid order with a voucher line item, one row per item purchased is created in the database – with the details the customer entered in the order form (recipient's name, recipient's email address, sender's name, greeting, desired delivery date), with the buyer's Shopify customer number and with a voucher code generated by Kartuu. For a value voucher, Kartuu uses it to create a real Shopify gift card through the Admin API. The card is then rendered. Only a line item whose product the merchant has set up in Kartuu as a voucher product counts as a voucher line item. If other products carry Kartuu details, the row is created in the state “Check product” – without a code, without a gift card and without a claim link – until the merchant releases or discards it in the order overview. Immediately before a voucher is issued, Kartuu queries the order's cancellation and payment status from Shopify; if it has been cancelled, fully refunded or the payment voided, no voucher is created.
5. The Kartuu block on the thank-you and order status page, if the merchant places it: it shows the buyer the status of their vouchers and, after a successful check, the claim links (Annex 1 section B).

Delivery has been implemented – through THE MERCHANT'S mail server. The merchant enters their own SMTP account in the app under “Settings”; Kartuu hands in the email through this account. It carries the rendered PDF as an attachment and a claim link. If the buyer has chosen a preferred date, Kartuu holds the email back until then; the merchant can bring it forward in the order overview with “Send now”. If the merchant enters nothing, Kartuu sends nothing for them: the voucher is generated, can be retrieved and downloaded, and the merchant hands it over themselves.

KYTH is not a processor at this point. The email to the recipient does not go through a sending route of KYTH's and not through a sub-processor of KYTH's, but through the mail provider the merchant has chosen and engaged themselves. Kartuu has no mail account of its own or shared mail account through which vouchers for all merchants would go out. KYTH's own mailbox carries only KYTH's notices to the merchant themselves (§ 2a no. 4) and never a voucher.

The rendered PDF is not stored; it is created anew with every delivery. What Kartuu actually processes today is listed exhaustively in Annex 1.

Pictures. The merchant can upload pictures – their logo, their product photo – so that a card template can draw them. These pictures are kept permanently: the bytes in the image storage (§ 3.4), the details about them (key, type, dimensions, size, checksum) in a database table. Annex 1 section A lists them with purpose, legal basis and deletion; the check on upload is set out in Annex 2 section 2.6.

If the range of functions is extended, this contract is adapted and presented to the merchant in the new version (§ 0.3).

1.2 Nature of the processing

Collection, recording, storage, use, retrieval, encryption, transmission to the group of recipients named in § 6, erasure and restriction of processing – in each case to the extent of Annex 1.

1.3 Purpose of the processing

Exclusively:

1. Installation and operation of the app in the merchant's shop: assigning the shop, obtaining and renewing the Shopify access tokens, authenticating calls from the embedded interface.
2. Fulfilling the data protection webhooks required by Shopify (access, erasure of a person, erasure of a shop).
3. Evidence of access to protected customer data (access log for protected customer data): a condition of Shopify's approval for protected customer data and our own accountability under Art. 5(2) GDPR. Art. 5(2) GDPR is the purpose here, not the legal basis; for the legal basis, see section 5.1 of the privacy policy.
4. Determining the subscription status of the merchant's shop at Shopify and enforcing it at three points: setting up the voucher product, the proof, and the delivery lock – without an active subscription, automatic sending stops and the finished vouchers wait until a plan is running again. The plan “Kartuu Free” counts like a missing subscription as long as the merchant has not consented to a version from consent record ID 1.27-2026-10-06 on (§ 6.4). The generation of a paid voucher is expressly not locked: the gift card is created, and the merchant can download the card and hand it over themselves. The plans are managed by Shopify; KYTH reads there whether an active subscription exists, what the plan is called, whether it is a test subscription and until when the current billing period runs. The first three details are cached; the end of the billing period is only displayed. With the same query, KYTH reads Shopify's identifier of the shop. It is not stored and is needed only for the report under § 6.4.
5. Generating the voucher card as a preview and as a PDF from details the merchant enters in the admin themselves – without storing the sample details and without access to the shop's order or customer data; only drafts the merchant expressly saves are stored.
6. Keeping the pictures uploaded by the merchant, so that a card template can draw them.
7. Setting up the voucher product in the merchant's shop on the merchant's click, and recording which product it is. Without this detail, a voucher order arriving through an express checkout could not be recognised as such.
8. Handling a paid voucher order in these steps: a) receiving the paid order and creating one record per item purchased; b) taking over the customer's details about the recipient and storing them encrypted; c) for a value voucher, generating a voucher code, storing it encrypted and using it to create a gift card at Shopify; d) rendering the card and noting the process as completed; e) delivering the finished voucher, namely through the merchant's mail account (§ 1.1). If the merchant has not entered one, nothing is delivered – the voucher remains retrievable and downloadable, and the merchant hands it over themselves; f) showing the buyer the status and the claim links of their vouchers in the Kartuu block.
9. Card preview on the shop's product page, without storage.
10. Operational diagnostics and security to the very narrow extent described in Annex 1.

There is no processing of the data under this contract for KYTH's own purposes – in particular for advertising, profiling, resale, training models or evaluation across merchants. Separately, KYTH, as a controller in its own right, attributes the installation of the app to an advertisement if the merchant consented to this on kyth.systems (privacy policy section 5.7). Only identifiers from the merchant's browser are processed for this, no data from the shop and no data of the customers.

1.4 Duration

Processing begins with consent under § 0 and the subsequent connection of the app. The contract runs for an indefinite period as long as the app is installed.

The contract ends, without the need for termination, with the uninstallation of the app. For data still present at that time, the obligations of this contract continue to apply until it is deleted under § 9.

Maximum duration. The data remaining in the database is deleted at the latest 30 days after uninstallation – as a rule earlier, namely with the shop/redact webhook, which Shopify as a rule sends 48 hours after uninstallation. If this webhook does not arrive, the clean-up run under § 9.3 no. 1 applies. Deleted data continues to exist in the backups until the periods there expire (§ 9.3 no. 2).

§ 2 Type of personal data and categories of data subjects

2.1 Categories of data subjects

2.2 Type of data

Listed exhaustively in Annex 1. In brief:

• Stored per shop: the shop's myshopify domain in plain text, a non-reversible HMAC hash of the same domain as search index, the Shopify access token and the Shopify refresh token (both encrypted), the merchant's contact address (encrypted), time and version identifier of their consent together with the language in which they saw Kartuu at the time, the state of the setup email (§ 2a no. 4), which version KYTH announced to them under § 0.3 and when, the subscription status last read from Shopify, a redeemed promo code with time, technical timestamps and the scope of permissions (scopes), entries in the access log for protected customer data, technical identifiers of incoming webhooks, the pictures uploaded by the merchant – their bytes in the image storage, their key, MIME type, size, dimensions and checksum in a database table –, drafts of their card design saved by the merchant, the mail account they entered (user name and password encrypted), the chosen language of the vouchers and the details of their voucher product (type, Shopify product ID, handle, chosen template, time of creation).
• Stored per voucher purchased: name and email address of the buyer, recipient's name, recipient's email address, sender's name, greeting and the voucher code, all encrypted; a claim token, also encrypted; non-reversible search values of voucher code, claim token, recipient's and buyer's address; the buyer's Shopify customer number in plain text; order identifier, line item identifier and the running number of the item; the type of voucher, the identifier of the card template and a frozen copy of this template with placeholders instead of values; face value and currency, the printed amount as text, the shop name and a validity date; the identifier of the Shopify gift card; status, time of the last status change, error counter and error reason as a short identifier of our own; an open question to the merchant after a refund (which question, how many items are still to be decided, since when); the desired delivery date; the order header (order number, time, total amount with currency, payment method, sales channel); the discount with which the item was bought (amount with currency, code or title of the discount and whether it applied to the whole order); and the keys of the pictures contained in this card.
• Only touched briefly in memory and stored nowhere: the Shopify session token of the logged-in merchant user, the name Shopify holds as the owner of the shop (for the salutation of the setup email), the country code of the shop (for the default card language at the first consent), customer number and email address from the data protection webhooks, the rest of the content of an incoming order, the sample details the merchant types in when designing (recipient's and sender's names, greeting, voucher code, amount, shop name, validity date), the details from the Kartuu block and the card preview in the shop (Annex 1 section B), and every generated PDF – including the one from an order.
• Not stored: postal addresses, phone numbers and payment data of the merchant's customers, and the order content beyond the voucher line items and the order header named above. The balance of a Shopify gift card is read but not stored: if the merchant asks for the redemption status in the order overview or opens the export, Kartuu fetches it from Shopify and passes it through. On cancellation, Kartuu queries it before deactivating: a card that has already been partly used is not deactivated without the merchant's decision.

On pictures: What an uploaded picture shows and which capture data it contains is determined by the merchant. A picture can show people, and the embedded capture data (EXIF) of a mobile phone can carry a location. KYTH checks the picture for format, dimensions and harmlessness (Annex 2 section 2.6) and does not evaluate its content.

The capture data is dropped on upload, from every picture. If the longer edge measures more than 2000 pixels, the picture is scaled down to this edge and re-encoded in the process; the orientation is applied to the pixels. If the picture is smaller, Kartuu only discards the parts of the file that contain capture data and does not re-encode – the pixels remain unchanged, and the orientation remains as the only detail, so that a photo taken upright does not lie on its side. Time of capture, device and location are dropped completely in both cases. Pictures uploaded before 23 September 2026 have been cleaned in the same way.

Who can retrieve a picture. There is no generally readable address of the image storage. The merchant receives their pictures in the admin after their session has been checked. Outside of it, a picture is delivered only through a signed address that is bound to the shop and the key and becomes invalid after one to two hours: in the preview in the admin and – if picture or logo belong to the design of a voucher product – to any person who opens that product page with the card preview. That person can download the image file as it is stored – without capture data. What a merchant chooses to load into a picture is their responsibility.

2.3 Permissions granted and their use

This section separates two things: what KYTH may do and what KYTH does.

What the merchant grants. The following are requested in the Shopify app configuration:

What KYTH still does not do. Kartuu does not query any customer data field through the Admin API – no address, no phone number, no payment data. The personal order data comes exclusively from the webhook Shopify delivers. An order is indeed queried, but only as to its state: on release, Kartuu queries the fulfillment orders and the open quantities for the order from which the voucher comes, in order to report the voucher line item as fulfilled. The order identifier is transmitted; back come identifiers, states and quantities – no customer data field. Immediately before a voucher is issued, Kartuu also asks whether the order has been cancelled and what its payment status is; again only the order identifier is transmitted. The complete list of the twenty-seven calls to the Admin API is in § 3.4.

Origin of the data. Personal data reaches Kartuu by these routes:

1. From the merchant's shop – through the order webhook. This data is stored (Annex 1 section A). For it, the merchant is the controller and KYTH the processor; the instruction for it is this contract together with setting up the voucher product.
2. From the merchant's input when designing – sample details are not stored (Annex 1 section B); saved drafts are stored (Annex 1 section A).
3. From an upload by the merchant – the pictures are stored (Annex 1 section A).
4. From the browser of the buyer or visitor – through the Kartuu block and the card preview in the shop. These details are not stored (Annex 1 section B).

If this changes. Before every extension that changes the range of data processed, this contract is presented in a new version and the version identifier increased – it takes effect for the merchant under § 0.3 (§ 11 no. 6).

2.4 Special categories of data

Special categories of data under Art. 9 GDPR and data under Art. 10 GDPR are not the subject of the processing. KYTH will not request them in future either.

§ 2a Obligations and rights of the controller

Art. 28(3), first sentence, GDPR requires that a data processing agreement also sets out the obligations and rights of the controller. This is done here.

1. Lawfulness of processing. The merchant alone is responsible for ensuring that the processing they instruct is lawful and that there is a legal basis under Art. 6 GDPR. They decide on purposes and means. KYTH does not and cannot check the legal basis.
2. Information obligations. The information obligations under Art. 13 and Art. 14 GDPR towards the merchant's customers and towards recipients lie with the merchant. Recipients typically do not provide their data themselves; the giver provides it – for this, Art. 14 GDPR applies.
3. Instructions. The merchant is entitled and obliged to give instructions under § 3; their instructions must be lawful. They name to KYTH the people authorised to give instructions on their behalf and keep this information up to date. If they name no one, the merchant's bodies authorised to represent it are deemed authorised to give instructions.
4. Contact address. In the consent step under § 0, the merchant gives an email address at which KYTH can reach them. The information is mandatory; without it, the app is not connected. The notices under § 0.3, § 6.6 and § 8.2 go to this address. If the merchant has set up a mail account, Kartuu also sends a note to this address through that account at most once a day when orders need their attention; the note names only counts and a link into the app, no names, addresses, codes or amounts. In addition, once after installation, KYTH sends them the setup email with the steps still missing before the first voucher sale – only if they have chosen a plan and a step is still missing, without advertising, and through KYTH's own mailbox at INWX GmbH, not through the merchant's mail account; exactly when is stated in the privacy policy (5.3). For the salutation, KYTH reads the name Shopify holds as the owner of the shop (§ 3.4) and takes the first name from it; it does not appear in the database or in the log (on bounces, Annex 1 B). The merchant keeps the address up to date and notifies a change in text form to datenschutz@kyth.systems. In the app it can be changed in the consent step: when the version of these texts increases, Kartuu asks again and shows the stored address for editing; the value entered is stored. There is no separate screen for it. If the address becomes undeliverable, KYTH can no longer reach the merchant directly – not even in the event of a personal data breach, for whose notification the merchant has only 72 hours under Art. 33(1) GDPR. Keeping it up to date is therefore in their own interest.
5. Evidence and audits. The merchant has the rights to evidence and audits under § 10.
6. Notification of data breaches. Notifying the supervisory authority of a personal data breach (Art. 33 GDPR) and informing the data subjects (Art. 34 GDPR) are the merchant's responsibility. KYTH supports them in this under § 8.2.
7. Own review. Before processing begins and regularly thereafter, the merchant satisfies themselves of the technical and organisational measures under Annex 2. Annex 2 expressly names the known gaps in section 7.

On handling the contact address. KYTH stores it encrypted, uses it exclusively for the notices, notes and the setup email named in number 4 and for forwarding requests from data subjects under § 7.1, does not pass it on and does not use it for advertising. It is deleted together with the shop row (§ 9).

§ 3 Processing only on documented instructions

3.1 Principle

KYTH processes personal data exclusively on documented instructions from the merchant. This also applies to transfers to a third country.

3.2 What counts as an instruction

Instructions are:

1. this contract including its annexes – it is the basic declaration of instructions; consent under § 0 is the giving of this basic declaration,
2. the installation of the app and the granting of permissions in the Shopify admin,
3. settings and actions of the merchant in the app – in particular uploading a picture, saving a draft, setting up the voucher product, entering the mail account, choosing the language, changing or completing card details and releasing a voucher. Sample details for a preview apply only to that one rendering run and are not stored,
4. individual instructions in text form to datenschutz@kyth.systems.

The merchant confirms instructions given orally without delay in text form. KYTH documents individual instructions and keeps them for the duration of the contract.

3.3 Limits of instructions

KYTH informs the merchant without delay if, in KYTH's opinion, an instruction infringes the GDPR or other data protection provisions. KYTH may suspend the execution of such an instruction until the merchant confirms or changes it.

If KYTH is legally obliged to carry out processing, KYTH informs the merchant of the legal requirement before processing, unless the law prohibits such information on important grounds of public interest.

3.4 Place of processing and third-country transfers

Processing by KYTH itself takes place in Germany: application and database run on a single virtual server at IONOS SE at the Berlin location. The daily database backups are stored in IONOS's object storage in the region eu-central-3, also Berlin. The pictures uploaded by the merchant are stored on the server itself – in a file storage on a persistent storage medium. See § 6.3. There is no other processing environment. The object storage does not create any third-country reference.

Transfers to parties outside KYTH arise exclusively from the group named in § 6:

• Shopify: Kartuu calls seven external endpoints outgoing, five of them at Shopify. Two are at the merchant's shop itself: the token endpoint (https://{shop-domain}/admin/oauth/access_token) and the Admin API (https://{shop-domain}/admin/api/{version}/graphql.json). The third is the storage location Shopify names for uploading a product image – it is communicated afresh for each upload and is not at the merchant's shop. The app's credentials and the respective token are transmitted, and for the third, the image data itself. The fourth and the fifth are at Shopify itself (https://api.shopify.com) and serve solely to bill the plan “Kartuu Free” (§ 6.4): at one, Kartuu obtains an access token with the app's credentials; at the other, it reports, for each voucher issued, Shopify's identifier of the shop, the time, an identifier of the report and the value in US dollars. Twenty-six different calls run through the Admin API, and they carry different things:

Order and customer data are not queried through the Admin API; they arrive incoming through the orders/paid webhook that Shopify delivers. Shopify is at the same time the platform on which the merchant's shop is operated anyway; the merchant maintains their own contractual relationship with Shopify for this. The contracting party for merchants in the European Economic Area is as a rule Shopify International Ltd., based in Ireland; processing by affiliated companies outside the EEA, in particular Shopify Inc. in Canada, cannot be ruled out.

Instruction. By concluding this contract, the merchant instructs KYTH to call the token endpoint and the Admin API of their own shop at Shopify and to receive the incoming webhooks from Shopify, also insofar as a transfer to Shopify entities outside the EEA takes place in the process (Art. 28(3)(a) GDPR). Without this data flow, the app cannot be operated.

Canada. For Canada there is an adequacy decision of the European Commission (Decision 2002/2/EC) for private-sector organisations subject to the Canadian data protection law PIPEDA.

Other third countries, in particular the USA: standard contractual clauses. Shopify incorporates the EU standard contractual clauses into its Data Processing Addendum in the version of 7 July 2026 – the clauses from Commission Implementing Decision (EU) 2021/914 of 4 June 2021. Transfers to Shopify entities outside the European Economic Area, including entities in the USA, are based on them. The addendum is publicly available at https://www.shopify.com/legal/dpa; the merchant receives a copy of the clauses on request to datenschutz@kyth.systems (Art. 13(1)(f) GDPR). The same basis is set out in section 8 of the privacy policy.

• The merchant's mail server. If the merchant has set up email sending, Kartuu establishes an SMTP connection to the mail server they entered, logs in there with their user name and password and hands in the emails: the email to the recipient with their email address, recipient's and sender's names, the shop name, the claim link with its validity date and the voucher as a PDF (greeting, amount, voucher code); on the merchant's click, a test email to their reply-to address; at most once a day the note under § 2a no. 4 to their contact address. The setup email under § 2a no. 4 does not go through this server. The mail server is the merchant's, and it is the merchant's own processor (§ 6.4). Where it is operated and whether a third country is involved is determined by the merchant with the choice of their mail provider. Instruction. By entering the mail account, the merchant instructs KYTH to establish this connection (§ 3.2 no. 3).

• KYTH's own mailbox at INWX GmbH, Berlin. Through it, a script on the server – not the application – sends the setup email and the announcement under § 0.3 to the merchant's contact address (§ 2a no. 4) and KYTH's messages to itself (Annex 1 section A). No data of the merchant's customers goes there, and no third country is involved (§ 6.4).

• Meta: no transfer of data under this contract. If the merchant consented to the Meta pixel on kyth.systems, Kartuu reports their installation to Meta Platforms Ireland Ltd. via the Conversions API (privacy policy section 5.7). This is the sixth external endpoint. Only identifiers from the merchant's browser go there – the Meta identifiers _fbc and _fbp, a hashed visitor identifier, IP address and browser identifier – and the time of the installation, no data from the shop and no data of the customers. This is KYTH's own processing as a controller and not processing on behalf of the merchant; Meta is not a sub-processor under this contract.

• European Central Bank: no transfer. For the plan “Kartuu Free”, Kartuu converts a voucher's value into US dollars and, for this, retrieves the public reference rates of the European Central Bank (https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml). This is the seventh external endpoint. The request carries no details – neither about the merchant nor about their customers; the central bank is not a sub-processor under this contract.

• Cloudflare: no transfer. The DNS zone kyth.systems is run at Cloudflare. For Kartuu, Cloudflare is therefore exclusively an authoritative DNS service; the app names resolve directly to the IP address of the server in Berlin, and the data traffic does not run through Cloudflare. Cloudflare receives neither merchant nor customer data and is therefore not a sub-processor under this contract. See § 6.4.

No other transfers of data under this contract to third countries take place. In particular, the backups are stored in Germany (§ 6.3).

§ 4 Confidentiality of the people engaged

KYTH engages for processing only people who have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28(3)(b) GDPR). The obligation continues beyond the end of their activity.

KYTH ensures that these people process personal data exclusively on the merchant's instructions and are familiar with the data protection requirements relevant to them.

The group of people with access. Access to the production environment – server, Coolify, database and the Shopify Partner Dashboard – is limited exclusively to KYTH's two managing directors, Stefan Grasse and Stephan Wittmann.

Beyond this, no one has access. There are no employees, no freelancers and no service providers with access to the production environment. The sub-processors under § 6.3 are not affected by this: they provide infrastructure and have no access to the application.

Confidentiality. Art. 28(3)(b) GDPR requires a commitment to confidentiality or an appropriate statutory obligation of confidentiality. For the managing directors, the obligation of confidentiality follows from their fiduciary duty as officers (section 43 of the German Limited Liability Companies Act, GmbHG; for the UG via section 5a(1) GmbHG). If a further person is given access, they are committed to confidentiality in writing beforehand.

§ 5 Technical and organisational measures (Art. 32 GDPR)

KYTH takes the technical and organisational measures described in Annex 2. Annex 2 contains only measures that have been implemented and names the known gaps in a section of its own.

The measures are subject to technical progress. KYTH may adapt them as long as the level of protection is not undercut. Significant changes are documented and communicated to the merchant on request.

KYTH holds no data protection or security certification (neither ISO/IEC 27001 nor SOC 2 nor a certification under Art. 42 GDPR) and does not claim any. Annex 2 is a self-assessment, not an audit report.

§ 6 Sub-processors

6.1 Consent

By concluding this contract, the merchant consents to the engagement of the sub-processors named under 6.3 (general written authorisation under Art. 28(2), second sentence, GDPR).

6.2 Conditions

KYTH contractually binds every sub-processor to data protection obligations corresponding to the obligations under this contract, in particular to sufficient guarantees under Art. 28(4) GDPR. If the sub-processor fails to fulfil its data protection obligations, KYTH is liable to the merchant for its compliance in accordance with Art. 28(4), second sentence, GDPR.

With IONOS, IONOS's data processing agreement applies (see below).

6.3 List of sub-processors

On the contracts under Art. 28(4) GDPR:

IONOS. IONOS's “Agreement on processing on behalf under Art. 28(3) GDPR” (“Vereinbarung zur Auftragsverarbeitung nach Art. 28 Abs. 3 DSGVO”), version 1.2, as of 06/2023, applies, publicly available at https://www.ionos.de/terms-gtc/avv/. KYTH keeps a copy in its contract documents. Under its § 1.1 it covers “all activities that the contractor performs to fulfil the order and that constitute processing on behalf”, and thus covers server and object storage insofar as both are obtained under the same main contract.

The object storage is provided by IONOS Cloud GmbH (Local Court Montabaur, HRB 31110); the provider identification of the service at s3.eu-central-3.ionoscloud.com names it. Server, database and backups run at IONOS SE (HRB 24498). Both can be reached at the same address; which company is the contracting party in a given case follows from the respective contract.

Shopify is not a sub-processor, but the merchant's own processor; see 6.4.

6.4 Further recipients who are not sub-processors

For the sake of completeness, because there is a data flow or involvement:

• Shopify International Limited, The Sidings, 4th Floor, Grand Canal Quay, Dublin D02 E7K8, Ireland (contracting party for merchants in the EEA), affiliated with Shopify Inc., 151 O'Connor Street, Ground floor, Ottawa, Ontario K2P 2L8, Canada – the merchant's own processor, not a sub-processor of KYTH.

What actually flows: platform: obtaining and renewing the access tokens through the shop's token endpoint; twenty-seven calls to the shop's Admin API (§ 3.4); transferring the product image; setting the delivery flag (§ 3.4); delivery of the incoming webhooks to Kartuu, including the paid orders; forwarding of requests from the shop to Kartuu (card preview on the product page, Kartuu block on the thank-you and order status page); management and billing of the app plans

Which data: the app's credentials, session token or refresh token, access token, shop domain, the voucher code, the face value and, where applicable, the expiry date when a gift card is created, the details of the voucher product, the product image and the delivery flag (whether email sending has been set up, yes or no). The buyer's customer number is not included. Recipient's name, recipient's email address and greeting do not go back to Shopify; they come from there and remain encrypted at KYTH

Classification. Sub-processing presupposes that KYTH engages the service provider. Here the merchant has engaged Shopify – Shopify runs their shop. When Kartuu creates a gift card through the Admin API, it writes data into the merchant's shop, and Shopify processes it there as the merchant's processor, under the merchant's own contract.

This is evidenced in two places:

• Shopify's Data Processing Addendum (version of 7 July 2026, https://www.shopify.com/legal/dpa) names its parties itself: “by and between You (or »Merchant«), and the Shopify Contracting Entity” and further: “You shall act as a Data Controller and Shopify shall act as a Data Processor with respect to the processing of Your Customer Personal Data.” KYTH is not a party to it.
• The Shopify Partner Program Agreement (as of 27 February 2026, https://www.shopify.com/partners/terms) – the contract binding KYTH – contains no Data Processing Addendum. In 9.14.2 it restricts the partner's use of merchant data (“Partner will only use or store such information for the purpose of providing the Partner's services to the Merchant”), but does not establish processing by Shopify on KYTH's behalf.

Billing of the app plans is to be seen separately. There, KYTH is itself Shopify's customer; this is a contractual relationship of KYTH's own and not processing on the merchant's behalf. If the merchant is on the plan “Kartuu Free”, KYTH reports to Shopify, for this billing, the value of each voucher issued and, for each cancellation, the value back. Transmitted are Shopify's identifier of the shop, the time, an identifier of the report and the value in US dollars. Not transmitted are details about buyers or recipients, and no voucher code. Reports are made only for shops that have consented from consent record ID 1.27-2026-10-06 on. The same applies to the Partner API, which Shopify provides to KYTH as the app's developer: through it, KYTH learns that, and for what reason, a shop has uninstalled Kartuu (Annex 1 section A), and, for shops on the plan “Kartuu Free”, once a day which total Shopify keeps for the current billing period; KYTH compares it with its own reports. KYTH's own access goes there and, for this comparison, Shopify's identifier of the shop. If the totals differ, KYTH receives a notice with the internal identifier of the shop and the two totals.

• The merchant's mail server – only if the merchant has set up email sending. The merchant's own processor, not a sub-processor of KYTH: the merchant chooses and engages the mail provider themselves; KYTH merely hands in emails through the account they have entered. What flows there is set out in § 3.4.
• INWX GmbH, Prinzessinnenstr. 30, 10969 Berlin, Germany (Local Court Berlin-Charlottenburg, HRB 237141 B) – provider of KYTH's own mailboxes under kyth.systems, not a sub-processor under this contract. Through it go the setup email to the merchant's contact address (§ 2a no. 4) and KYTH's messages to itself about a redeemed promo code and about an uninstallation (Annex 1 section A). This is KYTH's own processing as a contracting party; no data of the merchant's customers goes there. Place of processing Berlin, no third-country reference.
• Cloudflare (Cloudflare, Inc., San Francisco, USA; in the EU Cloudflare Germany GmbH, Munich) – authoritative DNS service for the zone kyth.systems, nothing more. The app's names resolve directly to the IP address of the server in Berlin. The data traffic between the merchant's browser and Kartuu does not run through Cloudflare; a proxy mode is not switched on for the app. Cloudflare merely answers name resolutions and in doing so processes neither connection nor content data of the merchants or their customers. Cloudflare is therefore not a sub-processor under this contract, and no third-country reference arises through Cloudflare.

The situation is different for KYTH's company website at kyth.systems and www.kyth.systems: these names run in proxy mode, and there Cloudflare processes connection data. This does not concern Kartuu and is the subject of the privacy policy of that website, not of this contract.

Switching the app to proxy mode would make Cloudflare a sub-processor; it will only be done after the list under 6.3 has been supplemented and the merchant informed under 6.6. - GitHub, Inc. (San Francisco, USA; a subsidiary of Microsoft Corporation) – private source code repository and deployment keys. GitHub processes no merchant, customer or voucher data. Access secrets are stored exclusively in the deployment environment and are excluded from the repository and the container image. - cdn.shopify.com – the embedded interface loads Shopify's “App Bridge” library directly from the Shopify CDN. This request is made from the merchant's browser, not from KYTH's server. The connection data of the merchant's browser (IP address, browser identifier) and the origin are transmitted. No customer, order or voucher data and no token are transmitted; the only attribute given is the public application identifier. The origin is limited to https://kartuu.kyth.systems by the policy Referrer-Policy: strict-origin-when-cross-origin, so the ?shop= parameter is not transmitted. The recipient is Shopify – the same party that delivers the surrounding admin interface. No additional group of recipients arises as a result.

6.5 Expressly not involved

Searched for and not present: no email delivery service – the voucher emails go through the merchant's mail account, KYTH's own notices through KYTH's mailbox (§ 6.4) –, no external font or icon service, no analytics or tag service, no external error-tracking service. The only HTTP library in the application code is used in seven places: two address the merchant's shop – the token endpoint and the Admin API –, the third uploads the product image to the storage location Shopify names for it (§ 3.4), the fourth reports an installation to Meta – without data under this contract (§ 3.4). Three more serve to bill the plan “Kartuu Free”: the fifth obtains KYTH's access at Shopify, the sixth reports voucher values there (§ 6.4), the seventh retrieves the reference rates of the European Central Bank (§ 3.4). In addition, the application connects via SMTP to the mail server the merchant has entered (§ 3.4, § 6.4).

Object storage is used exclusively at IONOS for the database backups (6.3). The application does not talk to it; the transfer there is handled by a separate backup script on the server, which encrypts the dump before it leaves the server (§ 9.3 no. 2).

Nor does the application talk to KYTH's mailbox at INWX GmbH: it only builds the setup email and the announcement under § 0.3; they are sent by scripts on the server (§ 3.4). The application holds no credentials for it.

6.6 Changes and right to object

KYTH informs the merchant of the intended engagement of a further sub-processor or the replacement of an existing one at least 30 days in advance in text form at the contact address stored by the merchant under § 2a no. 4. If this address has become undeliverable, the information is additionally given by publication at https://kartuu.kyth.systems/rechtliches/auftragsverarbeitung; the period then runs from publication.

The merchant can object to the change in text form within 30 days of receipt of the notice on an objective ground relating to data protection. If the parties do not reach agreement, the merchant can end the use of the app by uninstalling it; deletion is then governed by § 9. If the merchant does not object, the change is deemed approved.

If a change requires immediate action because of an immediate threat to security or availability, KYTH informs the merchant at the same time as the measure, at the latest within 24 hours. The merchant can object to the measure within 14 days of receipt of the notice. In the event of an objection, KYTH ends the engagement of the sub-processor without delay, or the merchant can terminate the contract with immediate effect; deletion is then governed by § 9. The right to object under Art. 28(2), second sentence, GDPR is thus preserved.

§ 7 Assistance with the rights of data subjects

7.1 Principle

Requests from data subjects are addressed to the merchant as controller. If a data subject contacts KYTH directly, KYTH forwards the request to the merchant without delay and does not answer it itself.

KYTH assists the merchant with appropriate technical and organisational measures in fulfilling their obligation to respond (Art. 12 to 23 GDPR), insofar as the merchant cannot already do so through their own Shopify access.

7.2 What is technically available

Kartuu is connected to the data protection webhooks required by Shopify:

Limit regarding recipients. Shopify's customers/redact and customers/data_request carry the customer identifier and address of exactly one person – the person Shopify knows. A recipient has not ordered and does not appear there; their rows are only affected by these webhooks if their email address is the same. The search route through the address has been built, a trigger for a third person has not. If a recipient requests access or erasure, KYTH carries it out manually on the merchant's instructions (§ 7.1). This is also stated in Annex 2 section 7.

Buyers without a customer number. For a guest purchase, the customer number is missing. The buyer's address therefore also carries a non-reversible search value, and the two webhooks find their details through it. Vouchers created before 23 September 2026 have this search value added by the daily clean-up run, as long as their email address is still stored.

7.3 Rectification, restriction, portability

For the shop's technical data (shop domain, tokens, timestamps), there are no details that could be incorrect in content and that the merchant cannot correct themselves through Shopify. If the merchant requests a restriction of processing, KYTH implements it by arrangement; the practically effective means is uninstalling the app.

The situation is different for the details of an ordered card. Recipient's name, recipient's email address, sender's name and greeting can be incorrect – they come from a form a customer filled in. The merchant can correct them in the app as long as the voucher has not yet been issued. In the order overview, every item in the state “prepared” carries the button “Change details”; if the details are missing entirely, the same button is called “Complete details”. It opens a form covering all four fields, and all four are stored together – including one the merchant has deliberately emptied. The address is stored encrypted and its search value rewritten, so that a later erasure request still finds the row.

Not after issuance. Once the card has been rendered, the voucher counts as delivered and is no longer rewritten. If anyone requests a rectification beyond this, a message in text form to datenschutz@kyth.systems is sufficient; KYTH carries it out manually. The route open to the merchant themselves is a newly issued item.

The delivery address is excepted from this. It does not appear on the card but is solely the destination of the delivery. It can therefore also be changed after issuance – through “Send to another address” on the “Delivery” screen – without the document changing by a single character.

Exception: the uploaded pictures. For them there is no deletion option in the app – neither for an individual picture nor for all. If the merchant requests the removal of a picture, for instance because it shows a person who has objected, a message in text form to datenschutz@kyth.systems is sufficient; KYTH removes the object and its row manually and confirms this. Until there is a deletion function in the app, this is the only way.

7.4 Effort

KYTH provides the assistance under this section free of charge, within the scope of what Art. 28(3)(e) GDPR requires. Remuneration for effort beyond this has not been agreed and is not charged.

§ 8 Assistance with security, data breaches and data protection impact assessments

8.1 Security of processing (Art. 32 GDPR)

KYTH maintains the measures described in Annex 2 and reviews them as the occasion arises, in particular with every extension of the range of functions.

8.2 Personal data breaches (Art. 33, 34 GDPR)

KYTH notifies the merchant of every personal data breach affecting data from their shop without delay after becoming aware of it in text form at the contact address stored by the merchant under § 2a no. 4. The notification contains, as far as known:

• a description of the nature of the breach, the categories and approximate number of data subjects and records concerned,
• a contact point for further information (datenschutz@kyth.systems),
• the likely consequences,
• the measures taken and proposed.

If not all information is available yet, KYTH first reports the known facts and supplies the rest without delay. Notifying the supervisory authority and informing data subjects are the merchant's responsibility (§ 2a no. 6); KYTH assists them with the information available.

Limit of this commitment. The channel to the merchant exists because the contact address is collected when the contract is concluded (§ 0.2, § 2a no. 4). It depends, however, on the merchant keeping it up to date. If the stored address has become undeliverable, KYTH can no longer reach them directly; KYTH then publishes the notification at https://kartuu.kyth.systems/rechtliches/auftragsverarbeitung and points to it in the embedded interface. This does not replace a direct notification – the merchant's 72-hour period under Art. 33(1) GDPR cannot be reliably met this way.

KYTH maintains a documented response plan for security incidents with escalation levels, named responsibilities, the 72-hour period of Art. 33 GDPR and the competent supervisory authority (Bayerisches Landesamt für Datenschutzaufsicht, BayLDA).

8.3 Data protection impact assessment and prior consultation (Art. 35, 36 GDPR)

If the merchant carries out a data protection impact assessment or consults the supervisory authority, KYTH provides on request the information about the processing by Kartuu required for this – in particular Annexes 1 and 2 of this contract and information about the sub-processors engaged.

§ 9 Deletion or return after the end of processing

9.1 What happens when

The tables to be emptied are not determined from a maintained list but at runtime from the database catalogue. All tables in the schema public that have a column named shop_id are covered; the current data set falls entirely under this. The clean-up run under 9.3 no. 1 uses exactly the same path. Foreign keys between these tables are only checked at the end of the transaction, so that the deletion succeeds in any order.

The bytes of the uploaded pictures are not in the database but in the image storage (§ 6.3); they are deleted by a route of their own, see 9.3 no. 6.

9.2 Deletion or return – the merchant chooses

After the end of processing, KYTH deletes all of the merchant's data or hands it over at the merchant's choice (Art. 28(3)(g) GDPR).

The choice belongs before uninstallation. Shopify requests deletion as a rule 48 hours after uninstallation, and KYTH then carries it out (§ 9.1). If the merchant requests the handover, they therefore notify this before uninstalling in text form to datenschutz@kyth.systems and uninstall the app only after they have received the data. KYTH can fulfil a notice given after uninstallation only as long as the data has not yet been deleted. Without a notice, KYTH deletes.

If the merchant requests the handover, KYTH provides the data stored for their shop within 14 days of receipt of the notice in a common machine-readable format (JSON). An automatic export has not been implemented; in this case KYTH compiles the data manually.

For classification: regarding the shop's technical data – shop domain, its hash, encrypted access tokens, encrypted contact address, record of consent, last read subscription status, technical timestamps and the entries of the access log for protected customer data – the following applies: the access tokens are invalid after uninstallation. The choice remains with the merchant.

Voucher data. If the merchant requests the handover, KYTH hands it over in JSON, with the encrypted fields decrypted. The voucher code is expressly included. The handover goes exclusively to the merchant as controller and exclusively to the contact address stored under § 2a no. 4.

Uploaded pictures. If the merchant requests the handover, KYTH hands them over as files – in the uploaded format, i.e. not packed in JSON. An exception applies to SVG pictures: the cleaned version is handed over, because only that is stored (Annex 2 section 2.6). The original file is with the merchant and has not been kept at KYTH at any time.

9.3 Destruction of existing copies – binding periods

Art. 28(3)(g) GDPR requires that, after the end of processing, KYTH also destroys existing copies, unless there is a statutory retention obligation. KYTH commits to the following periods for this.

Overview:

1. If shop/redact does not arrive: 30 days. If the webhook does not arrive – delivery is lost, the endpoint is temporarily unreachable, Shopify never reports it –, a clean-up run deletes the shop row completely 30 days after the time of uninstallation, through the same deletion path as shop/redact. The period is a safety net for the missing webhook and not a window for returning: as a rule, shop/redact deletes after 48 hours, and anyone who reinstalls after that consents again and gives their contact address again. Second case of the same clean-up run: connections that never came about – 90 days. If obtaining the access token from Shopify fails after consent, there is no time of uninstallation. The same clean-up run therefore deletes, through the same deletion path, a record that has no time of uninstallation, no access and no refresh token, and whose last sign of life lies more than 90 days back.

Key rotation. After every key rotation, the search hashes are recalculated so that the app/uninstalled webhook still finds its shop.

The clean-up run starts with the application and calls both rules every 24 hours; nos. 3 and 7 use the same run. 2. Backups: 30 days on the server, 95 days in the object storage – of which 90 days cannot be deleted. A complete backup of the database is created every night and encrypted with AES-256 before it leaves the server. It is stored on the server and in IONOS's object storage in Berlin, in the bucket kaspar-kyth-db-backup-worm.

On the server: 30 days. This is enforced by the backup script itself, on every run.

In the object storage, two mechanisms act one after the other. First, the backup cannot be deleted by anyone for 90 days thanks to Object Lock in COMPLIANCE mode – not even by KYTH itself and not by someone who takes over the server together with its credentials. After that, a lifecycle rule of the bucket (sicherungen-nach-95-tagen-loeschen, entire bucket, 95 days after creation and likewise 95 days for non-current versions) deletes it at storage level. The five-day gap ensures that the deletion does not hit a backup that is still locked.

The backup script deletes nothing in the object storage; clean-up there takes place exclusively through the bucket's lifecycle rule.

The dump is encrypted. It is encrypted symmetrically with AES-256 before it leaves the server; the password is stored on the server and not in the object storage. Transfer to the object storage uses TLS 1.3. Within the backup, the fields requiring protection are additionally encrypted field by field with AES-256-GCM; the key for this is only in the application's environment on the server, not in the backup and not in the object storage. Restorability has been verified by an actual restoration, and a daily check run reports missing backups.

Deleted data in backups. If a shop is deleted – through shop/redact, through the clean-up run under no. 1 or at the merchant's request –, its data remains contained in backups already made and disappears from them only when the periods named expire: at the latest 30 days later on the server, at the latest 95 days later in the object storage. Individual records are not cut out of existing backups. As long as the data is there, it is used exclusively for restoration in the event of a fault. 3. Technical webhook identifiers: 30 days after completion. The table with the identifiers of incoming webhooks (duplicate protection) has no shop assignment and is not covered by the shop's deletion. A clean-up run of its own removes a completed entry 30 days after its completion. In content, these are exclusively technical identifiers assigned by Shopify, without personal reference. Entries whose processing was never completed remain, so that the same webhook is not processed a second time; they too have no personal reference. 4. Application and container logs: 14 days. They contain the shop domain, the internal shop identifier, in the order process additionally order, line item and voucher identifiers and the error reason as a short identifier of our own, and the type of exceptions that occurred – no tokens, no contact address, no voucher code, no recipient's or sender's name, no greeting and no customer address. They are discarded after 14 days. The period is set in the operations tool. 5. Access log for protected customer data. It has a shop assignment and disappears completely with the shop – through shop/redact and through the clean-up run under no. 1. There is no separate, shorter period, because the log serves as evidence towards Shopify. 6. Uploaded pictures: with shop/redact, and before everything else. The pictures have no period of their own. They are kept as long as the merchant uses the app and are deleted with the shop.

How deletion works. Every object of a shop is stored under a key that begins with the identifier of that shop. Everything under this prefix is deleted – including an object whose upload was aborted before its row was written. The objects are deleted before the database rows; if that fails, the shop remains, and the deletion is repeated.

a) The clean-up run under no. 1 takes the same route, in the same order: first the objects, then the database rows.

b) Pictures no longer in use are not cleaned up. If a merchant uploads a picture and never uses it or no longer uses it, it remains as long as their shop exists. There is no place in the app where a merchant can delete an individual picture. Anyone who requests this contacts datenschutz@kyth.systems (§ 7.3); the deletion is then carried out manually. 7. Vouchers: personal details three years after creation. Three years after a voucher was created, its personal details are emptied: recipient, their email address and its search value, sender, greeting, buyer, their email address with search value, and the customer number. The voucher itself remains – code, status and value –, because it is the record of an obligation entered into. The period corresponds to the regular limitation period for the claim arising from the voucher (section 195 of the German Civil Code, BGB); the merchant keeps accounting records in their Shopify account. This is carried out daily by the same clean-up run as nos. 1 and 3. A voucher's claim link is not valid for longer than this period.

The rows have a shop assignment and disappear completely with the shop, through shop/redact as well as through the clean-up run under no. 1.

a) The erasure of an individual person does not delete the row. It empties the personal fields and leaves code, status, value and template copy in place (§ 7.2), because the voucher has been paid for and can be redeemed.

b) There is no trigger through Shopify for the recipient. If they request erasure before the period expires, KYTH carries it out manually on the merchant's instructions (§ 7.2).

9.4 Statutory retention

If, exceptionally, there is a statutory obligation to retain data further, deletion does not take place to that extent; the data is restricted in its processing and used exclusively for this purpose. KYTH informs the merchant of such retention.

§ 10 Evidence and audit rights of the controller

10.1 Evidence

On request to datenschutz@kyth.systems, KYTH makes available to the merchant all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR. As a rule, the following suffice:

• this contract with Annex 1 (processing overview) and Annex 2 (technical and organisational measures),
• the current list of sub-processors,
• the response plan for security incidents,
• information about the data stored for the merchant's shop.

10.2 Audits

If this evidence is not sufficient in an individual case, KYTH allows for and contributes to audits, including inspections (Art. 28(3)(h) GDPR). The merchant can carry out the audit themselves or engage an auditor of their choice who is not in competition with KYTH and is bound to confidentiality.

Audits take place after notice with reasonable lead time – as a rule 30 days –, during normal business hours, without disrupting operations and at most once per calendar year; if there is a specific reason, in particular after a personal data breach or at the request of a supervisory authority, also beyond this and at short notice.

10.3 What an audit cannot cover

• Certificates: KYTH holds none. No audit report can be presented that does not exist (see § 5).
• Data centre: the server infrastructure is rented from IONOS SE. KYTH cannot grant an on-site audit in the data centre; for this, reference must be made to IONOS's evidence and certifications.
• Other merchants' data: an audit must not lead to the auditor gaining access to other merchants' data. KYTH will restrict access accordingly.

10.4 Authorities

KYTH assists the merchant in audits by the competent supervisory authority and provides it with information directly on request (Art. 31 GDPR). KYTH informs the merchant without delay of official measures concerning their data, insofar as this is legally permissible.

§ 11 Order of precedence and final provisions

1. This contract takes precedence over the other contractual terms between the parties insofar as processing of personal data on behalf is concerned.
2. Annexes 1 and 2 form part of this contract.
3. Amendments and additions require text form. This also applies to waiving this form requirement.
4. If a provision is invalid, the rest of the contract remains effective. The parties replace the invalid provision with a valid one that comes closest to the purpose pursued.
5. German law applies. The place of jurisdiction is, insofar as legally permissible, KYTH's registered office.
6. Obligation to keep it up to date: contract and annexes reflect the state of the software named in the header. Before every extension that changes the range of data processed, Annex 1 and Annex 2 are compiled anew and the contract is presented in a new version under § 0.3.

§ 12 What you as a merchant must do

The obligations under § 2a are set out there in contractual language. Here they are again, briefly and in plain terms, so that after reading you know what you have taken on.

1. Keep your contact address up to date. The email address you gave when connecting the app is our only way to reach you – in the event of a data breach, a change of contract, a change of sub-processor. Once after installation, we also send you the setup email there if you have chosen a plan and steps are still missing before the first voucher sale (§ 2a no. 4). If the address changes, write to us at datenschutz@kyth.systems. If it becomes undeliverable, we can no longer reach you, and the 72 hours under Art. 33(1) GDPR still run (§ 2a no. 4, § 8.2).
2. Make sure there is a legal basis. For processing your customers' data you need a legal basis under Art. 6 GDPR. We do not and cannot check it.
3. Inform your customers and the recipients. The information obligations under Art. 13 and Art. 14 GDPR lie with you, not with us. Recipients do not provide their data themselves – for this, Art. 14 GDPR applies. Include Kartuu in your own privacy policy.
4. Answer requests from data subjects yourself. If someone contacts us, we forward the request to you and do not answer it (§ 7.1).
5. Report data breaches to your supervisory authority yourself. We report the incident to you; you make the notification under Art. 33 GDPR and inform the data subjects under Art. 34 GDPR (§ 8.2).
6. Give instructions in text form. Individual instructions go to datenschutz@kyth.systems. Please confirm anything you say orally to us in text form without delay (§ 3.2).

Annex 1 – Processing overview

Reflects the state of the software named in the header. The merchant receives evidence for individual details under § 10 on request to datenschutz@kyth.systems; KYTH presents it to a supervisory authority on request (Art. 31 GDPR).

Information under Art. 30(2) GDPR

KYTH does not collect the merchant's complete company details (company name, address, representation); they follow from the merchant's Shopify account and are requested through the stored contact address in the event of a request under Art. 31 GDPR.

Safeguards under Art. 30(2)(c) GDPR. For transfers to Shopify entities outside the EEA: the EU standard contractual clauses under Implementing Decision (EU) 2021/914, incorporated through Shopify's Data Processing Addendum in the version of 7 July 2026. For Canada, in addition, adequacy decision 2002/2/EC. Details are in § 3.4.

A. Data actually stored

The data named is stored in the PostgreSQL database on the server in Berlin and goes into the backups under § 9.3 no. 2 – with two exceptions: of the uploaded pictures, only the description is in the database. The bytes are in the image storage (§ 6.3) and are not part of the database backup. There is no backup for them; if the storage is lost, they are gone. And the message about an uninstallation to KYTH and the preview and report on the announcement under § 0.3 are not in the database but in KYTH's mailbox as emails (last rows).

B. Data touched only briefly – no storage

C. Not processed

Annex 2 – Technical and organisational measures (Art. 32 GDPR)

Reflects the state of the software named in the header. Only measures that have been implemented are listed; section 7 names the known gaps.

1. Confidentiality

1.1 Encryption of stored data

• The following are stored encrypted with AES-256-GCM: access token, refresh token, the merchant's contact address, user name and password of their mail account, and the voucher code, the claim token, the recipient's name, the recipient's email address, the sender's name, the greeting and the buyer's name and email address. Every ciphertext carries a key identifier, and this identifier is cryptographically bound to the ciphertext – rewriting the identifier afterwards is noticed on decryption.
• The database does not allow plain text in an encrypted column. Each of these columns carries a check rule on the ciphertext format, each search value column one on exactly 64 hex characters.
• Search values instead of plain text where searching is necessary. Voucher code, claim token and the email addresses of recipient and buyer each carry a non-reversible search value (HMAC-SHA256) next to the ciphertext. The buyer's Shopify customer number is stored in plain text, because it is the search key of the two data protection webhooks.
• What is not disclosed to Shopify. The note stored on a gift card when it is created contains no personal data. Who receives the voucher is stored in the encrypted column at KYTH and not in a free-text field at Shopify.
• The key comes exclusively from an environment variable; a separate one per environment. There is no operating mode in which encryption could be switched off.
• The search hash does not use the raw encryption key but a separate key derived from it (separation of purposes).
• Field encryption also applies within the database backups; the key is not in the backup and not in the object storage. See § 9.3 no. 2.

1.2 Separation of tenants

• Every table with a shop identifier (shop_id) has row protection at database level (row-level security, with ENABLE and FORCE) and exactly one policy on the tenant that has been set. Without a tenant set, the database returns no row for these tables – no tenant, no access.
• The shops table itself has no row protection. It has no shop_id column but is the shop table; the application role has SELECT on all its rows and DELETE. Tenant separation works there through the application – every query filters by the search hash of the shop domain – and through column-level permissions (1.3). See section 7.
• The application connects with a database role stripped of privileges, which may not bypass row protection and is expressly not the owner of the tables.
• If this role is missing in operation or is identical to the administration role, the application aborts its start instead of running without effective tenant separation.
• The data access layer cannot form a query without a tenant. Table names are checked against an allow-list and a fixed naming pattern, values are passed exclusively as parameters; a raw SQL fragment cannot be passed.
• In the image storage, the namespace itself separates. The key of a picture begins with the identifier of its shop. Two merchants who upload the same picture therefore get two different keys and two separate files. Every key is checked at every point against a fully anchored pattern before a path is made from it; the file storage additionally checks that the resolved path lies below its root directory. There is no generally readable address. A picture is delivered either after the merchant's session has been checked or through a signed address whose signature binds shop, key and a time window together; it is valid for one to two hours. The route passes the signed shop identifier on to the storage, and the storage rejects every key outside this shop. Such addresses appear in the preview in the admin and in the card preview on the product page (Annex 1 section B).

1.3 Permissions limited to what is necessary

Database permissions are granted per column instead of per table:

• changing the shop table only on individually released columns: tokens with expiry, rotation and scope of permissions, time of uninstallation, contact address, consent together with the interface language at the time, subscription status, redeemed promo code, sending route, appearance on the card, house colours, language of the vouchers, setup state, state of the setup email, state of the announcement, state of the review request, the times of the theme blocks seen and of the last merchant message – not on the shop domain, its search hash and the time of installation,
• creating a shop only with domain and hash,
• reading the webhook identifiers only on the columns actually read,
• creating a picture row only on the seven columns actually written – not on the running number and not on the time of upload, which the database sets itself,
• no right to change the access log for protected customer data, so that entries cannot be changed afterwards – and for a different reason none on the picture rows either: the key is the checksum of the content, so a changed row would describe a different object under the same address.

For the vouchers:

• A voucher cannot be created as “ready”. When creating, the application role has no right to the status and to the time of the status change, nor to code, gift card identifier or template copy; these arise only in later steps of the process.
• The identity of a voucher is unchangeable. There is no right to change shop, order, line item, running number, type, template and claim token. This preserves idempotency, and a claim link already delivered does not point into nothing.
• No right to change the assignment of pictures, and on the voucher products only for the state of the product image. Which pictures are in an issued card remains fixed. A created product belongs to the merchant; Kartuu does not reconcile it afterwards.

1.4 No secrets in the wrong place

• Neither access, refresh nor session tokens are logged – not even shortened. The same applies to the merchant's contact address, to the name Shopify holds as the owner of their shop, and to voucher code, claim token, recipient's and sender's names, greeting and the customers' email addresses. From the order process, only the shop domain, order, line item and voucher identifiers, the number of vouchers created, the state reached and the error reason as a short identifier of our own are logged. In the event of an error, as a rule only the type of exception is written; the exceptions to this are in the next point but one.
• Shopify's responses are not logged verbatim either. If Shopify rejects the creation of a gift card or a product, only the error code and the field path are taken over – both names from the GraphQL schema.
• Where the message is also written: if the token exchange with Shopify temporarily fails, a message consisting of our own text, HTTP status code, exception type, line count and shop domain is logged. Also the messages of our own error classes when a card design cannot be checked or rendered (with the name of the affected field or the image key), when a picture is rejected on upload (the reason: format, dimensions, result of the SVG cleaning), when the image storage is unreachable, and the exception's message when a step of the daily clean-up run fails. Tokens, contact addresses, voucher codes and the names, greetings and email addresses of customers do not appear in them in plain text. The messages serve to narrow down the cause of a fault.
• A check run against accidentally committed secrets (gitleaks) runs automatically as a Git hook before every commit to version control and checks the staged changes; if the tool is not set up, the commit is aborted. The local check routine additionally searches the entire history. The environment file is excluded from the repository and the container image.
• Access secrets are stored exclusively in the deployment environment.

1.5 Access log for protected customer data

The log is free of content: the permitted values for actor and field category are secured twice (check in the code and check rule in the database). An error when logging does not bring down the functional call.

Entries arise, among other things, when a paid order is received and with the data protection webhooks. Only the categories actually touched are recorded; an order without any personal detail writes no entry. The entry for the order is created on receipt and not on rendering, so that a repeat run does not create a second entry for the same access.

2. Integrity

2.1 Checking incoming calls

• Webhooks: HMAC-SHA256 over the raw content, comparison in constant time, rejection with status code 401 on errors – and before any further processing.
• Session tokens: check with an enforced signature algorithm, comparison in constant time, tight tolerance for validity times, replay window of 70 seconds, check of the audience against our own application identifier, and cross-check of issuer and destination including protection against injected user information in the host name.
• Requests from the shop (card preview on the product page) come through Shopify's app proxy and are checked by their signature; the requests of the Kartuu block on the thank-you and order status page carry a session token issued by Shopify. Signature, audience (our own application identifier), destination (the shop, from which the tenant assignment also comes) and validity are checked. Two differences compared with the admin session token: the token carries no issuer – the shop is established by signature and destination alone –, and it may be up to 330 seconds old instead of 70, because the extension reuses the same token for up to five minutes.
• Claim page of the vouchers (addresses under /gutschein): in front of the application, the reverse proxy throttles requests per IP address – on average one per second, up to 20 at once. For this, the address is held only in memory and discarded two seconds after its last request. Behind it, the application limits retrievals per shop, separately the requests that lead to no voucher, and the generation of the PDF across all shops.

2.2 Securing the embedded interface

Security headers: content security policy with dynamic framing restriction, whose shop parameter is checked against a fully anchored pattern and responds with rejection if given more than once; X-Content-Type-Options; Referrer-Policy: strict-origin-when-cross-origin.

2.3 Keeping the attack surface small

The interface's schema description and interactive documentation are switched off in production (the routes do not exist there).

2.4 Checking the input of the consent step

The contact address entered in the consent step is checked on the server against a fully anchored pattern (no line breaks, no separators, no angle-bracket-style appendix, domain with a dot, length limit); leading and trailing spaces are removed, upper and lower case is preserved. Consent must be transmitted as a genuine boolean – strings or numbers do not count as consent. The server accepts the interface language sent along only as German or English; any other value does not overwrite a stored value.

Limiting the request body. The body of this request must not exceed 4 kilobytes. The limit works in two places: in advance against the length announced by the caller, and during reading itself, which is aborted as soon as the limit is exceeded – even if a request conceals its length.

The same mechanism for the other requests with a body, each with its own cap: 256 kilobytes for the rendering calls (preview and PDF) and when saving a draft, because there the body carries the complete design document; considerably less for all others. All limits come from one common implementation. A body above the cap ends in a rejection and not in a response with empty values.

2.5 Checking the input of the voucher editor

Texts and designs from the editor are checked on the server before a document is made from them; the server does not rely on a check in the browser.

• Allow-lists instead of free values, and rejection instead of silent replacement. The selectable template, the sheet format, the layer type, the panel of the folded card, the alignment, the font and the permitted placeholder names are fixed. An unknown value is rejected, as is an unknown key in the object transmitted.
• The font never comes as a name from the input. Only an identifier is transmitted, which is mapped on the server to a fixed format template.
• Colours only as a hex value or “transparent”. Colour functions of the design format are thus excluded, including those that could trigger an outgoing call.
• Length limits per field, calculated from the templates' areas: recipient's and sender's names 40 characters each, voucher code 20, amount 18, greeting 240, shop name 60, validity statement 40. In addition, at most 2000 characters per layer text and at most 200 layers per document.
• Numbers only within named limits – font size 4 to 400 points, line height 0.5 to 4.0, letter spacing at most 40 points in either direction, rotation at most 360 degrees, stack position 0 to 999; position and size are checked against the sheet. “Not a number” and “infinity” are rejected instead of being bent into shape.
• Control characters are removed. Line breaks are preserved only in the greeting.
• A second, independent layer at the output. When the HTML is generated, every number runs once more through a fixed format template from which no separator can arise, and is clamped to the sheet format; every colour is checked again against the same allow-list and otherwise replaced by “transparent”. This also applies to a document that reaches the renderer without passing the input check.
• No evaluation of merchant input as a template. The placeholders in a layer's text are replaced purely textually and in one pass. A value that itself looks like a placeholder is therefore not replaced a second time. All free texts are escaped when inserted; a script cannot appear in the result.
• Rate limiting per shop: 120 rendering runs and six PDF retrievals per minute, using a bucket model that refills continuously. The key is the shop domain from the checked session token and never a detail from the body or the address bar. Each of the four worker processes keeps its own quota; the actual upper limit is four times as high.
• The PDF's file name is fixed and is not built from the values.
• None of this ends up in the log. If a value is rejected, the name of the field is recorded, never its content (Annex 1 section A, row application logs).

2.6 Checking uploaded pictures

An uploaded picture is checked once on upload, before it is stored; what does not pass the check is never stored.

• Allow-list of formats. Only JPEG, PNG, WebP and SVG are accepted. Other image formats are rejected and not converted.
• The format is determined from the content, not from the caller's claim. The type the request states is not read, and the request cannot send a file name. A raster image is recognised by its header data and fully decoded; an SVG by the fact that it can be read as SVG.
• Size cap: 5 mebibytes. It works in three places: in advance against the length announced by the caller, during reading, and a third time in the check itself.
• Lock against decompression bombs. The pixel limits (at most 6000 pixels per edge, at most 12 million in total) apply after reading the header data and before decoding. Behind this, as a fallback, is the image library's own limit, lowered to the same value.
• SVG is cleaned, and the cleaned version is stored. The cleaning works with an allow-list for elements and attributes and rebuilds the picture from it. This removes, among other things, script elements and event attributes, embedded HTML, style sheets and the style attribute, and every outgoing reference; references are only permitted to elements of the same document. Document type definitions and entities are switched off. The nesting depth is limited to 40 levels. A picture that would draw nothing after cleaning is rejected and not stored empty.
• Rate limiting per shop: ten uploads per minute, using the same bucket model as in 2.5, but with a quota of its own. Here too the key is the shop domain from the checked session token and never a detail from the request. As in 2.5, each of the four worker processes keeps its own quota.
• Order of the steps. Check the session token, apply the rate limit, resolve the shop – and only then read a byte of the body.
• First the file, then the row. If the process aborts in between, a file without a row remains, which the next identical upload picks up again and which shop/redact also clears through the namespace. A row without a file cannot arise this way.
• None of this ends up in the log. The accepted type or the reason for a rejection is recorded – never the key, never the checksum, never an excerpt of the file.
• Capture data. Kartuu removes it from every raster image. Above 2000 pixels edge length, the picture is scaled down and re-encoded; below that, Kartuu only discards the blocks of the file that carry capture data (EXIF, XMP, IPTC, comments, embedded thumbnails), and the pixels remain unchanged. Only the orientation is kept. Pictures from before 23 September 2026 are cleaned in the same way when the application starts; a file is only replaced if both versions are identical pixel for pixel.

2.7 Measures in the order process

• Idempotency key per item. Shop, order, line item and running number together form a unique index. Shopify repeats a webhook for up to 48 hours; a repeat thus hits the same rows and does not create second vouchers. The shop comes first in the key, so that uniqueness does not apply across shops.
• One record per item, not per line item. Three vouchers bought for 50 euros each produce three rows with three codes; each can be given away and redeemed individually.
• The state machine is in one place and works in two. Ten named states, fixed as a check rule in the database. The single write path attaches the permitted transitions as a condition to the write statement itself; two workers running at the same time cannot advance the same voucher twice.
• Completeness from the state “ready”. The database only allows this state if code and template copy are present – for a value voucher, additionally face value and gift card identifier.
• The code is in the row before the card is created at Shopify. Kartuu first writes the code, in a statement that only takes effect as long as the field is empty; only then does it call Shopify. Of two simultaneous workers, only one calls the mutation, and an abort in between leads to the same code on the next attempt. Because a voucher code is unique per shop, either the missing card is created or Shopify rejects the code as taken. In the end, exactly one paid card exists. If Shopify rejects the code as taken, the process ends in a visible error state (section 7).
• The error reason is a short identifier of our own, never a foreign error message. The database enforces the format [a-z0-9_], so that no passed-through message can quote the recipient's name or voucher code.
• The code is not guessed and not confused. It comes from a cryptographically secure random generator, 16 characters from an alphabet without the pairs that can be confused on paper. The claim token comes from the same source; it authorises retrieval and therefore never appears where the code appears.
• The webhook only acknowledges once the rows are in the database. Everything expensive (Shopify call, rendering) runs afterwards; a restart delays processing but does not lose it.
• What the customer did not fill in in the order form is not guessed. An order through an express checkout arrives without personalisation. These rows are marked “details incomplete”, remain in place and trigger no call to Shopify until the merchant completes the details.
• Delivery exactly once. Before a voucher is sent, a worker process reserves the delivery in the database; a second process finds it reserved and does not send again.

2.8 Traceability of changes

The database schema is changed exclusively through migrations and in a separate process before the application starts; no worker process sees a half-finished schema.

3. Availability and resilience

• The container does not run with system privileges (own user), multi-stage build, health check.
• Lock conflicts in the database run into a time limit of 20 seconds and end in a clean error message instead of a hanging worker process.
• Daily database backup, encrypted with AES-256 before it leaves the server, stored on the server (retention 30 days) and in IONOS's object storage in Berlin (retention 95 days, the first 90 of which cannot be deleted thanks to Object Lock). A copy is thus kept outside the server. Details in § 9.3 no. 2.
• The backup checks itself. Before uploading, the encrypted file is decrypted again and checked to see that a database dump comes out; after uploading, the storage is asked whether the object has arrived in the expected size. A dump that is too small leads to an abort.
• A daily check run reports missing backups to KYTH's operations address if no successful run has been recorded for more than 26 hours. That a backup can be restored has been verified by an actual restoration.
• External monitoring, since 24 September 2026. A computer outside the data centre asks every minute whether the application and its database respond (/health/db), and alerts KYTH after three failed attempts. The answer carries only the state (“ok” or “degraded”), no personal data.
• There is no backup for the uploaded pictures. They are in the image storage and not in the database; the daily run above therefore does not cover them. If the storage is lost, the pictures are gone – the merchants' cards would then be without a picture, and the other details would remain complete. See section 7.

4. Resilience of the configuration

The application does not start without the required configuration values; the encryption key is checked for the correct format. Misconfiguration leads to an abort, not to silent continued running.

5. Separation of test and production

Two separate applications, each with its own database, own encryption key, own database role with its own password, own domain and own Shopify application. The addresses of the legal texts are also derived per environment from the respective application's own address.

6. Procedures for review and evaluation

• Deletion path without a maintained list: the tables to be emptied on deletion are determined at runtime from the database catalogue – all tables in the schema public with a column shop_id; the current data set falls entirely under this. Deletion runs in one transaction.
• One deletion path, two triggers. The clean-up run for orphaned shops (§ 9.3 no. 1) uses the same deletion function as shop/redact, including the first step, removing the pictures through the shop's namespace.
• Automatic checks against creeping deviation: every new table assigned to a shop must be reachable through the data access layer or be excluded with a reason, must carry a delete permission for the application role, and every table with a column that is personal by its naming pattern must be entered in the list of tables with personal fields – otherwise the check fails. Access and erasure under Art. 15 and Art. 17 run over this list; today the voucher table is in it. The shops table is excluded because it has no shop_id column; the contact address in it is excluded as merchant data for exactly this one column.
• Response plan for security incidents with a 72-hour period, named supervisory authority (BayLDA), escalation levels and an express reference to Art. 14 GDPR for recipients.

7. Known gaps

These points are not or not completely fulfilled.