Ferry — Политика за съхранение на данни

В сила от: 3 август 2026 г. Собственик: „Прендит“ ЕООД (Prendit EOOD) · privacy@ferrycommerce.com

Принцип

Пазим лични данни само докато са необходими за целта, за която са събрани (създаване и проследяване на пратка и, при включване от търговеца, превенция на измами с наложен платеж), и за изпълнение на правни/счетоводни задължения. Данните се минимизират при събиране и се изтриват — или се свеждат до псевдонимизирана/агрегирана форма — щом престанат да са нужни. (Хеш с ключ е псевдонимизация, а не анонимизация: псевдонимните данни остават лични данни навсякъде в тази политика.)

График на съхранение

Категория данни	Срок на съхранение	Какво задейства изтриването
Лични данни по пратката (име на получател, адрес/офис, телефон, имейл)	90 дни след като пратката достигне краен статус (доставена/върната/отказана), броени от ПОСЛЕДНОТО ѝ запитване — при проследяван обратен курс към подателя това е физическото връщане при подателя (или 14-дневният срок за изоставен курс), не първият сигнал за връщане	Планиран purge процес
Етикети (PDF) (R2; може да съдържат име/адрес)	Като личните данни по пратката	Purge процесът изтрива R2 обекта
Съхранен адрес за доставка (`orders.delivery_address_json` — записва се при избор „до адрес“ в пикера след покупка, или за запазване на оригиналния Shopify адрес преди Ferry да го пренапише към офис/коригирана форма)	90 дни след `orders.created_at`	Purge-ът NULL-ва колоната; изтрива се и per-поръчка от `customers/redact`, и с целия ред от `shop/redact`
Вход/резултат от нормализация на адрес (`orders.address_norm_input_json` / `normalized_address_json` — адресът, както го е написал купувачът, и коригираната форма; преходното AI извикване е описано в Политиката за поверителност §2.1)	90 дни след `orders.created_at`	Същото purge правило като съхранения адрес; изтрива се от `customers/redact`; с реда — от `shop/redact`
Текст на куриерски отказ (`shipments.last_error` — дословното съобщение за грешка при неуспешна товарителница; може да цитира фрагменти от адреса, върнати от куриера)	До следващата успешна товарителница за поръчката; чисти се от 90-дневния purge, щом пратката достигне краен статус. Изоставена неуспешна пратка никога не достига краен статус; добавя се purge по възраст за тези редове — дотогава те се чистят при заявка за изтриване и при деинсталация	Чисти се при последващо успешно създаване; от purge-а (крайни пратки) и от `customers/redact`; с реда — от `shop/redact`
Метаданни за поръчка/пратка без преки идентификатори (номер на поръчка, сума НП, куриер, статус, номера на товарителница/проследяване)	Може да се пазят по-дълго за аналитика/съгласуване — псевдонимизирани (без име/адрес/телефон/имейл, но свързваеми с поръчка чрез идентификаторите ѝ)	Изтриват се изцяло от `shop/redact`
Акаунт на търговеца и куриерски креденшъли	За срока на инсталацията	При деинсталация / `shop/redact`
Рисков сигнал за купувача (`orders.risk_level`, `risk_report_count`, `risk_reasons_json`, `risk_provider`, `risk_checked_at`, `risk_hold_status`, `risk_reported_at` и разбивката по източници `risk_sources_json`) — псевдонимни лични данни, отнасящи се до купувача (свързани чрез поръчката; без преки идентификатори — телефонът/имейлът за проверката никога не се съхраняват)	90 дни от проверката (при частична проверка, оставила го празен — от създаването на поръчката)	Планов purge изчиства нивото, броя, причините, разбивката по източници, доставчика, часа на проверката и състоянието на задържането, и маркира поръчката, за да не бъде проверявана повторно. Отбелязването, че е публикуван сигнал, се запазва нарочно — то е защитата срещу втори публичен сигнал за същия купувач. Изтриват се и с реда на поръчката от `shop/redact`; изтриваеми при потвърдена директна заявка на купувача (§8 от Политиката за поверителност)
Ключ за историята на купувача (`orders.buyer_phone_hash`) — HMAC хеш на телефона на купувача под сървърния секрет на Ferry, записван при постъпване, за да може пер-търговският рисков източник да разпознае повтарящ се купувач без съхранение на телефон в чист вид; псевдонимизиран, необратим без секрета. Ключът на хеша е глобален (един сървърен секрет), затова един и същ телефон дава еднакъв digest в различни магазини — но всяка заявка по историята е строго ограничена до съответния магазин; единствените междутенантни четци са opt-in мрежовият сигнал по-долу и ограниченият по TTL кеш на присъди	90 дни след `orders.created_at`	Purge-ът NULL-ва колоната; изтрива се и от `customers/redact`, и с реда от `shop/redact`
Споделени събития за върнати пратки (`buyer_reputation_events`) — по един ред на върната пратка с НП: HMAC-SHA256 хеш на нормализирания телефон под сървърния секрет на Ferry (псевдонимизиран, необратим без секрета), референция към пратката, допринасящ магазин, маркер `kind='returned'` и времеви печат; без имена, адреси, имейли, суми или телефони в чист вид	365 дни, автоматично изтриване.	`customers/redact` изтрива всички редове за хеша на купувача във всички магазини, когато Shopify предостави телефона му в заявката (редовете съдържат само хеша, без телефона не могат да бъдат намерени и изтичат на 365-дневния лимит); `shop/redact` изтрива редовете на магазина; отписването на търговеца незабавно изтрива приноса му
Собствен API ключ на търговеца за рисковия доставчик (`risk_provider_credentials.api_key_enc`, шифрован в покой; при конфигуриране замества платформения nekorekten токен на Ferry за проверките на този магазин и винаги е акаунтът за публикуване на сигнали)	За срока на инсталацията	Изтрива се при деинсталация / `shop/redact`
Междутенантен кеш на рискови присъди (Cloudflare KV; ключ — HMAC хеш на телефона под сървърния секрет, стойност — производният публичен сигнал) — псевдонимизиран, необратим без секрета; ограничен по TTL (7 дни), изтриван best-effort при `customers/redact`	7 дни (TTL)	Изтича автоматично; best-effort изтриване при `customers/redact`, когато Shopify предостави телефона; не е ограничен до магазин, затова не участва в `shop/redact` и 90-дневния purge
Регистър на плащанията по наложен платеж (`cod_settlements` — референции към куриерски преводи/документи, номер на проследяване, суми бруто/такса/нето, валута, дата на превод) — паричният слой куриер→търговец; без лични данни на купувачи	За срока на инсталацията (финансово-съгласувателен запис)	Изтрива се изцяло от `shop/redact`; не се докосва от 90-дневния purge
Съпорт тикети (`support_tickets` + `support_ticket_messages` — текстове на търговеца, AI резюме, евентуални прикачени файлове в R2 под `tickets/{shopId}/`) — бизнес кореспонденция търговец↔Ferry; без систематични лични данни на купувачи, макар свободният текст на търговеца инцидентно да може да споменава детайли за поръчка/клиент	За срока на инсталацията (пазени като бизнес кореспонденция)	Изтриват се изцяло (D1 редове + R2 файлове) от `shop/redact`; не са в 90-дневния purge
Кратки линкове за избор на офис (`pick_short_links` — случайни per-поръчка идентификатори зад линка в напомнящия SMS; без лични данни)	30 дни	Дневно изтриване на изтеклите; изцяло — от `shop/redact`
Оперативни записи без лични данни на купувачи (`order_returns` огледало на връщанията, `pickup_claims` регистър на куриерските заявки, времеви печати за напомняния/архив/съгласуване върху `orders`)	За срока на инсталацията (оперативно счетоводство)	Изтриват се от `shop/redact`; не са в 90-дневния purge (не съдържат лични данни)
Оперативни логове в D1 (`webhook_log` dedupe ключове, `job_log` статусни редове — само идентификатори и статуси, без лични данни)	Оперативни записи; пазят се до рутинно почистване — добавя се изтриването им при `shop/redact`	Не са в PII purge-а
Одит лог на GDPR заявките (`gdpr_requests` — кои заявки за изтриване/данни са получени и обработени: идентификатор на магазин, клиент/поръчки, времеви печати; без име/адрес/телефон/имейл)	Пази се след изтриването като доказателство за съответствие (отчетност, чл. 5, пар. 2) — определя се максимален срок	Съзнателно преживява `shop/redact` (документира, че изтриването се е случило)
Записи за фактуриране/такси (`usage_charges` — регистър на таксите на товарителница: магазин, пратка, суми, Shopify идентификатори; конфигурационните редове като `shop_settings` / `shipping_mappings` не съдържат лични данни)	Финансово-счетоводни записи — пазят се по законовите счетоводни срокове; конфигурационните редове са оперативни	Не са в PII purge-а; финансовите записи може законно да преживеят `shop/redact`; добавя се изтриване на конфигурационните редове при `shop/redact`
Кеширана куриерска номенклатура (офиси/градове — не са лични данни)	TTL кеш (KV)	Изтичане на кеша
Оперативни логове (Cloudflare Workers логове/observability)	30 дни или по-малко (по подразбиране на платформата)	Автоматична ротация

Изтриване при заявка (задължителните Shopify webhooks)

Ferry изпълнява GDPR webhook-ите на Shopify:

customers/data_request — съставя за търговеца опис на това, което Ferry държи за този клиент (кои пратки имат съхранен етикет / данни от проследяване / адресен JSON, по направления). Тъй като Ferry почти не съхранява преки идентификатори, самите артефакти се свеждат до PDF етикети, данни от проследяване и адресния JSON, достъпни per-поръчка при поискване. Добавя се пакетиран експорт на тези артефакти, включително производните рискови полета.
customers/redact — изтрива личните данни на клиента (записите за пратки И В ДВЕТЕ направления — изходящо и връщане, PDF етикети, адресен JSON, телефонен хеш) в срока, изискван от Shopify (понастоящем 30 дни от получаване).
shop/redact — изпраща се от Shopify ~48 часа след деинсталация: изтриват се личните данни на магазина (пратки, креденшъли, токени, етикети, съпорт тикети), при документираните одитни/финансови изключения в графика по-горе.

Статус на изпълнение: плановият purge процес и трите webhook обработчика са имплементирани. Webhook-ите верифицират HMAC и нареждат работата на опашка; тя тече в консуматора. Purge-ът върви на честия (на всеки 5 минути) cron, ограничен на изпълнение, и чисти личните данни по пратката 90 дни след краен статус — часовникът е закотвен в последното запитване на пратката, не в момента на първото ѝ достигане до краен статус. За повечето пратки двете съвпадат. Единственият случай на разминаване: обратен курс към подателя става returned (краен) при ПЪРВИЯ сигнал за връщане, но Ferry продължава да пита на ~6 часа, докато пратката физически се върне при подателя — всяко от тези запитвания подновява часовника, така че 90-те дни започват от реалното връщане (или от 14-дневния праг за изоставен курс), никога от първия сигнал.

По силата на минимизацията Ferry не съхранява име/адрес/телефон/имейл на получателя в базата си от самата Shopify поръчка — те се четат на живо от Shopify само при създаване на товарителница и предаване на куриера (същото важи за напомнящите имейли/SMS: контактът на купувача се чете на живо при всяко изпращане и не се съхранява в базата на Ferry). Личните данни по пратката в покой са затова PDF етикетите (R2), данните от куриерското проследяване (tracking_events), съхраненият адрес за доставка (orders.delivery_address_json), входът/резултатът от нормализацията на адреса, текстът на куриерския отказ (shipments.last_error) и псевдонимизираният buyer_phone_hash. Purge и redact процедурите изтриват всичко това, оставяйки само псевдонимизирани метаданни за поръчката/пратката (без преки идентификатори; номерата на поръчка/проследяване остават свързваеми).

Обратните товарителници са покрити и в двете направления: една поръчка може да има изходяща и обратна пратка (при връщането купувачът е подателят), а purge, customers/redact и customers/data_request обхождат и двете — етикетът и проследяването на обратната товарителница се третират като лични данни на купувача точно както изходящите.

Проверка за риск (nekorekten): за поръчки с наложен платеж Ferry проверява телефона/имейла на купувача срещу nekorekten.com по подразбиране, чрез платформения си токен — проверяват се поръчки с неуредено плащане при постъпване (моделът НП); платени/възстановени/ анулирани никога не се проверяват (минимизация). Търговецът може да свърже собствен ключ, който замества платформения за неговия магазин. И в двата случая изпратеният телефон/имейл не се записва в базата на Ferry — съхранява се само производният сигнал (ниво, брой доклади, кодове на причини без лични данни, доставчик, времеви печат, статус на задържане) върху поръчката, плюс времевият печат risk_reported_at при публикуван сигнал (ръчно или — в бъдеще — чрез opt-in авто-доклада за непотърсени пратки — настройка, която понастоящем НЕ е активна). Публикуването (ръчно или автоматично) винаги ползва собствения акаунт на търговеца; Ferry никога не публикува през платформения си токен, и администратор на публичното твърдение е търговецът. Самият opt-in флаг е настройка на ниво магазин без лични данни. Ferry поддържа и краткотраен междутенантен кеш на присъди в KV, с ключ — HMAC хеш на телефона под сървърния секрет, ограничен до 7-дневен TTL — необратим без секрета, съдържащ само публичния сигнал; изтрива се best-effort при customers/redact (когато Shopify предостави телефона) и иначе изтича сам. Съхраненият сигнал върху поръчката е псевдонимни лични данни (свързани с купувача чрез поръчката), затова има свой определен максимален срок: 90 дни от проверката, изпълняван от същия планов purge, който чисти личните данни по пратката и съхранения адрес. Изчистената поръчка се маркира, за да не бъде проверявана повторно — иначе следваща промяна по нея просто би събрала отново току-що изтритото. Корекция или изтриване на изходно събитие се разпространява и към производните сигнали върху поръчки на други търговци: съответният ред отпада и съставната оценка се преизчислява от останалите източници (чл. 19). Рисковите колони допълнително се изтриват с целия ред от shop/redact и са изтриваеми при потвърдена директна заявка на купувача. Собственият ключ на търговеца (risk_provider_credentials.api_key_enc) е отделен, шифрован в покой секрет, изтриван при shop/redact заедно с куриерските креденшъли.

Мултиизточникова агрегация + история на купувача: горната проверка е един от няколко рискови източника, комбинирани в една обща присъда (важи най-лошото ниво); разбивката по източници се съхранява като risk_sources_json (производна, без лични данни). Успоредно с външния nekorekten източник Ferry извежда пер-търговски сигнал от историята върху собствените резултати от доставки на търговеца: ако същият купувач вече е имал върната пратка при този търговец, новата поръчка се флагва (никога автоматично задържане — този сигнал е ограничен до „флаг“). За разпознаване на повтарящ се купувач без телефон в чист вид всяка поръчка носи buyer_phone_hash — HMAC хеш под сървърния секрет, изчисляван при постъпване; псевдонимизиран (необратим без секрета). Ключът е един сървърен секрет, затова digest-ът е стабилен между магазини, но заявките по историята са строго ограничени до съответния магазин (сигналът ползва само собствените данни на търговеца и не е разкриване към подизпълнител). Единственото изключение е opt-in мрежовият регистър buyer_reputation_events: той внася псевдонимизирани събития за върнати пратки и разкрива на участващите търговци само производен брой от други Ferry магазини, както е в графика по-горе. buyer_phone_hash се третира като псевдонимизирани лични данни: чисти се при customers/redact, маха се с поръчката при shop/redact и — за разлика от производните рискови колони — е включен в 90-дневния purge.

Регистър на плащанията по НП: таблицата cod_settlements записва паричния слой куриер→търговец — референции към преводи/документи, номер на проследяване и суми бруто/такса/нето от куриерските отчети. Не носи лични данни на купувачи, затова се пази за срока на инсталацията като финансово-съгласувателен запис и не е в 90-дневния purge. Изтрива се изцяло, на ниво магазин, от shop/redact.

Касов бон: за да издаде куриерът касов бон при доставка с НП, Ferry изпраща описни данни за стоките (име на продукт, количество, единична цена) към куриера заедно с товарителницата. Те се четат на живо от Shopify поръчката в момента на създаване и не се съхраняват в базата на Ferry — единственият задържан артефакт е PDF етикетът (вече покрит от 90-дневния purge). Имената/цените на продукти са ниско чувствителни (не са лични данни) и потокът не добавя лични данни на купувача отвъд това, което създаването на товарителница вече изпраща.

AI нормализация на адреси: при отхвърлен от куриер адрес Ferry може да изпрати адресните полета (град/улица/номер/пощенски код/квартал/бележка — никога име, телефон или имейл) плюс съобщението за грешка към Anthropic API, за предложение на коригирана форма (вж. таблицата с подизпълнители в DPA). Преносът е per-заявка; в покой остава входът/резултатът върху поръчката (address_norm_input_json / normalized_address_json), покрити от 90-дневния purge и redact процедурите по графика.

Напомняния за избор на офис: напомнящият имейл (през Cloudflare Email) и opt-in SMS-ът (през SMSAPI) четат имейла/телефона на купувача на живо от поръчката при всяко изпращане; Ferry съхранява само броячи/времеви печати без лични данни и случайния кратък линк (pick_short_links, 30-дневно изтичане).

Съпорт тикети: съпорт чатът съхранява текстовете на търговеца, нишката от съобщения (търговец/AI/собственик), AI резюме и качените файлове (снимки/PDF, до 5MB) — D1 редове плюс R2 обекти под префикса tickets/{shopId}/ на магазина. Това е бизнес кореспонденция на търговеца, не систематични лични данни на купувачи — макар свободният текст инцидентно да може да споменава номер на поръчка или име на клиент. Понеже документира съпорт отношението за живота на инсталацията, е изключена от 90-дневния purge и се пази до деинсталация. shop/redact я изтрива изцяло: всеки ред тикет+съобщение и всеки R2 обект под префикса.

Връщания/откази: двете колони върху orders, задвижващи анулирането при отказана НП пратка — refused_observed_at и refused_cancelled_at — са само времеви печати, без лични данни. Като другите подобни (cod_paid_at / archived_at) не са в 90-дневния purge и се изтриват с реда на поръчката при shop/redact. Самото анулиране мутира само Shopify поръчката (не създава нови данни в покой).

Как става изтриването

D1: редове, ограничени по shop_id (и клиент/поръчка), се изтриват необратимо — при документираните изключения от графика (одитът gdpr_requests, финансовите записи и оперативните webhook_log/job_log редове до влизането на изтриването им).
R2: обектите с етикети се изтриват по ключ.
KV: записите за креденшъли/сесии/кеш се изтриват или изтичат.
Опашки (Queues): съобщенията в пайплайна (които преходно може да носят данни от поръчка, вкл. телефон/имейл на купувач) съществуват само до доставката си или, при недоставими — до изчерпване на dead-letter опашката — ограничено до дни; записът в D1 за dead-letter е статусен ред без лични данни.
Оперативните логове се ротират по сроковете от графика. Контактни данни на купувачи не се пишат в логове при нормална работа; един fallback при неконфигуриран доставчик засега логва контакта-дестинация на напомняне — премахването му предстои.
Резервните копия, управлявани от Cloudflare, изтичат по сроковете на платформата; не поддържаме отделни дълготрайни резервни копия с лични данни.

Преглед

Тази политика се преглежда поне веднъж годишно и при всяка промяна в обработката.