Privacy Policy

This Privacy Policy for palmstudio GmbH, doing business as DigiCard Pro ("we," "us," or "our"), explains how and why we collect, use, store, disclose, and otherwise process personal information when you use our services ("Services").

The Services include:

• the website https://www.digicard.pro;
• the public digital business card generator;
• the authenticated card management platform;
• Apple Wallet and Google Wallet card generation;
• card delivery links and transactional emails;
• related support, billing, account, and communication features.

We are responsible for deciding how personal information is processed in connection with the Services, except where a third-party provider acts as an independent controller for its own services, for example payment-provider, wallet-provider, or identity-provider services.

If you do not agree with this Privacy Policy, please do not use the Services.

Controller and Contact Details

Controller:

palmstudio GmbH
Pfalzgrafenstraße 38
67434 Neustadt an der Weinstraße
Germany

VAT ID: DE364046229

Privacy contact:

• Email: support@digicard.pro

Summary of Key Points

We process personal information to provide digital business cards that can be saved to Apple Wallet and Google Wallet.

The most important data you provide is the card data itself, such as names, company details, job titles, email addresses, phone numbers, websites, addresses, notes, social links, logos, and QR payload settings.

For direct vCard cards, the QR code contains contact data directly. Anyone who scans or otherwise receives the QR code may be able to read, save, import, or forward that contact data.

For Google Wallet cards, we send the information required to create and update a Google Wallet object to Google. This may include card display data, QR payload data, wallet object identifiers, layout information, and logo image URLs.

For Apple Wallet cards, we generate .pkpass files and may process Apple Wallet update-service data, including pass identifiers, device registration identifiers, and APNs push tokens when a pass registers for updates.

We use Dodo Payments for hosted checkout. We do not process full payment-card details directly in our application.

We use Firebase/Google Cloud for authentication, backend infrastructure, database, storage, hosting-related services, and analytics where enabled.

We use Resend for transactional emails such as verification emails, order-ready emails, and card delivery emails.

We use Termly for embedded legal policies and consent-preference functionality.

We use Google Tag Manager as a consent-gated tag management tool where enabled. We use Google Ads conversion tracking for advertising measurement where enabled, including purchase and add-to-cart conversion events. If enhanced conversions are enabled and advertising consent is present, we may send Google a server-generated SHA-256 hash of the buyer email for conversion matching.

We use DataFast for consent-gated website analytics and revenue attribution where enabled. DataFast may set a visitor identifier cookie, and the visitor ID may be used with Dodo Payments metadata to attribute successful payments to traffic sources.

We may process optional location data for Apple Wallet lock-screen relevance if you choose to use that feature.

You have rights under applicable data protection laws, including rights to access, correct, delete, restrict, object, portability, and complain to a supervisory authority, subject to legal requirements and exceptions.

Table of Contents

1. Who This Policy Applies To
2. What Information We Collect
3. Card Data, vCards, and Third-Party Card Subjects
4. Wallet Provider Data Sharing
5. Payments, Orders, and Billing
6. Account Registration and Google Sign-In
7. Cookies, Analytics, Local Storage, and Similar Technologies
8. Location Data
9. How We Use Personal Information
10. Legal Bases for Processing
11. When and With Whom We Share Personal Information
12. International Transfers
13. How Long We Keep Personal Information
14. How We Protect Personal Information
15. Children
16. Your Privacy Rights
17. Account Closure and Deletion
18. Do-Not-Track Signals
19. Region-Specific Rights
20. Updates to This Policy
21. Contact
22. Review, Update, or Delete Your Data

1. Who This Policy Applies To

This Privacy Policy applies to personal information processed when:

• you visit our websites;
• you create or manage a digital business card;
• you create an account;
• you purchase a card or card credit;
• you use the anonymous generator;
• you use templates, groups, or bulk imports;
• you claim an anonymous card or template into an account;
• you upload logos or images;
• you request or receive wallet delivery links;
• you receive transactional emails from us;
• you contact support;
• someone creates or manages a card containing your personal information.

If a customer creates a card for an employee, colleague, client, or other third party, that customer is responsible for having a lawful basis or permission to provide that person's data to us and to create or distribute the resulting digital business card.

2. What Information We Collect

2.1 Information You Provide Directly

Depending on how you use the Services, we may collect:

• name;
• email address;
• phone numbers;
• professional title or job title;
• company or organization name;
• website URL;
• postal address or business address;
• notes or additional card text;
• social profile links or identifiers, including LinkedIn, Instagram, X, Facebook, WhatsApp, Telegram, WeChat, LINE, and Snapchat where supported;
• card language;
• card design data, such as colors, card name, card title, selected wallet front layout, and logo references;
• uploaded logos and related image metadata;
• QR payload settings, including direct vCard or supported direct URL settings;
• group names, descriptions, defaults, locked fields, and group settings;
• spreadsheet or CSV import rows used for bulk card creation;
• account registration details;
• marketing email opt-in status;
• support messages and other correspondence;
• billing and checkout contact details.

2.2 Account and Authentication Data

For registered users, we may process:

• Firebase Auth user ID;
• account email address;
• email verification status;
• display name;
• selected locale;
• signup source, such as email/password or Google sign-in;
• timestamps for terms acceptance and privacy acknowledgement;
• marketing email opt-in status;
• last login timestamp;
• active company context, memberships, and roles where company features are used;
• Dodo customer IDs stored for authenticated checkout and customer portal access.

Passwords are handled by Firebase Authentication. We do not store plaintext passwords.

2.3 Anonymous Generator, Draft, Cart, and Claim Data

When you use the anonymous generator, we may process:

• saved card drafts;
• anonymous card IDs;
• browser-local draft references;
• cart access tokens;
• anonymous checkout access tokens;
• claim tokens;
• checkout success access credentials;
• template access tokens;
• token hashes stored server-side;
• token status, expiry, and usage timestamps.

Anonymous browser storage generally stores references and access tokens rather than full card content. The full card data is stored server-side after explicit save, cart, checkout, or template actions.

2.4 Wallet Generation Data

For wallet generation, we may process:

• resolved card contact data;
• QR payload data and hashes;
• Apple Wallet pass files;
• Google Wallet class and object identifiers;
• generated wallet assets;
• wallet generation status and error messages;
• timestamps for generation, publication, and delivery;
• public or signed URLs needed to display or deliver wallet assets.

2.5 Apple Wallet Update Data

Apple Wallet passes may include update-service metadata. If an installed Apple Wallet pass registers for updates, we may process:

• pass type identifier;
• pass serial number;
• pass authentication data derived server-side;
• Apple Wallet device library identifier;
• Apple Push Notification service push token;
• registration timestamps;
• APNs environment;
• pass publication and push notification timestamps;
• update errors.

This data is used to support in-place updates for eligible editable Apple Wallet passes and to stop sending updates where registrations are removed or invalid.

2.6 Google Wallet Data

For Google Wallet cards, we create or update Google Wallet generic objects through Google APIs. We may send Google the data required to create, display, save, and update the Google Wallet card, including:

• card display fields such as name, company, title, email, phone, and layout fields selected for the wallet front;
• QR payload data, including the direct vCard or supported direct URL;
• logo image URLs or generated Google Wallet image URLs;
• background and text color data where applicable;
• Google Wallet class ID;
• Google Wallet object ID;
• issuer and object metadata required by Google Wallet;
• update requests when an editable card changes.

Google Wallet may process this data as an independent provider under Google's own terms and privacy documentation when users save or interact with the wallet object. The Google Wallet save flow may require the end user to use Google services or a Google account.

Our use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements, where that policy applies.

2.7 Payment and Order Data

When you start checkout or make a purchase, we may process:

• order ID;
• checkout session ID;
• payment transaction ID;
• purchased item type;
• card variant;
• quantity;
• currency;
• subtotal, tax amount, total amount;
• order status;
• fulfillment status;
• buyer account ID, if logged in;
• buyer email, if available;
• Dodo checkout session ID;
• Dodo payment ID;
• Dodo customer ID;
• Dodo customer email;
• DataFast visitor ID where analytics consent is present and revenue attribution is enabled;
• Google Ads enhanced-conversion email hash where advertising consent is present and enhanced conversions are enabled;
• provider status, error codes, and error messages;
• invoice and customer portal access metadata where available.

Dodo Payments processes payment details in the hosted checkout. We do not directly store full payment card numbers or payment card security codes in our application.

2.8 Email and Communication Data

We may process:

• recipient email address;
• sender email address;
• sender display label;
• email locale;
• email subject and body generated from templates;
• email verification links;
• order delivery links;
• card distribution links;
• Apple Wallet .pkpass email attachments;
• Resend message IDs;
• delivery status and error messages.

Card distribution events may store both the recipient email and a hash of the recipient email to support send-once checks, support, audit, and abuse prevention.

2.9 Location Data

If you use optional Apple Wallet lock-screen relevance, we may process:

• selected Google Place ID;
• place label and formatted address resolved at runtime;
• latitude and longitude returned by Google Place Details;
• device/browser coordinates if you choose "current location";
• reverse-geocoded address data;
• whether the location source is enabled or disabled;
• timestamps for location setting updates.

Location-based Apple Wallet lock-screen relevance is optional. You can choose not to use it. Browser/device location access can be refused or disabled in your device or browser settings.

2.10 Analytics, Advertising, and Conversion Measurement Data

Where analytics, advertising, or similar measurement technologies are enabled and the required consent has been given, we may process:

• consent status and consent categories, including analytics and advertising choices managed through Termly;
• Google Consent Mode status values, including ad_storage, ad_user_data, ad_personalization, and analytics_storage;
• Google Tag Manager container identifiers and tag-loading information;
• Google Ads conversion events and related event parameters;
• Google Ads click or attribution identifiers if present in the browser, URL, or tag environment, such as ad-click parameters;
• Google Ads audience, campaign optimization, remarketing, or personalized advertising data where such features are enabled or used by the Google Ads account or campaigns;
• Google Ads Performance Max audience signals or similar campaign optimization signals where enabled;
• Google Ads purchase conversion data, including transaction ID, order ID, checkout session ID, purchase value, currency, and card count;
• Google Ads add-to-cart conversion data, including item type, card variant, quantity, cart total item count, and currency where available;
• server-normalized SHA-256 hash of the buyer email for Google Ads enhanced conversions, only where enhanced conversions are enabled and advertising consent is present;
• Firebase Analytics event and device data where Firebase Analytics is enabled after analytics consent;
• DataFast visitor identifiers, including the datafast_visitor_id cookie where set;
• DataFast analytics and attribution data, such as page views, referrer, traffic source, UTM parameters, ad-click parameters where present, browser and device data, approximate country or location inferred from technical data, session activity, conversion or payment attribution data, and related identifiers;
• checkout-start or payment attribution metadata linking a DataFast visitor ID to a Dodo Payments checkout or payment where the DataFast/Dodo integration is enabled;
• cookie, local storage, or similar browser identifiers used by analytics or advertising tools.

Code review confirms that known analytics and advertising tools are gated through Termly consent categories. Google Tag Manager is loaded only after analytics or advertising consent is present. Google Ads conversion events are held until advertising consent is present. DataFast and Firebase Analytics are loaded only after analytics consent is present. Google Maps/Places is loaded only when optional place search is used, but it is not currently routed through Termly consent categories in code because it is an optional user-triggered feature. The deployed provider and dashboard configuration should be kept aligned with this policy, the Cookie Policy, and the live consent-banner settings before publication and after provider changes.

Google Ads enhanced-conversion data is not raw buyer email in the browser event. The backend normalizes the buyer email, hashes it with SHA-256, and returns only the hash for the advertising-consented conversion event. A hashed email may still be personal data under applicable law and must be reviewed as part of the legal basis, disclosure, transfer, and consent analysis.

2.11 Information Automatically Collected

When you visit, use, or navigate the Services, we may automatically collect:

• IP address;
• browser type and version;
• device and operating system information;
• language preference;
• referrer URL;
• pages viewed;
• timestamps;
• feature usage;
• error, diagnostic, security, and performance logs;
• approximate location inferred from IP address;
• cookie and local storage identifiers where applicable.

This information is used to operate, secure, debug, analyze, and improve the Services.

2.12 Sensitive Information

We do not intentionally request special categories of personal data such as racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data for identification, health data, or data concerning sex life or sexual orientation.

Because card text fields are customer-controlled, you must not enter sensitive personal information unless you have a valid legal basis and the information is necessary for the intended card use.

3. Card Data, vCards, and Third-Party Card Subjects

The Services are built around contact data. A card may describe the account holder, the buyer, an employee, a team member, a contractor, or another person.

If you create or manage a card for another person, you are responsible for ensuring that:

• the person knows their data is being used for a digital business card;
• you have permission, contractual authority, employment-related authority, or another lawful basis to provide their data to us;
• the data is accurate and up to date;
• the card can lawfully be distributed by email or QR code.

For direct vCard cards, contact data is encoded directly into the QR code. This is intentional so the card can work offline and import quickly. It also means that anyone who sees or receives the QR code may be able to read, copy, save, import, or forward the contact data.

We cannot technically recall contact data once a third party has scanned the QR code, imported the vCard, downloaded a wallet pass, taken a screenshot, or saved the data outside our systems.

4. Wallet Provider Data Sharing

4.1 Google Wallet

When Google Wallet output is enabled or required for a purchased card, we send Google the data needed to create, update, display, and save the Google Wallet card.

This may include personal information from the card profile, such as name, organization, job title, email address, phone number, website, QR payload, and logo image data. The exact fields sent depend on the selected card design, wallet layout, QR payload type, and current feature implementation.

Google Wallet card data may be processed by Google when:

• we create or update a Google Wallet generic object;
• we generate a Google Wallet save link;
• a user opens a Google Wallet save link;
• a user saves the card to Google Wallet;
• Google fetches a logo image URL used by the wallet object;
• Google caches, displays, synchronizes, or otherwise operates the wallet card.

Google may act as an independent controller for its own Wallet, account, security, platform, and diagnostic processing. You and card recipients should review Google's applicable terms and privacy documentation.

4.2 Apple Wallet

For Apple Wallet output, we generate an Apple Wallet .pkpass file containing card display data, QR payload data, pass metadata, and generated images.

When an Apple Wallet pass is installed, Apple Wallet may communicate with our Apple Wallet update service to register, update, or unregister the pass. This may involve Apple Wallet device identifiers and APNs push tokens used only for Wallet update notifications.

Apple may process wallet and device data under its own terms and privacy documentation when a user saves, stores, syncs, or interacts with an Apple Wallet pass.

4.3 Practical Consequences

Because wallet providers are necessary to provide the selected wallet outputs, we cannot provide Google Wallet output without sending required card data to Google, and we cannot provide Apple Wallet output without generating and delivering pass data compatible with Apple Wallet.

If you do not want card data to be processed by a wallet provider, you should not use or distribute the corresponding wallet output.

5. Payments, Orders, and Billing

We use Dodo Payments for hosted checkout, payment processing, and, where available, customer portal or invoice access.

When you start checkout, we create order and payment transaction records in our systems and send required checkout information to Dodo Payments. Dodo Payments may collect and process additional payment details directly in its hosted checkout. We receive payment status, checkout session data, payment references, customer references, and customer email data needed to fulfill and support the order.

Where analytics or advertising consent is present and the relevant integrations are enabled, checkout may also be used for revenue attribution and conversion measurement. For DataFast revenue attribution, we may pass a DataFast visitor ID from the browser cookie or checkout request header into Dodo Payments metadata. If the Dodo Payments/DataFast integration is configured, successful payment data may then be associated with that visitor ID for analytics and attribution. For Google Ads enhanced conversions, the checkout success flow may request a server-generated SHA-256 hash of the buyer email and include that hash in the Google Ads conversion event after advertising consent.

We process order and payment data to:

• create checkout sessions;
• confirm payments;
• prevent duplicate checkout attempts;
• fulfill paid orders;
• generate wallet cards;
• send order-ready emails;
• provide customer support;
• maintain billing, tax, accounting, and audit records;
• handle cancellations, refunds, disputes, chargebacks, and fraud prevention.

6. Account Registration and Google Sign-In

You can create an account using email/password authentication or Google sign-in where available.

If you use Google sign-in, Firebase/Google may provide us with account information such as:

• Google/Firebase user ID;
• email address;
• email verification status;
• display name;
• profile information made available through the sign-in flow.

We use this information to create and manage your account, authenticate you, verify email status, and provide the authenticated platform.

We do not currently offer Facebook, X, or other social login providers unless they are expressly shown in the user interface.

7. Cookies, Analytics, Local Storage, and Similar Technologies

We may use cookies, local storage, SDKs, scripts, pixels, and similar technologies to operate, secure, measure, and improve the Services.

These technologies may be used for:

• authentication and session handling;
• remembering legal or consent preferences;
• storing anonymous draft, cart, and template references;
• protecting checkout and claim flows;
• preserving user preferences;
• analytics and performance measurement;
• advertising conversion measurement and attribution;
• revenue attribution for checkout and payment flows;
• fraud prevention and security;
• loading embedded legal-policy and consent tools;
• loading Google Maps/Places scripts when optional location search is used.

The Services currently use or may use:

• Firebase Authentication and Firebase SDKs;
• Firebase Analytics where enabled;
• Google Tag Manager where analytics or advertising tags are enabled;
• Google Ads conversion tracking, Google tag, and Conversion Linker where advertising measurement is enabled;
• Google Consent Mode to communicate consent choices to Google tags;
• DataFast website analytics and revenue attribution where enabled;
• Termly legal embeds and consent-preference functionality;
• browser local storage for anonymous draft/cart/template references;
• Google Maps JavaScript Places library for optional place search;
• Dodo Payments hosted checkout;
• Google Wallet save links;
• Apple Wallet pass delivery flows.

Some technologies are necessary to provide the Services. Others may require consent depending on applicable law and configuration. Specific information about cookies, local storage, analytics, consent preferences, and how to refuse or withdraw consent is provided in the Cookie Policy.

7.1 Consent Management

We use Termly to provide cookie-policy embeds and consent-preference functionality. Termly consent categories are used by the application to control known analytics and advertising tools.

Code review confirms the current implementation is designed as follows:

• Termly AutoBlocker is off, and known analytics and advertising tags are loaded manually after Termly consent synchronization;
• Firebase Analytics and DataFast require analytics consent before they are loaded or initialized;
• Google Tag Manager loads only when analytics consent or advertising consent is present;
• Google Ads conversion events require advertising consent;
• Google Ads enhanced-conversion user data requires advertising consent;
• Google Maps/Places is loaded only when the optional place-search functionality is used and the browser-side Google Maps API key is configured;
• Google Maps/Places is intentionally event-triggered for optional place search and is not currently routed through the Termly analytics or advertising consent categories in code.

If you withdraw or refuse consent, we will use the available technical controls to prevent further non-essential analytics or advertising processing through those tools from the current browser session. Some provider-side records from earlier consented processing may remain according to the provider settings, contractual terms, and applicable law.

7.2 Google Tag Manager and Google Consent Mode

We use Google Tag Manager as a tag management system. Google Tag Manager allows us to load and manage analytics, advertising, and measurement tags through a container instead of hard-coding each tag directly into the website.

Code review confirms that the application loads a Google Tag Manager container for the English service:

• GTM-MR548T6F for the English DigiCard Pro site.

According to the current Google Tag Manager account information provided for this draft, the English container currently contains four tags:

• a general Google tag;
• a Conversion Linker tag that fires on all pages;
• a Google Ads purchase conversion tag for the digivi_purchase event;
• a Google Ads add-to-cart conversion tag for the digivi_add_to_cart event.

Google Consent Mode is configured with default denied values for:

• ad_storage;
• ad_user_data;
• ad_personalization;
• analytics_storage.

Code review confirms that when the Termly consent state changes, the application updates Google Consent Mode so that advertising consent controls ad_storage, ad_user_data, and ad_personalization, and analytics consent controls analytics_storage. The current implementation also sets Google Ads data redaction to true by default.

The exact tags inside each Google Tag Manager container must match the published Cookie Policy and this Privacy Policy. This draft is written to cover the current general Google tag, Conversion Linker, purchase conversion tag, and add-to-cart conversion tag setup, as well as Google Ads audience-based campaign features described below.

7.3 Google Ads Conversion Tracking and Enhanced Conversions

Where enabled, we use Google Ads conversion tracking to measure whether Google Ads or other advertising campaigns lead to relevant actions in the Services. The current code and account information provided for this draft support:

• a purchase conversion event named digivi_purchase;
• a secondary add-to-cart observation event named digivi_add_to_cart;
• Google Ads enhanced conversions for purchases where advertising consent is present and enhanced conversions are enabled;
• a Conversion Linker tag that fires on all pages;
• a general Google tag in Google Tag Manager.

The currently identified Google Ads conversion events are the purchase event and the add-to-cart event. Purchase is intended to be the primary revenue conversion, while add-to-cart is intended as a secondary observation conversion.

The purchase conversion event is created after our backend confirms a completed checkout. The event may include:

• transaction ID and order ID;
• checkout session ID;
• decimal purchase value;
• currency;
• number of purchased cards;
• ecommerce transaction metadata used by Google Ads or Google Tag Manager;
• a SHA-256 hash of the buyer email for enhanced conversions, where available and where advertising consent is present.

The add-to-cart event may include:

• item type;
• card variant;
• quantity;
• total number of items in the cart;
• currency where available.

These conversion events are intended for advertising measurement, reporting, attribution, and campaign optimization. For enhanced conversions, Google may use hashed first-party customer data, such as a hashed email address, to match a conversion to Google accounts that interacted with ads. We do not include raw payment card details in Google Ads conversion events. The current implementation also does not include card profile content, QR payload data, or wallet pass content in the Google Ads conversion event payload.

According to the current Google Ads account information provided for this draft, enhanced conversions are enabled for the purchase conversion, and the only user-provided enhanced-conversion field intentionally mapped is the SHA-256-hashed email address. No other user-provided data, such as name, phone number, postal address, or un-hashed email address, is intentionally provided for enhanced conversions.

Google Ads may also be used for campaign optimization and audience-based advertising features, including audiences and Performance Max audience signals. This draft is written broadly to cover Google Ads audience, remarketing, personalized advertising, campaign optimization, and similar advertising features where they are enabled by the Google Ads account, Google Tag Manager setup, or campaign configuration. If such features are disabled or materially limited in the final Google Ads account, the lawyer may simplify this wording.

7.4 Firebase Analytics

Firebase Analytics may be used for app and website analytics where enabled. The current implementation initializes Firebase Analytics only after analytics consent has been granted and mirrors the analytics consent state into Firebase's analytics consent controls.

Firebase Analytics may process technical and usage information such as device and browser information, app or page interactions, approximate location inferred from technical data, and related analytics identifiers, depending on the final Firebase configuration.

7.5 DataFast Analytics and Revenue Attribution

Where enabled, we use DataFast for website analytics and revenue attribution. Code review confirms that DataFast is loaded only after analytics consent is present. The browser script configuration uses the hosted DataFast script https://datafa.st/js/script.js and the following website ID for the English service:

• dfid_w4nFVfdq9vhtHS79zDQa0 for digicard.pro.

The current code uses DataFast's default hosted script with cookies. No custom DataFast account or tracking settings have been configured by us beyond the application-side script attributes described here. The script sets data-disable-payments="true" and data-disable-console="true". Code review did not identify use of DataFast's cookieless script.

DataFast may set or use a datafast_visitor_id cookie or similar visitor identifier. The visitor ID may be used to connect page activity, traffic source, UTM parameters, referrer data, ad-click parameters where present, and checkout or payment events for revenue attribution.

According to DataFast's documentation for the default script with cookies, DataFast may collect visitor information such as IP address, browser type, device information, user agent, country, unique identifiers, cookies, and page activity. DataFast's API documentation also describes visitor records that may include identity and journey information such as location, browser, operating system, device, viewport, URL parameters, ad click IDs, visit counts, page views, first and last visit timestamps, completed goals, payment events, and conversion prediction where available.

DataFast's DPA states that the customer is the controller and DataFast acts as a processor for analytics processing. The same DPA states that DataFast processes data to provide analytics, reporting, and related features, and that it does not use customer data for its own marketing or profiling and does not sell or share customer data to third parties. The DPA lists DataFast's current subprocessors as AWS, Vercel, Mapbox, OpenAI, MongoDB, Upstash, TinyBird, and ClickHouse. It also states that most of DataFast's infrastructure is located outside the EU, including in the United States, and that DataFast relies on subprocessor compliance with applicable laws, including GDPR Standard Contractual Clauses where relevant.

For checkout attribution, the current implementation may send the datafast_visitor_id from the browser to our backend in a checkout request header and then store it in Dodo Payments checkout metadata as datafast_visitor_id. If the Dodo Payments/DataFast integration is configured, successful payment data may be sent to DataFast so that revenue can be attributed to traffic sources. The browser script is configured to disable DataFast's automatic payment tracking, so payment attribution is expected to happen through the explicit checkout/payment integration rather than automatic URL-parameter payment detection.

According to DataFast's and Dodo Payments' integration documentation, the DataFast/Dodo Payments revenue-attribution flow works by capturing the datafast_visitor_id cookie, storing that visitor ID in Dodo Payments checkout metadata, and sending successful payment data to DataFast through DataFast's Payment API or the Dodo Payments DataFast integration. The documented payment payload may include amount, currency, transaction ID, and datafast_visitor_id. Dodo Payments' integration documentation explains that the DataFast API key is configured in the Dodo Payments webhook integration and should not be exposed in client-side code.

The DataFast provider documentation does not state one fixed long-term visitor data retention period for all paying customers. Its DPA says customer account data is kept until account deletion, visitor data for long-term customers is retained longer to provide historical analytics, and deletion can be requested at any time. DataFast's public privacy policy states that trial analytics and collected non-personal data are deleted a few days after the trial period ends if the customer does not subscribe.

The DataFast provider documentation distinguishes the default script with cookies from a separate cookieless script. We currently use the default script with cookies, not the cookieless script. DataFast states that the default script uses cookies for visitor identification and provides higher attribution accuracy, while the cookieless script avoids cookies for assigning a stable browser visitor ID but has lower long-range attribution accuracy.

7.6 Current Termly Cookie Scan and Cookie Policy Maintenance

The current Termly cookie report for the English DigiCard Pro service should be maintained in Termly for the deployed English domain. The cookie report should list the cookies and browser storage entries actually observed on the English site, including any entries set by Termly, Google Tag Manager, Google Ads, DataFast, Firebase, embedded media providers, Google Maps/Places, Dodo Payments, Google Wallet save flows, Apple Wallet delivery flows, and local storage used by the application.

Because Google Tag Manager and Google Ads behavior depends on deployed container and Google Ads dashboard configuration, the cookie report should be checked again after finalizing the GTM and Google Ads setup.

Cookie Policy:

• https://www.digicard.pro/en/legal/cookies

Cookie Policy maintenance note:

The cookie table should stay aligned with the deployed Termly consent categories, GTM container contents, provider cookies, and local storage keys. Code review confirms application-side use of Termly, Firebase Analytics, Google Tag Manager, Google Ads dataLayer events, Google Consent Mode, DataFast, Google Maps/Places, Dodo Payments checkout, Google Wallet save links, Apple Wallet delivery flows, anonymous draft/cart/template local storage, datafast_ignore, and datafast_visitor_id forwarding. Provider-set cookie names, durations, and classifications should be maintained in Termly and the relevant provider dashboards whenever the deployment or provider setup changes.

8. Location Data

We do not require precise location data for the core card generator or standard wallet delivery.

Location data is used only for optional Apple Wallet lock-screen relevance features. If you choose to use the feature, you may either search for a place through Google Places or allow the browser/device to provide current coordinates.

If you use Google Places search, search queries and selected place information may be processed by Google. We persist the Google Place ID needed to resolve the selected place later. Display labels and addresses may be resolved at runtime.

If you use current device location, your browser or device may ask for permission. We may store the selected latitude and longitude for the card or group so Apple Wallet can use the location for relevance. You can refuse location permission or disable location access in your browser or device.

9. How We Use Personal Information

We process personal information to:

• provide the public card generator;
• create, save, restore, and manage card drafts;
• generate QR codes;
• generate Apple Wallet passes;
• create and update Google Wallet objects;
• deliver wallet passes and save links;
• create and manage accounts;
• verify email addresses;
• provide Google sign-in where selected;
• manage groups, templates, locked fields, and bulk imports;
• process checkout, payments, invoices, refunds, and customer portal access;
• fulfill orders and card credits;
• send transactional emails;
• send marketing emails where you opt in;
• provide customer support;
• prevent abuse, fraud, duplicate sends, and unauthorized access;
• secure and debug the Services;
• maintain logs, diagnostics, and audit trails;
• manage cookie and consent preferences;
• measure website and feature usage where analytics consent is present;
• attribute purchases and cart actions to traffic sources where analytics or advertising consent is present;
• measure Google Ads conversions and enhanced conversions where advertising consent is present;
• comply with legal, tax, accounting, and regulatory obligations;
• enforce our Terms and defend legal claims;
• improve the Services and understand feature usage.

10. Legal Bases for Processing

Where the GDPR, UK GDPR, or similar laws apply, we rely on the following legal bases.

Performance of a Contract

We process personal information where necessary to provide the Services, including creating cards, generating wallet outputs, processing checkout, fulfilling orders, managing accounts, sending transactional emails, and providing support.

Consent

We rely on consent where required, including for marketing emails, certain cookies or analytics technologies, optional browser/device location permission, and other processing that legally requires consent.

This may include consent for:

• analytics cookies, scripts, SDKs, and similar identifiers, including Firebase Analytics and DataFast where enabled;
• advertising cookies, scripts, pixels, conversion tags, and similar identifiers, including Google Tag Manager, Google Ads conversion tracking, Google tag, Conversion Linker, and Google Ads enhanced conversions where enabled;
• Google Ads audience-based advertising, remarketing, personalized advertising, Performance Max audience signals, and similar campaign optimization features where enabled;
• sending hashed buyer email data to Google for enhanced-conversion matching where advertising consent is required;
• communicating consent status to Google tags through Google Consent Mode;
• optional browser/device location permission for current-location selection.

You may withdraw consent at any time. Withdrawal does not affect processing that occurred before withdrawal and does not affect processing based on other legal bases.

Legal Obligations

We process information where necessary to comply with legal obligations, including tax, accounting, invoicing, consumer-law, commercial-law, regulatory, and recordkeeping obligations.

Legitimate Interests

We process information where necessary for legitimate interests, provided those interests are not overridden by your rights and freedoms. These interests may include:

• securing the Services;
• preventing fraud and abuse;
• debugging and maintaining systems;
• maintaining necessary technical logs and operational diagnostics;
• enforcing legal terms;
• managing support and disputes;
• keeping audit trails;
• improving the product;
• preventing repeated card distribution sends;
• operating necessary business administration.

Vital Interests

We may process information where necessary to protect vital interests, such as where there is a potential threat to the safety of a person. This is expected to be rare.

11. When and With Whom We Share Personal Information

We may share personal information with service providers, processors, and other recipients where necessary to provide, secure, support, and improve the Services.

11.1 Main Recipients and Providers

Provider roles may differ by service, feature, and account configuration. Some providers may act as processors, independent controllers, or both for different processing activities. This should be confirmed against the applicable data processing agreements, product terms, and account settings, especially for Google Ads, Google Tag Manager, DataFast, Dodo Payments, wallet providers, and identity/authentication providers.

OpenAI is identified in code as an admin-only promo image generation provider. It is not used for ordinary card creation, wallet generation, checkout, or customer support workflows. If an administrator includes personal information in a prompt or reference image, that information may be processed by OpenAI for the image generation request.

11.2 Business Transfers

We may share or transfer information in connection with a merger, sale of company assets, financing, acquisition, restructuring, or similar transaction involving all or part of our business.

11.3 Affiliates

We may share information with affiliates or entities under common control where necessary for operating the Services, provided they honor this Privacy Policy or equivalent privacy obligations.

11.4 Public or Recipient Access Through the Product

The product itself may disclose personal information when you intentionally share a card, QR code, wallet pass, save link, direct URL, or distribution email.

Anyone who receives or scans a direct vCard QR code may be able to access the encoded contact data.

Anyone with a valid bearer delivery link may be able to access the related wallet delivery action until the link expires or is revoked.

12. International Transfers

We are located in Germany. Some providers and recipients may process personal information in Germany, the European Economic Area, the United States, Belgium, or other countries where our providers operate.

Where personal information is transferred outside the European Economic Area, the United Kingdom, or Switzerland, we rely on appropriate safeguards where required, such as adequacy decisions, standard contractual clauses, data processing agreements, provider transfer safeguards, or other lawful transfer mechanisms.

The following provider-specific summary is based on project code review, repository documentation, information provided for this draft, and public provider documentation reviewed on May 25, 2026. Provider subprocessor lists and transfer terms may change over time; the provider-maintained links listed at the top of this draft should be treated as the source of truth for the current contractual position.

12.1 Firebase and Google Cloud

We use Firebase and Google Cloud services for authentication, backend functions, database services, storage, logs, and related infrastructure. Firebase and Google Cloud services are provided by Google entities and may involve Google affiliates and third-party subprocessors.

Google publishes a Firebase subprocessor list and a broader Google Cloud subprocessor list. The Firebase list currently identifies Accenture, EPAM Systems, Fastly, and Firebase, Inc. for specific Firebase support, hosting, and service activities, and explains that Firebase features may also use relevant Google Cloud subprocessors. The Google Cloud subprocessor list is a large, provider-maintained list that identifies entities, activities, countries of processing, and relevant services.

For Firebase and Google Cloud processing, the current transfer position should be based on the applicable Firebase Data Processing and Security Terms, Google Cloud Data Processing Addendum, Google Cloud/Firebase subprocessor lists, and any Google Cloud account-region settings. Google documentation states that the Cloud Data Processing Addendum includes Standard Contractual Clauses for applicable EU, UK, and Swiss transfer requirements.

12.2 Google Tag Manager, Google Ads, and Google Consent Mode

We use Google Tag Manager, Google tags, Google Consent Mode, Google Ads conversion tracking, Conversion Linker, enhanced conversions, and, where enabled in the Google Ads account or campaigns, audience-based advertising, remarketing, personalized advertising, Performance Max audience signals, or similar campaign optimization features.

Google's published Ads service information identifies relevant personal data categories for services used in this draft, including online identifiers such as cookie identifiers, IP addresses, device identifiers, client identifiers, and, for enhanced conversions, customer data such as names, email addresses, phone numbers, addresses, client identifiers, and online identifiers depending on what the advertiser provides. For this project, the only user-provided enhanced conversion field intentionally mapped is the SHA-256-hashed buyer email address.

Google's EU User Consent Policy requires legally valid consent for cookies or local storage where legally required and for the collection, sharing, and use of personal data for ads personalization for users in the EEA, the United Kingdom, and Switzerland. The current implementation is designed to load and fire the known Google advertising and analytics tags only after the relevant Termly consent is present and to communicate consent status through Google Consent Mode.

Depending on the specific Google Ads service and configuration, Google may act as a processor, independent controller, or controller-controller recipient. Transfer and subprocessor safeguards should be evaluated under the applicable Google Ads Data Protection Terms, Google Controller-Controller Data Protection Terms, Google Ads service information, Google EU User Consent Policy, and account settings.

12.3 Google Maps, Places, Wallet, and Google APIs

Google Maps/Places is used only when a user actively uses the optional place search or location feature. Google Maps Platform terms require user-facing notice that the application includes Google Maps features and that Google Maps features are subject to Google's applicable terms and privacy policy.

Google Wallet is used when we create, update, display, or provide save links for Google Wallet cards. Google Wallet privacy and terms materials point users to the Google Privacy Policy, Google Terms of Service, Google Wallet User Policy, and, where payment features are involved, Google Payments terms. This service does not use Google Wallet as a payment method; it uses Google Wallet for digital card passes.

Where Google APIs and Google sign-in are used, our use and transfer of information received from Google APIs must follow the Google API Services User Data Policy, including Limited Use requirements where applicable.

12.4 Apple Wallet and Apple Push Notification Service

Apple Wallet and APNs are used to generate, install, update, and deliver Apple Wallet passes. Apple may process wallet, device, diagnostics, account, and APNs data under Apple's own terms and privacy documentation. Apple's developer terms cover APNs use for passes and require compliance with applicable laws and Apple program requirements.

For this draft, Apple is best described as an independent platform provider for Apple Wallet, device, iCloud, diagnostics, APNs, and related Apple services, not as an ordinary processor under our direct instructions for all Apple-side processing. We process our own Apple Wallet update-service data separately as described in the Apple Wallet sections of this policy.

12.5 DataFast

For DataFast, the public DataFast DPA identifies JustShipIt Pte. Ltd. trading as DataFast as the processor for the customer's analytics data. It lists AWS, Vercel, Mapbox, OpenAI, MongoDB, Upstash, TinyBird, and ClickHouse as current subprocessors and states that most DataFast infrastructure is located outside the EU, including in the United States, with reliance on subprocessor compliance and GDPR Standard Contractual Clauses where relevant.

The current project uses DataFast's default script with cookies, loaded after analytics consent, and forwards datafast_visitor_id to checkout metadata for revenue attribution where applicable. DataFast's public DPA states that it processes data only to provide analytics, reporting, and related features and does not use customer data for its own marketing or profiling.

12.6 Dodo Payments

For Dodo Payments, the public Dodo Payments DPA states that Dodo Payments acts as an independent controller when it acts as merchant of record for buyer-facing transaction processing, payment facilitation, fraud detection, risk analysis, sanctions screening, regulatory compliance, tax calculation and remittance, chargeback and dispute handling, and related legal-seller activities.

The Dodo Payments DPA also describes processor activities where Dodo Payments processes personal data on the supplier's documented instructions, for example merchant-specific analytics or transmission of data at the supplier's direction. It states that Dodo Payments may use subprocessors and group entities, will maintain an up-to-date subprocessor list available to suppliers on written request, and may transfer personal data outside the EEA and UK. The DPA describes transfer mechanisms including Standard Contractual Clauses, the EU-US Data Privacy Framework where applicable, or other valid transfer mechanisms under applicable data protection law.

The Dodo Payments DPA currently identifies AWS-hosted infrastructure and current third-party service providers including Amazon Web Services, Airwallex, Stripe, and Cashfree in its technical and organizational measures section. Dodo's privacy policy states that Dodo Payments transfers personal data within the Dodo Payments group and to third parties in connection with its stated purposes because of the international nature of its business.

12.7 Resend

We use Resend for transactional email delivery. Resend's public DPA states that Resend may engage authorized subprocessors, maintains the current list at https://resend.com/legal/subprocessors, gives advance notice of changes, and uses written subprocessor obligations. Resend's DPA also states that primary processing operations take place in the United States and that ex-EEA transfers are made under the applicable EU Standard Contractual Clauses modules where required.

Resend's current public subprocessor list includes, among others, Amazon Web Services, Anthropic, Cloudflare, Datadog, Elastic, Google, Inngest, Liveblocks, Metabase, Plain, Retool, RunPod, Salesforce/Slack, Snowflake, Stripe, Supabase, Svix, Tinybird, and Vercel.

12.8 Termly

We use Termly for policy embeds, cookie-policy information, consent management, consent preference storage, and cookie scanning. Termly's privacy center states that its DPA covers personal data processed by Termly on behalf of customers, including visitor and platform-user personal data, and that its DPA is incorporated into its Terms of Use by default for customers using Termly services.

Termly publishes a public subprocessor list. Its current list includes service providers for hosting, analytics, authentication, customer support, business operations, communications, payments, and related services. Termly's privacy center states that Termly may transfer personal data to third countries, including the United States, and that it relies on Standard Contractual Clauses where no adequate legal framework or adequacy decision applies.

Termly's support documentation states that new EU accounts automatically use the EU data center for visitor consent data by default, that existing customers can request migration to EU-only consent-data storage, and that the account-specific consent domain can be checked in the Termly dashboard. For this project, Termly consent data should be kept on the EU data center where the account supports that configuration.

12.9 OpenAI Admin Promo Image Generation

The repository contains an admin-only promotional image generation workflow that uses the OpenAI API. The browser sends admin prompts and optional admin-uploaded reference images to the admin API, the backend calls OpenAI, and the generated PNG is stored in Firebase Storage. Optional reference images are forwarded to OpenAI for the generation request and are not persisted by this application in Firebase Storage.

This OpenAI workflow is not part of ordinary user card creation, wallet generation, checkout, payment, transactional email, analytics, or customer support. If personal information is included in an admin prompt or reference image, OpenAI may process it for the API request. OpenAI's API data controls state that API data is not used to train OpenAI models unless the account opts in and describe default abuse-monitoring retention and available retention controls. OpenAI publishes a DPA and subprocessor list for API services.

12.10 Practical Transfer Review Position

Based on the current project review, the main international-transfer risk areas for lawyer review are Google advertising and enhanced conversions, DataFast analytics/revenue attribution, Dodo Payments as merchant of record and processor for directed integrations, Resend email delivery, Termly consent storage, Firebase/Google Cloud infrastructure, wallet-provider processing by Apple and Google, and the admin-only OpenAI promo image workflow.

The project should keep signed or accepted provider DPAs, account-level transfer settings, current subprocessor URLs, and consent/Cookie Policy settings on file. If provider dashboards later enable new analytics, advertising, AI, support, monitoring, chat, email-marketing, or payment integrations, this section and the Cookie Policy should be updated before publication or deployment.

13. How Long We Keep Personal Information

We keep personal information only as long as necessary for the purposes described in this Privacy Policy unless a longer retention period is required or permitted by law.

Current retention principles include:

• account profile data is generally kept while the account exists;
• user-owned cards, user-owned groups, and user-owned assets may be deleted during account closure, subject to legal and technical limits;
• company-owned cards and company business records may be preserved even when a user account is closed;
• billing, payment, order, invoice, tax, accounting, audit, and legal records may be retained as required or permitted by law;
• anonymous checkout success links and delivery-email success links are designed for short access windows, currently approximately 24 hours;
• checkout-attempt reservations are temporary, currently approximately 30 minutes;
• anonymous templates may be automatically deleted after a rolling inactivity period, currently approximately 90 days;
• terminal background workflow and job records are retained for checkout follow-up and support, currently approximately 40 days after terminal completion;
• Apple Wallet pass download links may be short-lived;
• generated Google Wallet image assets may be retained because Google Wallet may cache or refetch old image URLs asynchronously;
• wallet distribution tokens may remain active to support card delivery unless revoked, replaced, or no longer needed;
• logs, diagnostics, backups, and security records are retained for appropriate operational periods;
• consent records and consent-preference records may be retained as needed to demonstrate, honor, or audit consent choices;
• analytics and advertising identifiers, conversion records, attribution data, and enhanced-conversion records may be retained according to the settings and retention periods configured in Firebase, Google Ads, Google Tag Manager, DataFast, Dodo Payments, Termly, and related provider accounts;
• DataFast account data is retained by DataFast until the DataFast account is deleted according to its public DPA, and DataFast visitor data for long-term customers is retained longer to provide historical analytics unless deletion is requested or another provider retention rule applies;
• Dodo Payments may retain personal data where necessary to comply with legal or regulatory obligations, establish, exercise, or defend legal claims, or prevent fraud according to its public DPA;
• support correspondence may be retained as needed to handle support, disputes, and legal claims.

When we no longer have an ongoing need or legal basis to process personal information, we will delete, anonymize, or isolate it where appropriate. Backup copies may persist for a limited period until overwritten or deleted according to backup cycles.

The Termly default statement that no purpose requires keeping data longer than three months after account termination should not be used without lawyer review, because order, payment, tax, audit, company, and wallet records may need longer retention.

Provider retention maintenance note:

Code and repository documentation confirm app-owned retention windows for approximately 24-hour anonymous checkout success and delivery-email access links, 30-minute checkout-attempt reservations, 90-day rolling anonymous-template cleanup, and 40-day terminal background workflow/job cleanup. Public DataFast and Dodo Payments DPA wording has been incorporated above. External retention settings for Firebase Analytics, Google Ads conversion data, Google Tag Manager diagnostic data, Termly consent records, provider logs, server/runtime logs, and account-specific DataFast or Dodo Payments settings are provider-account settings and should be kept consistent with this retention section.

14. How We Protect Personal Information

We use appropriate technical and organizational measures designed to protect personal information, including access controls, provider security measures, token hashing for many anonymous access flows, private storage for original assets, signed URLs where appropriate, validation, authentication, and backend authorization checks.

However, no electronic transmission over the internet or storage technology can be guaranteed to be 100% secure. We cannot guarantee that unauthorized third parties will never defeat security measures or improperly collect, access, steal, or modify information.

You should access the Services only in a secure environment and protect account credentials, wallet delivery links, claim links, and anonymous access links.

15. Children

The Services are intended for users who are at least 18 years old. We do not knowingly collect data from or market to children under 18.

If we learn that personal information from a person under 18 has been collected without appropriate authorization, we will take reasonable steps to delete or deactivate the relevant data where required.

If you become aware of data we may have collected from a person under 18, please contact us.

16. Your Privacy Rights

Depending on where you are located and which laws apply, you may have the right to:

• request access to personal information;
• request a copy of personal information;
• request correction of inaccurate information;
• request deletion of information;
• request restriction of processing;
• object to processing;
• request data portability;
• withdraw consent where processing is based on consent;
• object to direct marketing;
• lodge a complaint with a supervisory authority;
• not be subject to decisions based solely on automated processing where such decisions have legal or similarly significant effects.

We do not currently use solely automated decision-making that produces legal or similarly significant effects.

We will consider and act on privacy requests in accordance with applicable data protection laws. We may need to verify your identity before responding.

You can also use the consent-preference tool where available to refuse or withdraw consent for non-essential analytics and advertising technologies. This does not necessarily delete records already created before withdrawal, but it is intended to prevent further consent-based processing through those technologies from the current browser going forward.

If you are located in the EEA and believe we are unlawfully processing your personal information, you have the right to complain to your local data protection authority. You may also contact the German supervisory authority responsible for palmstudio GmbH:

Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Rheinland-Pfalz

Hintere Bleiche 34

55116 Mainz

Germany

Website: https://www.datenschutz.rlp.de

If you are located in the UK or Switzerland, you may have the right to contact the UK Information Commissioner's Office or the Swiss Federal Data Protection and Information Commissioner.

17. Account Closure and Deletion

Registered users can request account closure through the available account deletion flow or by contacting us.

Current account closure may:

• delete the user account profile;
• delete the Firebase Auth account;
• delete user-owned cards;
• delete user-owned groups;
• delete user-owned assets and related storage objects where possible;
• delete or revoke app capability tokens and wallet distribution links for deleted user-owned cards;
• delete user-owned card credits;
• delete the authenticated shopping cart;
• cancel pending unpaid app checkout state;
• mark company memberships as left;
• unassign company-owned cards from the closing user;
• clear direct account references from preserved app records where possible.

Current account closure may preserve:

• company-owned cards and groups;
• company business data;
• billing records;
• payment records;
• order records;
• audit and legal records;
• system-owned generated assets;
• records required for tax, accounting, legal, fraud-prevention, or dispute purposes.

Account closure may be blocked if you are the last active owner of a company or if deletion would violate legal, operational, or security requirements.

Deleting an account does not necessarily remove wallet passes already saved to Apple Wallet or Google Wallet, contact data already imported by third parties, or data independently processed by wallet providers, payment providers, or other third parties.

18. Do-Not-Track Signals

Most web browsers and some mobile operating systems include a Do-Not-Track ("DNT") feature or setting. At this stage, no uniform technology standard for recognizing and implementing DNT signals has been finalized. We do not currently respond to DNT browser signals.

Some privacy laws distinguish legacy DNT signals from recognized opt-out preference signals, such as Global Privacy Control ("GPC"), that may communicate a user's choice to opt out of sale, sharing, or targeted advertising. Where applicable law requires us to honor a recognized opt-out preference signal, we will treat that signal as a request to opt out of sale, sharing, targeted advertising, or similar processing to the extent required by that law and supported by our consent-management setup.

Users can also manage analytics and advertising preferences through the cookie and consent preferences provided by Termly. If we materially expand advertising or tracking in jurisdictions that require recognized opt-out preference signals, we will configure the consent-management setup and update this Privacy Policy and Cookie Policy as needed.

19. Region-Specific Rights

We are established in Germany and operate the Services from Germany. This Privacy Policy and our privacy program are therefore primarily structured around the GDPR and related German and European data protection laws.

The Services may also be made available internationally, including to customers in the United States, and we may run advertising campaigns that reach users in the United States. International availability and US advertising do not change our German establishment or our GDPR-focused baseline. They also do not exclude mandatory local privacy laws where those laws apply to us.

Users in the United Kingdom or Switzerland may also have rights under the UK GDPR, the UK Data Protection Act, or Swiss data protection law.

19.1 United States Privacy Rights

If you are a resident of the United States, you may have additional rights under applicable US state privacy laws if those laws apply to us. Whether a specific US state privacy law applies may depend on factors such as your state of residence, whether our products or services are targeted to residents of that state, the number of residents whose personal information we process, revenue thresholds, and whether personal information is used for targeted advertising, sale, sharing, or certain profiling activities.

Depending on the applicable law, US privacy rights may include:

• the right to know whether we process personal information about you;
• the right to access categories or copies of personal information;
• the right to correct inaccurate personal information;
• the right to delete personal information;
• the right to obtain a portable copy of personal information;
• the right to opt out of sale, sharing, targeted advertising, or certain profiling activities;
• the right to limit the use or disclosure of sensitive personal information where that right applies;
• the right not to be discriminated against for exercising privacy rights;
• the right to appeal a denied privacy request where an appeal right applies.

We do not intentionally sell personal information for money. However, some US state privacy laws define "sale," "sharing," or "targeted advertising" broadly. Depending on the final provider configuration, advertising and attribution tools such as Google Ads, Google tags, Conversion Linker, audience-based advertising, Performance Max audience signals, remarketing, personalized advertising, DataFast attribution, or similar technologies may be treated as sale, sharing, or targeted advertising under certain US state privacy laws.

Where applicable US state privacy laws require it, you may opt out of sale, sharing, targeted advertising, or similar processing through the cookie and consent preferences provided on the Services, by using a recognized opt-out preference signal where supported and legally required, or by contacting us at the privacy contact listed in this policy.

We may need to verify your request before acting on it. We may deny or limit a request where permitted by law, for example where we need information for security, fraud prevention, payment processing, tax or accounting records, contract performance, legal claims, or other legally permitted purposes.

We do not currently include separate state-by-state notices for every US state. If our US activities meet state-specific notice, opt-out-link, appeal, sensitive-data, universal-opt-out, or other requirements, we will update this Privacy Policy, the Cookie Policy, and the consent-management setup as needed.

19.2 Other Regions

We do not currently include dedicated privacy sections for Australia, New Zealand, South Africa, or other non-European privacy laws because the Services do not currently materially target those regions as separate markets. If we later materially target those regions, establish local operations there, or become subject to region-specific privacy laws, we will update this Privacy Policy as needed.

20. Updates to This Policy

We may update this Privacy Policy from time to time. The updated version will be identified by an updated date at the top of the policy.

If we make material changes, we may notify users by posting a prominent notice, sending a direct notification, requiring renewed acknowledgement, or using another appropriate method depending on the nature of the change and applicable law.

We encourage you to review this Privacy Policy regularly.

21. Contact

If you have questions or comments about this Privacy Policy or our processing of personal information, you may contact us at:

palmstudio GmbH
Pfalzgrafenstraße 38
67434 Neustadt an der Weinstraße
Germany

Email: support@digicard.pro

Privacy contact:

Email: support@digicard.pro

We have not appointed a formal data protection officer because we currently do not understand ourselves to be legally required to appoint one. Privacy requests and privacy questions should be sent to the privacy contact above.

22. Review, Update, or Delete Your Data

Depending on applicable law, you may request access to the personal information we collect about you, request details about how we process it, correct inaccuracies, delete personal information, restrict processing, object to processing, request portability, or withdraw consent.

You may exercise rights by contacting us using the details above.

If you have an account, you may also be able to review or update certain account or card information from within the authenticated platform.

Some requests may be limited by legal obligations, fraud prevention, tax and accounting requirements, company-owned business records, payment records, audit records, security needs, wallet-provider limitations, or data that has already been distributed to third parties through QR codes, wallet passes, emails, or bearer links.