Comments 16
В соответствии с PCI DSS хранить CVC нельзя. Как работают платежи с
помощью сохранённой карты? Почему банкам не нужен CVC в этом случае?
Используется только номер карты, выставляются нужные флаги повторной авторизации и тогда CVC не нужен (вообще он и при первичной авторизации не особо обязателен, но высокий риск что банк отклонит авторизацию). Либо использовать родную токенизацию визы/мастеркард.
Сейчас мы интегрируемся с PSP, а PSP интегрируются с банками и
платёжными системами. «АПИшки» PSP — зоопарк, у всех всё по разному и
редко сделано хорошо. А насколько API банков лучше? Есть ли какие-то
банковские стандарты по разработке API и насколько банки их
придерживаются?
Очень странный вопрос для человека, который 7 лет в платежах - ISO 8583 (https://en.wikipedia.org/wiki/ISO_8583). Но у каждого экваера могут быть свои ньюансы использования.
Помимо интеграций с банками нужно ли будет ещё интегрироваться и с платёжными системами VISA/MC/НСПК?
Нужно получить Merchant ID.
Спасибо за ответы. Вообще, я про исо знаю, но пока не приходилось поработать с апи сделанным по исо. Отсюда и все эти вопросы :-)
Протокол старый и страшный, но библиотеки под него должны быть чтобы не писать реализацию с нуля.
Докину ещё мыслей.
Можно ли получить выигрыш в комиссии эквайринга или всё наоборот? Кажется, что если в цепочке оплаты мерчант → PSP → банк-эквайер пропадает звено PSP, то комиссия должна быть ниже, но, с другой стороны, PSP — крупные клиенты банков и, возможно, банки дают им максимально низкую комиссию, настолько, что комиссии при интеграции напрямую могут оказаться выше. Как на самом деле?
Это в первую очередь зависит от умения договариваться. Ну и конечно объемы. Можно найти выходящего на рынок игрока который демпингует.
Ещё важно, что во многих странах местный экваер будет давать больший процент апрувнутых авторизаций, тогда даже учитывая более высокий процент это может быть выгоднее. А где-то вообще картами почти не платят, а работают местные платежные системы.
Так что на глобальном рынке очень важно иметь гибкий "роутинг" настраиваемый бизнес-правилами и проводить много экспериментов.
Вроде бы у Тинька была схема, когда оплаты автоматически могут распределяться по разным компаниям в зависимости от условий. Как раз для агентов по сути)
А с СБП есть еще неочевидный, но, на мой взгляд, крайне неудобный момент, что деньги сразу зачисляются на расчетный счет компании и там же сразу списывается комиссия. Потом статистику не очень удобно по платежам сводить, так как приход от эквайера не совпадает с фактическим оборотом по отчету.
Я правильно понимаю, что к вашему токенизатору (CST) фронтенд так же обращается напрямую из браузера ?
По итогу, заказ с сайта 3 дня назад. Пиццу не привезли, не смогли определить адрес хоть он и был указан, «отменили» заказ, деньги не вернулись, результат после оплаты редиректит на апиху а не страницу заказа.
Одна из проблем, которые создаёт CSE, — то, что в скоуп PCI DSS попадает платёжный шлюз целиком, то есть все его компоненты. Т.е. компоненты обрабатывают данные карт и к ним применяются повышенные требования безопасности и требуется проводить и проходить их аудит. А попадают они туда, потому что криптограммы — это хоть и зашифрованные, но всё равно данные карт.
Исходя из документов и обсуждений пришёл к выводу, что зашифрованные данные карты можно прокидывать вне контура PCI DSS. По сути, они ведь не отличаются от токена для внешнего наблюдателя.
Аудиторы придираются и говорят, что к криптограммам нужно относиться как к данным карты :-)
Возможно, из-за рисков утечки приватного ключа у провайдера, например, но там странная история, ведь в этом случае данные и так будут скомпрометированы. Я не сильно погружен в обсуждение этого вопроса, но думаю, что можно поспорить с аудиторами на этот счет, ну, или хотя бы уточнить причину :-)
Стандарт имеет несколько уровней и обычный вариант, это когда сайт сертифицируется на основании того, что данных карты он не получает, а шлюз по системе защиты этих данных. Чтоб прокинуть зашифрованные данные нужно поднимать уровень защиты данных на сайте, что сильно усложнит сертификацию. С точки зрения большинства аудиторов, зашифрованные данные - всё равно риск. Вот для этого и придумали всякие STT/LTT и прочие токены. Таким образом сайт не получает данных карты. Альтернатива - односторонняя трансформация типа хэша.
Мы у себя используем прокси-сервис VGS (verygoodsecurity), который даёт нам нужный уровень pci dss, и мы именно через него шлём данные карт в платёжки, и через него же токенизируем карты. Получается, что это универсальное хранилище карт, из которого можно наружу в любую платёжку отправить данные.
Интересный материал, спасибо!
Есть разница между стандартами pci-dss и pa-dss. Шлюз в PА, а сайт надо исключить из этого контура. В крайнем случае свезти под более широкий и гибкий pci-dss. PCI аудиторы верифицируют систему в общем, а не конкретный модуль или шлюз. То есть если вы докажете, что данные карты никогда не попадают на сайт, то и не надо его сертифицировать от версии к версии. Поэтому то платёжные сервисы и предлагают iframe или redirect, чтоб их сайт-клиент никак не участвовал в передачи платёжных данных.
Если данные карты на сайте всё таки есть, то хороший аудитор будет сканировать логи и делать крашдампы памяти, чтоб убедиться, что даже в этих местах нет треков и номеров. И делать это будут раз или два в год. Хотя, конечно, зависит от места. Я работал в европах.
Зашифрованные данные - риск. Если данные можно расшифровать - значит это возможно сделают в будущем. Карты живут от 5 до 10 лет и шанс, что вашу криптографии вынесут через Х лет - вполне не иллюзорный. И помимо этого надо будет еще доказать, что даже зашифрованные данные имеют инвалидацию. То есть этот зашифрованный номер нельзя повторно использовать на ваших же сервисах или при разрыве сессии и тд. Там тоже много edge case есть.
Как устроены интернет-платежи в Dodо