Станислав Ломадуров

1. Да (*), только не путайте покупки = e-commerce retail и именно переводы. В онлайне по реквизитам, напечатанным на карте, осуществляются покупки. Перевод денег с карты -- это другой сервис (Visa MoneyTransfer / MasterCard MoneySend).
2. Да (*), в теории, но на практике злоумышленника очень быстро заблокируют через несколько попыток.
3. Нет, везде по-разному.
4. Нет, с 1 января 2014 года - правила поменялись. У Вас есть сутки на то, чтобы заявить о мошеннической операции.
5. Нет, везде по-разному.
6. Нет, это порча карты -- собственности банка, не самая лучшая идея. Надо сначала просто узнать в своем банке, безо всяких умных слов, "можно ли совсем запретить по данной карте покупки в интернете", и все. Если можно -- заказываете эту услугу и через пару дней пробуете проверить. Если нет -- ну тогда как повезет.
7. Что значит "не предназначены"? Если можно, значит "предназначены". Просто Ваша безопасность - только в Ваших руках, в любом случае. Проявите инциативу, в конце концов, когда Вы заключаете договор на выпуск карты, можно все вопросы задать.
8. Скорее нет, но не все банки в России и мире надежно проверяют эти данные.
9. Да (*), но вопрос доверия к торговцу в мире вообще не решен, нигде и никак. Точно так же могут быть и поддельные банкоматы, и терминалы, да хоть целый поддельный физический офис банка.

С ссылками все печально. Адекватно раскрыть тему для потребителя в удобоваримом виде и объеме текста довольно сложно. Или же будут советы типа "используйте виртуальные карты, берегите свой ПК и смартфон от злых вирусов, проверяйте иконку HTTPS в браузере" и т.д.

php и javascript отлично подходят для решения этой задачи.

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

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

Для вертки Email уже говорили, что про блочную верстку вообще лучше забыть. Только табличная.

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

Заявления типа "Забудь о табличной верстке навсегда" - это не очень компетентное заявление.

еще пишут так

+function(){
    /*       */   
}();

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

Инструменты просты, переход на них — дело одного выходного дня, и может быть сопряжен со сложностями только в связи с новизной.

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

Вы не указали, какие конкретно инструменты для разработки Вы используете. Если же с деплоем все гораздо проще, то при выборе инструментов для тестирования я рекомендую Вам ориентироваться на те, которые нативны для Вашего основного фреймворка и языка (PHP, если правильно понимаю) и привычны их пользователям. Это позволит быстро применить устоявшиеся практики к Вашему проекту и понять всё на деле.

Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.