Василий Банников

например для защиты от злоумышленников

Когда ты защищаешься от злоумышленников - нужно представлять, от какой конкретно угрозы ты хочешь защититься.

Сокрыть пути ты точно не сможешь - они всё равно будут все показаны в панели разработчика в браузере.
Также они всё равно будут видны в исходниках твоего приложения в браузере.

Иногда есть смысл сделать нечитаемое имя для роута, чтобы усложнить жизнь всяким системам для автоматического исследования API методами перебора, или чтобы сделать невозможным вызов какого-то метода клиентом, который не знает заранее какой-то секрет, но при этом нет возможности использовать Authorization заголовок или какой-то иной способ аутентификации.

Но это очень специфичные сценарии, которые крайне редко актуальны, их не нужно применять по принципу "на всякий случай".

Если ты не обрабатываешь персональные данные, то тогда никого уведомлять не нужно.
То что платёжный шлюз для чего-то берёт емеил - это его забота. (тем более что емеил не является ПД)

CORS умеет блокировать не только ответы, но и запросы, но только в случае "сложных" запросов.
(Например POST с Content-Type: application/json будет сложным)
А банк от csrf-уязвимостей должен защититься при помощи csrf-токенов.

https://habr.com/ru/companies/macloud/articles/553826/

В общем случа - нет.
swf-объекта и не будет.

Если это диплом, то просто сделай заглушку, чтобы платёж обрабатывался без реального платёжного шлюза.
Просто в тексте упомяни, что платёжный шлюз реализован, но в целях демонстрации используется заглушка.

По хорошему следует реально заложить архитектуру такую, чтобы можно было легко переключить на настоящую платежку

Нет никакой причины, почему нельзя было бы использовать Django для сайта клиники

Можно, но тогда тебе придётся пройти сертификацию PCI DSS и интегрироваться с банком-эквайером, который предусматривает такой сценарий. На какой конкретно уровень надо получать сертификат - не подскажу, зависит от количества транзакций, но начать можно отсюда:
https://www.nspk.ru/cards-mir/security/standart-pc...

https://habr.com/ru/companies/payonline/articles/1...

Невозможно

1. Юридическое лицо обязательно придется завести

2. Налоговая в любом случае увидит тут признаки дохода и ты будешь обязан взимать НДФЛ с исполнителей, как налоговый агент.
Вот и требование отчитываться в налоговую.
Вот тебе, получается, нужно узнавать полные данные и ИНН исполнителей.
Вот и закон о персональных данных кокетливо машет рукой, а РКН ждёт от тебя стопку бумаг о том, как ты с этими ПД работаешь и как защищаешь. Очень возможно, что придётся ещё потратиться, чтобы всем требованиям соответствовать.

3. А ещё тут очень легко можно попасть на отмывание денег. Возможно, для того что ты хочешь сделать, нужно ещё получать лицензию. Стоит проконсультироваться с юристом по поводу того, какой у тебя ОКВЭД тут будет.

4. Учитывая это - я хз как ты собираешься не получать с этого прибыль. Ибо только на то чтобы запустить такой сервис и чтобы он работал придется немало денег вложить и регулярно тратить.

Без юридического лица можно попробовать крипту, но тут тоже есть нюансы, начиная опять же с комиссий(говорят есть варианты с небольшой комиссией) и волатильности (по идее есть стейблкоины, но и они умеют обваливаться), заканчивая серым статусом, зато всего остального получится избежать.

У нас на проекте нагрузочное обязательно проводят перед каждым релизом как часть регрессионного тестирования.

Но у нас и соглашения с клиентами есть по скорости ответов, отсюда и необходимость проверять.

Думаю, если задать вопрос типа "а зачем в проекте нагрузочное тестирование", то тогда и по периодичности всё станет ясно.

Смотрим в тестах максимальную "прочность", сколько RPS можно держать без значительной деградации и стабильность - можем ли мы длительное время держать достаточно большую нагрузку (объем смотрим по пиковой нагрузке в проде)

+ к этому ещё и постоянный мониторинг времени ответа на проде.

Регресс, естественно, происходит в окружении близком к продовому.

+ ещё сейчас затащили нагрузочное тестирование в ci - там только смотрим, есть ли деградация по максимальной производительности. Там тестирования происходит уже в очень далёком от прода окружении, зато часто (на каждый MR)

Можно попробовать zxing - https://zxing-wasm-demo.deno.dev/
Умеет по картинке определять. Думаю, что склеить с камерой это будет не трудно.

Может быть и касперский, но фиг знает - попробуй у них и спросить, посмотри ещё с какого ip приходит запрос и кому он принадлежит.
Однозначно можно сказать только то что это какой-то бот.

Chatgpt4 умеет распознавать картинки, но дельных советов он не даст, так как нюансов очень много и нужно иметь контекст проекта, чтобы оценить качество.

Я буду очень удивлён, если ошибся

Доход приносит не сайт, а бизнес. Сайт - один из активов этого бизнеса.
Покупать соответственно нужно не "сайт", а юридическое лицо с конкретными активами.
(условно, если это какой-то сайт, который продаёт ключи от игр - надо сразу получать контакты на поставщика этих ключей и инструкции, как разгребать сбои и спорные ситуации, ибо без всего этого ты на тот же самый доход не выйдешь)
Далее уже смотреть на бухгалтерию и отчёты.

У сервиса оплаты, кроме гайдов, таки должна быть документация на api, через который его придётся интегрировать с сайтом.
Если она отсутствует - стоит посмотреть ещё раз внимательно, а потом, если реально нет, спросить в поддержке.