Дмитрий Ковальский

В приложение я бы не лез. Если приложение хостится под IIS, то в настройках приложения есть раздел "Перенаправление протокола HTTP".

По соображениям безопасности ваши реквизиты не нужны клиенту от слова "никак".
1) Вы подключаетесь к некому платежному сервису, сообщая ему реквизиты, на которые будут поступать деньги.
2) Вы направляете клиента в этот платежный сервис с нужными входными параметрами.
3) Клиент передает свои деньги платежному сервису.
4) Платежный сервис передает деньги вам, забрав свою долю.

На какой их этих шагов вы хотите засунуть свой номер карты или счета?

Звучит как гигантский чугунный велосипед. Можно называть как больше нравится - прогрессивный Jpeg, MVP или еще как-то.
Большой проект это over9000 маленьких и средних проектов.
По факту вам надо реализовать несколько бизнес-процессов(хоть с 1 начните. авторизация и 1 бизнес-процесс) и затем на базе имеющейся архитектуры наращивать функционал. Но забегая вперед скажу что примерно на 3-4 шаге вы споткнетесь о то что в имеющейся архитектуре новый функционал чужероден.

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

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

Касательно архитектуры - тащить репозиторий до уровня контроллера это уровень второй четверти первого класса.
В идеале у вас должен быть уровень bl который проверит пользователя, выдаст ему сессионную куку или еще какой признак авторизации и вернет результат своей работы. В случае успеха - перенаправить куда-нибудь.
Касательно хеширования - SHA512 и какой-нибудь алгоритм засолки повеселее(не надо просто лепить соль сбоку).
Касательно уровня, на котором будет считаться хеш - все зависит от алгоритма авторизации. В вашем случае пахнуло EF и видимо стоит считать хэш на уровне обращения к репозиторию.
Если будете использовать хранимки - придется тащить пароль не трогая до самой бд и считать хеш там. Иначе появится логика извлечения всей базы пользователей с последующим поиском нужного, который не факт что найдется

Я бы добавил решения в области Continius Integration.
Весьма удобно видеть что бранч сломан не только у вас, но и у всех + каким коммитом сломали.
Так же удобно автоматизировать процесс публикации как на предпром/пром, так и просто в тестовые контуры.

А зачем вам ввод данных на вашей стороне? можете объяснить ваш сценарий, требующий этой функциональности? Последний раз когда я изучал документацию по вводу платежных данных на своей стороне - поставщик услуг обязался проводить приемосдаточные испытания данного функционала. Требования? отсутствие клиентской логики(только валидация ввода), https-протокол.
Если вам нужен индивидуальный дизайн страницы ввода данных - вступайте в дискуссию с поставщиком услуг. Многие пойдут на встречу при определенных условиях.
Только вот учитывая стоимость сертификации и аудита по PCI DSS - удивляюсь почему вы здесь задаете подобные вопросы. У вас должен быть целый отдел технических спецов по данному вопросу.

www.ozon.ru/context/detail/id/4711416 Вот такая есть книжка. Вам нужно искать "антикварную" литературу по ASP.NET для версий .net 3.5-4(максимум).

protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&m... - 4 странички эти уже прочитали?из них 1 страничка обложки, а вторая пустая. Первые пункты - "Основание для разработки", "назначение разработки". На мой взгляд если вы не можете описать эти 2 пункта - вы не очень понимаете какую проблему вообще решаете, а соответственно написать конкретное тех.задание будет трудно

1)Это не XAML, а ASPX - иначе вы разрабатываете для WPF и вопрос задали не по тем тегам.
2)WebForms - отмирающая хрень, и если вы планируете зарабатывать на жизнь веб-разработкой под ASP.NET - изучайте MVC.
3)Ваш код в описанном виде вполне нормален, но у WebForms есть фича, с которой сейчас мало кто связываться хочет, а именно - жизненный цикл страницы. Внимание загадка - на каком этапе жизненного цикла вы вкрячили этот контрол? Есть вероятность что вы его вкрячили на этапе, когда страница считает что все Контролы уже полностью инициализированы и их осталось только отрисовать.
4) Ну и без кода вашего контрола что-либо судить тоже трудно.

У select есть атрибут name, а у его option-ов нет атрибута value. по PHP ничего сказать не могу - не знаю этого языка.

Хотите красиво ? Верстайте шаблон письма на HTML с подстановкой нужных переменных.

Я правильно понимаю что вы хотите текстовое поле в которое будет вбиваться запрос и он должен исполняться на сервере БД? Технически это грубейшая уязвимость. Поскольку это ваша "фича", то делайте на том языке и платформе, которую знаете. Если душа не лежит к PHP - есть и ASP.NET и Django и RoR. Разницы в принципах работы с данными между ними нет. Я как разработчик ASP.NET могу лишь заметить что из коробки платформа пытается выявить потенциально опасные запросы и ваш функционал не пройдет проверку - нужно будет разбираться с атрибутами и настройками приложения. А насчет пригодиться? Пригодиться может хороший программист. На какой платформе он работает - вторично. Могу лишь предложить пойти на сайт с вакансиями в вашем регионе и повбивать названия ASP.NET, PHP и прочее. Посмотреть уровень зарплат и кол-во самих вакансий. Заодно и требования увидите.