Ferry — Privacy Policy

Effective date: 3 August 2026 Data controller for this app: Prendit EOOD (Прендит ЕООД), 4a Boycho Ognyanov Str., 9300 Dobrich, Bulgaria, ЕИК 201597899 Contact: privacy@ferrycommerce.com

1. Who we are and what Ferry does

Ferry is a Shopify application that helps merchants ship orders with the courier networks operating in Bulgaria that Ferry supports — currently Speedy, Econt, BOX NOW, Sameday and Pigeon Express. Each merchant connects their own contract with the courier(s) they use. When a merchant uses Ferry, we generate a courier waybill (товарителница) — including cash-on-delivery (наложен платеж) — print shipping labels, let the buyer pick a courier office/automat or delivery address, sync shipment tracking back to the store, and — where the merchant approves a return — generate a return waybill (customer→merchant) for the same shipment data categories.

Except for the separate shared dataset described in §4.2, for personal data contained in a merchant’s orders, the merchant is the data controller and Ferry (Prendit EOOD) acts as a data processor on the merchant’s behalf, under the Data Processing Addendum. For data about the merchant’s own account and use of the app, Prendit EOOD is the controller.

2. What personal data we process

We practise data minimisation — we request and process only what is required to create a shipment:

Where the merchant enables Ferry’s storefront picker, the buyer may type their name, phone (and e-mail) and pick an office before checkout — those values are written by the buyer’s browser into the Shopify checkout (they reach Ferry as part of the Shopify order, same as above); the office pick itself is sent to Ferry.

We request only these fields under Shopify’s Protected Customer Data programme. We do not process payment card data, and we do not request or intentionally process special-category data — free-text fields (an address note, a support message or attachment) are not intended for such data, and any incidental content follows the same retention and erasure rules as the field it arrived in.

Separately from buyer data, we process merchant-account data: the shop domain and configuration, encrypted courier credentials and Shopify tokens, billing/usage records, and support correspondence (messages, attachments and PII-safe shop diagnostics). Prendit EOOD is the controller of this data (§1).

The office picker is also surfaced natively on Shopify’s post-checkout pages (the Thank-you and Order-status pages, via UI extensions). Those extensions record only the buyer’s chosen pickup office and read only Ferry’s own metafields plus a non-personal list of courier offices — they do not read the buyer’s name, address, phone or email on those pages — so they add no new personal-data category to the processing above.

2.1 Auxiliary processing that uses the same data

All of the following use only the data categories in the table above, for the same shipping purpose:

• Office-pick reminders. When an order awaits the buyer’s office choice, Ferry e-mails the buyer their office-selection link (the buyer’s e-mail/phone are read live from the order per send and are not persisted in Ferry’s database), on a limited schedule (up to 3 automatic reminders; the merchant can additionally trigger a resend manually). If the order has no e-mail and the merchant has enabled SMS reminders (off by default), the reminder is sent as an SMS to the buyer’s phone via the SMS provider in §4. These are transactional messages needed to complete the delivery the buyer requested — never marketing.
• Real-time checkout shipping rates. Where the merchant enables carrier-calculated rates, Shopify sends Ferry the checkout’s destination — the delivery address plus the buyer name and phone as Shopify provides them — which Ferry forwards to each connected courier able to quote a price, before any courier is chosen. The data is used transiently for the quote (a short-lived, ≤15-minute cached quote) and no waybill or order record is created at this stage.
• AI-assisted address normalization. If a courier rejects a delivery address, Ferry may send the address fields (city, street, number, postal code, quarter, free-text note — no name, phone or e-mail) together with the courier’s error message to the AI provider in §4 to propose a corrected form, which is auto-applied only if the courier then validates it. The input/result are stored on the order and follow the normal 90-day retention + erasure flows.

3. Why we process it (purpose & legal basis)

We process the data for these purposes and no others:

• Shipping (the core purpose) — creating outbound and return waybills, labels, office selection, tracking sync, office-pick reminders, checkout shipping-rate quoting and delivery-address normalization (§2, §2.1), carried out on the documented instructions of the merchant;
• COD fraud prevention — the risk checks in §4.1 (on by default) and, where the merchant opts in, the shared network signal in §4.2;
• Reflecting delivery outcomes on the order — marking a COD order paid when the courier remits the collected amount, and cancelling an order whose parcel the buyer refused (manually, or automatically where the merchant enables it);
• Merchant support — handling support requests the merchant sends from the app (see the Anthropic row in §4).

The legal basis is the performance of the contract between the merchant and Prendit EOOD, the merchant’s legitimate interest in fulfilling the order the customer placed, and — for the risk screening — the legitimate interest described in §4.1. Because a risk score can significantly influence the merchant’s decision, we treat the screening under the standards for automated decision-making (cf. CJEU C‑634/21 „SCHUFA“): a score never automatically refuses an order — at most it places the order on hold for the merchant’s manual review (§4.1), the decision to ship or refuse always remains with a human (the merchant), and buyers can contest a result directly with Ferry (§8). We do not use personal data for advertising or unrelated profiling, and we never sell personal data.

4. Who we share it with (sub-processors & recipients)

Each merchant brings their own courier contract(s); Ferry is an integration layer, not a courier reseller. Waybill data goes only to the courier the merchant selects for that order; the one exception is checkout-rate quoting (§2.1), which sends the checkout destination to each connected courier able to quote, before a courier is chosen. (Separately, the office-picker map view — in the merchant admin and on the buyer’s office-selection page — loads map tiles directly from OpenStreetMap: the viewer’s browser contacts OSM with ordinary request metadata such as its IP address; no order or identity data is sent to OSM.) Where a courier requires a recipient e-mail and the order carries none, Ferry supplies the merchant’s configured notification e-mail or, as a last resort, a Ferry-operated per-order alias address (parcel+<order>@ferrycommerce.com) so courier delivery notifications are not lost — messages received there are handled as shipment correspondence and are not used for any other purpose. The §4.2 returned-parcel dataset is shared among opted-in Ferry merchants through Ferry’s own infrastructure; it introduces no third-party recipient or sub-processor and is distinct from the nekorekten.com sub-processor engagement in §4.1.

4.1 Buyer risk screening (nekorekten.com)

For cash-on-delivery (наложен платеж) orders, Ferry sends the order’s buyer phone number and/or email to nekorekten.com (a community database of buyers who systematically refuse cash-on-delivery parcels) to check it against that database — on by default, using Ferry’s own platform nekorekten account. Screening targets orders whose payment is still outstanding at intake (the cash-on-delivery pattern); orders already paid, refunded or voided are never checked. A merchant may instead connect their own nekorekten API key, which then overrides Ferry’s platform account for that shop’s checks.

Roles. For the screening step itself — submitting the buyer’s phone/email, performing the check and attaching the result to the order — Ferry and the merchant act as joint controllers: Ferry selects the provider, enables the check by default and operates the integration and the cross-merchant cache, while the merchant’s use of Ferry for COD orders supplies the context and consumes the result. The merchant remains the sole controller of the subsequent order decision (ship, hold, refuse). The essence of this allocation is set out in the DPA §5. nekorekten.com is operated by CHECK AND PROTECT EOOD as an independent controller of its reporting platform — it is a recipient of the queried phone/email, not Ferry’s sub-processor.

Separately, a merchant may choose to publish a signal to nekorekten.com (report a buyer who failed to honour a COD delivery). Publishing always uses the merchant’s own nekorekten account — Ferry never publishes under its platform account, and the merchant, not Ferry, is the controller of that public claim.

A merchant may in future enable automatic publishing: an opt-in setting under which Ferry would publish such a signal automatically — but only for genuinely unclaimed parcels (the buyer never collected them), never for a parcel the buyer engaged with and refused (including after an inspection/test). It is disabled, and will remain disabled until, at minimum, all of the following exist: a reliable, auditable courier-data distinction between unclaimed, refused, cancelled and courier/merchant-caused returns; a documented legitimate-interest assessment; event-level evidence and audit logs; prior or prompt notice to the buyer; an effective correction, objection and challenge procedure; a defined retention period at the provider; a final role allocation covering Ferry, the merchant and CHECK AND PROTECT EOOD; and — preferably — human confirmation before each public report. When eventually enabled it would always use the merchant’s own nekorekten account (a shop with no connected own account never auto-publishes), and enabling it is the merchant’s standing authorization to publish on their behalf; Ferry stores only the derived signal and a timestamp of the publish (never the buyer’s phone/email).

• Purpose: cash-on-delivery (наложен платеж) fraud prevention — helping Ferry and the merchant decide whether to hold a shipment for manual review before it is dispatched.
• Legal basis: the legitimate interest (Art. 6(1)(f) GDPR) of the joint controllers in preventing COD losses, balanced against the buyer’s rights — checks are limited to outstanding-payment (COD-pattern) orders and only the minimum data (phone/email) is disclosed. The disclosure to the provider is processing in its own right.
• Retention: the phone/email sent to nekorekten.com for the check is not retained by Ferry (which does not remove the disclosure itself from this policy’s scope). We store the derived risk signal returned by the provider — a risk level, a report count, and short reason codes — attached to the order. That stored result is personal data relating to the buyer (pseudonymous — linked via the order, without direct identifiers); its retention is governed by the Data Retention Policy. Ferry also keeps a short-lived (7-day), hashed, cross-tenant cache of check results (a keyed hash is pseudonymisation, not anonymisation).
• nekorekten.com (CHECK AND PROTECT EOOD) acts as an independent controller of its reporting platform and a recipient of the queried phone/email; see the Data Processing Addendum §5 for the role allocation.

4.2 Shared returned-parcel signal (Ferry network, opt-in)

Separate from the §4.1 nekorekten.com check and the per-merchant buyer-history signal, Ferry operates an opt-in shared store of returned cash-on-delivery parcel events. The per-merchant signal remains per-tenant and is never shared across merchants; the separate network signal described here is the only exception, and merchants receive only its pseudonymized derived signal, not another merchant’s underlying events.

For each returned COD parcel included by the nightly sweep, buyer_reputation_events stores exactly: the shipment id; an HMAC-SHA256 hash of the buyer’s normalized phone, keyed with Ferry’s server-side secret (pseudonymized and not reversible without that secret); the contributing shop’s id; the marker kind='returned'; and a timestamp. It stores no names, addresses, emails, order amounts, or plaintext phone numbers. “Returned” is used deliberately: couriers provide no structured return reason, so Ferry does not characterize a parcel as “unclaimed” or claim buyer bad faith.

• Choice and reciprocity: participation is off by default for each merchant. The same opt-in both permits that merchant’s returned-COD events to be contributed and permits that merchant to read the network signal (“contribute and see”).
• What the merchant sees: only a derived count of the buyer’s returned COD parcels at other Ferry stores, rendered as a flag capped at medium severity. The network signal itself can never automatically hold an order; an automatic hold-for-review can result only from multiple external nekorekten reports (§4.1) or from a repeat-return threshold the merchant explicitly configures over their own shop’s delivery history. A held order is always released or refused by the merchant, never automatically.
• Purpose and legal basis: COD delivery-risk signalling (repeat returned parcels) — a „returned“ event does not by itself establish fraud or bad faith (returns can result from courier failure, wrong data, illness, cancellation or ordinary consumer behaviour), which is why the signal is deliberately labelled „returned“ and capped at a flag. Based on the legitimate interest (Art. 6(1)(f) GDPR) of Ferry and the participating merchants, with the merchant’s explicit opt-in as an additional safeguard (the opt-in is not the buyer’s consent — a documented legitimate-interest assessment is a pre-launch requirement, see below).
• Retention and deletion: events auto-purge after 365 days. Opting out immediately deletes the merchant’s contributed rows; shop/redact also deletes that shop’s rows. A buyer erasure request (customers/redact) removes that buyer’s entries across all shops when Shopify supplies the buyer’s phone in the redact payload. A buyer may also contact Ferry directly (privacy@ferrycommerce.com, §8): on a verified request Ferry locates the records by hashing the supplied phone number, corrects or deletes disputed events, restricts the signal while a dispute is investigated, and records objections — with corrections propagated to derived signals. The workflow is carried out by Ferry staff once the request has been verified; there is deliberately no self-serve surface, because one would let anyone restrict or erase any phone number they can type.

Roles (settled position): Ferry is the controller of this shared dataset — it determines the purpose, participation model, data fields, hashing method and secret, matching logic, severity cap, permitted recipients, retention and deletion. Contribution to and operation of the network signal happens under joint controllership of Ferry and each contributing merchant (a deliberate, reciprocal opt-in); Ferry is the principal controller for central storage, matching, security and retention; a receiving merchant is controller of its own use of the signal when handling an order. The essence of the Art. 26 arrangement is set out in the DPA §5. The network has not operated to date and will not open before a data-protection impact assessment, the finalized Art. 26 arrangement and the documented legitimate-interest assessment are in place; the fourth prerequisite, the direct-rights workflow described above, is implemented.

5. International transfers

Data is processed within Cloudflare’s infrastructure. The AI processing in §2.1 involves Anthropic, PBC (USA). Where any transfer outside the EU/EEA occurs, it is covered by an appropriate Art. 46 safeguard (e.g. EU Standard Contractual Clauses and/or an applicable adequacy framework such as the EU–US Data Privacy Framework).

6. How we protect it

• Encryption in transit (TLS) and at rest (Cloudflare-managed storage).
• Per-merchant courier credentials and Shopify access tokens are additionally encrypted at rest with authenticated encryption (AES-GCM) and decrypted only per operation.
• Separation of test/staging/production environments and data.
• Least-privilege access; access to systems is protected with strong authentication. Administrative access to merchant/support data is restricted to authorised Prendit EOOD personnel behind per-environment access tokens.
• Request logging and operational monitoring/alerting.

See the Incident Response Policy for how we handle breaches.

7. How long we keep it

We keep personal data only as long as needed to provide the service and meet legal obligations, per the Data Retention Policy. When a merchant uninstalls the app, Shopify issues the mandatory shop/redact request (typically about 48 hours after uninstall) and the shop’s personal data is deleted then; a customers/redact request deletes that customer’s personal data within the timeframe Shopify requires.

8. Data-subject rights

For personal data in a merchant’s orders, end-customers can exercise their rights (access, rectification, erasure, restriction, objection, portability) with the merchant as controller; the merchant can relay a request to us and we will action it. For the processing where Ferry acts as (joint) controller — the §4.1 risk-screening step and the §4.2 network signal — buyers may exercise their rights directly against Ferry at privacy@ferrycommerce.com, including disputing a risk result (the signal is restricted while a dispute is investigated). You have the right to lodge a complaint with the Bulgarian Commission for Personal Data Protection (КЗЛД) or your local supervisory authority.

9. Changes to this policy

We may update this policy; the effective date above reflects the latest version. Material changes will be communicated to merchants.

10. Contact

Prendit EOOD · 4a Boycho Ognyanov Str., 9300 Dobrich, Bulgaria · privacy@ferrycommerce.com · https://ferrycommerce.com