1. Who is responsible for your data
The eSIM Zone service is operated under the trading name "eSIM Zone by Dream Digital". That trading name is the only company identification that appears anywhere in our published materials.
The full legal identity of the data controller: registered company name and legal form, registered office address, company registration number (BCE/KBO if Belgian, SIREN/SIRET if French), and intra-community VAT number. None of these exist anywhere in the product or its configuration, so none are stated here.
Whether a Data Protection Officer has been appointed, and if so their name and contact address. No DPO is referenced anywhere in the product.
A single authoritative privacy contact address. The product currently references several conflicting support addresses across different components, on two different domains (esimzone.fr and esimzone.com). One must be designated as the address for data-protection requests.
Source in the product
- frontend/messages/en.json — Footer.copyright: "© {year} eSIM Zone by Dream Digital"
- Repository-wide search for SIREN / SIRET / TVA / VAT / BCE / RCS returns no company identifier
2. Account data we store
When you create an eSIM Zone account, the following fields are stored on your customer record:
- First name and last name.
- Email address (unique, and used as your login identifier).
- Phone number, where you provide one.
- Country.
- Interface language and preferred display currency, together with a flag recording whether you chose them yourself or we inferred them.
- Your password, stored only as a one-way hash — never in readable form.
- If you signed in with a social provider: the provider name, the identifier that provider gave us, your avatar URL, and the date your email was verified.
- Your referral code, referral tier, loyalty points balance, and the partner you were referred by, if any.
- Four notification preferences: order, usage, expiry and marketing.
Marketing is off unless you turn it on. The marketing notification flag is created with a default of false on both your account and each registered device; the other three are created enabled, because they concern an eSIM you have actually bought.
Source in the product
- app/Models/Customer.php:21-41 ($fillable), :48-60 ($casts), :67-71 ($hidden — password, remember_token, deleted_at)
- database/migrations/2025_08_20_102423_create_customers_table.php:17-26
- database/migrations/2026_08_15_090000_add_notification_baseline_to_customers.php:32-38 (notify_marketing default false)
- database/migrations/2026_08_31_000000_add_locale_and_currency_preferences_to_customers_table.php:56-76
- database/migrations/2026_04_12_100000_add_social_auth_to_customers.php:11-27
3. Payment data
We never store your card number. Card payments are processed by Paystack, and what we keep is a token Paystack issues plus the non-identifying descriptors needed to show you which card you saved:
- An authorisation code issued by Paystack, stored encrypted, and a gateway signature.
- Card brand, card type, the last four digits, the BIN, the expiry month and year, and the issuing country code.
- The date the card was last used.
- A consent record: the timestamp you agreed to save the card, plus the IP address and browser user-agent at that moment.
Saved cards are purged automatically. A scheduled job runs daily and deletes any saved payment method that has expired or has gone unused for thirteen months. This is the only data-retention period that is actually implemented in the service, so it is the only one stated as fact in this policy.
Source in the product
- database/migrations/2026_04_29_140000_create_customer_payment_methods_table.php:15, :28-57 (no PAN; consent_captured_at / consent_ip / consent_user_agent)
- app/Console/Commands/PurgeExpiredPaymentMethods.php:12, :30 (13-month RGPD retention)
- app/Console/Kernel.php:265 (scheduled daily)
4. Security and audit records
Sensitive account events are written to an audit log. Each entry records the event, the customer and object it concerns, the IP address, the browser user-agent, and a small structured metadata payload. These entries exist so that a disputed action — a saved card, a deletion request, a refund — can be evidenced after the fact.
The audit entry recording an account-deletion request deliberately keeps the IP address and user-agent unredacted, because that entry is the proof the deletion was genuinely requested.
Source in the product
- database/migrations/2026_04_29_141000_create_customer_audit_logs_table.php:14, :22-33
- app/Modules/Customer/Services/AccountDeletion.php:88-101
5. Devices and push notifications
If you register a device for push notifications, we store the platform, app version and build number, the device locale and timezone, and your four notification preferences for that device. The device identifier is stored only as a SHA-256 hash — never the raw value — and the push token is stored both as a hash (used for identity) and encrypted (used for delivery).
Web push subscriptions store the standard W3C WebPush triple: an endpoint URL and the two associated keys.
Whether outbound push delivery to Apple (APNs) and Google (Firebase Cloud Messaging) is live in production. Registration is implemented and active; the code describes actual dispatch to Apple and Google as gated behind a separate authorisation, so this policy cannot state that your token is transmitted to Apple or Google today, nor that it is not.
Source in the product
- database/migrations/2026_08_15_010000_create_push_devices_table.php:47-69 (device_id_hash "Never the raw value", token_hash, token_encrypted)
- database/migrations/2026_04_11_100000_create_push_subscriptions_table.php
- config/push.php:49-63 (fcm / apns configuration)
- app/Modules/Push/Controllers/PushDeviceController.php:24, :34-47
6. Mobile app diagnostics
The mobile app contains a deliberately narrow diagnostics layer. It can emit only six event types — application error, API failure, screen performance, checkout stage failure, install-help entry, and usage-unavailable — and each one carries only values drawn from a fixed, enumerated list. Free-form text is not accepted.
The layer additionally refuses any property whose name or value looks like personal or sensitive data. Blocked terms include email address, phone number, first name, last name, customer identifier, device identifier, location coordinates, ICCID, QR and LPA activation strings, tokens, credentials, supplier names, cost and margin, and the text of notifications or chat messages.
In production this diagnostics layer is configured with no network destination and no persistence. It does not transmit anything to us or to any third party. It exists so that the behaviour can be enabled deliberately rather than by accident.
Source in the product
- mobile/src/observability/telemetry.ts:1-8 (allowed events), :56-62 (allowed property shapes)
- mobile/src/observability/telemetry.ts:106-113 (prohibited key fragments and restricted value pattern), :149 (enforcement)
- mobile/src/observability/telemetry.ts:225, :246-247 ("Production remains deliberately no-network and no-persistence by default")
7. Support conversations and contact requests
Chat conversations with our assistant, and every message inside them, are stored against your account. This is free text you typed, so it may contain anything you chose to include — names, phone numbers, travel plans. It is deleted outright when you delete your account.
If you use the contact form, we store the name, email address, subject and message you submitted, together with the IP address the submission came from.
Source in the product
- app/Modules/Customer/Services/AccountDeletion.php:196-198, :203-211
- app/Http/Controllers/Api/ContactController.php (contact_submissions: name, email, subject, message, ip_address)
8. Who actually receives your data
This list is derived from the code that makes the outbound calls, not from a generic template. Each entry states what is genuinely transmitted.
- Paystack (payments). Receives your email address and your display name on every checkout, plus the amount, currency, transaction reference and the name of the package you are buying. Saved-card charges send the same.
- eSIM suppliers — Airalo, Telna and eSIM Go. In an ordinary purchase these receive a product identifier, a quantity and our internal order reference. They do not receive your name, and they do not receive your email address. The one exception is a refund request sent to Airalo, which transmits your email address because Airalo requires it to identify the order.
- BotMarketing (WhatsApp Business messaging). If you receive WhatsApp messages from us, this provider receives your phone number in international format and your first and last name, and it is the channel the eSIM delivery message travels through. Your phone number is the identifier used for the conversation.
- api.qrserver.com. When an eSIM is delivered over WhatsApp, the activation code is sent to this third-party image service in order to render the QR code picture.
- Sentry (error diagnostics). Active only when an error-reporting endpoint is configured. Where it is active, it is configured not to attach personal data by default, and session replay is disabled on both the frontend and the backend.
- Google Analytics. Active only when a measurement identifier is configured. Automatic page-view collection is switched off and page paths are sent explicitly; no user identifier is attached.
- Email delivery. Transactional email — including eSIM delivery — is sent to your address over SMTP.
- Our hosting provider, OVHcloud. The application, the database and the cache all run on a single OVHcloud virtual server.
The identity of the production transactional email provider. The repository contains only framework and local-development defaults for mail configuration, so the real provider cannot be named from source and must be taken from the production environment.
Whether CinetPay is still a live payment processor. Existing published copy in the product names CinetPay alongside Paystack, but the active payment gateway code is Paystack; CinetPay survives only as a reconciliation path. One of the two statements is out of date and must be corrected before publication.
The formal processor inventory and the Article 28 data-processing agreements for each recipient above. This section describes what the software transmits; it does not evidence that a contract exists with each recipient.
Source in the product
- app/Modules/Payment/Gateways/PaystackGateway.php:70-79 (email, customer_name)
- app/Services/Payment/PaystackProvider.php:77-107 (transaction/initialize), :264-280 (chargeAuthorization)
- app/Modules/Fulfillment/Services/FulfillmentService.php:271-276 (customer payload handed to the driver layer)
- app/Modules/Providers/Drivers/Airalo/AiraloProvider.php:538-542, :582-587 (order reference used, not email), :948-961 (refund sends email)
- app/Services/TelnaPurchaseService.php:260-264 (no PII in the purchase body)
- app/Modules/Providers/Drivers/EsimGo/EsimGoProvider.php:338-349 (SKU and ICCID only)
- app/Services/BotMarketingService.php:548-558 (phone, first_name, last_name), :597-599 (phone is the identity)
- app/Services/WhatsAppService.php:80 (activation code sent to api.qrserver.com)
- frontend/instrumentation-client.ts:17, :28-32 (sendDefaultPii false, replay disabled); frontend/instrumentation.ts:34, :53
- .env.example:157-161 (SENTRY_SEND_DEFAULT_PII=false)
- frontend/app/[locale]/layout.tsx:86, :90-93 (GA gated on NEXT_PUBLIC_GA_MEASUREMENT_ID, send_page_view false)
- frontend/components/AnalyticsPageView.tsx:16-19
- config/mail.php:16, :39; app/Modules/Fulfillment/Services/FulfillmentNotifier.php:238
- docs/RUNBOOK.md:11-16; deploy/deploy.sh:4 (OVH VPS)
10. Sessions and authentication
API access uses bearer tokens. A web session token is configured to expire after 24 hours. A token issued to a mobile device is configured to expire after 30 days. Signing out, and deleting your account, revoke every token immediately.
Source in the product
- config/sanctum.php:16, :36 (expiration 1440 minutes), :38 (mobile_expiration default 43200 minutes)
- app/Models/Customer.php:13 (HasApiTokens)
- app/Modules/Customer/Services/AccountDeletion.php:103
11. How long we keep things
One retention period is implemented and enforced: saved payment methods are deleted after thirteen months without use, or once expired.
Beyond that, transactional records — orders, payments, eSIM provisioning, wallet ledger entries, reconciliation and audit — are retained after an account is deleted, because an eSIM seller has accounting, tax, chargeback and supplier-reconciliation obligations that outlive the account. The service deliberately does not define how long, and no purge is scheduled for them.
The statutory retention period for transactional and accounting records, determined for the correct jurisdiction, and a corresponding purge or archival process. Existing published copy elsewhere in the product asserts a five-year period; that figure is not implemented anywhere in the service and is not repeated here as fact.
Source in the product
- app/Console/Commands/PurgeExpiredPaymentMethods.php:30 (the only enforced retention window)
- app/Modules/Customer/Services/AccountDeletion.php:20-26, :28-35 ("It does not invent a statutory retention period")
12. Deleting your account
Account deletion anonymises rather than erases. When you delete your account, it is made immediately unusable and the personal data on it is overwritten in place.
Overwritten or removed immediately:
- Your name is replaced with "Deleted Account" and your email address with a permanently unroutable placeholder.
- Phone number, country, language, currency preference, avatar, social login link, email verification date and referral code are cleared.
- Your password is replaced with a random unusable value and all notification preferences are switched off.
- Every session token is revoked, and every registered push device and web-push subscription is deleted.
- Every saved payment method is permanently deleted — including ones you had already removed — along with the encrypted authorisation code, the gateway signature, the card descriptors and the consent IP address.
- Your cart, any pending sign-in flows, and all support conversations and their messages are deleted.
- Your name is scrubbed from any review you left, and from any referral record naming you.
Deliberately retained:
- Orders, payments, eSIM provisioning records, wallet ledger entries and reconciliation data, for the accounting and dispute reasons described above.
- An audit entry recording that this deletion was requested, including the request IP address and browser user-agent.
- The partner link, loyalty points balance and referral tier attached to the account.
Deletion is available today in the mobile app, under your account, and requires you to confirm — by re-entering your password, or by typing DELETE if you signed in with a social provider.
Account deletion on the website is not functional. The confirmation control on the web account-settings screen is permanently disabled, so a customer who does not use the mobile app currently has no self-service way to exercise erasure. Either the web control must be completed, or this policy must publish a working alternative route (a named email address that is monitored and actioned) before it goes live.
Source in the product
- app/Modules/Customer/Services/AccountDeletion.php:20-53 (model and retained fields), :103-140, :144-184, :187-193, :203-216
- app/Modules/Customer/Services/AccountDeletion.php:57-58 (deleted.esimzone.invalid, RFC 2606)
- routes/api/customer.php:93 (DELETE /account, auth:sanctum)
- app/Modules/Customer/Controllers/AccountDeletionController.php:14, :27, :73-77, :85-104
- mobile/src/app/(tabs)/account.tsx:104; mobile/src/app/account/delete.tsx; mobile/src/account-deletion/gateway.ts:29-38
- frontend/app/[locale]/account/settings/page.tsx:419, :472 (confirm button hard-coded disabled)
13. Your rights
Where the GDPR applies to you, you have the right to access your data, to have inaccurate data corrected, to have your data erased, to restrict or object to processing, to data portability, and to withdraw consent at any time where processing is based on consent. You also have the right to complain to a supervisory authority.
The address to which data-subject requests should be sent, the response procedure, and the identity of the competent supervisory authority — which depends on the controller establishment that has not yet been determined in section 1.
A documented procedure for access and portability requests. Erasure is implemented in software; access and export are not, so a manual process must exist and be described before this section can promise them.
14. Legal bases for processing
What the software demonstrates is that marketing communication is treated as separate and opt-in: the marketing flag is created disabled on both accounts and devices, while order, usage and expiry notifications are created enabled because they concern an eSIM you bought.
The formal mapping of each processing purpose to its Article 6 legal basis — contract, legitimate interest, consent or legal obligation — together with a legitimate-interest assessment for anything relying on that basis. This is a legal determination, not something the code can settle.
Source in the product
- database/migrations/2026_08_15_090000_add_notification_baseline_to_customers.php:32-38
- database/migrations/2026_08_15_010000_create_push_devices_table.php:64-69 ("installing an app is not agreement to be marketed to")
15. Where your data is processed
The application, its database and its cache all run on a single virtual server provided by OVHcloud.
The OVHcloud datacentre region hosting the server, and therefore whether customer data rests inside the EU. The server hostname identifies the provider but not the region, so no claim about EU residency is made here.
The transfer mechanism — adequacy decision, Standard Contractual Clauses or otherwise — for each recipient in section 8 that processes data outside the EEA.
Source in the product
- docs/RUNBOOK.md:16 (OVH VPS); deploy/deploy.sh:4; docs/MARKETING_BRIEF.md:22
16. Children
A minimum age for holding an account, and whether any age verification applies. The product contains no age gate and no age field, so no minimum age is asserted here.
17. Effective date and changes
The effective date of this policy. It is deliberately left blank rather than backdated, and must be set on the day legal review is completed and the policy is published.