Proposed Merchant DPA

1. Status, subject matter and duration

This public document is a proposed, non-binding controller–processor framework under Article 28 GDPR. It is not an offer, acceptance mechanism or executed agreement, and it is not executed merely because it is available at /dpa. It does not invite incorporation or acceptance. Any future binding DPA would need a separately prepared and reviewed agreement. The intended subject matter is processing during a future merchant service and its controlled return or deletion process.

2. Nature, purposes and details of processing

Loyvero processes customer account and sign-in data, reward claims and redemptions, optional profile information, birthday day and month where enabled, marketing preferences, reward and campaign activity, and identifiers used for fraud prevention. The purposes are to authenticate customers, issue and display rewards, validate redemptions, send service messages, operate merchant administration, prevent abuse and provide configured wallet passes.

Data subjects are the merchant’s customers, prospective customers and authorised merchant users. The merchant determines the documented purpose, lawful basis, fields, retention setting, campaign rules and instructions. Loyvero does not use merchant customer data for cross-merchant advertising.

3. Documented instructions and confidentiality

Loyvero processes personal data only on documented instructions from the merchant, including the contract, order, configured settings and valid written instructions. Loyvero informs the merchant if an instruction appears to infringe GDPR, unless law prohibits that information. Persons authorised to process data are bound by confidentiality.

4. Technical and organisational measures

The verified measures include authenticated customer and merchant access flows, role-aware merchant administration, rate limiting for public support, pseudonymous network-derived identifiers for fraud prevention rather than a raw reward-account network identifier, and provider access needed for hosting, storage, authentication, email and wallet services. Measures are proportionate to the current implementation and may change as the service changes; no unverified certification, encryption detail or uptime promise is made.

5. Assistance and incidents

Taking account of the nature of processing, Loyvero will provide reasonable assistance with data-subject requests, correction, deletion, restriction, portability, security obligations, a personal-data breach, data-protection impact assessments and supervisory-authority consultation. The merchant remains responsible for deciding and responding to its customers. Loyvero will notify the merchant of a confirmed personal-data breach affecting its data without undue delay after becoming aware, subject to available facts and applicable law.

6. Subprocessors and changes

Schedule 3 identifies current provider categories for discussion in a future agreement; it does not constitute the merchant’s authorisation. A future DPA would need to set out advance notice of additions or replacements and a reasonable, specific objection process. No automatic acceptance or unverified transfer safeguard is promised.

7. International transfers

The current provider list and integrations are confirmed in Schedule 3. The applicable processing location and transfer mechanism are not confirmed for every provider and configuration. Schedule 4 therefore records “not confirmed” rather than claiming adequacy, Standard Contractual Clauses or another safeguard. Before a transfer is relied upon, the parties must verify the applicable provider terms, location and GDPR Chapter V mechanism.

8. Information and audit

Loyvero will make available information reasonably necessary to demonstrate compliance with the processor obligations and will support audits mandated by Article 28, subject to confidentiality, security, reasonable notice, scope and cost arrangements in the merchant contract. Public availability of this DPA is not evidence that a particular merchant has accepted it.

9. Return and deletion

At the end of the service, Loyvero will follow the merchant’s documented choice to return or delete personal data, unless Union or Member State law requires storage. The public implementation does not confirm a universal export format, export window, backup deletion schedule or reward honouring period; those details must be agreed and recorded. Retention configured by a merchant during service remains relevant to deletion criteria.

10. Merchant duties as controller

The merchant must establish a lawful basis, give an Article 13/14 notice, identify itself and its privacy contact before customer collection, honour rights, minimise fields, configure accurate retention and campaign settings, keep instructions lawful, secure its accounts, and ensure its staff and content are authorised. The merchant must not make marketing consent a condition of ordinary reward access.

Schedule 1 — Processing details

Subject matter: operating the merchant’s QR loyalty programme and its administration. Duration: the service term plus the documented return or deletion process. Categories of data: email, optional profile fields, birthday day and month, marketing preferences, reward/campaign/redemption records, pseudonymous fraud identifier, user-agent data where received, and merchant user account data. Categories of subjects: customers, prospective customers and merchant users. Operations: collection, authentication, storage, retrieval, display, reward issuance, validation, service email, security and deletion or return.

Schedule 2 — Security measures

Confirmed measures are access-controlled customer and merchant flows, role-aware administration, rate limiting, fraud-prevention identifiers, provider access controls and separation of merchant customer programmes. The current evidence does not verify a complete security-control catalogue, a certification, a fixed log-retention period or a particular encryption specification; none is promised here.

Schedule 3 — Current subprocessors

Supabase (database, authentication support and object storage); Resend (transactional email delivery); Replit (hosting/runtime and, when configured, connector proxy); Apple (Apple Wallet when enabled); Google (Google Wallet when enabled). A provider is used only for the relevant enabled feature. The merchant remains responsible for its controller notice.

Schedule 4 — Transfer mechanisms

No particular transfer mechanism is confirmed by this schedule. Provider processing locations, adequacy decisions, Standard Contractual Clauses and other Chapter V safeguards must be verified for the relevant deployment before reliance. Requests for currently available transfer information may be sent to hello@loyvero.com.