PrestaOne Data Processing Agreement (DPA)
This Data Processing Agreement ("DPA") is incorporated into the PrestaOne Terms of Service between MB "Elevio" (company code 306653242, VAT code LT100016572716, Šilutės pl. 35G-36, LT-94105 Klaipėda, Lithuania; "PrestaOne", the "Processor") and the Customer (the "Controller"). It applies whenever PrestaOne processes personal data on the Customer's behalf and reflects the requirements of Article 28(3) of Regulation (EU) 2016/679 ("GDPR").
Acceptance. This DPA is accepted by accepting the Terms of Service or by using the Service; no signature is required. A countersigned copy is available on request.
1. Scope and roles: what we do and do not process
1.1 Customer as controller. The Customer determines the purposes and means of processing personal data related to its Store, staff and buyers, and is the controller of that data.
1.2 PrestaOne as processor, Signaling Data only. PrestaOne processes on the Customer's behalf only the minimal metadata needed to operate pairing, access control, reliable push delivery and related security/audit functions ("Signaling Data"), described in Annex A. Object references and order amounts can be indirectly personal data where the Customer can link them to a buyer.
1.3 What PrestaOne does not process. The Service is architected so that the Customer's full business records (orders, products, customer records, direct buyer identifiers, message content and statistics) travel directly between the Customer's devices and the Customer's own server and never reaches PrestaOne's infrastructure. Push notification payloads deliberately contain no direct buyer identifiers (no names, no email addresses, no addresses, no message content), but may contain internal object references and order amount/currency as described in Annex A. Visitor analytics data collected by the Module is stored solely in the Customer's own database on the Customer's server; PrestaOne has no access to it and is not a processor of it (the Module is supplied as software; see the Module License Agreement).
1.4 Independent controller. PrestaOne is an independent controller, not a processor, for the Customer's account, device, diagnostics and billing data, as described in the Privacy Policy.
2. Processing on documented instructions
PrestaOne processes Signaling Data only to provide the Service as configured by the Customer through the app and portal (which constitute the Customer's documented instructions), and only as permitted by applicable law. PrestaOne will inform the Customer if, in its opinion, an instruction infringes the GDPR.
3. Confidentiality
Persons authorized to process Signaling Data are bound by confidentiality obligations and process it only as needed to operate the Service.
4. Security
PrestaOne implements the technical and organisational measures described in Annex B, appropriate to the risk of the processing (GDPR Art. 32). The measures reflect the data-minimising architecture: full buyer records and direct buyer identifiers are kept out of PrestaOne's infrastructure.
5. Sub-processors
5.1 General authorization. The Customer authorizes PrestaOne to engage the sub-processors listed in the Sub-processor List.
5.2 Changes. PrestaOne will update the list and, where practicable, notify Workspace owners by email at least 14 days before a new sub-processor starts processing Signaling Data. Where an urgent replacement is required for security, legal compliance or service continuity, PrestaOne may give notice as soon as reasonably possible. If the Customer objects on reasonable data-protection grounds and no resolution is found, the Customer may terminate the affected subscription with a pro-rated refund of prepaid unused fees.
5.3 Flow-down. PrestaOne imposes data-protection obligations on sub-processors that are materially equivalent to this DPA and remains liable for their performance.
6. International transfers
Primary processing takes place in the EU (Google Cloud region eur3, Belgium/Netherlands;
Sentry EU ingest, Germany). Where a sub-processor processes data outside the EEA (Expo,
Resend, United States), the transfer is protected by the EU–US Data Privacy Framework
certification of the sub-processor and/or Standard Contractual Clauses, as recorded per
vendor in the Sub-processor List. PrestaOne will not transfer Signaling Data outside the EEA
by other means without a valid transfer mechanism under GDPR Chapter V.
7. Assistance with data subject rights
Taking into account the nature of the processing, PrestaOne will assist the Customer with requests from data subjects (GDPR Arts. 15–22) insofar as they concern Signaling Data. In practice, self-service tools cover common cases: a successfully completed unpair removes the active connection and credentials, and account deletion can be started in the app after active subscription/connection dependencies have been resolved. Successful account deletion removes operational connection, device and push records; security/audit records may be pseudonymised or retained where legally necessary. PrestaOne forwards to the Customer any data subject request it receives that concerns the Customer's data.
8. Personal data breach
PrestaOne will notify the Customer without undue delay after becoming aware of a personal data breach affecting Signaling Data, providing information reasonably needed for the Customer's obligations under GDPR Arts. 33–34, and will cooperate in the investigation and remediation.
9. Data protection impact assessments
PrestaOne will provide reasonable assistance with data protection impact assessments and prior consultations (GDPR Arts. 35–36) relating to Signaling Data, to the extent the required information is not already available in this DPA, the Privacy Policy and Annexes.
10. Deletion and return
Upon termination of the Service, or earlier upon unpairing or account deletion, PrestaOne deletes Signaling Data per the retention windows in Annex A, unless EU or Lithuanian law requires longer storage. Given the nature of Signaling Data (operational metadata with no direct buyer identifiers), export-on-termination is available on request in a structured machine-readable format for connection and device records.
11. Audits
PrestaOne will make available information reasonably necessary to demonstrate compliance with this DPA: this DPA and its Annexes, the Sub-processor List, and available third-party certifications or reports of its infrastructure providers. Where this is insufficient, the Customer may conduct (itself or via an independent auditor bound by confidentiality) an audit of PrestaOne's compliance, no more than once per 12 months, on at least 30 days' notice, during business hours, without disrupting operations, and at the Customer's cost.
12. Liability and term
Liability under this DPA is subject to the limitations of the Terms of Service. This DPA applies for as long as PrestaOne processes Signaling Data and is governed by the law of the Republic of Lithuania.
Annex A: details of processing
| Item | Description |
|---|---|
| Subject matter | Operation of store pairing, access control and push notification signaling for the PrestaOne Service |
| Duration | The subscription term, plus the deletion windows below |
| Nature and purpose | Receiving event signals from the Customer's server; routing push notifications to paired devices; maintaining connection/permission records |
| Categories of data subjects | The Customer's staff and other persons the Customer authorizes to use seats (app users); indirectly, buyers only as numeric references |
| Categories of personal data | Authorized app users: account/user reference, random per-account device identifier, pseudonymous device stability key, device platform/model, push token, connection, permission and routing records. Event signals: internal store ID, event type, object reference numbers (order/customer/message thread IDs), order amount and currency. No buyer names, emails, addresses or message content. |
| Special categories | None |
| Retention / deletion | Active connection credentials are removed after successful unpair or account deletion; invalid push tokens are removed after provider invalidation; push retry/delivery outbox and recipient snapshots are kept up to 30 days, then scheduled for Firestore TTL deletion; security/audit events are retained as needed for integrity and may be pseudonymised on account deletion. Controller-side OTP and billing records are governed by the Privacy Policy, not this DPA. |
Annex B: technical and organisational measures (summary)
- Architecture-level minimisation: full buyer/business records and direct buyer identifiers are excluded from PrestaOne infrastructure by design; signaling is limited to internal references and, for orders, amount/currency.
- Authentication: passwordless one-time email codes (10-minute validity, hashed at rest, single-use, attempt-limited) and provider-signed Google/Apple credentials; an existing email-code identity must be verified before a new provider credential is linked; no password database exists.
- Authorization: granular per-connection permissions; deny-by-default database security rules (clients may read only their own records; server-only collections locked to backend); writes only through backend functions.
- Tokens: short-lived access tokens minted per connection, valid for at most 24 hours and automatically shortened so that a token never outlives the subscription entitlement behind it; shared secrets never reach the mobile app; secrets stored server-side and, on the Customer's server, encrypted (AES-256-GCM).
- Transport: TLS everywhere; the Module rejects non-HTTPS requests; server-to-server messages HMAC-SHA256-signed with replay protection (±300 s timestamp window).
- Device: credentials and cache encryption keys kept in secure device storage; a size-limited encrypted offline cache may hold business records fetched directly from the Customer's server and is purged on sign-out or Store removal.
- Abuse prevention: rate limiting on login, pairing and API; IP addresses used only as salted/hashed short-lived counters.
- Logging hygiene: one-time codes never logged; backend logs contain no tokens or codes; the Module writes only occasional failure entries to the Customer's own PHP error log, and those contain no credentials, buyer identifiers or message content.
- Diagnostics: crash reporting configured not to send default PII; reports may contain a stable pseudonymous Sentry user ID, country-level location, internal Store ID, device/app metadata and technical breadcrumbs, with EU ingest.
- Data residency: primary database and backend in Google Cloud EU (
eur3); functions ineurope-west1. - Deletion: successful self-service account deletion removes operational account, authentication, device, push and connection records after active dependencies are resolved; selected security/audit data is pseudonymised and legally required billing records may be retained. Automated TTL cleanup applies to authentication artifacts and push delivery records; module uninstall removes all module tables from the Customer's server.