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

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

Принцип

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

„Прендит“ ЕООД оперира два продукта (Политика за поверителност §1) и те изтриват по различни механизми, тъй че имат отделни графици: Ferry (Shopify) по-долу, Ferry Social в собствен раздел след него.

График на съхранение — Ferry (Shopify)

Категория данни	Срок на съхранение	Какво задейства изтриването
Лични данни по пратката (име на получател, адрес/офис, телефон, имейл)	90 дни след като пратката достигне краен статус (доставена/върната/отказана), броени от ПОСЛЕДНОТО ѝ запитване — при проследяван обратен курс към подателя това е физическото връщане при подателя (или 14-дневният срок за изоставен курс), не първият сигнал за връщане	Планиран purge процес
Етикети (PDF) (R2; може да съдържат име/адрес)	Като личните данни по пратката	Purge процесът изтрива R2 обекта
Архив с GDPR експорт (R2 `gdpr/<shop>/<request-id>.zip` — пакетираният отговор на `customers/data_request`: етикетите (PDF), събитията от проследяването, запазените адреси (JSON) и рисковия сигнал по заявените поръчки, тоест замразено копие на лични данни, вече описани в редовете по-горе)	7 дни от доставянето	Purge процесът изтрива R2 обекта и занулява указателя, с което линкът за изтегляне спира да работи; изтрива се и по-рано от `customers/redact` (всички живи архиви на магазина — в ZIP не може да се търси по един купувач) и от `shop/redact`
Съхранен адрес за доставка (`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, щом пратката достигне краен статус, а за изоставена неуспешна пратка, която никога не се минтва — 90 дни след създаването на пратката	Чисти се при последващо успешно създаване; от 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` статусни редове — само идентификатори и статуси, без лични данни)	Оперативни записи, per-магазин	Не са в 90-дневния PII purge; изтриват се изцяло per-магазин от `shop/redact`
Одит лог на GDPR заявките (`gdpr_requests` — кои заявки за изтриване/данни са получени и обработени: идентификатор на магазин, клиент/поръчки, времеви печати; без име/адрес/телефон/имейл; при заявка за данни — и SHA-256 отпечатък на имейла за контакт на търговеца, на който е изпратен линкът, но никога самия имейл)	Пази се след изтриването като доказателство за съответствие (отчетност, чл. 5, пар. 2) — определя се максимален срок	Съзнателно преживява `shop/redact` (документира, че изтриването се е случило)
Записи за фактуриране/такси (`usage_charges` — регистър на таксите на товарителница: магазин, пратка, суми, Shopify идентификатори)	Финансово-счетоводни записи — пазят се по законовите счетоводни срокове, съзнателно преживяват `shop/redact`	Не са в PII purge-а; не се изтриват от `shop/redact`
Конфигурационни редове на ниво магазин (`shop_settings`, `shipping_mappings` — настройки за доставка/тегло/риск и мапинги на native ставки; без лични данни)	За срока на инсталацията (оперативни)	Изтриват се изцяло per-магазин от `shop/redact`; не са в 90-дневния PII purge
Кеширана куриерска номенклатура (офиси/градове — не са лични данни)	TTL кеш (KV)	Изтичане на кеша
Оперативни логове (Cloudflare Workers логове/observability)	30 дни или по-малко (по подразбиране на платформата)	Автоматична ротация

Ferry Social държи данни от друг вид: съдържанието на чужди съобщения. Сроковете по-долу се изпълняват от планиран процес, който върви на същия петминутен cron като този на Shopify страната, ограничен на изпълнение, всяка категория независимо от останалите.

Един срок, няколко часовника. Всяка категория по-долу е 90 дни, но разговор и поръчка не остаряват по едно и също: разговорът се мери от последното си съобщение, а поръчката и купувачът ѝ — от терминалния статус на пратката (доставена / върната / анулирана). Двата часовника съществуват, защото изтриването на разговор не бива да отнася поръчката — екранът на поръчката трябва да продължи да се показва. Пратка, която никога не достигне терминален статус, спира да държи поръчката си 90 дни след собственото си създаване, тъй че неуспяла товарителница, която никой не е повторил, не задържа данните на получателя безсрочно.

Където ред не може да бъде изтрит (колона е NOT NULL или екран прави join към него), личните колони се изчистват и на тяхно място застава заместител — записът остава, човекът зад него не. Едно следствие е нарочно: купувач, който пише отново след деветдесет дни, отваря нов разговор, защото самоличността, която би го разпознала, вече я няма.

Категория данни	Срок на съхранение	Какво задейства изтриването
Транскрипт на разговора (`social_conversations.transcript_json` — всяко съобщение дословно, на купувача и на продавача), досието на поръчката и неотнесените бележки, прочетени от него, и идентификаторът на купувача в платформата за този разговор	90 дни след последната активност в разговора	Планиран purge: транскриптът се изпразва, досието и бележките се изчистват, идентификаторът в платформата се заменя със заместител
Дословните цитати, прикачени към това, което купувачът е поискал (`conversation_engagements.fields_json` — всеки артикул, размер, количество и цена носи изречението, от което е прочетен)	Изчистват се заедно с разговора си; цитат, чийто разговор вече не съществува — 90 дни след собствената си последна промяна	Планиран purge
Ескроу на граничния въпрос (`pending_order_boundary.payload_json` — име, телефон и адрес на получателя и дословната реплика на купувача, задържани, докато Ferry чака продавачът да каже дали това е нова поръчка)	Изтрива се заедно с разговора си; осиротял — 90 дни след като е бил вдигнат	Планиран purge изтрива реда (празен въпрос е по-лош от липсващ)
Самоличност на купувача от Meta (`people.display_name`, `people.avatar_url` — адресът на профилната снимка, не самата снимка — идентификаторът в платформата и телефонът по записа)	90 дни след последната активност на този човек	Планиран purge: името се заменя със заместител, останалото се изчиства. Редът се запазва, защото списъкът с поръчки на продавача прави join към него
Човекът над платформените профили (`initiators.display_name`, `initiators.notes` — свободната бележка на продавача за този купувач — и телефон)	Изчиства се, щом всичко под него е изчистено: нито един неизчистен платформен профил и нито една неизчистена поръчка	Планиран purge
Запис за купувача (`buyers.name`, `phone`, `address_json`, `notes`, `tags_json`)	90 дни след терминалния статус на пратката на този купувач (мерено от последното ѝ запитване); купувач без нито една пратка — 90 дни след последната промяна на самия запис	Планиран purge: името и телефонът се заменят със заместители (и двете са ключове), адресът, бележките и етикетите се изчистват
Чернова на поръчката (`order_drafts.input_json` — име, телефон, имейл, адрес, град, текст за офиса на получателя и дословната реплика на купувача — и `model_summary_json`, записът на това, което е било показано на модела)	90 дни по същия часовник на пратката	Планиран purge премахва изброените лични полета и резюмето за модела; търговската част на поръчката (артикули, наложен платеж, куриер, тегло, колети) остава
Регистър на идентификаторите от Meta (`processed_messages` — суровите идентификатори на съобщенията, по един на входящо съобщение, за да не бъде едно и също съобщение обработено два пъти)	90 дни след като идентификаторът е видян	Планиран purge изтрива редовете. Таблицата е обща, не по продавач, тъй че „Изтрий всичките ми данни“ на един продавач не я докосва — 90-дневната давност е единственият ѝ часовник
Тестов корпус (`chat_fixtures.transcript_json`, `seed_candidates.snapshot_json` — реални разговори, запазени за тестване на извличането)	90 дни	Планиран purge изтрива редовете; изтриват се и от „Изтрий всичките ми данни“
Паркиран въпрос от споделяне (`share_parks.frames_json` — прочитът на чат, споделен в приложението, задържан, докато Ferry чака да му кажат за кой разговор се отнася) и събрани кадри от споделяне (`share_collect_frames.messages_json` — текстът, прочетен от споделените снимки; никога самата снимка)	30 дни	Планиран purge изтрива редовете
Склад за споделяне преди влизане (Cloudflare KV — самата снимка, base64, плюс текста, за да преживее споделянето влизането, което го е прекъснало)	15 минути (TTL)	Изтрива се в мига, в който споделянето продължи; иначе изтича. Това е единственото място в Ferry Social, където байтовете на чужда снимка изобщо се записват
Споделени събития за върнати пратки (`buyer_reputation_events` — същият псевдонимизиран мрежов набор като в Shopify графика по-горе)	365 дни, автоматично изтриване	Планиран purge
Блокирани телефонни номера (`block_list` — нормализиран телефон плюс кратка бележка на продавача)	Докато продавачът не премахне записа	Премахва се от продавача. Изтриване по давност и включването на списъка в „Изтрий всичките ми данни“ се добавят
PDF етикети (R2 — име, телефон и адрес, отпечатани върху етикета) и данни от куриерското проследяване (`tracking_events`)	Днес в Ferry Social се изтриват, когато продавачът анулира пратката (етикетът) или изтрие всичките си данни (и двете); изтриване по давност се добавя, за да съвпадне с 90-те дни на Shopify страната	Анулиране на пратката; „Изтрий всичките ми данни“
Собствените публикации и текстове на продавача (`page_posts`) — неговият каталог, не данни на купувача	За срока на акаунта	Изтриват се от „Изтрий всичките ми данни“
Регистър на известията (`notification_events` — вид на събитието и препратка към човек; без съдържание на съобщения)	За срока на акаунта	Изтриват се от „Изтрий всичките ми данни“
Буфер на съобщенията в движение (хранилище на Durable Object — съобщения, чакащи да бъдат прочетени заедно като един бърст)	Преходен	Изчиства се, когато бърстът бъде обработен
Акаунт и връзки на продавача (имейл адрес, свързаната Meta страница и нейният шифрован токен за достъп, шифровани куриерски креденшъли, данни за подателя, абонаменти за push известия, настройки)	За срока на регистрацията	Изтриване на акаунта се извършва от „Прендит“ ЕООД по заявка до privacy@ferrycommerce.com; самообслужващ път се добавя

Какво какво изтрива в Ferry Social. Съществуват два механизма: планираният purge по-горе и собственият жест на продавача „Изтрий всичките ми данни“, който премахва всеки работен ред за този продавач (разговори, ангажименти, купувачи, платформени профили, инициатори, поръчки, пратки, събития от проследяването, паркирани и събрани споделяния, публикации, тестовия корпус) и обектите с етикети в R2, като нарочно запазва акаунта и връзките му, за да не се налага продавачът да свързва всичко отново. Тук няма Shopify webhooks — shop/redact и customers/redact не съществуват в този продукт — и, както е казано в §8 на Политиката за поверителност, няма повърхност за заявки от купувачи: заявката стига до privacy@ferrycommerce.com и се изпълнява на ръка.

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

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

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

Статус на изпълнение (Ferry Social): purge-ът, описан в графика за Ferry Social, е имплементиран — един планиран процес на петминутния cron, всяка категория със собствена заявка, ограничен на изпълнение, тъй че натрупване се източва през следващите тикове, вместо да бъде прескочено. Двете категории, които той още не покрива, са назовани в графика: PDF етикетите с данните от проследяването и списъкът с блокирани номера.

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

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

Обратните товарителници са покрити и в двете направления: една поръчка може да има изходяща и обратна пратка (при връщането купувачът е подателят), а 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: редове, ограничени по наемателя (Shopify магазина или продавача в Ferry Social) и по клиент/поръчка, се изтриват необратимо — при документираните изключения от графика (одитът gdpr_requests и финансовите записи).
R2: обектите с етикети се изтриват по ключ.
KV: записите за креденшъли/сесии/кеш се изтриват или изтичат.
Опашки (Queues): съобщенията в пайплайна (които преходно може да носят данни от поръчка, вкл. телефон/имейл на купувач) съществуват само до доставката си или, при недоставими — до изчерпване на dead-letter опашката — ограничено до дни; записът в D1 за dead-letter е статусен ред без лични данни.
Оперативните логове се ротират по сроковете от графика. Контактни данни на купувачи не се пишат в логове при нормална работа.
Резервните копия, управлявани от Cloudflare, изтичат по сроковете на платформата; не поддържаме отделни дълготрайни резервни копия с лични данни.

Преглед