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

Prendit EOOD operates two products under the Ferry Commerce name. They share a shipping backbone and this policy, but they take in different personal data, from different places.

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.

Ferry Social is a separate application for sellers who take orders in chat — Facebook Messenger and Instagram direct messages. The seller connects their own Meta page; Ferry receives the messages exchanged in that page’s conversations, reads them with an AI model to draft an order (recipient, phone, destination, items, cash-on-delivery amount), and — once the seller confirms — creates a waybill with the same couriers. Ferry Social is not a Shopify application and processes no Shopify data. What it takes in is set out in §2.2, the AI reading in §2.3, and what Ferry itself sends into the chat in §2.4.

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

Meta platform integration. The Ferry Commerce application on Meta platforms (Facebook Messenger, Instagram) — the application behind Ferry Social — is registered under REYTEKS Ltd, a Bulgarian company under the same beneficial ownership as Prendit EOOD. Prendit EOOD operates the Ferry services and is responsible for the personal data processing described in this policy; REYTEKS Ltd holds the Meta developer registration on Prendit EOOD’s behalf.

2. What personal data we process

We practise data minimisation — we request and process only what is required to create a shipment. Because the two products take their data from different places, they are listed separately: the table below and §2.1 are Ferry (Shopify); §2.2 to §2.4 are Ferry Social.

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.

2.2 Ferry Social — data that comes from a chat

In Ferry Social the source is not an order form but a conversation, so the data is of a different kind: the content of messages written by the buyer and by the seller, and the buyer’s identity on the Meta platform. A data subject here is anyone who writes to the seller’s page — including someone who asks a question and never orders.

Ferry Social sends no SMS and stores no payment card data. As in §2, we do not request or intentionally process special-category data; a chat is free text, so incidental content follows the same retention and erasure rules as the conversation it arrived in.

Separately from buyer data, we process seller-account data: the e-mail address, the connected Meta page and its access token, encrypted courier credentials, the sender details the seller configures, web-push subscriptions and app settings. Prendit EOOD is the controller of this data (§1).

2.3 AI reading of conversations and images (Ferry Social)

Ferry Social reads conversations with an AI model provided by Anthropic, PBC. This is not an optional feature layered on the product — it is the product, and there is no per-seller setting that turns it off. What follows is what actually leaves Ferry.

What is sent. For each reading: the new messages verbatim, a window of the preceding messages verbatim, and the order state Ferry has collected so far — recipient name, phone, city, courier, weight, number of parcels, the items and prices, and the sentence each of those was read from. Photos from the chat and screenshots the seller shares are sent as image data for a single call.

What is not sent. The recipient’s e-mail address is excluded: the model may not write it and it is not part of the state the model is shown. It reaches only the courier, and only where the courier supports it.

What happens to the pictures. They are downloaded, sent for one call and discarded — no picture from a chat is written to Ferry’s storage. One exception: a share that arrives before the seller has signed in is held, picture included, in Cloudflare KV for 15 minutes so it survives the sign-in, and is deleted the moment the share resumes.

Calls go directly to Anthropic’s API. Under Anthropic’s commercial terms, API inputs are not used to train models.

The model never ships anything. It proposes an order; the seller confirms it, and only then is a waybill created.

2.4 What Ferry sends into the chat, and what it reads from before

Ferry writes to the buyer. When a shipment’s courier status changes, Ferry sends a message into the same Messenger/Instagram thread — that the parcel is on its way, that it has arrived, and its tracking number. Ferry sends it; the seller does not press anything. These are messages about the delivery the buyer asked for, never marketing. The first of them — the announcement that the waybill exists — is skipped where the seller has already sent it by hand; every later status is information the seller has not sent and goes out.

History import. When a conversation is new to Ferry, up to 200 messages exchanged before the seller connected the page may be read, so an order already half-agreed is not lost. This is a seller setting, on by default; a seller who turns it off gets only the messages that arrive from then on.

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 in Ferry (Shopify), off by default in Ferry Social) 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).

In Ferry Social, to the same end, two further purposes:

• Reading the conversation to draft the order — the AI extraction in §2.3, which is how a chat becomes a shipment at all;
• Telling the buyer where their parcel is — the status messages in §2.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 — and each Ferry Social seller — 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. In the Shopify app, screening targets cash-on-delivery orders with an outstanding payment: the order’s payment method must be recognised as cash on delivery AND the payment must still be outstanding at intake. An order already paid, refunded or voided — or one placed with another payment method, such as an unpaid bank transfer — is never checked. Separately, a merchant may enable an optional checkout gate that hides cash on delivery from buyers likely to refuse it: when enabled, the storefront widget screens the phone number the buyer has entered at checkout — before an order exists — against the same check, and only the resulting hide/show decision reaches the storefront, never the underlying risk level, report count or reason codes. A merchant may instead connect their own nekorekten API key, which then overrides Ferry’s platform account for that shop’s checks.

In Ferry Social the external check is off by default. The nekorekten source runs only for a seller who switches it on; until then nothing about a buyer is disclosed to the provider. What still runs are the seller’s own signals — whether that buyer already had a parcel returned at that seller, and the seller’s own list of blocked phone numbers — and neither leaves Ferry.

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 cash-on-delivery orders with an outstanding payment 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”). The dataset exists in both products on the same terms, off by default in each, and the master hold described below refuses every opt-in, contribution and read in both until the pre-launch items are complete.
• 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. The two Shopify triggers exist only in Ferry (Shopify); in Ferry Social the routes are the 365-day expiry, the seller’s opt-out, and a request to Ferry. 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 and §2.3 involves Anthropic, PBC (USA). Ferry Social additionally exchanges data with Meta, which operates its own platforms and its own transfer arrangements — the messages, the buyer’s profile and the seller’s page posts are already Meta’s before Ferry reads them. Where any transfer outside the EU/EEA occurs on Ferry’s side, 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, Shopify access tokens and Ferry Social’s Meta page 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. The two products delete on different triggers.

Ferry (Shopify). 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.

Ferry Social. There is no Shopify here, and none of those requests exist. Instead a scheduled job runs every five minutes and clears, at 90 days: the conversation transcript and everything read out of it, the buyer’s identity from Meta, and the buyer and order records. The clock differs per category — a conversation is measured from its last message, an order from the terminal state of its shipment — and each is set out in the Data Retention Policy. Separately, a seller can delete all of their own working data from the app at any time.

8. Data-subject rights

For personal data in a merchant’s orders or a Ferry Social seller’s conversations, end-customers can exercise their rights (access, rectification, erasure, restriction, objection, portability) with the merchant or seller as controller; they 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).

How a request is carried out. In Ferry (Shopify) an access or erasure request arrives as a Shopify webhook and the app executes it. Ferry Social has no such surface: there is no address in the application at which a buyer, or a seller acting for a buyer, can serve a request, and no automated route by which one is executed. A request sent to privacy@ferrycommerce.com is carried out by Prendit EOOD staff against the database, and the 90-day deletion in §7 runs on its own schedule regardless. A buyer-request route for Ferry Social is being built.

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