Як офлайн-чек на касі активує цифрові гігабайти: логіка роботи Embedded-сервісу Yezzz!

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Більшість звикли працювати з суто цифровими воронками: юзер клікнув на банер, перейшов у застосунок, натиснув кнопку, сервіс відправив запит на бекенд, база даних оновилася — магія відбулася. Усе це відбувається в одному середовищі.

Але що, якщо тригером для складної цифрової послуги стає... паперовий чек за хліб, молоко та ковбасу?

Сьогодні я хочу розібрати логіку роботи Embedded-сервісів на прикладі мобільного зв’язку Yezzz! усередині екосистеми застосунку «Сільпо». Наш продукт надає послуги безкоштовного мобільного зв’язку за виконання спеціальної пропозиції під час звичайного офлайн або онлайн шопінгу в супермаркетах «Сільпо».

Для продуктової команди та розробників це означає необхідність безшовно подружити дві величезні, архаїчні за своєю природою сутності: ритейл-бекенд (з його POS-терміналами) та класичний телеком-білінг.

Як система розуміє, що пропозицію виконано

Щоб офлайн-дія перетворилася на цифровий бонус, нам потрібен ідентифікатор. У нашій екосистемі ним виступає картка лояльності «Власний Рахунок».

Процес виглядає так:

1. Користувач сканує застосунок на касі. Термінал фіксує перелік товарів (SKU) та загальну суму.
2. Дані транзакції миттєво летять у процесинговий центр ритейлера.
3. Це мозок системи. Він слухає потік транзакцій і перевіряє кожну з них на відповідність правилам. Наприклад, логіка спеціальної пропозиції може бути такою: «Сума чека > 1000 грн» або «У чеку є товари з категорії X на суму > Y».
4. Якщо умови збігаються, процесинг лояльності генерує подію

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

Уявіть біль користувача: він спеціально купив товарів на потрібну суму, виходить із супермаркету, відкриває застосунок, а там — тиша. Статус пропозиції не змінився, інтернет не запрацював. Щоб уникнути цього, архітектура будується на принципах Event-Driven архітектури.

Щойно згенерована подія, запускається асинхронний ланцюжок:

1. Бекенд застосунку через API/webhook відправляє сигнал на сторону білінгової системи мобільного зв’язку: «Цей абонент виконав умови, нарахуйте йому пакет послуг на місяць».
2. Білінг оператора — це дуже специфічна річ. Він має не просто записати дані в базу, а надіслати команди на мережеве обладнання (комутатори), щоб номеру відкрили доступ до мережі.
3. Білінг відповідає ритейл-бекенду: «Успіх, пакет нараховано».

У цій архітектурі критично важлива відмовостійкість. Якщо API телекому в момент оплати лежить або відповідає довго, подія не має загубитися. Вона потрапляє в чергу і буде повторно відправлятися, поки абонент не отримає свої законні гігабайти.

Embedded Telecom — це реальна точка перетину двох складних систем. Коли ви зв’язуєте офлайн-чек із хмарним білінгом, ви створюєте продукт, який стає для користувача магією: він просто живе своє життя, робить рутинні покупки, а його базова потреба у мобільному зв’язку закривається сама собою.

Це суттєво підвищує Retention застосунку та змінює патерни поведінки людей. Адже навіщо йти в інший магазин чи платити за телефон окремо, якщо твоя вечеря буквально розблоковує тобі 4G?