Документация: этапы по фазам, решения D-026…D-033
- Новый порядок этапов (D-026): фаза 1 — концепт на dev без внешних сервисов (1b сайт, 1c вход, 1d ключи, 1e счёт и демо-оплата, 1f демо-выдача, 1g продления, 1h рефералы); фаза 2 — Telegram; фаза 3 — ALTCHA, ЮKassa, почта, Twenty, Chatwoot, Umami, выдача через API и публичный запуск; фаза 4 — звёзды и эквайринги. - Решения: демо-оплата по списку IP (D-027), выдача ключей через адаптер manual/demo/api (D-028), страницы сайта из блоков Payload (D-029), пересборка через revalidatePath (D-030), RU-адрес у mass (D-031), счётчик свободных серверов (D-032), переводы на 5 языков в каждом этапе (D-033). - Тексты описывают работающий продукт; Вейликс — выделенный IP на общем сервере; Telegram поддержки — @veilix_support; сроки ответа не обещаем; VPN-серверы не ведут журналов. - Ссылки на этапы во всех документах, Q-12 решён (ЮKassa для RUB), R-19 (библиотеки для headless Chromium) сделано. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
andreypr207andClaude Opus 5.5 committed
1 parent
0cad9bae18
commit
515acfb69d
53 files changed
+778
-348
No files matched your search
@@ -1,34 +1,48 @@
|
||||
# Этап 1b. Маркетинговые страницы
|
||||
# Этап 1b. Сайт
|
||||
|
||||
Статус: не начат.
|
||||
Статус: в работе.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Сайты обоих брендов по макетам, с контентом из Payload, формами и SEO.
|
||||
Сайты обоих брендов по макетам: весь контент — в Payload, 5 языков, SEO и пересборка по событию.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Страницы по макетам для обоих брендов: главная, цены, локации (карта, отрисованная на сервере), поддержка ([07-frontend.md](../07-frontend.md), раздел 2). Юридические страницы `/legal/*`, 404 и 500.
|
||||
2. Коллекции `pages`, `faq` (с местами показа), `leads`; поля контактов в `sites`.
|
||||
3. Контент из макетов на RU и EN: тексты, FAQ, локации, тарифы.
|
||||
4. Черновики юридических текстов на RU и EN с заглушками вместо данных юрлица: условия, конфиденциальность, возвраты, cookies.
|
||||
5. ALTCHA ([08-integrations.md](../08-integrations.md), раздел 2). Формы «Индивидуальные условия» и обратной связи с ALTCHA пишут в `leads`. Письмо администратору появится в 1c.
|
||||
1. Страницы по макетам для обоих брендов: главная, цены, локации (карта и глобус, отрисованные на сервере), поддержка ([07-frontend.md](../07-frontend.md), раздел 2). Юридические страницы `/legal/*`, 404 и 500.
|
||||
2. Контент в Payload ([D-029](../decisions/D-029-pages-blocks.md)): коллекция `pages` из блоков; `faq` с местами показа, включая вопросы кабинета для 1d; поля `sites` — почта и Telegram поддержки, часы работы, SEO по умолчанию.
|
||||
3. Тексты на 5 языках ([D-033](../decisions/D-033-translations.md)): RU и EN — из макетов и `i18n.js`, de, fr, es — перевод с глоссарием. Тексты описывают работающий продукт ([07-frontend.md](../07-frontend.md), раздел 7).
|
||||
4. Черновики юридических текстов на 5 языках с заглушками вместо данных юрлица (Q-13): условия, конфиденциальность, возвраты, cookies.
|
||||
5. Формы «Индивидуальные условия», «Особые условия» и «Написать нам» — только интерфейс: проверка полей и состояние «отправлено», без отправки ([D-026](../decisions/D-026-stage-order.md)).
|
||||
6. SEO: `<title>` и описания на каждом языке, `hreflang`, `canonical`, `sitemap.xml` и `robots.txt` на каждый домен, картинки для соцсетей.
|
||||
7. Статическая сборка «язык × валюта» и пересборка по событию из Payload ([D-017](../decisions/D-017-static-pages.md)).
|
||||
8. Решить, показывать ли количество свободных серверов.
|
||||
7. Статическая сборка «язык × валюта» и пересборка по событию из Payload ([D-017](../decisions/D-017-static-pages.md), [D-030](../decisions/D-030-revalidate-path.md)).
|
||||
8. Счётчик свободных серверов рядом со статусом, если поле заполнено ([D-032](../decisions/D-032-free-servers.md)).
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Оформление заказа (1d), кабинет (1f), переводы на de, fr, es (1h; до этого — английский запасной).
|
||||
ALTCHA (3a), отправка заявок (3d, 3e), Umami и баннер cookies (3f), оформление заказа (1e).
|
||||
|
||||
## 4. Перед стартом
|
||||
## 4. Решения при сверке плана (21–22.10.2026)
|
||||
|
||||
Открытых вопросов нет: Q-02, Q-08, Q-09 и Q-16 решены 21.10.2026 ([00-index.md](../00-index.md), раздел 4.1).
|
||||
1. Цвета карт Вейликса: глобус в hero — как в `Main`, плоская карта на /locations — как в `Locations`.
|
||||
2. Статусы локаций везде по [01-product.md](../01-product.md): «Серверы в наличии» / «Установим за 24 часа» и «Включено» / «Скоро» — в списках, карточках, на карте и во всплывающей карточке.
|
||||
3. `--ink-3` подбирается в обеих темах до контраста 4,5:1 (WCAG AA); в макете — 3,9:1.
|
||||
4. Карта: точки расположены как в макете; клик выбирает ближайшую точку (в Европе точки перекрываются); выбор синхронизируется между картой и сеткой, с клавиатуры — через сетку. На узком экране всплывающая карточка — HTML поверх карты.
|
||||
5. FAQ главной и поддержки — отдельные записи: формулировки в макетах разные. Блок FAQ на /pricing появляется, только если есть вопросы с этим местом показа. Цен в ответах нет.
|
||||
6. Seed создаёт страницы, FAQ и юридические тексты, только если их ещё нет: повторный `pnpm seed` не затирает правки из админки.
|
||||
7. Под формами — строка о согласии с политикой конфиденциальности со ссылкой, без чекбокса. Обязательные поля: в «Написать нам» — почта и текст, в заявке — хотя бы один контакт.
|
||||
8. Цена «в месяц» у годового тарифа mass округляется вниз до целых: 582 ₽, $5.82. Экономия считается точно.
|
||||
9. «Купить» передаёт тариф, локацию и валюту; у mass по умолчанию выбран «Год».
|
||||
10. Ошибки вёрстки макетов исправляются: переполнение сеток на 375 px, поля 15 px, `div role=button` вместо радиокнопок и ссылок, поля без подписей, кнопки меньше 44 px, нет `prefers-reduced-motion`.
|
||||
11. Сверка с макетами по скриншотам и замеры Lighthouse — в headless Chromium (R-19).
|
||||
|
||||
## 5. Готово, когда
|
||||
## 5. Перед стартом
|
||||
|
||||
1. Страницы обоих брендов совпадают с макетами: светлая и тёмная тема, десктоп и мобильный, RU и EN.
|
||||
2. Правка цены, статуса локации или FAQ в админке видна на сайте в течение нескольких секунд.
|
||||
Root: R-19 — сделано.
|
||||
|
||||
## 6. Готово, когда
|
||||
|
||||
1. Страницы обоих брендов совпадают с макетами: светлая и тёмная тема, десктоп и мобильный, 5 языков.
|
||||
2. Правка цены, статуса локации, FAQ или текста страницы в админке видна на сайте в течение нескольких секунд.
|
||||
3. Lighthouse mobile ≥ 90 на главной и странице цен обоих брендов.
|
||||
4. Формы создают заявки, ALTCHA работает.
|
||||
4. Формы проверяют поля и показывают состояние «отправлено».
|
||||
5. `sitemap.xml` и `hreflang` проходят проверку.
|
||||
@@ -1,16 +1,16 @@
|
||||
# Этап 1c. Вход по коду и почта
|
||||
# Этап 1c. Вход по коду
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Регистрация и вход по коду из письма в кабинетах обоих брендов; почтовая подсистема с журналом.
|
||||
Регистрация и вход по коду в кабинетах обоих брендов. Письма не отправляются, а пишутся в журнал: код виден в админке.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Почта ([08-integrations.md](../08-integrations.md), раздел 1): глобал «Почта» (транспорты `smtp`, `sendmail`, `log_only`), email-адаптер, `email-templates` с шапкой и подвалом бренда, `email-log`, задача `send-email`, тестовое письмо, флаг «Записывать коды входа в журнал».
|
||||
2. Шаблоны на RU и EN: `login_code`, `admin_new_lead` (и подключить его к формам из 1b).
|
||||
3. `customers` со своей стратегией, `customer-sessions`, `auth-codes`; запрос и проверка кода, лимиты, ALTCHA ([05-auth.md](../05-auth.md), разделы 2–4).
|
||||
1. Почта ([08-integrations.md](../08-integrations.md), раздел 1): глобал «Почта» с транспортом `log_only`, email-адаптер, `email-templates` с шапкой и подвалом бренда, `email-log`, задача `send-email`, флаг «Записывать коды входа в журнал».
|
||||
2. Шаблон `login_code` на 5 языках.
|
||||
3. `customers` со своей стратегией, `customer-sessions`, `auth-codes`; запрос и проверка кода, лимиты по IP и email ([05-auth.md](../05-auth.md), разделы 2–4).
|
||||
4. Страница `/login` по макету с состояниями: код отправлен, ошибка, истёк, повторная отправка через 60 секунд.
|
||||
5. Выход, выход на всех устройствах.
|
||||
6. Язык и валюта аккаунта при регистрации ([04-billing.md](../04-billing.md), раздел 2).
|
||||
@@ -18,15 +18,14 @@
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Telegram (этап 3), реферальная привязка при регистрации (1g).
|
||||
ALTCHA (3a), отправка писем через `sendmail` и `smtp` (3c), Telegram (2a–2c), реферальная привязка при регистрации (1h).
|
||||
|
||||
## 4. Перед стартом
|
||||
|
||||
Root: R-07 (Postfix, OpenDKIM, DNS) или данные SMTP-провайдера. Без них этап делается на транспорте `log_only`.
|
||||
Этап 1b готов.
|
||||
|
||||
## 5. Готово, когда
|
||||
|
||||
1. Регистрация и вход работают на `dev.my.veilix.app` и `dev.my.veilixvpn.com`; аккаунты сайтов независимы.
|
||||
2. С флагом коды видны в журнале; на `log_only` письма не уходят.
|
||||
3. Через `sendmail` или `smtp` письмо доходит до Gmail не в спам; оценка mail-tester ≥ 9/10.
|
||||
4. Лимиты и счётчик попыток работают; сессии отзываются.
|
||||
2. Код входа виден в журнале писем в админке; письма никуда не уходят.
|
||||
3. Лимиты и счётчик попыток работают; сессии отзываются.
|
||||
@@ -1,36 +0,0 @@
|
||||
# Этап 1d. Биллинг без эквайринга
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Деньги и заказы работают целиком: оформление заказа, оплата с баланса, ручные платежи, продления, льготный период — без внешних платёжных систем.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Коллекции `orders`, `payments`, `ledger-entries`, `payment-methods` (структура), `keys` (поля и статусы), `key-extensions`, `audit-log`.
|
||||
2. `core/billing`: `processPayment`, оплата с баланса, задачи `renewals`, `expiry`, `reminders`, `reconcile`; блокировки и уникальные ограничения ([04-billing.md](../04-billing.md)).
|
||||
3. `/order` по макетам обоих брендов: шаг «Почта» из 1c, шаг «Оплата» (с баланса; «Заказ создан, ожидает оплаты», когда платёжных систем нет), согласие с условиями, сводка из тарифа, локации и валюты.
|
||||
4. `/buy` в кабинете: dedicated — сетка локаций с ценами, mass — «Месяц» и «Год».
|
||||
5. Админка: ручной платёж, корректировка баланса, возврат на баланс, продление вручную (запись в `key-extensions`, [04-billing.md](../04-billing.md), раздел 6.4), блокировка, «Очередь выдачи»; всё — в журнал действий.
|
||||
6. Шаблоны писем на RU и EN: `order_paid`, `key_provisioning`, `renewal_reminder`, `expiry_reminder`, `renewal_succeeded`, `renewal_failed`, `grace_started`, `key_expired`, `topup_succeeded`, `refund_issued`, `admin_new_order`, `admin_provisioning_needed`.
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Подключения и выдача ключа (1e), реальные платёжные системы (этап 4). Для проверок ключ переводится в `active` вручную в админке.
|
||||
|
||||
## 4. Перед стартом
|
||||
|
||||
Этап 1c готов.
|
||||
|
||||
## 5. Готово, когда
|
||||
|
||||
Автотесты `core/billing` проходят сценарии:
|
||||
|
||||
1. Ручное пополнение → оплата заказа с баланса → заказ оплачен → ключ `provisioning`.
|
||||
2. Частичный баланс + ручной платёж на разницу → заказ оплачен.
|
||||
3. Продление с баланса за 24 часа; денег нет → заказ ждёт → пополнение само оплачивает продление.
|
||||
4. Переходы в льготный период и «истёк» с письмами.
|
||||
5. Частичный и полный возврат на баланс, с отменой ключа и без.
|
||||
6. Повторный `processPayment` и параллельные запуски задач не списывают дважды.
|
||||
7. `reconcile` не находит расхождений.
|
||||
@@ -0,0 +1,36 @@
|
||||
# Этап 1d. Ключи и подключения
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Администратор создаёт ключи и подключения вручную; пользователь видит ключи в кабинете и получает конфиги и ссылки.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Коллекции `keys` (поля и статусы) и `connections` с шифрованием содержимого ([03-data-model.md](../03-data-model.md), раздел 5); журнал действий `audit-log`.
|
||||
2. Админка:
|
||||
a. ключ вручную: пользователь, тариф, локация (dedicated);
|
||||
b. подключения: WG/AWG — файлом или текстом, ссылка Happ, ссылка Xray, RU-адрес, номер устройства, страна;
|
||||
c. «Выдать ключ», «Очередь выдачи», «К отключению», блокировка ключа.
|
||||
3. Кабинет по макетам `App` и `MassApp`:
|
||||
a. главная: ключи, «Купить ключ», FAQ кабинета;
|
||||
b. список ключей, бейдж «Истекает» ([04-billing.md](../04-billing.md), раздел 15);
|
||||
c. страница ключа: срок, WG-конфиги (скачать, QR), Happ и Xray (копировать, QR), RU-адрес; у mass — WG по странам.
|
||||
4. Состояния: готовится, активен, льготный период, истёк, заблокирован; нет ключей; нет подключений.
|
||||
5. Содержимое конфигов отдаётся отдельным запросом только владельцу и в HTML страницы не попадает. QR строится в браузере.
|
||||
6. Шаблон `key_ready` на 5 языках.
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Покупка и оплата (1e), автоматическая выдача (1f), автопродление и «Продлить сейчас» (1g).
|
||||
|
||||
## 4. Перед стартом
|
||||
|
||||
Этап 1c готов.
|
||||
|
||||
## 5. Готово, когда
|
||||
|
||||
1. Ключ, созданный и выданный в админке, виден в кабинете владельца активным; срок идёт с момента выдачи.
|
||||
2. Скачанный `.conf` импортируется в WireGuard; QR сканируется в WireGuard и Happ.
|
||||
3. Чужой пользователь получает 404 на конфиг (тест).
|
||||
@@ -0,0 +1,39 @@
|
||||
# Этап 1e. Счёт и оплата
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Покупка ключа и пополнение баланса работают целиком на демо-оплате, без эквайринга.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Коллекции `orders`, `payments`, `ledger-entries`, `payment-methods`.
|
||||
2. `core/billing`: `processPayment`, оплата с баланса, блокировки и уникальные ограничения ([04-billing.md](../04-billing.md), разделы 1–5 и 14).
|
||||
3. Платёжная система «Демо» ([D-027](../decisions/D-027-demo-payments.md)): страница демо-оплаты, демо-привязка карты, доступ по списку IP. `manual` — для администраторов.
|
||||
4. `/order` по макетам обоих брендов: шаг «Почта» (вход из 1c), шаг «Оплата» (с баланса, демо-оплатой, демо-картой; «Заказ создан, ожидает оплаты», если платёжных систем нет), согласие с условиями, сводка из тарифа, локации и валюты.
|
||||
5. Кабинет:
|
||||
a. `/buy`: dedicated — сетка локаций с ценами, mass — «Месяц» и «Год»;
|
||||
b. «Счёт и платежи»: баланс, пополнение (пресеты и своя сумма), привязанная карта и «Отвязать карту», история;
|
||||
c. смена валюты аккаунта ([04-billing.md](../04-billing.md), раздел 2).
|
||||
6. После оплаты ключ создаётся в статусе `provisioning` и выдаётся вручную (1d); автоматически — с 1f.
|
||||
7. Админка: ручной платёж, корректировка баланса, возврат на баланс; всё — в журнал действий.
|
||||
8. Шаблоны на 5 языках: `order_paid`, `key_provisioning`, `topup_succeeded`, `refund_issued`, `admin_new_order`, `admin_provisioning_needed`.
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Продления (1g), реальные платёжные системы (3b, 4a, 4b).
|
||||
|
||||
## 4. Перед стартом
|
||||
|
||||
Этап 1d готов.
|
||||
|
||||
## 5. Готово, когда
|
||||
|
||||
1. С разрешённого IP ключ покупается демо-оплатой и с баланса; отказ демо-оплаты виден пользователю.
|
||||
2. Демо-карта привязывается и отвязывается.
|
||||
3. Автотесты `core/billing` проходят сценарии:
|
||||
a. пополнение → оплата заказа с баланса → заказ оплачен → ключ `provisioning`;
|
||||
b. частичный баланс и оплата разницы → заказ оплачен;
|
||||
c. частичный и полный возврат на баланс, с отменой ключа и без;
|
||||
d. повторный `processPayment` не списывает дважды.
|
||||
@@ -1,26 +0,0 @@
|
||||
# Этап 1e. Ключи и подключения
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Администратор выдаёт ключи вручную; пользователь получает конфиги и ссылки на странице ключа.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Коллекция `connections` с шифрованием содержимого ([03-data-model.md](../03-data-model.md), 5.2).
|
||||
2. Админка: на странице ключа — добавление подключений (WG/AWG — файлом или текстом, ссылка Happ, ссылка Xray, RU-адрес, номер устройства, страна), действие «Выдать ключ» (к сроку добавляются дни продлений без оплаты, ждавшие выдачи), список «К отключению».
|
||||
3. Страница ключа в кабинете: срок, галочка автопродления, «Продлить сейчас», WG-конфиги (скачать, QR), Happ/Xray (копировать, QR); для mass — WG по странам: конфиги, которые добавил администратор; нужна другая страна — ссылка на поддержку.
|
||||
4. Состояния: готовится, льготный период, истёк, нет подключений.
|
||||
5. Содержимое конфигов отдаётся отдельным запросом только владельцу, в HTML страницы не попадает. QR строится в браузере из полученного содержимого.
|
||||
6. Шаблон `key_ready` на RU и EN.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Этап 1d готов.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
1. Администратор выдал ключ — пользователь видит его активным, срок пошёл с момента выдачи.
|
||||
2. Скачанный `.conf` импортируется в WireGuard; QR сканируется в WireGuard и Happ.
|
||||
3. Чужой пользователь получает 404 на конфиг (тест).
|
||||
@@ -1,24 +0,0 @@
|
||||
# Этап 1f. Веб-кабинеты
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Кабинеты обоих брендов по макетам `App` и `MassApp`.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Главная: ключи, «Купить ключ», FAQ.
|
||||
2. Список ключей; бейдж «Истекает» по правилу [04-billing.md](../04-billing.md), раздел 15.
|
||||
3. «Счёт и платежи»: баланс, пополнение (пресеты и своя сумма; пока платёжных систем нет — понятное сообщение), сохранённая карта и «Отвязать карту» (видно с этапа 4), ближайшие списания, история.
|
||||
4. Настройки: язык, валюта (правило — [04-billing.md](../04-billing.md), раздел 2), тема; выход.
|
||||
5. Мобильная навигация: вкладки «Главная, Ключи, Купить, Ещё».
|
||||
6. Различия брендов: у mass «Список ключей» без «текущей/запасной локации».
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Реферальная страница (1g), MiniApp (этап 3).
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Кабинеты обоих брендов совпадают с макетами: светлая и тёмная тема, десктоп и мобильный, RU и EN. Все данные — реальные, из базы.
|
||||
@@ -0,0 +1,24 @@
|
||||
# Этап 1f. Выдача ключей «Демо»
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
После оплаты ключ выдаётся сам через адаптер выдачи. Сейчас это эмулятор; на этапе 3g на его место встанет настоящий API.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Адаптер выдачи в `core/provisioning/` ([D-028](../decisions/D-028-provisioning-adapter.md)): выдать ключ, создать WG-конфиг (для устройства, у mass — для страны), отключить подключения ключа. Реализации `manual` и `demo`; режим — настройка сайта.
|
||||
2. `demo`: при оплате ключ выдаётся сам — со ссылкой Happ и подключением к RU-адресу. Локация «24 часа» выдаётся с задержкой (по умолчанию минута), чтобы было видно состояние «готовится». Данные правдоподобные, но фиктивные: адреса из тестовых диапазонов.
|
||||
3. Кабинет: «Получить конфиг WireGuard» на странице ключа — для устройства, у mass — для страны.
|
||||
4. Истёкший или отменённый ключ: подключения отключаются через адаптер; у `manual` — по списку «К отключению».
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Этап 1e готов.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
1. После демо-оплаты ключ в локации «в наличии» сразу активен со ссылкой Happ; в локации «24 часа» — сначала «готовится», затем активен.
|
||||
2. WG-конфиг создаётся по кнопке и импортируется в WireGuard (подключиться он не сможет: адреса фиктивные).
|
||||
3. В режиме `manual` всё работает, как в 1d.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Этап 1g. Продления
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Ключи продлеваются сами — с баланса, затем с демо-карты; льготный период, истечение и напоминания работают.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Задачи `renewals`, `expiry`, `reminders`, `reconcile` ([04-billing.md](../04-billing.md), разделы 6–7; [02-architecture.md](../02-architecture.md), раздел 7).
|
||||
2. Автопродление: галочка на ключе, «Продлить сейчас»; списание с баланса, затем с демо-карты, повторы. Неуспешное списание с демо-карты включается в админке ([D-027](../decisions/D-027-demo-payments.md)).
|
||||
3. Продления без оплаты: коллекция `key-extensions`, «Продлить вручную» в админке ([04-billing.md](../04-billing.md), раздел 6.4).
|
||||
4. Кабинет: «Следующее списание», «Продлится автоматически через N дней» или «Осталось N дней», бейдж «Истекает».
|
||||
5. Шаблоны на 5 языках: `renewal_reminder`, `expiry_reminder`, `renewal_succeeded`, `renewal_failed`, `grace_started`, `key_expired`.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Этап 1f готов.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Автотесты проходят сценарии:
|
||||
|
||||
1. Продление с баланса за 24 часа до окончания; денег нет → заказ ждёт → пополнение само оплачивает продление.
|
||||
2. Продление с демо-карты; неуспешное списание → повторы → льготный период.
|
||||
3. Переходы в льготный период и «истёк» с письмами в журнал.
|
||||
4. Параллельные запуски задач не продлевают ключ дважды.
|
||||
5. `reconcile` не находит расхождений.
|
||||
@@ -1,26 +0,0 @@
|
||||
# Этап 1h. Переводы, аналитика, запуск prod
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Сайты и кабинеты на 5 языках работают на основных доменах.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Переводы de, fr, es: интерфейс и контент Payload, машинный перевод LLM с глоссарием ([06-i18n.md](../06-i18n.md), раздел 7); проверка непереведённых ключей.
|
||||
2. Umami на этом сервере ([D-018](../decisions/D-018-analytics.md)) с проксированием через домены брендов; баннер cookies ([08-integrations.md](../08-integrations.md), раздел 8).
|
||||
3. Проверка производительности (Lighthouse mobile ≥ 90) и доступности.
|
||||
4. Prod под пользователем vx_prod: `.env`, команда выкладки с папками релизов и откатом ([02-architecture.md](../02-architecture.md), раздел 5), первая выкладка, начальные данные prod, первый администратор, smoke-тесты.
|
||||
5. Бэкапы базы и media с проверкой восстановления.
|
||||
6. Юридические черновики на сайтах (Q-13 — пока с заглушками).
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Root: R-08…R-11, по желанию R-15. Решения: Q-14 (куда бэкапы), Q-18 (кто запускает выкладку).
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
1. Основные домены работают по HTTPS, dev и prod разделены.
|
||||
2. Выкладка и откат отрепетированы.
|
||||
3. Восстановление из бэкапа проверено.
|
||||
@@ -1,10 +1,10 @@
|
||||
# Этап 1g. Реферальная программа
|
||||
# Этап 1h. Реферальная программа
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
«Приведите друга — вы оба получите по месяцу в подарок» по правилам [04-billing.md](../04-billing.md), раздел 11. Бонус — дни срока ключа, а не деньги ([D-025](../decisions/D-025-referral-days.md)).
|
||||
«Приведите друга — вы оба получите по месяцу в подарок» по правилам [04-billing.md](../04-billing.md), раздел 11. Бонус — дни срока ключа, а не деньги ([D-025](../decisions/D-025-referral-days.md)). Этим этапом заканчивается концепт: дальше он проверяется на dev целиком.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
@@ -14,9 +14,13 @@
|
||||
4. Бонус обоим после первой оплаты заказа `new_key` приглашённого: дни к ключам через `key-extensions`; статус `review` при совпадении хэша IP.
|
||||
5. Число дней бонуса в `sites` (`referralBonusDays`).
|
||||
6. Страница `/referral` по макету: приглашено, начислено месяцев, ожидает; ссылка с копированием; приглашённые с замаскированной почтой. Условия под ссылкой — про дни, а не про списание ([07-frontend.md](../07-frontend.md), раздел 7).
|
||||
7. Шаблон `referral_reward` на RU и EN; список приглашений в админке.
|
||||
7. Шаблон `referral_reward` на 5 языках; список приглашений в админке.
|
||||
|
||||
## 3. Готово, когда
|
||||
## 3. Перед стартом
|
||||
|
||||
Этап 1g готов.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
1. A делится ссылкой → B регистрируется → B оплачивает первый заказ → к ключу B и к последнему ключу A добавлено по 30 дней.
|
||||
2. У A нет подходящего ключа — дни добавляются к следующему ключу A.
|
||||
@@ -1,19 +0,0 @@
|
||||
# Этап 2. Chatwoot и Twenty CRM
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Входит
|
||||
|
||||
1. Chatwoot ([08-integrations.md](../08-integrations.md), раздел 4): виджет на сайтах и в кабинетах, отдельные входящие каналы для каждого бренда; идентификация вошедших пользователей с HMAC; категория в баннере cookies.
|
||||
2. Боты поддержки обоих брендов подключены к Chatwoot как Telegram-каналы.
|
||||
3. Почта поддержки: email-каналы Chatwoot для ящиков `help@…` на почтовом хостинге — письма по IMAP, ответы через SMTP хостинга (Q-16).
|
||||
4. Twenty ([08-integrations.md](../08-integrations.md), раздел 5): заявки уходят через API фоновой задачей с повторами, `leads.crmId`.
|
||||
|
||||
## 2. Перед стартом
|
||||
|
||||
Root: R-12 — VPS, Chatwoot, Twenty, ключи API, боты поддержки в BotFather. Ящики поддержки (R-18) и их данные IMAP и SMTP.
|
||||
|
||||
## 3. Готово, когда
|
||||
|
||||
1. Сообщения из виджетов и ботов поддержки приходят в Chatwoot с указанием бренда; вошедший пользователь опознан.
|
||||
2. Заявки появляются в Twenty.
|
||||
@@ -0,0 +1,27 @@
|
||||
# Этап 2a. MiniApp в Telegram
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Кабинет внутри Telegram по макетам `AppTG` и `MassAppTG`: всё, что умеет веб-кабинет, на тех же демо-режимах.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. MiniApp на `tg.*` с Telegram SDK: BackButton, MainButton, тема Telegram, отклик вибрацией ([07-frontend.md](../07-frontend.md), раздел 2).
|
||||
2. Вход по `initData`, аккаунт по Telegram без почты ([05-auth.md](../05-auth.md), раздел 6.1).
|
||||
3. Ключи, покупка, счёт, рефералы — на тех же `core/` и демо-режимах, что веб-кабинет ([D-027](../decisions/D-027-demo-payments.md), [D-028](../decisions/D-028-provisioning-adapter.md)).
|
||||
4. Тестовые боты для dev; dev-MiniApp открывается только для Telegram-аккаунтов из списка.
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Команды и уведомления бота (2b), привязка и объединение аккаунтов (2c), звёзды Telegram (4a).
|
||||
|
||||
## 4. Перед стартом
|
||||
|
||||
1. Root: R-13 — основные и тестовые боты в BotFather, адреса MiniApp.
|
||||
2. Решения: Q-10 (имена ботов), Q-11 (оплата в Telegram; до этапа 4a — демо-оплата и баланс).
|
||||
|
||||
## 5. Готово, когда
|
||||
|
||||
Из MiniApp можно зарегистрироваться, купить ключ демо-оплатой, получить конфиги, пополнить баланс и пригласить друга.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Этап 2b. Основной бот
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Основные боты обоих брендов: команды, меню, кнопка MiniApp, уведомления.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Боты на grammY ([D-015](../decisions/D-015-telegram-bots.md)): вебхук `/svc/telegram/<сайт>/webhook` с секретным токеном, команды и меню ([08-integrations.md](../08-integrations.md), раздел 6). Тексты и кнопки — в Payload на 5 языках.
|
||||
2. Уведомления из [04-billing.md](../04-billing.md), раздел 12, дублируются в бот, если Telegram привязан.
|
||||
3. Реферальный код через `/start <код>`.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Этап 2a готов.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Команды работают на 5 языках; уведомления о выдаче ключа и продлениях приходят в бот.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Этап 2c. Связь аккаунтов Telegram и сайта
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Человек с Telegram и почтой — один аккаунт на сайте бренда, откуда бы он ни вошёл.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Привязка почты из Telegram ([05-auth.md](../05-auth.md), раздел 6.2): код на почту, до этапа 3c — в журнал писем.
|
||||
2. «Подключить Telegram» в кабинете и «Войти через Telegram» на сайте ([05-auth.md](../05-auth.md), раздел 6.3).
|
||||
3. Объединение аккаунтов, автоматическое и ручное из админки ([05-auth.md](../05-auth.md), раздел 6.4).
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Этап 2b готов. Root: домен кабинета для Telegram Login в BotFather (R-13).
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Сценарии привязки и объединения аккаунтов проходят: автотесты и проверка вручную.
|
||||
@@ -1,23 +0,0 @@
|
||||
# Этап 3. Telegram
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Входит
|
||||
|
||||
1. Основные боты обоих брендов на grammY: вебхук, команды, меню, тексты в Payload на всех языках ([08-integrations.md](../08-integrations.md), раздел 6).
|
||||
2. MiniApp по макетам `AppTG` и `MassAppTG` с Telegram SDK: BackButton, MainButton, тема Telegram, отклик вибрацией; вход по `initData`.
|
||||
3. Привязка почты из Telegram, «Подключить Telegram» в кабинете, «Войти через Telegram» на сайте, объединение аккаунтов ([05-auth.md](../05-auth.md), раздел 6).
|
||||
4. Уведомления в бот; реферальный код через `/start`.
|
||||
5. Тестовые боты для dev с доступом по списку Telegram-аккаунтов.
|
||||
6. Оплата в Telegram — по решению Q-11.
|
||||
|
||||
## 2. Перед стартом
|
||||
|
||||
1. Root: R-13 — основные и тестовые боты, домен для Telegram Login, адреса MiniApp.
|
||||
2. Решения: Q-10 (имена ботов), Q-11 (оплата в Telegram).
|
||||
|
||||
## 3. Готово, когда
|
||||
|
||||
1. Из Telegram можно зарегистрироваться, купить ключ (по Q-11), получить конфиги, пополнить баланс, пригласить друга.
|
||||
2. Уведомления приходят в бот.
|
||||
3. Сценарии привязки и объединения аккаунтов проходят.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Этап 3a. ALTCHA
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Защита запроса кода входа и форм от ботов без сторонних сервисов ([D-013](../decisions/D-013-captcha.md)).
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. ALTCHA ([08-integrations.md](../08-integrations.md), раздел 2): эндпоинт `/svc/altcha/challenge`, ключ подписи в `.env`, одноразовые решения; провайдер изолирован в `core/`.
|
||||
2. Без видимого виджета: задача решается в фоне, пока человек заполняет форму. Скрипт грузится только на страницах с формами.
|
||||
3. Запрос кода входа; формы — вместе с их отправкой (3d, 3e).
|
||||
4. Root: `limit_req` в nginx на вход и формы ([09-infrastructure.md](../09-infrastructure.md), раздел 4).
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Фаза 2 готова.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Запрос кода без решения или с уже использованным решением отклоняется; в браузере вход работает без видимой капчи.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Этап 3b. ЮKassa
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Пополнение баланса в рублях через ЮKassa.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Адаптер `yookassa` ([08-integrations.md](../08-integrations.md), раздел 7): создание платежа, вебхук с проверкой, идемпотентная обработка ([04-billing.md](../04-billing.md), раздел 14). Только пополнение (`topup`).
|
||||
2. Состояния пополнения: ожидание, отказ, успех.
|
||||
3. Сначала тестовый магазин, затем боевой.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Root: R-14 — аккаунт ЮKassa (сначала тестовый магазин), адрес вебхука. Для боевого магазина нужны данные юрлица (Q-13). Разные аккаунты для брендов — Q-17.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Пополнение в тестовом режиме проходит путь от оплаты до зачисления, включая повторную доставку вебхуков.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Этап 3c. Отправка почты
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Письма уходят на самом деле и не попадают в спам.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Транспорты `sendmail` (Postfix) и `smtp` в глобале «Почта», кнопка «Отправить тестовое письмо» ([08-integrations.md](../08-integrations.md), раздел 1).
|
||||
2. Postfix, OpenDKIM, SPF, DKIM, DMARC для обоих доменов ([09-infrastructure.md](../09-infrastructure.md), раздел 6).
|
||||
3. Письма администраторам уходят на почту поддержки.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Root: R-07 (или данные SMTP-провайдера), R-18 (ящики поддержки).
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Письмо доходит до Gmail не в спам; оценка mail-tester ≥ 9/10.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Этап 3d. Twenty CRM
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Заявки «Индивидуальные условия» и «Особые условия» с сайта и из кабинета попадают в Twenty.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Формы заявок отправляют данные: проверка полей, ALTCHA (3a), лимит по IP.
|
||||
2. Twenty ([08-integrations.md](../08-integrations.md), раздел 5): человек и сделка с полями заявки, брендом и страницей. Нужен ли буфер в базе на случай, когда Twenty недоступен, — решаем на старте этапа.
|
||||
3. Письмо `admin_new_lead` на почту поддержки.
|
||||
|
||||
## 3. Не входит
|
||||
|
||||
Форма «Написать нам» — это обращение в поддержку, она уходит в Chatwoot (3e).
|
||||
|
||||
## 4. Перед стартом
|
||||
|
||||
Root: R-12 — Twenty на VPS, ключ API.
|
||||
|
||||
## 5. Готово, когда
|
||||
|
||||
Заявки обоих брендов появляются в Twenty; при недоступности Twenty заявка не теряется молча.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Этап 3e. Chatwoot
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Поддержка обоих брендов в одном Chatwoot: виджет, Telegram, почта.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Chatwoot ([08-integrations.md](../08-integrations.md), раздел 4): виджет на сайтах и в кабинетах, свои входящие каналы у каждого бренда; идентификация вошедших пользователей с HMAC.
|
||||
2. Боты поддержки обоих брендов подключены к Chatwoot как Telegram-каналы; на сайтах они заменяют `@veilix_support`.
|
||||
3. Почта поддержки: email-каналы Chatwoot для ящиков `help@…` на почтовом хостинге — письма по IMAP, ответы через SMTP хостинга (Q-16).
|
||||
4. Форма «Написать нам» создаёт обращение в Chatwoot.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Root: R-12 — Chatwoot на VPS, ключи API, боты поддержки в BotFather; ящики поддержки (R-18) и их данные IMAP и SMTP.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Сообщения из виджетов, ботов поддержки, почты и формы приходят в Chatwoot с указанием бренда; вошедший пользователь опознан.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Этап 3f. Umami и баннер cookies
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Своя аналитика без cookies и согласие на необязательные cookies.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Umami на этом сервере ([D-018](../decisions/D-018-analytics.md), [08-integrations.md](../08-integrations.md), раздел 8): пользователь `umami`, база `umami`, панель `umi.veilix.cc`; трекер — через домены брендов под нейтральными путями; поле `domains.umamiWebsiteId`.
|
||||
2. Баннер cookies: обязательные (сессия, язык, валюта) и функциональные (Chatwoot). Решение хранится в cookie `vx_consent`; виджет Chatwoot загружается только после согласия.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Root: R-10 — nginx и сертификат для `umi.veilix.cc`, проксирование путей трекера.
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
Посещения видны в Umami; без согласия виджет Chatwoot не загружается.
|
||||
@@ -0,0 +1,14 @@
|
||||
# Этап 3g. Выдача ключей через API
|
||||
|
||||
Статус: обсуждение при старте этапа.
|
||||
|
||||
## 1. Что известно
|
||||
|
||||
1. Адаптер `api` встаёт на место `demo` ([D-028](../decisions/D-028-provisioning-adapter.md)): по тарифу (страны, теги) подбирается свободный сервер, бэкенд возвращает подключения для ключа.
|
||||
2. Автоматика создаёт те же подключения, что администратор или демо-адаптер ([D-020](../decisions/D-020-key-models.md)), и отключает их, когда ключ истекает.
|
||||
3. Наличие в локациях и счётчик свободных серверов обновляются автоматически. Сайты пересобираются по событию; если числа меняются часто — добавляем обновление из браузера ([D-032](../decisions/D-032-free-servers.md)).
|
||||
4. VPN-серверы не ведут журналов ([10-security.md](../10-security.md), раздел 6).
|
||||
|
||||
## 2. Обсудить при старте
|
||||
|
||||
Источник серверов и подключений, способ интеграции, как получать WG-конфиги mass по странам, обработка ошибок выдачи.
|
||||
@@ -0,0 +1,26 @@
|
||||
# Этап 3h. Публичный запуск
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Сайты и кабинеты работают на основных доменах и открыты для всех.
|
||||
|
||||
## 2. Входит
|
||||
|
||||
1. Prod под пользователем vx_prod: `.env`, команда выкладки с папками релизов и откатом ([02-architecture.md](../02-architecture.md), раздел 5), начальная миграция, первая выкладка, начальные данные prod, первый администратор, smoke-тесты.
|
||||
2. Бэкапы базы и media с проверкой восстановления.
|
||||
3. Финальная проверка переводов на 5 языках и непереведённых ключей; юридические тексты после юриста (Q-13).
|
||||
4. Проверка производительности (Lighthouse mobile ≥ 90) и доступности.
|
||||
5. Демо-оплата в prod — только с разрешённых IP ([D-027](../decisions/D-027-demo-payments.md)).
|
||||
6. Страница nginx на случай, когда приложение не отвечает.
|
||||
|
||||
## 3. Перед стартом
|
||||
|
||||
Root: R-11, по желанию R-15 и R-16. Решения: Q-13 (юрлицо), Q-14 (куда бэкапы), Q-18 (кто запускает выкладку).
|
||||
|
||||
## 4. Готово, когда
|
||||
|
||||
1. Основные домены работают по HTTPS, dev и prod разделены.
|
||||
2. Выкладка и откат отрепетированы.
|
||||
3. Восстановление из бэкапа проверено.
|
||||
@@ -1,26 +0,0 @@
|
||||
# Этап 4. Платёжные системы
|
||||
|
||||
Статус: не начат.
|
||||
|
||||
## 1. Входит
|
||||
|
||||
1. Адаптеры ([08-integrations.md](../08-integrations.md), раздел 7):
|
||||
a. Stripe: Payment Element, сохранение карты, автосписания на переменную сумму, возвраты, отвязка карты, вебхуки;
|
||||
b. RUB: процессинги для карт РФ — пополнения (провайдеров выбираем на старте, Q-12);
|
||||
c. криптовалюта — пополнения, экран счёта с адресом, суммой и таймером курса;
|
||||
d. ЮKassa — опционально, пополнения.
|
||||
2. Состояния оформления и пополнения: 3-D Secure, отказ, ожидание подтверждения сети.
|
||||
3. Повторы автосписаний ([04-billing.md](../04-billing.md), 6.1); возврат на карту (`refund` + `payout`).
|
||||
4. Тексты согласия на автосписания в оформлении заказа и в юридических документах.
|
||||
5. Настройка платёжных систем в админке: валюты, назначения, лимиты, тестовый или боевой режим. Если бренды получат разные аккаунты одного провайдера — Q-17.
|
||||
|
||||
## 2. Перед стартом
|
||||
|
||||
1. Root: R-14 — аккаунты провайдеров (сначала тестовые).
|
||||
2. Решения: Q-12; для боевого Stripe нужны данные юрлица (Q-13).
|
||||
|
||||
## 3. Готово, когда
|
||||
|
||||
1. Каждый адаптер в тестовом режиме проходит путь от оплаты до зачисления, включая повторную доставку вебхуков.
|
||||
2. Автопродление через Stripe работает на тестовых картах. Если карта требует 3-D Secure, пользователь получает письмо оплатить вручную.
|
||||
3. Возвраты на карту работают.
|
||||
@@ -0,0 +1,11 @@
|
||||
# Этап 4a. Звёзды Telegram
|
||||
|
||||
Статус: обсуждение при старте этапа.
|
||||
|
||||
## 1. Что известно
|
||||
|
||||
По правилам Telegram цифровые товары в ботах и MiniApp оплачиваются звёздами (Telegram Stars), за нарушения ботов блокируют ([08-integrations.md](../08-integrations.md), раздел 6). Варианты: звёзды, внешняя страница оплаты, покупки в Telegram только с баланса (Q-11).
|
||||
|
||||
## 2. Обсудить при старте
|
||||
|
||||
Курс звёзд к ценам тарифов, зачисление на баланс, возвраты.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Этап 4b. Западные эквайринги и криптовалюта
|
||||
|
||||
Статус: обсуждение при старте этапа.
|
||||
|
||||
## 1. Входит
|
||||
|
||||
1. Stripe, USD ([08-integrations.md](../08-integrations.md), раздел 7): Payment Element, сохранение карты, автосписания на переменную сумму, возвраты, отвязка карты, вебхуки.
|
||||
2. Криптовалюта — пополнения, экран счёта с адресом, суммой и таймером курса; провайдера выбираем на этапе.
|
||||
3. Состояния оформления и пополнения: 3-D Secure, отказ, ожидание подтверждения сети.
|
||||
4. Повторы автосписаний ([04-billing.md](../04-billing.md), раздел 6.1); возврат на карту (`refund` + `payout`).
|
||||
5. Тексты согласия на автосписания в оформлении заказа и в юридических документах.
|
||||
|
||||
## 2. Перед стартом
|
||||
|
||||
Root: R-14 — аккаунты провайдеров (сначала тестовые). Для боевого Stripe нужны данные юрлица (Q-13). Разные аккаунты одного провайдера для брендов — Q-17.
|
||||
|
||||
## 3. Готово, когда
|
||||
|
||||
1. Каждый адаптер в тестовом режиме проходит путь от оплаты до зачисления, включая повторную доставку вебхуков.
|
||||
2. Автопродление через Stripe работает на тестовых картах. Если карта требует 3-D Secure, пользователь получает письмо оплатить вручную.
|
||||
3. Возвраты на карту работают.
|
||||
@@ -1,13 +0,0 @@
|
||||
# Этап 5. Автоматизация выдачи ключей
|
||||
|
||||
Статус: обсуждение при старте этапа.
|
||||
|
||||
## 1. Что известно
|
||||
|
||||
1. По тарифу (страны, теги) подбирается свободный сервер, бэкенд возвращает подключения для ключа.
|
||||
2. Автоматика создаёт те же подключения, что на этапе 1 добавляет администратор ([D-020](../decisions/D-020-key-models.md)), и отключает их, когда ключ истекает.
|
||||
3. Наличие в локациях обновляется автоматически, сайты пересобираются по событию.
|
||||
|
||||
## 2. Обсудить при старте
|
||||
|
||||
Источник серверов и подключений, способ интеграции, как получать WG-конфиги mass по странам, обработка ошибок выдачи.
|
||||
Reference in new issue
Block a user