Безплатен плъгин — но плащате ли с данните на клиентите и бизнеса си?

Когато онлайн магазин издава товарителница за Speedy, Econt или BOX NOW чрез „Bulgarisation for WooCommerce“ 4.0.13, заявката не се изпраща директно от магазина към официалното API на куриера.

Плъгинът я изпраща само към частния сървър:

api.bulgarisation.bg

Към същата инфраструктура се изпращат и структурирани данни за поръчките при генериране на стандартизирания одиторски XML файл по Наредба Н-18.

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

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

При издаването на товарителница към api.bulgarisation.bg се изпращат, в зависимост от куриера и настройките:

името на клиента;
телефонният му номер;
имейл адресът му;
адресът или избраният офис/автомат за доставка;
информация за пратката и поръчката;
стойността на поръчката;
размерът на наложения платеж;
интернет адресът на онлайн магазина.

При Speedy и Econt, когато търговецът използва услугата куриерът да издава фискален бон за наложения платеж, заявката съдържа и подробна разбивка на покупката:

наименования на продуктите;
количества;
единични цени;
други данни за артикулите;
при Speedy — и теглото.

Така сървърът получава информация кой е клиентът, какво е купил, в какво количество, на каква цена и каква сума трябва да бъде събрана.

За онлайн магазина тези заявки разкриват продуктите, цените, обема и стойността на поръчките, обработени през съответните куриерски интеграции.

Но това не е всичко.

Към същия сървър плъгинът изпраща и:

потребителското име и паролата за Speedy;
потребителското име и паролата за Econt;
access token за BOX NOW.

Следователно операторът на api.bulgarisation.bg технически получава едновременно:

лични данни на клиентите;
подробности за техните покупки;
търговска информация за продажбите;
средства за достъп до куриерските профили на магазините.

Това не е анонимна статистика или обикновена проверка за актуализация.

Не „първо към посредника“, а само към него

Плъгинът не изпраща една заявка до посредника и друга директно до куриера.

Кодът на плъгина изпраща заявката за товарителницата към api.bulgarisation.bg и разчита този сървър да извърши последващата комуникация с куриера.

Търговецът може да види как данните напускат неговия магазин, но няма достъп до:

сървърния код на посредника;
неговите логове;
базите му данни;
резервните му копия;
настройките за съхранение;
списъка на лицата, които имат достъп.

Публичният код не показва какво става с информацията след получаването ѝ от api.bulgarisation.bg.

Записват ли се заявките? Колко време се пазят? Архивират ли се? Използват ли се за друга цел? Включват ли се в анализи за отделните магазини?

На тези въпроси няма проверим отговор в кода на плъгина.

Посредническият сървър не е необходим за издаването на товарителница

Официалните API на Speedy, Econt и BOX NOW позволяват магазинът да комуникира директно с куриера.

Още по-показателно е, че GitHub историята на самия плъгин съдържа по-ранни реализации с директна комуникация. Впоследствие те са заменени с изпращане към api.bulgarisation.bg.

Промяната при BOX NOW е направена на 18 ноември 2025 г.

Директната интеграция със Speedy е заменена с посредническа заявка на 5 април 2026 г.

При Econt промяната е направена на 19 юли 2026 г.

Следователно преминаването през сървър на разработчика не е необходимо за самото издаване на товарителница. То е допълнителен архитектурен избор.

Това поставя очевидни въпроси:

Защо е добавен този посредник?
Защо заявките вече не се изпращат директно до куриерите?
Защо личните данни и подробностите за покупките трябва да преминават през допълнителен оператор?
Защо куриерските пароли и токени се изпращат до него?
Записват ли се данните?
Броят ли се заявките и поръчките?
Изгражда ли се история на продажбите за отделните магазини?
Използва ли се сървърът за ограничаване и монетизиране на функционалността?
Може ли от получените заявки да се създаде база данни за клиенти, продукти, цени и обороти?

Това са въпроси, а не доказани от клиентския код отговори. Но разработчикът трябва да обясни защо е добавил оператор, който не е необходим на куриерското API и който получава целия чувствителен пакет от данни.

Одиторският файл по Наредба Н-18 също се изпраща към сървъра

При генериране на стандартизирания одиторски XML файл плъгинът изпраща към api.bulgarisation.bg структуриран отчетен набор, който може да включва:

номера и дати на поръчки;
номера и дати на документи;
идентификатори на плащания и транзакции;
наименования на продукти и услуги;
количества;
единични цени;
общи стойности;
отстъпки;
ДДС;
сторнирания и възстановявания;
данни за магазина и отчетния период.

GitHub историята показва, че преди това файлът е бил генериран локално, на сървъра на самия търговец.

На 9 април 2026 г. локалният XML генератор е премахнат и заменен с изпращане на отчетния набор към api.bulgarisation.bg.

Следователно и тук изпращането на данните към чужд сървър не е техническа необходимост. Предишната версия е създавала файла локално.

Защо информацията за продажбите трябва да напуска магазина, след като файлът може да бъде генериран на неговия собствен сървър?

Записват ли се изпратените отчети?

Броят ли се поръчките?

Използва ли се дистанционната обработка, за да може достъпът до функцията да бъде спрян и поставен зад платена версия?

Свидетелства за лимит от 100 поръчки и искане за плащане

Получихме свидетелски сведения, според които след достигане на 100 поръчки услугата за генериране на стандартизирания одиторски файл спира и от търговеца се иска да премине към платена версия.

Според същите сведения плащане е поискано като „дарение“ чрез Revolut, а когато клиентът е поискал фактура, му е било заявено, че трябва допълнително да заплати ДДС.

Кодът и интерфейсът на плъгина потвърждават съществуването на лимит от 100 поръчки и представят премахването му като Pro възможност.

Конкретните сведения за начина на плащане и фактуриране обаче трябва да бъдат потвърдени с кореспонденция, платежни документи и позиция на получателя. Само въз основа на свидетелски разказ не може да се обяви извършено данъчно нарушение.

Но въпросите остават:

Спира ли сървърът генерирането на файла след 100 поръчки?
Как сървърът установява, че лимитът е достигнат?
Броят и съхраняват ли се поръчките на отделните магазини?
Къде потребителят е информиран предварително за квотата?
Защо локално работещият генератор е преместен на сървър, от който достъпът може да бъде контролиран?
Искат ли се плащания под формата на „дарения“ през Revolut?
Кое лице получава тези плащания?
Издава ли се платежен или счетоводен документ?
Защо според свидетелството ДДС се иска допълнително, когато клиентът настоява за фактура?
Как се осчетоводяват получените плащания?
Съвместимо ли е спирането след квота с WordPress.org Guideline 5?

Guideline 5 забранява включена в плъгина функционалност да бъде ограничавана или спирана след достигане на период или квота. Допуска се платена външна услуга, когато тя предоставя реална самостоятелна функционалност.

Тук възниква важният въпрос: представлява ли сървърът самостоятелна услуга с реална добавена стойност, или локално работещ код е преместен дистанционно, за да бъде поставен под контрол и зад квота?

Това трябва да бъде разгледано от WordPress.org Plugin Review Team.

Кой управлява `api.bulgarisation.bg`?

WHOIS справката, с която разполагаме, посочва физическо лице като регистрант на bulgarisation.bg, а не дружество.

Това доказва кой е регистрирал домейна. Не доказва само по себе си кое лице фактически управлява API услугата и в какво качество обработва получените данни.

Затова трябва да се отговори:

Кой е операторът на сървъра — физическо лице или дружество?
Какви са пълното му наименование, ЕИК, адрес и данни за контакт?
На кого търговците фактически предоставят информацията за клиентите и продажбите си?
В какво качество операторът обработва личните данни?
Обработващ ли е по смисъла на GDPR?
Самостоятелен или съвместен администратор ли е?
Къде е договорът по чл. 28 GDPR?
Къде е политиката за поверителност на API услугата?
Какви са сроковете за съхранение?
Кои подизпълнители имат достъп?
Къде физически се обработват данните?
Как търговецът изпълнява искане на клиент за достъп или изтриване на информацията, достигнала до посредника?

Самото изреждане на домейна в readme.txt не отговаря на тези въпроси.

Защо плъгинът премахва WordPress HTTP контролите?

Преди разглежданите заявки кодът извиква функцията woo_bg_remove_api_filters().

Тя премахва всички регистрирани callbacks от:

http_request_args;
pre_http_request;
http_api_curl;
requests-curl.before_send.

След приключване на заявката плъгинът ги възстановява.

Тези механизми могат да бъдат използвани от защитни, одитни, privacy и debugging решения за наблюдение и контрол на изходящите заявки.

Защо точно около изпращането на клиентските данни и куриерските пароли се премахват общите WordPress HTTP hooks?

Коя техническа необходимост налага това?

Защо не е използвано по-тясно решение, което не отстранява чужди защитни и одитни механизми?

Самото премахване не доказва намерение за укриване. Но поведението съществува в кода и изисква конкретен технически отговор.

Connectix и NepoStop: отделен, второстепенен проблем

При активиране на съответните функции плъгинът изпраща телефонния номер на клиента към Connectix или NepoStop, за да бъде оценена вероятността пратката да бъде получена.

Резултатът може да бъде използван и за автоматично изключване на плащането с наложен платеж.

Това е отделен проблем, който повдига въпроси за:

профилиране на физически лица;
правното основание за проверката;
източника и точността на използваните данни;
информирането на клиента;
правото му на възражение и корекция;
наличието на човешка проверка;
автоматичното ограничаване на начин на плащане.

Основният проблем обаче остава api.bulgarisation.bg, защото през него преминават товарителниците за три куриера, куриерските пароли и токени, подробностите за покупките и отчетният набор за одиторския файл.

Станали ли са търговците и клиентите им продуктът?

Публичният код не доказва, че получените данни се продават или се използват извън заявената услуга.

Той доказва, че данните се изпращат.

Архитектурата дава на оператора техническата възможност да наблюдава заявките и да контролира достъпа до дистанционната функционалност.

Затова въпросът е напълно основателен:

Безплатен ли е плъгинът, ако търговецът предоставя личните данни на клиентите си, подробна информация за продажбите и куриерските си достъпи на допълнителен оператор, а част от функционалността впоследствие може да бъде спряна зад квота?

Станали ли са магазините източник на данни за:

клиенти;
продукти;
количества;
цени;
наложени платежи;
обем на продажбите;
търговско поведение?

Ако отговорът е „не“, операторът може да разсее тези съмнения чрез:

пълна идентификация;
договор по чл. 28 GDPR;
ясна политика за поверителност;
точни срокове за съхранение;
описание на логовете и резервните копия;
списък на подизпълнителите;
независим одит на инфраструктурата;
техническа възможност магазинът да комуникира директно с куриерите.

Какво трябва да направят търговците

Ако използвате тези интеграции, не приемайте, че данните отиват единствено при куриера.

Поискайте писмено:

Идентификация на оператора на api.bulgarisation.bg.
Договор по чл. 28 GDPR.
Политика за поверителност и срокове за съхранение.
Списък на подизпълнителите и местата за обработване.
Потвърждение дали заявките, паролите, токените, IP адресите и логовете се записват.
Обяснение защо е необходим посредническият сървър.
Възможност за директна комуникация с куриерските API.
Обяснение как се отчита лимитът от 100 поръчки.
Информация кое лице получава плащанията за платената версия и какви документи издава.

Проверете дали собствената ви политика за поверителност посочва този получател и всички категории данни, които му предоставяте.

Попитайте Speedy, Econt и BOX NOW дали одобряват предаването на потребителски имена, пароли и токени през тази инфраструктура.

Ако не получите проверими отговори, преценете преустановяване на засегнатите интеграции и смяна на куриерските достъпи след съгласуване с куриера.

Запазете екраните за лимита, кореспонденцията и документите за поискано плащане. Те могат да бъдат предоставени за проверка на WordPress.org Plugin Review Team, КЗЛД и при необходимост на други компетентни органи.

Заключение

Установеното от кода е конкретно:

При Speedy, Econt и BOX NOW плъгинът изпраща заявките за товарителници към api.bulgarisation.bg.

При Speedy и Econt изпраща потребителско име и парола, а при BOX NOW — access token.

При фискализация се изпращат подробности за закупените продукти, количествата и цените.

При генериране на одиторския файл структурирани данни за поръчките се изпращат за дистанционна обработка.

Посредническият сървър не е необходим за самото издаване на товарителниците. GitHub историята показва, че директните и локалните реализации са били заменени.

Публичният код не показва какво се прави с информацията след получаването ѝ от сървъра.

Въпросът вече не е дали данните достигат до посредника — кодът показва, че достигат.

Въпросът е:

Защо е добавен посредник, който не е необходим за основната операция, какво прави с получените данни и използва ли контрола върху дистанционната услуга, за да ограничава и монетизира функционалността?

Mreja.Net / „И-ТЕХ“ ЕООД предлага собствени WooCommerce интеграции и може да бъде разглеждано като конкурент на анализирания продукт. Публикуваме техническите доказателства, за да могат читателите да проверят изводите самостоятелно.