Data Processing Agreement

Version 1.1 · Last updated: September 8, 2026 · Effective from: September 8, 2026

This Data Processing Agreement (the "DPA") is concluded under Article 28 of Regulation (EU) 2016/679 ("GDPR") and Article 28 of Italian Legislative Decree 196/2003, as amended by Legislative Decree 101/2018 (the Italian Privacy Code), between the Shop, as Controller, and radioBros, as Processor, and governs the processing of personal data of the Shop's customers in the context of the TesserApp service.

Version 1.1 aligns this DPA with version 1.2 of the Privacy Policy, following a full review of the service's source code. It extends the disclosures that were previously written for private programs only to every personal card type and to app-less web enrollment; it replaces the sub-processor list, the retention table and the description of security measures with what the systems actually do; and it removes commitments that no automated process enforced. Where this DPA and the Privacy Policy describe the same processing, they are intended to say the same thing.

The Italian-language version of this DPA is the official version and prevails over translations in case of discrepancy.

1. Parties

1.1 Controller: the natural or legal person who registers on the TesserApp Shop platform and subscribes to the Service (hereinafter the "Shop"). The Shop's identifying details are those entered at signup and editable from the dashboard.

1.2 Processor: radioBros di Alberto Miconi, registered office at Via Ridolfino Venuti 30, 00162 Rome (Italy), Italian VAT number IT15127451001, contact email privacy@tesserapp.eu (hereinafter "radioBros").

The Parties mutually acknowledge the roles above, without prejudice to radioBros' independent role as Controller for its own processing in the performance of the subscription (invoicing, Shop account, security logs of its own systems), which is governed by the Privacy Policy and the Terms of Service.

2. Definitions

The definitions of Article 4 GDPR apply. In addition:

• "Personal Data": any information relating to an identified or identifiable natural person within the meaning of Art. 4 no. 1 GDPR, processed by the Processor on behalf of the Controller in the context of the Service.
• "Data Subject": the Shop's customer who holds a loyalty card under one of the Shop's programs, whether that card is held in the TesserApp mobile app or only in Apple Wallet or Google Wallet.
• "Service": the web platform, mobile applications and infrastructure components that radioBros makes available to the Shop for the operation of its loyalty programs.
• "Personal card": a card that is by construction issued to one named individual. There are four types: private (a personal stamp card), discount, access and prepaid. For all four, the holder's name and email address are mandatory.
• "Anonymous card": a standard (stamp) card or a points card, which the Data Subject activates itself from the app or the catalogue, and which carries no name and no email address.
• "Sub-processor": any third party engaged by the Processor to process Personal Data, under Art. 28(4) GDPR. The list is in Appendix A, section A.1.
• "Personal Data Breach": as defined in Art. 4 no. 12 GDPR.

3. Subject matter, duration, nature and purposes of the processing

3.1 The Shop, as Controller, instructs radioBros, as Processor, to process the Personal Data of Data Subjects for the purposes necessary to deliver the Service and as set out in this DPA.

3.2 Subject matter: the technical operation of the Shop's loyalty program, including activation of customer cards, recording of transactions (stamps awarded, prizes redeemed, reversals, changes to a points or credit balance), synchronization of cards to Apple Wallet and Google Wallet, delivery of push notifications related to the loyalty program, delivery of the announcements the Shop composes for the holders of one of its programs, exposure of the program in the consumer app catalogue (where the Shop has opted for public visibility), provision of location-based discovery features, and in addition:

• for personal cards (private, discount, access, prepaid): issuance of a card to a single named holder, delivery of an email installation invitation, and binding of the card to the holder's device account;
• for app-less web enrollment (standard cards only): creation of a card and of a native Wallet pass from a web page, without the Data Subject installing the consumer app, together with the optional name, email address and marketing-consent marker that the enrollment form may collect.

3.3 Nature of processing: automated processing carried out on the Processor's IT infrastructure and that of its authorized Sub-processors.

3.4 Purposes: performance of the contract between the Shop and its own customers in relation to the loyalty program; compliance with the Shop's legal obligations as Controller; security of information systems and prevention of fraud on stamps, prizes and balances; delivery of personal cards to the specific individuals designated by the Controller and restriction of each such card to the holder's device account; and, for app-less web enrollment, creation of a card for a Data Subject who has not installed the app.

3.5 Duration: this DPA is effective for the entire duration of the Shop's subscription to the Service. The obligations under articles 9 (Return and deletion) and 13 (Confidentiality) survive termination.

4. Categories of Data Subjects and Personal Data

4.1 Categories of Data Subjects: customers of the Shop who hold a loyalty card under one of the Shop's programs, whether in the TesserApp consumer app or only in a native Wallet.

4.2 Categories of Personal Data processed (Appendix B):

• anonymous install identifiers (256-bit random tokens, not linked to a person's identity, stored by the Processor only as a cryptographic hash);
• loyalty card identifiers (opaque UUIDs) and card serial numbers;
• transaction metadata (stamp award events, prize redemptions, reversals, points and credit balance changes; date, time and the Shop location at which the operation took place; the amount or number of stamps requested; and, for a reversal, the free-text reason written by the Shop);
• Apple Wallet / Google Wallet pass identifiers, pass update tokens, the identifier the operating system assigns to the device's pass library, and the related push tokens;
• push notification tokens issued by Apple (APNs) or Google (FCM), registered for the app installation itself;
• device system language, platform (iOS or Android) and app version;
• IP addresses and user-agent strings, recorded in audit and access logs for security purposes. Contrary to what version 1.0 of this DPA stated, these are not processed transiently: they are retained as described in Appendix B, section B.2;
• GPS coordinates, exclusively where the Data Subject has enabled the nearby-shops discovery feature or browses the catalogue sorted by distance, and only for the duration of that request. The coordinates are not stored, by the Processor or on the device;
• Data Subject email address, where voluntarily provided by the Data Subject to the Processor (GDPR rights requests, support contacts);
• technical error and crash reports, which carry the device model, the operating system version and the app version, and may contain the technical identifier of a card or program involved in the error. They are configured not to collect user-identifying data and not to attach the IP address.

4.2 bis — Personal cards (private, discount, access, prepaid): for all four personal card types, and not only for private programs:

• the holder's name and email address, both mandatory, provided by the Controller when it creates the card, and processed for the purpose of issuing the card, emailing an installation invitation, printing the holder's details on the card and on the Wallet pass, and displaying them to the Shop's staff when the card is scanned;
• an external reference (external_ref) — the identifier the Controller already uses for that natural person in its own systems, for example an employee or member number — where the Controller sets it through the integration API or the MCP connector;
• a pseudonymous device-account binding reference (an opaque identifier derived from the holder's iCloud or Google account, not the holder's name or email), processed solely to enforce that the card remains on the holder's account.

The Controller warrants that it has a lawful basis and, where required, the Data Subject's consent to provide this data; the Processor processes it only on the Controller's documented instructions.

4.2 ter — App-less web enrollment (standard cards only): where a Data Subject obtains a standard card by enrolling from a web page and adding it directly to Apple Wallet or Google Wallet, without installing the consumer app, the enrollment form may collect:

• an optional name and an optional email address. If they are left blank the card is created anonymously, exactly like a card activated in the app; if they are supplied they are attached to the card and processed on the Controller's behalf as under §4.2 bis;
• a marketing-consent marker, comprising the date and the source of the capture. Today this is a stored field only: no promotional message is sent on its basis, by the Processor or by the Controller through the Processor's systems.

App-less web enrollment is available for standard (stamp) programs only. The enrollment page that radioBros publishes itself asks for none of these fields; they remain available to a Controller that integrates the feature into its own tools.

4.3 Data NOT processed: Data Subject postal address; Data Subject phone number; Data Subject payment data (the Service does not process customer payments to the Shop); browsing history; biometric data; advertising identifiers; special categories of data under Art. 9 GDPR; data on criminal convictions under Art. 10 GDPR; data of minors under 16 (the Service is not directed to that age group). The Processor operates no advertising, attribution or analytics SDK and builds no behavioural profile.

Whether a name and an email address are processed depends on the path by which the card was obtained, not on the card type alone. Version 1.0 of this DPA stated that "for all standard/public programs, name and email remain not processed". That is no longer accurate, and the correct position is:

How the card was obtained	Name and email
Standard or points card self-activated in the app (QR code or catalogue)	Not processed. The card is anonymous and stays anonymous
Personal card (private, discount, access, prepaid) created by the Controller	Always processed — both are mandatory (§4.2 bis)
Standard card obtained through app-less web enrollment	Optional — processed only if the form collects them and the Data Subject fills them in (§4.2 ter)
Card created by the Controller through the integration API or the MCP connector	Name and email as above, plus the Controller's own external reference (§4.2 bis)

5. Obligations of the Processor

The Processor undertakes to:

5.1 process Personal Data only on documented instructions from the Controller, including with regard to transfers of Personal Data to a third country or international organization, unless required to do so by Union or Member State law to which the Processor is subject; in such a case the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;

5.2 ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;

5.3 take all measures required pursuant to Art. 32 GDPR, as described in Appendix D of this DPA;

5.4 respect the conditions referred to in paragraphs 2 and 4 of Art. 28 GDPR for engaging Sub-processors, as further specified in art. 6 of this DPA;

5.5 taking into account the nature of the processing, assist the Controller by appropriate technical and organizational measures, insofar as this is possible, for the fulfilment of the Controller's obligation to respond to requests for exercising the Data Subject's rights under Arts. 15-22 GDPR;

5.6 assist the Controller in ensuring compliance with the obligations pursuant to Arts. 32-36 GDPR, taking into account the nature of processing and the information available to the Processor;

5.7 at the choice of the Controller, delete or return all Personal Data after the end of the provision of services relating to processing, and delete existing copies, unless Union or Member State law requires storage of the data;

5.8 make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller;

5.9 immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.

6. Sub-processors

6.1 The Shop hereby grants the Processor general authorization to engage the Sub-processors listed in Appendix A, section A.1 of this DPA.

6.2 The Processor shall inform the Shop of any intended changes concerning the addition or replacement of other Sub-processors with at least 30 days' prior notice, thereby giving the Shop the opportunity to object to such changes.

6.3 In the event of the Shop's reasoned objection, the Processor shall assess alternative technical solutions. Where it is not possible to avoid the new Sub-processor, the Shop may terminate the subscription without penalty, effective from the date the new Sub-processor becomes operational.

6.4 The Processor enters into a written contract with each Sub-processor containing data protection obligations equivalent to those set out in this DPA, in particular regarding appropriate technical and organizational measures, confidentiality, assistance to the Controller and cooperation with the supervisory authority.

6.5 The Processor remains liable to the Shop for the Sub-processor's actions within the limits provided by Art. 28(4) GDPR.

6.6 Appendix A also lists, separately from the Sub-processors, the other third-party recipients that receive data as the direct effect of a product feature without that data passing through the Processor's systems (section A.2), and the components that are the Processor's own installations on its own domains and are therefore not Sub-processors (section A.3). The distinction mirrors the one used in §4 of the Privacy Policy.

7. Data Subject rights

7.1 Taking into account the nature of the processing, the Processor assists the Controller by appropriate technical and organizational measures, insofar as this is possible, for the fulfilment of the Controller's obligation to respond to requests for exercising the Data Subject's rights under Chapter III of the GDPR (Arts. 12-22), and in particular:

• right of access (Art. 15);
• right to rectification (Art. 16);
• right to erasure (Art. 17), operationalized through the flow described in art. 9 below, whose first step is the immediate and irreversible erasure of the holder's identifying data;
• right to restriction of processing (Art. 18);
• right to data portability (Art. 20);
• right to object (Art. 21);
• right not to be subject to a decision based solely on automated processing (Art. 22): the Service does not operate automated profiling with legal effects on the Data Subject.

7.2 Requests received directly by the Processor are forwarded without delay to the Controller, unless the Processor is authorized in writing by the Controller to respond directly.

7.3 What the dashboard actually offers today. Version 1.0 of this DPA stated that the dashboard provided tools to export, anonymize and suspend the data of an individual Data Subject. Only one of those tools exists. The accurate position is:

Right	How it is exercised today
Erasure of an individual Data Subject	Self-service in the dashboard. Under Settings → Customer data the Controller can look a card up by its serial number and delete it. Deletion removes the holder's name, email and external reference from the card
Export of an individual Data Subject's data	On request, performed by the Processor. There is no per-Data-Subject export in the dashboard. The dashboard's data-export feature produces the Controller's own account archive, not an individual Data Subject's file. Write to privacy@tesserapp.eu and the Processor will prepare the extract
Rectification of an individual Data Subject's details	On request, performed by the Processor, or by the Controller reissuing the card
Restriction / suspension of an individual Data Subject	On request, performed by the Processor. There is no per-Data-Subject suspension control in the dashboard

7.4 The Processor undertakes to extend the self-service tooling to per-Data-Subject export and restriction. Until it exists, this DPA does not represent it as available, and requests under §7.3 are handled by the Processor within the time limits of Appendix C.

8. Personal Data Breach notification

8.1 In the event of a Personal Data Breach of which the Processor becomes aware, the Processor notifies the event to the Controller without undue delay and in any case within 72 hours of becoming aware of it, providing, insofar as possible, the information referred to in Art. 33(3) GDPR and in particular:

• the nature of the breach, the categories and approximate number of Data Subjects concerned;
• the categories and approximate number of personal data records concerned;
• the contact details of the point of contact for the incident;
• the likely consequences of the breach;
• the measures taken or proposed to address it and mitigate its possible adverse effects.

8.2 Where, and to the extent that, it is not possible to provide the information at the same time, the information may be provided in phases without further undue delay.

8.3 It is understood that it is the responsibility of the Controller, under Arts. 33 and 34 GDPR, to decide whether to notify the breach to the supervisory authority and communicate it to the Data Subjects.

9. Return and deletion of Personal Data at termination

9.1 Export. Upon termination of the subscription, and in any case within 30 days of termination, the Shop may request from the Processor the full export of the Personal Data in a structured, commonly used and machine-readable format. The export is produced as a ZIP archive containing JSON files, uploaded to the Processor's object storage and delivered to the Shop as a signed link valid for 48 hours. Customer-side identifying material that is not the Shop's to receive (install token hashes, IP addresses) is anonymized inside the archive.

9.2 Deletion. After the expiry of the period above without a request for export, or following completion of the export, the Processor proceeds to delete the Personal Data. The lifecycle actually enforced by the Service is the following, and version 1.0's statement that data is "permanently deleted from production systems within 5 days" is withdrawn:

• a suspended subscription is cancelled automatically after 60 days;
• 150 days after cancellation the Shop is sent a notice that its data is about to be deleted;
• 180 days after cancellation the account is anonymised automatically. Anonymisation removes the login name and email, the password, the second factor, passkeys, social identities, staff records, paired devices, API keys, and the name, email address and external reference on every one of the Shop's customers' cards;
• where the Shop requests deletion from the dashboard, the same anonymisation is carried out 30 days after the request, that period being a grace window in which the request can be cancelled;
• an individual card that is deleted has the holder's identifying fields erased at the moment of the request, together with the install credential that bound the card to the holder's device; the deletion is irreversible from that moment and no recovery window exists. Within 30 days a scheduled nightly job removes the card's dependent rows and the card row itself, save where a retained transaction record refers to it: the row is then purged in place, leaving a bare identifier that identifies nobody, which is removed in any event on the anonymisation described above.

9.3 Data excluded from deletion. Excluded from deletion, for the strictly necessary time, are Personal Data whose retention is required by legal obligations binding on radioBros. This concerns the Processor's own invoices to the Shop, not Data Subject data, and the retention period is 10 years:

• Art. 2220 of the Italian Civil Code requires that invoices — those received, and the copies of those issued — and the accounting records that refer to them be kept for 10 years. This is the obligation actually applied, and it is the period stated in the Privacy Policy and in the Terms of Service.
• Applicable Italian tax law (DPR 633/1972; D.Lgs. 127/2015) sets a shorter minimum of 7 years, which the period above already satisfies.

Such data is kept in segregated custody, with restricted and audited access, and is not subject to any further processing other than performance of the obligation.

9.4 Upon written request of the Shop, the Processor issues a formal statement of deletion completed.

10. International data transfers

10.1 The Processor processes Personal Data on its own systems exclusively on infrastructure located within the European Economic Area. Production systems are hosted in Germany.

10.2 Some Sub-processors listed in Appendix A may have their seat or operations in the United States (in particular Stripe, Apple, Google, Cloudflare). Transfers of Personal Data to such parties are carried out on the basis of the Standard Contractual Clauses adopted by the European Commission with Decision 2021/914/EU, supplemented by additional measures where necessary in light of CJEU judgment C-311/18 (Schrems II).

10.2 bis — Transfers that do not pass through the Processor's systems. Certain recipients listed in Appendix A, section A.2 are contacted directly by the Shop's browser or by the Data Subject's device, as the direct effect of a product feature. For these, the place of processing is the recipient's own and the Processor is not in the transmission path:

• Overpass (overpass-api.de, a public service of the OpenStreetMap project): on iOS, the Data Subject's device sends it the GPS coordinates when the nearby-shops feature is used;
• LocationIQ (Unwired Labs): the Shop's browser sends it the address text typed into the dashboard;
• Google Fonts and Stripe.js: loaded by the dashboard on every page, so the IP address and browser type of whoever opens the dashboard reach Google and Stripe respectively.

10.3 No transfers are made to third countries outside the Standard Contractual Clauses framework or an adequacy decision of the Commission, save for the browser-direct and device-direct calls in §10.2 bis, whose transfer basis is stated in Appendix A.

11. Technical and organizational measures

The technical and organizational measures adopted by the Processor under Art. 32 GDPR are described in Appendix D of this DPA, which forms an integral part hereof. Appendix D distinguishes measures that are in place today from those the Processor undertakes to put in place. Such measures are subject to periodic update to reflect the state of the art; any update may not result in a reduction of the level of security guaranteed.

12. Audit

12.1 The Processor makes available to the Controller, upon written request, the information necessary to demonstrate compliance with the obligations under Art. 28 GDPR and this DPA.

12.2 The Controller may request, once per calendar year, the performance of an audit, to be carried out upon at least 30 days' prior written notice, during business hours, at the Processor's premises, in a manner that does not interfere with the operational continuity of the Service and respects the security measures in force.

12.3 The direct costs of the audit are borne by the Controller, unless the audit reveals significant breaches of this DPA attributable to the Processor, in which case the costs are borne by the Processor.

12.4 The Processor holds no third-party security certification today (no SOC 2 report, no ISO 27001 certificate). Should it obtain one, it may offer the corresponding independent auditor's report, together with equivalent documentation, in lieu of the on-site audit.

13. Confidentiality

13.1 The Parties undertake to treat as strictly confidential all information acquired in the performance of this DPA, except for information in the public domain or whose disclosure is required by law or order of the authority.

13.2 The confidentiality obligation extends to the Parties' employees, collaborators and Sub-processors and survives termination of this DPA.

14. Liability and indemnity

14.1 Each Party is liable for the damage caused by its processing which violates the GDPR, within the limits and in the manner provided by Art. 82 GDPR.

14.2 In the internal relations between the Parties, radioBros' liability to the Shop for the processing of Personal Data is governed by the limitation-of-liability clause in the Terms of Service, save for cases of wilful misconduct or gross negligence and without prejudice to liability to the Data Subject under the GDPR.

14.3 The Shop guarantees and holds radioBros harmless from any claim arising from the Shop's breach of its own obligations as Controller under the GDPR (in particular: proper information to Data Subjects under Arts. 13-14 GDPR; proper legal basis for processing; correctness of instructions issued to the Processor).

15. Duration, amendments and final provisions

15.1 Duration. This DPA is effective from the date of acceptance by the Shop at signup (through a dedicated tick-box) and for the entire duration of the subscription to the Service. The obligations of return/deletion (art. 9) and confidentiality (art. 13) survive termination.

15.2 Amendments. Material amendments to this DPA shall be communicated to the Shop with at least 30 days' prior notice by email to the address registered on the account and through a dedicated banner on the dashboard. The Shop will be required to re-accept the new version at the next login. Failure to accept entails the right to terminate the subscription without penalty.

15.2 bis — Entry into force of version 1.1. Version 1.1 of this DPA takes effect on the publication date shown at the top of this document, without waiting out the 30 days' notice provided for in §15.2. The reason lies in what this revision is: version 1.1 imposes no new obligations on the Controller and reduces no protection for Data Subjects; it corrects statements in version 1.0 that were inaccurate, widens the disclosures made, and withdraws commitments that no process of the Service ever carried out — among them the deletion “within five days” addressed in §9.2, which the systems did not perform. In several places the resulting text is less favourable to the Processor and more favourable to the reader, because it stops over-claiming the confidentiality on offer and stops promising deletions that did not happen. To defer a correction of that kind by 30 days would be to keep a text known to be inaccurate in force for another 30 days: the notice period in §15.2 exists to protect the Shop from changes that alter obligations, not to delay a truthful description of processing already under way. This reasoning does not extend to §6.2, which this provision leaves wholly untouched. Appendix A now lists recipients that version 1.0 did not: most were already involved in the processing and are simply being written down. At least one, however — Unwired Labs (LocationIQ), engaged in June 2026 for address autocompletion in the Shop dashboard — was genuinely added after version 1.0, and the status of the further items in Appendix A, section A.4 is not yet determined. For those, §6.2 applies in full: the 30 days' notice and the Shop's right to object are given as that article requires, and section A.4 records that commitment.

§15.2 survives intact. §15.2 remains in full force for every future amendment of this DPA. §15.2 bis is a one-time transitional carve-out, confined to the entry into force of version 1.1: it does not reduce, reinterpret or suspend the 30 days' notice, the requirement to re-accept, or the right to terminate without penalty that §15.2 confers on the Shop, and the same holds for §6.2 as regards the actual addition of a new Sub-processor. Any later amendment that alters the obligations of the Parties follows §15.2 in full.

The notice given with this publication. On the entry into force of version 1.1 the following is given: publication of the text on this page, carrying the date and version number at its top; an email to Shops at the address registered on the account; and a request to accept the new version, which will be put to the Shop once the facility for it is available — at the publication date the Service has no re-acceptance mechanism, and this provision does not promise one before then. No notice is given to Data Subjects through the app: the app is not a channel for legal notices. A Shop that does not wish to accept version 1.1 retains the right under §15.2 to terminate without penalty.

15.3 Language. The Italian-language version of this DPA is the official version and prevails over translations in case of discrepancy.

15.4 Governing law and jurisdiction. This DPA is governed by Italian law. Any dispute is subject to the exclusive jurisdiction of the Court of Rome.

15.5 Acceptance tracking. Acceptance of the DPA is tracked by the Processor by recording: Shop legal name, email of the user who accepted, IP address, timestamp and DPA version accepted. Such data constitutes proof of acceptance under Arts. 20 and 21 of Italian Legislative Decree 82/2005 (Digital Administration Code).

---

Appendix A — Sub-processors, other recipients and own infrastructure

This appendix uses the same three-way split as §4 of the Privacy Policy, so that the two documents can be read side by side.

A.1 Sub-processors (GDPR Art. 28)

Providers that process Personal Data on the Processor's behalf, under an Art. 28 agreement. The "Whose data" column matters: some of these providers touch only the Shop's own data and never Data Subject data.

Sub-processor	Seat and place of processing	Role	Whose data, and which	Transfer basis
Contabo GmbH	Germany	VPS hosting of all production systems: database, application, job queues, cache, catalogue search index, and the database dumps described in D.3	Data Subject data — every category subject to the Service	EU processing
Stripe Payments Europe Ltd.	Ireland (group with US operations)	Processing of Shop subscription payments; invoice issuance	Shop data only — payment and tax data. Not Data Subject data	SCC 2021/914/EU
Cloudflare, Inc.	USA — R2 buckets configured in the EU region	Object storage for the program and access-card images the Shop uploads and for the GDPR export archives the Shop requests; CDN for static resources. No database backup is stored here (see D.3)	Shop data, plus Data Subject data to the extent it is contained in an export archive the Shop has requested	SCC 2021/914/EU
Apple Inc.	USA	Apple Wallet pass delivery and push notifications (APNs); provisioning of the Shop's own Pass Type ID and signing certificate through the App Store Connect API	Data Subject data — push tokens, pass identifiers, and the pass content itself, which for personal cards includes the holder's name and email. The App Store Connect calls carry Shop identifiers only	SCC 2021/914/EU
Google LLC	USA	Google Wallet pass delivery (Google Wallet API) and push notifications (Firebase Cloud Messaging)	Data Subject data — as for Apple	SCC 2021/914/EU
Operator of the transactional mail host mail.tesserapp.eu	[TO BE COMPLETED — see A.4]	Delivery of transactional email over SMTP: card installation invitations, activity alerts, service notices	Data Subject data — recipient email address and the content of the message; and Shop data	[TO BE COMPLETED — see A.4]
Unwired Labs (LocationIQ)	[TO BE COMPLETED — see A.4]	Address autocompletion in the Shop dashboard. Engaged by the Processor, but the call is made directly from the Shop's browser with a publishable key and does not pass through the Processor's systems — see A.2 and §10.2 bis	Shop data only — the address text typed and the browser's IP address. Not Data Subject data	[TO BE COMPLETED — see A.4]
Electronic-invoicing intermediary for the Italian Sistema di Interscambio (SdI)	Italy	Transmission of the Processor's own electronic invoices. Conditional: the Service supports an external intermediary, but the default configuration submits nothing to one. Whether production uses an intermediary today is [TO BE COMPLETED — see A.4]	Shop data only — invoice data. Not Data Subject data	EU processing

Removed in version 1.1. Two providers named in Appendix A of version 1.0 are not, and never were, engaged, and have been removed:

• Resend — never used. There is no dependency, no call site and no configuration for it anywhere in the Service. Transactional email is sent over SMTP through mail.tesserapp.eu. A database column named resend_message_id survives as a legacy name and is filled with the message id returned by the SMTP server.
• FontAwesome, Inc. — receives nothing. cdn.woptima.com is the Processor's own licensed icon CDN (see A.3); this website's icons are compiled into the published pages.

A.2 Other third-party recipients

Services that receive data as the direct effect of a product feature, without that data passing through the Processor's systems. They are not Sub-processors, because the Processor is not in the transmission path.

Recipient	What it receives, and when
Overpass — overpass-api.de, a public service of the OpenStreetMap project	On iOS, when the Data Subject uses the nearby-shops feature, the device sends this public endpoint the Data Subject's GPS coordinates, at full precision and not rounded, to look up points of interest within a 50-metre radius. Nothing else is sent: no identifier, no card, no app data. On Android the same client exists in the app but the code path is not currently reached
LocationIQ (Unwired Labs)	When the Shop types an address in the dashboard, the browser sends LocationIQ the text typed (and, in the location forms, the country code). It does not send the Shop's identity or any session data. The browser's IP address is implicit in every call. The publishable key is embedded in the dashboard bundle and is domain-restricted
Google LLC (Google Fonts)	The dashboard's typefaces are loaded from fonts.googleapis.com and fonts.gstatic.com on every page: Google therefore receives the IP address and browser type of whoever opens the dashboard
Stripe, Inc. (Stripe.js)	The payment library is loaded on every page of the dashboard, not only on the billing pages: Stripe therefore receives the IP address and technical browser data even when no payment is under way. Card details are entered into Stripe-hosted fields and never pass through the Processor's systems
Apple Inc. / Google LLC (Sign in with Apple / with Google)	Only where the Shop chooses to sign in with Apple or Google, and only for the sign-in operation
Apple Inc. / Google LLC (device backup, native wallets)	In their role as the providers of the Data Subject's own account: the consumer app's local database, including the holder name and email on personal cards, is carried into the Data Subject's own iCloud or Google account backup

A.3 The Processor's own infrastructure

Components that may look like third-party services but are the Processor's own installations, on the Processor's own domains, with no data shared with the software's vendor. They are not Sub-processors.

Component	Software	Role
glitchtip.radiobros.com	GlitchTip (self-hosted)	Collection of the apps' technical error and crash reports. Configured not to collect user-identifying data, not to track sessions and not to attach IP addresses
helpdesk.radiobros.com	Zammad (self-hosted)	Support system for the Shop's tickets. Receives the Shop's contact email and business name, and the title, body and attachments of each ticket
mail.tesserapp.eu	SMTP	The Processor's own transactional mail domain. Who operates the host behind it is recorded in A.1
cdn.woptima.com	Static CDN under the Processor's own licence	Delivery of interface icons, both to the browser and to the Processor's servers when they compose a Wallet pass. No personal data. FontAwesome, Inc. receives nothing
adminizer.radiobros.com	Authentik (self-hosted)	Identity provider gating administrative and machine-to-machine access to production systems
Central application-log collection	Loki (self-hosted)	Diagnostics and security. Where enabled, logs may contain IP addresses and the technical context of a request
Catalogue search index	Meilisearch (self-hosted, on the production host)	Search over public programs. Holds Shop program data, not Data Subject data: no names, no email addresses, no cards

A.4 Open items in this appendix

The following are not determinable from the Service's own configuration and are stated here as open rather than guessed. The Processor will complete them in the next version and, if any of them turns out to add a Sub-processor, will give the 30 days' notice required by §6.2:

1. Who operates the mail host mail.tesserapp.eu, its place of processing and its transfer basis.
2. LocationIQ's place of processing and transfer basis (Unwired Labs).
3. The hosting provider of the Processor's own *.radiobros.com subdomains listed in A.3.
4. Whether production submits electronic invoices through an external SdI intermediary today.

The current list is maintained in this appendix. Version 1.0 referred the Shop to a "Privacy → Sub-processors" page in the dashboard; no such page exists, and this appendix is the authoritative list.

Appendix B — Categories of data and retention periods

Version 1.0 of this appendix quoted retention periods that no process enforced. This version separates the two cases, on the principle that it is better to describe how the Service actually behaves than to publish a deadline nothing applies.

B.1 Periods enforced by an automated process

Category	Retention	Legal basis
Webhook delivery records sent to the Shop (for personal cards these payloads contain the holder's name and email)	30 days, deleted automatically by a scheduled sweep. When a card is deleted, the name, email and external reference are masked immediately in payloads already stored; the technical record of the call (event, outcome, date) remains until the 30 days elapse	Legitimate interest in the reliability of the integration
Shop subscription lifecycle	A suspended subscription is cancelled after 60 days; 150 days after cancellation a deletion notice is sent; 180 days after cancellation the account is anonymised, which removes the name, email and external reference on every one of the Shop's customers' cards	Art. 28(3)(g) GDPR; storage limitation
Deletion requested by the Shop from the dashboard	Executed 30 days after the request, with the same anonymisation. The window is a grace period in which the request can be cancelled	Controller's instruction
Individual card deleted by the Data Subject or by the Shop	Identifying fields erased immediately and irreversibly; no recovery window. The dependent rows and, where no retained transaction refers to it, the card row itself are removed within 30 days; see B.2	Performance of the loyalty program contract
Unconsumed payment intents for new locations	24 hours, then deleted by a daily sweep	Performance of contract (Shop data only)

B.2 Categories with no automated expiry

For the following, no scheduled job deletes the data. It is removed on request under §7.3, and in any event by the anonymisation in B.1.

Category	What actually happens
Loyalty card identifiers and card rows in a "deleted" state	The row is retained indefinitely in a "deleted" state. A timestamp field for a permanent purge is written when a card is deleted, but nothing reads it: the permanent purge is a manual administrative operation. Version 1.0's "deletion within 5 days" is withdrawn
Transaction metadata (stamps, prizes, reversals, balance changes)	Retained as the record of the Shop's activity, and not deleted along with an individual card. References to the holder are removed when the holder's data is erased. Version 1.0's "24 months active, then archived with pseudonymized references" is withdrawn: there is no such archival job
Audit events and access logs, including IP address and user-agent	Retained with no predefined expiry. There is no retention job for them, and no separate access-log table. They are the record of what was done, including the proof that an erasure was carried out. Version 1.0's "IP addresses nulled upon permanent deletion of the Data Subject's card" is withdrawn
Outbound email records (recipient address and the content of the template variables)	Retained with no automatic expiry: nothing deletes them. Version 1.0's "30 days from the conclusion of the proceeding" is withdrawn
Data Subject email address voluntarily provided to the Processor	Retained as long as needed to handle the request and to evidence the outcome. No automatic expiry
Shop announcements sent to a program's holders (title, text, image, link, number of devices reached)	Retained as the record of the Shop's communications. No automatic expiry
Install registrations for notifications (install token hash, push token, language, platform, app version)	Retained until removal is requested. No automatic expiry
Apple / Google Wallet pass identifiers and update tokens	Retained until the Data Subject removes the pass from the native wallet, or the card is deleted
GPS coordinates	Not retained at all. They travel in the single request that uses them and are stored neither by the Processor nor on the device
GDPR export archives requested by the Shop	The ZIP is uploaded to object storage and delivered through a 48-hour signed link. The archive then remains in the bucket until removed manually: the 7-day storage lifecycle rule referred to in the code is not configured. The signed link's expiry, not a deletion job, is what limits exposure
Support tickets in the Processor's helpdesk	Retained with no automatic expiry
Technical error and crash reports	Retained in the Processor's own diagnostics system for as long as needed to fix the defect
Shop subscription invoices	See §9.3: 10 years under Art. 2220 of the Italian Civil Code, which names invoices expressly; applicable tax law requires at least 7, which that period already satisfies. Shop data, not Data Subject data

Appendix C — Data Subject rights and methods of exercise

The Shop is the first recipient of GDPR rights requests from its own customers. radioBros assists the Shop by providing:

• a customer-data tool in the dashboard (Settings → Customer data) that looks a card up by serial number and deletes it, removing the holder's name, email address and external reference. This is the only per-Data-Subject action available as self-service today; export, rectification and restriction are performed by the Processor on request, as set out in §7.3;
• the option to request directly from radioBros, at privacy@tesserapp.eu, the exercise of rights, which will be forwarded without delay to the Shop, or actioned on the Shop's instruction;
• an audit trail of significant operations, held by the Processor and made available to the Shop on request. Version 1.0 described this as "accessible at any time by the Shop"; there is no dashboard view of it today, and the Processor supplies the relevant extract on request.

Indicative response times (maximum under Art. 12 GDPR): 30 days from the request, extendable by a further 60 days in case of complexity, with notice to the Data Subject.

Appendix D — Technical and organizational measures (Art. 32 GDPR)

Each measure below is marked [in place] where it is implemented in the Service today, or [undertaking] where the Processor commits to it without yet being able to evidence it. Version 1.0 presented several measures as facts that the systems did not implement; those are corrected here.

D.1 Confidentiality

• [in place] Encryption in transit via TLS 1.2 or higher on all exposed endpoints.
• [in place] Encryption at rest with AES-256 (SSE) for objects stored on Cloudflare R2. Application secrets — Wallet pass certificates, TOTP secrets — are encrypted with AES-256-GCM under a separate key.
• [in place] argon2id hashing, with OWASP-compatible parameters, for Shop account passwords, staff PINs and recovery codes. No password is ever stored in plaintext.
• [in place] SHA-256 hashing for high-entropy random tokens — session cookies, install tokens, invitation tokens, API keys. Version 1.0 stated that authentication tokens were argon2id-hashed; that is not correct, and the choice is deliberate: for a 256-bit random token the search space already makes brute force infeasible, so a deliberately slow hash buys nothing and costs a lookup on every request.
• [in place] Certain tokens are stored as issued, not hashed, because they must be replayed verbatim to a third party or matched by an inbound caller: push notification tokens (APNs, FCM), the Wallet pass authentication token, and the single-use wallet claim tokens used by app-less enrollment. Their exposure is limited by scope — a push token is meaningless outside the Service's own app; a pass authentication token authorises only pass updates for that one pass — and by the access controls in D.2.
• [in place] Segregation of environments (production, staging, development) with distinct credentials and no access to production data from non-production environments.

D.2 Integrity

• [in place] Role-based access control on production infrastructure, with administrative and machine-to-machine access gated by the Processor's own identity provider (A.3).
• [in place] Audit log of every significant administrative and Shop-side operation, written to a dedicated table to which the application only ever appends.
• [in place] Versioned database schema migrations, tracked by a hash journal that detects a modified migration.
• [in place] Rate limiting on authentication and public API endpoints.

D.3 Availability and resilience

Version 1.0 described "automatic daily database backups with Point-In-Time Recovery (PITR) via WAL streaming (pgBackRest)". No part of that is implemented. What the Service actually does:

• [in place] Hourly logical database dumps (pg_dump, custom compressed format), taken by a dedicated container that connects directly to PostgreSQL.
• [in place] Three-step verification of every dump before it is published: the dump command must exit successfully; the file must exceed a minimum size, which catches the "connected, authenticated, dumped an empty schema" failure; and the dump's table of contents must contain a sentinel table, which proves real data is inside. Only a dump passing all three is published, and only a verified success is allowed to prune older dumps — so a run of failures can never erode the good backups that remain.
• [in place] Flat retention of the 168 most recent dumps, held on the production host's own filesystem. At the hourly interval that is roughly one week of history. There is no tiered promotion.
• Not implemented, stated plainly: the dumps are not encrypted by the backup process itself; there is no WAL archiving and therefore no point-in-time recovery — the recovery point is the backup interval; and the dumps are not replicated off-host. A machine-readable status file records the outcome of the most recent run.
• [undertaking] Encryption of the dumps at rest, and an off-host copy.
• [undertaking] Documented restore drills, at least annually.
• [undertaking] Infrastructure monitoring with alarms on security and availability anomalies.
• [in place] Rate limiting on public endpoints. Version 1.0's claim of "perimeter anti-DDoS via Cloudflare" is withdrawn: Cloudflare is used for object storage and static delivery, and does not sit in front of the API.

D.4 Verification procedures

• [undertaking] Annual external penetration test.
• [undertaking] Six-monthly internal review of security configurations.
• [undertaking] Vulnerability management with defined remediation targets (critical: 7 days; high: 30 days; medium: 90 days).

D.5 Processing continuity

• [undertaking] Documented disaster recovery and incident management procedures.
• [in place] Substitutability of infrastructure Sub-processors within reasonable timeframes, the Service being deployed from a versioned container definition rather than from provider-specific managed services.

D.6 Incident handling

• [in place] A single named point of contact for Personal Data Breach handling, reachable at privacy@tesserapp.eu.
• [undertaking] A written internal breach-handling procedure with a predefined notification chain, to ensure compliance with the 72-hour deadline in art. 8 of this DPA.

---

Contacts

• Processor: radioBros di Alberto Miconi, Via Ridolfino Venuti 30, 00162 Rome (Italy), Italian VAT number IT15127451001.
• Email for any matter relating to this DPA: privacy@tesserapp.eu.
• Lead supervisory authority for radioBros: Italian Data Protection Authority (Garante) — gpdp.it. Shops established in other EU Member States may also contact their local supervisory authority.

---

Version 1.1 — adopted on September 8, 2026, superseding version 1.0 of May 30, 2026. Historical versions, where available, are archived in PDF format at URLs https://tesserapp.eu/legal/dpa/v{version}.pdf.