У нас разделено. Биллинг на одном сервере в одном ДЦ, тикетница на другом сервере в другом ДЦ, клиенты одной из локаций в одном из этих ДЦ, но в другом сегменте. Таким образом, даже если упадёт тикетница или ДЦ, где она расположена, останется возможность коммуникации через сервер с биллингом, и наоборот. Плюс у нас есть отдельный сайт для информирования о технических проблемах, который находится в третьем ДЦ.
Да там же телефоны покупают не из-за esim.99% людей даже не знают, что это.
У продавца спросите.
Смотря в скольких ДЦ компания размещает серверы и что это за компания) У кого-то свой ДЦ или большое присутствие только в одном ДЦ, такие обычно внутри него всё и держат. А если локаций много, то и риск падения сразу всего крайне минимальный.
В моём понимании у всех нормальных хостеров система биллинга, система тикетов и собственный сайт отделены от клиентских сайтов. Всё на одном размещают разве что мелкие, у которых нет нескольких серверов.
в какой момент все хостеры решили отказаться от телефонной поддержки (у меня впечатление, что я проспал этот день)
Это потеряло эффективность с развитием чатов и систем тикетов. Сейчас гораздо эффективнее оказывать поддержку через эти средства, чем тратить огромные деньги на оплату телефонии и человекочасов операторов. Но да, оффтоп уже)
Эти данные в основном не хранят магазины, их хранят эквайринговые системы (банки, агрегаторы и т.п.). Много ли мы знаем фактов кражи БД из таких систем? Вот магазины часто взламывают, но там лишь часть данных. В некоторых случаях магазин дейсвительно может иметь полный номер карты и даже реквизиты, но лишь в случае, если соответствует PCI DSS и сам передаёт данные карты экварийнгу для осуществления транзакции. Чтобы такое подключить, нужно пройти строгую проверку экваринга. Да и чтобы хранить такие чувствительные данные в открытом виде, надо иметь очень тупую команду разработчиков.
Ага. Юридически там всё составлено так, чтобы они могли подключать что угодно и списывать за это деньги, иначе бы не промышляли таким безнаказанно годами.
СБП можно привязать для авто-оплаты, там даже страшнее, ибо привязывается банковский счёт, а не карта, которую можно заблокировать в любой момент. Юмани тоже можно, если принимается через Юкассу. Но мало где такой функционал видел в действии.
И как тогда базы данных с картами регулярно воруют и у мелких и у крупных интернет-магазинов и продают на хакерских форумах а иногда и в паблик сливают?
Это все фейк и тоже клиенты сами виноваты?
Базы с картами не воруют, воруют базы с масками карт (первые 6 и последние 4 цифры), ФИО и т.п., что позволяет бандитам использовать эти данные для обмана путём обзвона и т.п. Полные данные карты не предоставляет магазинам даже обслуживающий их банк. Все реквизиты для автоматической оплаты сохраняет сам банк или платёжный агрегатор (а они все идут с сертификацией по стандарту PCI DSS, поэтому данные в открытом виде тоже не хранят).
Карта же сохранена в сервисе, а значит взломав аккаунт в сервисе кто-то в теории может что-то картой в рамках сервиса оплатить. Вот если бы оплатили картой вне сервиса, то уже были бы большие вопросы к безопасности данных.
Зависит от задачи, наверное. Я для себя другое решение нашёл: карты сохраняю, но все карты привязаны к счетам, куда деньги переводятся по мере необходимости. Это удобнее виртуалок с лимитами, которые ещё и надо не забыть подправить перед оплатой.
Так Руцентр всегда таким был и вряд ли его кто-то нормальной компанией считает. Но именно привязка карты у них не скрыта и явно видна.
Реквизиты карт нигде, хоть у мелких, хоть у крупных, не хранятся в открытом доступе и никто к ним доступа не имеет. Поэтому сама по себе кража баз ничем не поможет злоумышленнику, разве что если злоумышленник не сам сервис, где карта сохранена.
Коллега после того как картой опалтил им не их сайте начались списания ежемесясные.
Ну тут коллега тоже виноват, привязал карту оплачивая у любителей смошенничать. В форме оплаты сложно не заметить кнопку привязки.
JSC - форма собственности юр. лица. По идее нужно писать с ней, так как именно это юридически верное наименование посредника. Но по опыту это не так важно и важнее верно указанный SWIFT-код. Банк-отправитель сам к тому же может подправить при необходимости.
