3DS clarifications

src/en/clean-copy/02-Section I. The API Design/05.md

@@ -988,6 +988,8 @@ With the API popularity growth, it will inevitably become necessary to introduce
 
 You are not obliged to actually generate those exceptions, but you might stipulate this possibility in the terms of service. For example, you might describe the `429 Too Many Requests` error or captcha redirect, but implement the functionality when it's actually needed.
 
+It is extremely important to leave a room for multi-factored authentication (such as TOTP, SMS, or 3D-secure-like technologies) in case it's possible to make payments through the API. In this case, it's a must have from the very beginning.
+
 ##### No results is a result
 
 If a server processed a request correctly and no exceptional situation occurred — there must be no error. Regretfully, an antipattern is widespread — of throwing errors when zero results are found.

src/en/drafts/04-Section III. The API Product/09.md

@@ -1,3 +1,5 @@
-### IT-Security
+### Technical Means of 
 
-As we have mentioned several times, API serves as a multiplier to *any* possibility, including illegal ones: severabl
+As we have mentioned several times, API serves as a multiplier to *any* possibility, including illegal ones: having a severe API vulnerability means that *every* client application is vulnerable, and that is a much greater threat level than a security flaw in a single service. So the informational security of the API service must be of the highest possible priority.
+
+Every contemporary IT service under the hood uses the internal APIs that are usually a main target of cybercriminals. In that sense, the sets of attack vectors against a public API and against an internal API of some service are almost identical. We won't be discussing there 

src/ru/clean-copy/02-Раздел I. Проектирование API/05.md

@@ -982,6 +982,8 @@ POST /v1/orders
 
 Вы не обязаны с самого начала такие ошибки действительно генерировать — но вы можете предусмотреть их на будущее. Например, вы можете описать ошибку `429 Too Many Requests` или редирект на показ капчи, но не имплементировать возврат таких ответов, пока не возникнет такая необходимость.
 
+Отдельно необходимо уточнить, что в тех случаях, когда через API можно совершать платежи, ввод дополнительных факторов аутентификации пользователя (через TOTP, SMS или технологии типа 3D-Secure) должен быть предусмотрен обязательно.
+
 ##### Отсутствие результата — тоже результат
 
 Если сервер корректно обработал вопрос и никакой внештатной ситуации не возникло — следовательно, это не ошибка. К сожалению, весьма распространён антипаттерн, когда отсутствие результата считается ошибкой.

src/ru/drafts/04-Раздел III. API как продукт/09.md

@@ -4,6 +4,8 @@
 
 В случае сервисов для конечных пользователей мы могли бы показать капчу; но в случае API это весьма проблематично, особенно если вы пренебрегли советом [«Предусмотрите ограничения»](#chapter-11-paragraph-19). Если полная отработка сценария (идентификация пользователя — показ капчи или honeypot-а — пометка результатов прохождения теста) на вашем уровне невозможна или не была предусмотрена, вам придётся переложить её на партнёра (т.е. это партнёр должен будет показывать капчу и идентифицировать пользователя, основываясь на сигналах, поступающих от эндпойнтов API) что, конечно, сильно снижает комфортность работы с таким API.
 
+**NB**. Вместо капчи здесь могут быть любые другие действия, вводящие дополнительные факторы аутентификации. Это может быть, например, подтверждение номера телефона или второй шаг протокола 3D-Secure. Важно здесь то, что запрос второго шага аутентификации должен быть предусмотрен в API, поскольку добавить его его обратно совместимым образом нельзя.
+
 Другой способ борьбы с роботами — это попытка идентифицировать среду атаки. Программная оболочка, через которую выполняются запросы, не идентична реальному пользовательскому устройству, и этот факт можно попытаться определить — особенно это касается веб-страниц, которые часто обрабатываются не эмулятором браузера, а каким-то фреймворком, который будет не способен, например, исполнять JavaScript или не поддерживает последние дополнения к WebAPI браузеров.
 
 Немаловажен и вопрос, а что вы будете делать, если вы всё же смогли идентифицировать злонамеренного пользователя, но не можете сделать так, чтобы он прекратил слать запросы. В какой-то момент придётся прибегнуть к одной из двух стратегий: