pci pts что такое

В чем различия между A98 и C98 в POS-терминалах Ingenico iCT220/250

Или как избежать несовместимость пин-пада и POS-терминала

Прежде чем ответить на вопрос: чем отличаются терминалы Ingenico iCT220/250 A98 и C98? мы проведем небольшой ликбез на тему стандартов безопасности, которые предъявляются к платежным технологиям.

PCI SSC

Существует глобальная открытая формация, которая называется «Совет по стандартам безопасности индустрии платежных карт» (PCI SSC). Основной миссией которого является развитие, расширение и распространение стандартов безопасности в индустрии платёжных карт. В данный совет входят:

Совет возглавляют члены «Исполнительного комитета», состоящего из представителей всех пяти мировых платёжных брендов.

Общими усилиями всех вышеперечисленных организаций был разработан «Стандарт безопасности данных индустрии платёжных карт» — PCI DSS.

Данный стандарт включает в себя ряд технических требований, а если быть точнее, то их всего 12, для программ обеспечения безопасности данных о держателях платёжных карт.

Стандарт безопасности PCI PTS

Мы не будем рассматривать все 12 требований, иначе статья получится слишком большой. В данном случае нас интересует только один стандарт безопасности — PCI PTS.

Стандарт PCI PTS регламентирует требования к безопасности для устройств ввода PIN кода:

Версии PCI PTS

PCI PTS на сегодняшний день имеет несколько версий — v1, v2, v3.

И здесь мы вплотную приблизились к ответу на наш главный вопрос, озвученный в самом начале статьи.

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

A98 и C98 в POS-терминалах Ingenico

Данные обозначения скрывают за собой версии стандарта безопасности PCI PTS, а так же версии ключей шифрования низкого уровня PKI (Private Key Infrastructure), загружаемых в терминал в процессе прошивки.

POS-терминалы Ingenico iCT220/250 A98 соответствуют требованиям стандарта PCI PTS v2. Ключи шифрования загружаются PKI v1.

POS-терминалы Ingenico iCT220/250 C98 соответствуют требованиям стандарта PCI PTS v3. Ключи шифрования загружаются PKI v3.

Как определить, какая версия: A98 или C98?

Как определить версию PCI PTS в пин-паде Ingenico iPP220?

Важно!
Если вы планируете использовать POS-терминал Ingenico iCT220/250 с выносной клавиатурой пин-пад Ingenico iPP220, то необходимо помнить, что комплект должен быть одной версии стандарта PCI PTS- либо v2 либо v3. Если вы подключите пин-пад версии стандарта PCI PTS v2 к терминалу версии стандарта PCI PTS v3, то пин-пад не будет работать. На экране терминала вы увидите сообщение — INCOMPATIBLE PINPAD.

P.S. Статья написана по материалам сайта bankomatchik.ru.

На этом все. Спасибо за внимание. Успехов в вашем бизнесе!

Источник

Мобильные платежные технологии и требования по безопасности PCI SSC

Мобильные платежные технологии и требования по безопасности PCI SSC

Мобильные платежные технологии и требования по безопасности PCI SSC

Что такое mPOS

Мобильное платежное решение (mPOS) состоит из следующих основных компонентов:

Под мобильным платежным решением будем понимать программно-аппаратную платформу для торгово-сервисных предприятий (далее – ТСП), позволяющую принимать платежи от физических лиц посредством смартфона/планшета и подключенного к нему считывающего устройства. Посредством mPOS возможно принимать оплату как бесконтактным способом (банковской картой, загруженной в мобильный телефон клиента с поддержкой NFC (далее – NFC-карта), или бесконтактной банковской картой), так и по обычным пластиковым картам (с магнитной полосой и/или EMV-чипом).

Кроме функций защищенного чтения карты и ввода PIN-кода у mPOS должна быть поддержка всех основных способов верификации владельца карты, шифрования данных при передаче между компонентами и процессинговой частью системы, а также возможность печати чеков или их отправки по SMS и электронной почте.

На стороне сервис-провайдера или банка-эквайера, которые занимаются приемом и дальнейшей обработкой данных при mPOS-платежах, используется back-end система (платежный шлюз), схожая с теми, что используются при интернет- или обычном POS-эквайринге.

Для того, чтобы понять, какие требования по безопасности должны предъявляться, на техническом уровне необходимо определить основные компоненты экосистемы mPOS и существующие информационные потоки. Для понимания ответственности субъектов экосистемы mPOS за безопасность платежей на бизнес-уровне необходимо определить существующие бизнес-модели участников платежного процесса.

Схема информационных потоков содержит 8 основных этапов (см. рис. 1):

В реализации описанного выше процесса могут участвовать следующие компании:

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

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

Виды сертификации

Первые рекомендации по безопасности мобильных платежных решений были выпущены Visa в 2011 г. В них содержались общие рекомендации для разработчиков и ТСП в части безопасности использования мобильных платежных решений. В 2012 г. Советом PCI SSC были выпущены более детальные рекомендации для разработчиков. На сегодняшний день МПС и PCI SSC почти каждый год выпускают обновленные рекомендации по безопасности mPOS.

Кроме рекомендаций Visa и MasterCard разработали программы сертификации поставщиков мобильных платежных решений. По сути, обе программы достаточно похожи, и с большой вероятностью можно утверждать, что разработка решения согласно требованиям одной из МПС может быть сертифицирована у другой. Обе МПС ведут реестры сертифицированных компаний и mPOS-решений.

Далее будут описаны особенности применения каждого из стандартов PCI SSC к mPOS-решениям.

Стандарты PCI SSC

PCI DSS
В новой версии стандарта появились новые требования, которые как нельзя кстати относятся к безопасности mPOS. В частности, в разделе 9 добавился пункт 9.9, согласно которому необходимо вести учет устройств считывания карт, а также проводить периодическое обучение сотрудников/пользователей, обслуживающих устройства, для того чтобы они умели определять подмену mPOS или иные признаки скимминга. В случае с сервис-провайдерами mPOS-решений или эквайрингами при предоставлении клиентам считывающих устройств они должны будут разработать рекомендации и инструкции по защите от скимминга и довести их до сведения сотрудников ТСП. В рамках выполнения требования 12.8 сервис-провайдеры и эквайеры на уровне договорных отношений могут обязать ТСП выполнять соответствующие требования по безопасности mPOS.

Требование 12.8 также актуально для тех случаев, когда ПО mPOS-решений для сервис-провайдера разрабатывается сторонней организацией. В этом случае выполнение требования 6.5 полностью ложится на плечи компании-разработчика. При этом если компания-разработчик не будет выполнять требования, сервис-провайдер не сможет пройти аудит на соответствие PCI DSS. В договорах между сервис-провайдерами (эквайерами) и разработчиками следует предусмотреть вопрос проведения аудита определенных бизнес-процессов компании-разработчика в случае прохождения сервис-провайдером ежегодной сертификации по PCI DSS, т.к. процесс разработки будет включен в область аудита сервис-провайдера. То же актуально и в случае аутсорсинга иных услуг. В общем случае подтверждение третьей стороной соответствия требованиям PCI DSS в части, ее касающейся, может быть обеспечено путем самостоятельной сертификации по PCI DSS необходимых бизнес-процессов с последующим предоставлением свидетельств об успешно пройденой проверке либо путем предоставления возможности аудита бизнес-процесса в рамках аудита сервис-провайдера (эквайера).

Отметим, что в нашей стране аудит разработчиков в рамках аудита компании-заказчика происходит довольно редко. Разработчики на словах могут гарантировать знание и применение методов безопасной разработки, но по факту не владеть нужными знаниями и не выполнять соответствующих процедур. С выходом новой версии PCI DSS положение вещей должно измениться, так как требования стали детальными, и указанные в тексте стандарта проверочные процедуры обязывают QSA-аудитора проводить более глубокие проверки.

PCI PTS
Стандарт PCI PTS регламентирует требования к безопасности для Point of interaction devices (POI) и Hardware Security Modules (HSM). Считывающее устройство, подключаемое к мобильному устройству, является POI. Как упоминалось выше, в mPOS-решениях используется два класса POI: PIN Entry Device (PED) и Secure Card Reader (SCR). В зависимости от того, к POI какого типа относится считывающее устройство, определяются группы требований PCI PTS, которым устройство должно соответствовать.

В настоящий момент в некоторых предлагаемых на отечественном рынке mPOS-решениях используются считыватели no-name-производителей. Использование таких считывателей не гарантирует безопасной передачи данных между устройствами и делает возможным передачу в мобильное устройство номера карты в открытом виде. Поэтому, выбирая mPOS-решение, необходимо убедиться, что сервис-провайдер предлагает сертифицированное по PCI PTS считывающее устройство.

PA-DSS
Для mPOS-решений PA-DSS в обязательном порядке применим к прошивкам устройств, считывающим карточные данные. Для программного обеспечения, устанавливаемого на мобильное устройство сотрудника ТСП, данный стандарт является рекомендательным. Это связано с тем, что мобильное устройство является недоверенной и слабоконтролируемой средой. Например, на устройстве может быть выполнен jailbreak, который на порядок снижает безопасность устройства и не гарантирует безопасности установленного платежного приложения. Именно поэтому МПС запрещают использовать мобильные устройства для ввода PIN-кода и требуют, чтобы данные от считывающего устройства приходили в мобильное ПО в зашифрованном виде и далее в том же виде передавались в эквайринг. В этом случае данные платежных карт не будут в открытом виде обрабатываться и храниться в мобильном устройстве, а значит, и требования PA-DSS не применимы.

В версии 3.0 стандарта появились новые требования, на которые разработчикам прошивок для считывающих устройств и коробочных платежных приложений следует обратить внимание в первую очередь. Во-первых, каждое выпускаемое обновление должно проходить отдельную сертификацию. Во-вторых, теперь клиенты должны использовать только те версии (обновления) ПО, которые являются сертифицированными и приведены на сайте Совета PCI.

PCI P2PE
Сравнительно недавно вышел в свет новый стандарт безопасности PCI P2PE. Стандарт предназначен для решений, обеспечивающих криптографическую защиту данных при их передаче между всеми компонентами платежного решения. В случае применения шифрования достигается сужение области действия стандарта в ТСП до минимального уровня, так как у ТСП нет возможности получения данных о держателях карт в открытом виде.

В перечень всех основных компонентов экосистемы mPOS входит:

В отличие от PCI DSS, который распространяется только на информационную инфраструктуру, PCI P2PE является более комплексным и распространяется не только на инфраструктуру, но и на считывающие устройства и программное обеспечение POI-терминалов (в приложении к mPOS – это считывающие устройства). Стандарт состоит из 6 доменов, требования которых основаны на действующих стандартах PCI: считывающие устройства должны удовлетворять требованиям PCI PTS SRED; программное обеспечение считывающих устройств – PA-DSS; управление ключами шифрования – PCI PIN Security Requirements; платежная информационная инфраструктура ТСП – PCI DSS. Если решение сертифицировано по PCI P2PE, это значит, что данные между всеми подсистемами (от считывателя к мобильному устройству в ПО, от ПО в процессинг и далее) передаются в шифрованном виде, и все подсистемы выполняют требования соответствующих стандартов PCI.

По требованиям P2PE могут быть сертифицированы как отдельные компоненты, так и готовые решения.

МПС рекомендуют использовать P2PE-решения для приема mPOS-платежей. Однако сложность состоит в том, что на текущий момент на рынке существует немного решений подобного типа, поэтому МПС не требуют, а рекомендуют использовать PCI P2PE-решения и при разработке руководствоваться ими. Тем не менее, сервис-провайдерам платежного mPOS-решения нужно быть готовыми к тому, что МПС в скором времени будут требовать обязательной сертификации их mPOS-решений по требованиям PCI P2PE.

Источник

PCI DSS – как и зачем получать сертификат соответствия

Привет, %username%!
Этот пост мы подготовили для тех, кто работает в сфере интернет-коммерции и планирует принимать (или уже принимает) платежи на собственном сайте. Мы расскажем о международном стандарте безопасности данных PCI DSS. Поговорим о его основных требованиях к информационной инфраструктуре, которая обеспечивает обработку и обеспечение безопасности данных банковских карт. Также мы рассмотрим основные причины прохождения сертификации и возможности, которые получает сертифицированная компания.

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS.

Но самостоятельная работа с банками дает компании не только преимущество в адаптации платежной системы «под себя». Она обязывает компанию взять на себя борьбу с мошенническими операциями при обработке данных банковских карт на своем сайте. Иными словами, компании необходимо построить собственную систему мониторинга и борьбы с мошенническими операциями (анти-фрод). Задача анти-фрод системы – фильтрация операций, определяемых как мошеннические, по ряду признаков (например, несовпадение банка-эмитента со страной оплаты или проживания плательщика).

На стадии построения и отладки анти-фрод системы много времени «съест» сбор и анализ данных об операциях по банковским картам. Цель сбора данных – выявление отличительных признаков мошеннических операций. В процессе сбора статистики компании придется столкнуться с большим объемом «charge-back» операций.

Построение собственной анти-фрод системы логично и финансово обосновано для компаний с большим оборотом платежей по банковским картам. Для таких компаний гибкость и полный контроль над системой фильтрации платежей являются критически важными. Плюс, у такой компании есть возможность выделить ресурсы на разработку и постоянное развитие технологий и инструментов собственного “мини процессингового центра”.

Стоит отметить, что в мониторинге рисков сложно найти лучшего поставщика услуг, чем процессинговый центр. Благодаря разнообразию и значительному количеству клиентов, ПЦ обладает обширной историей мониторинга и фильтрации. Даже если компания занимается построением собственной анти-фрод системы, она может отдавать на обработку в ПЦ транзакции, вызывающие сомнения у внутренних специалистов по рискам.

Для принятия взвешенного решения о выборе способа обработки данных банковских карт, необходимо оценивать все составляющие процесса от подачи документов до поддержки кардхолдеров. Для того чтобы принять решение было проще, мы провели сравнение двух основных подходов по приему и обработке данных банковских карт: если ввод данных осуществляется на стороннем сайте (например, ПЦ) – и если данные вводят на сайте предприятия с последующей авторизацией платежа в банке.

Таким образом, если компания собирается пройти сертификацию на соответствие PCI DSS и самостоятельно обрабатывать данные банковских карт на сайте, к ней применяются все требования стандарта PCI DSS. Они охватывают безопасность на уровне сетей, оборудования, приложений, баз данных, физических хранилищ, документирования и управления процессами. И, как уже говорилось выше, построение анти-фрод системы и биллинговой системы, задача непростая и длительная в реализации, также выполняется компанией самостоятельно.

К компаниям, работающим только с платёжным шлюзом и не принимающих на своем данных банковских карт клиентов, относятся только требования департамента рисков платежного шлюза (ПЦ). Они касаются сайта предприятия e-commerce, корректности контента и ценовых предложений, организационной формы компании.

Если после прочтения этого поста у Вас появились вопросы – пишите в комментарии. Со стороны аудитора и специалиста по требованиям стандарта PCI DSS Вас проконсультирует Евгений Безгодов aka Bezgodov, исполнительный директор компании Deiteriy, CISA, PCI QSA. Со стороны платежного шлюза как всегда на связи специалисты процессингового центра PayOnline.

Источник

Что такое PCI DSS и как происходит проверка на соответствие стандарту?

В конце 2015 года система электронных платежей PayOnline уже в восьмой раз доказала, что мерчанты и плательщики находятся под надежной защитой. А в мае 2016 года компания получила физический сертификат соответствия требованиям стандарта PCI DSS версии 3.1, подтверждающий высший мировой уровень безопасности.

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

Если попробовать забить аббревиатуру PCI DSS в Google или поискать по ней на Хабре, то можно обнаружить достаточно много статей, описывающих этот стандарт. Тут же выяснится, что целевой аудиторией всех этих материалов будут те, кто так или иначе связан с электронной коммерцией. Главным образом это платёжные агрегаторы и процессинговые центры, а уже потом разработчики интернет-магазинов.

Любой вид электронной коммерции так или иначе основан на том, что покупатели, желающие приобрести товар, должны будут расплатиться за него. Несмотря на то, что возможность расплатиться архаичным способом (отдать деньги курьеру при встрече) наиболее популярна в России, есть большая вероятность, что покупатель предпочтет воспользоваться своей платёжной картой. Тут разработчикам магазина придётся иметь дело с такой деликатной материей как личные данные пользователей, которые ещё и связаны с их финансами. Вряд ли кто-то из клиентов магазина захочет, чтобы все это стало достоянием общественности, поэтому здесь приходится прибегать к продуманным и многократно проверенным решениям.

Создание целого интернет-магазина с нуля — мягко говоря, задача непростая. Поэтому на рынке довольно много фреймворков, помогающих разработчикам с этим (у всех на слуху Magento, к примеру). Задачу приема платежей, как одну из самых важных, потому что она связана с деньгами, включают в себя все решения для электронной коммерции. Разработчики, имевшие с этим дело, знают, что это достаточно простая последовательность шагов, которая часто выглядит как «качаем код библиотеки для платёжного шлюза XYZ», «настраиваем его» (все обычно сводится к получению и использованию специального ключа, позволяющего шлюзу понять с каким магазином он имеет дело), «немного допиливаем» и «выгружаем на продакшн».

Как правило, это не вызывает существенных проблем. Правда, после того, как пользователь вашего магазина перешел на страницу оплаты выбранного платежного шлюза, ввел данные своей платежной карты и нажал на кнопку «Оплатить», вмешаться в процесс уже не получится — разве только обработать ответ шлюза на своей стороне и показать пользователю красивую страничку с благодарностью (если всё прошло нормально) или извиниться (если что-то пошло не так).

Квалифицированный пользователь знает, к примеру, что https лучше http и проверяет это, многие браузеры будут показывать в адресной строке данные сертификата сайта. Однако когда платёжный шлюз начнёт свои «внутренние» транзакции с банком-эмитентом (тот, который выдал карту) и с банком-эквайером (тот, который должен получить оплату), то может возникнуть вполне закономерный вопрос — а насколько это всё вообще безопасно? Ведь передача данных по протоколу https — еще не гарантия безопасности, а лишь один из сотен параметров, обеспечивающих защиту информации.

Может быть ребята из этого шлюза и смогли настроить себе https, купили сертификат и даже большими буквами написали на своём сайте, что всё очень хорошо и всё очень защищено. Но единственным по-настоящему надёжным способом убедиться в этом является выполнение каких-то процедур, удостоверяющих безопасность внутреннего кода платежного шлюза. И, конечно, желательно, чтобы пройти такую проверку было бы сложнее, чем написать на своём сайте немного красивого HTML — «100% гарантия безопасности».

Мы опишем такую процедуру и попробуем понять, почему она является стандартом в индустрии электронной коммерции. Всё это будет скрываться под аббревиатурой PCI DSS, и именно наличие этого сертификата у платёжного шлюза вполне может означать, что данные платёжной карты (да что там, проще говоря, деньги плательщика) дойдут до адресата без проблем.

Что такое PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Другими словами, это документация со списком критериев, которому должен удовлетворять сервис, если он как-то управляет такими вещами, как номер карты, срок её действия и CVV-код.

Платёжных карт можно насчитать довольно много (все знают Visa и MasterCard), а поскольку речь идёт о стандарте индустрии, то было бы нелишним всем компаниям договориться между собой о том, что они будут считать безопасным. Для этого существует Совет PCI SSC (Payment Card Industry Security Standards Council) — Совет по стандартам безопасности индустрии платежных карт, образованный пятью крупнейшими платёжными системами. Именно он создаёт правила «безопасной игры», и именно его правилам должны следовать компании, желающие получить заветный шильдик «Сертифицировано PCI-DSS». Проходить сертификацию необходимо каждый год.

Что именно проверяют?

На самом деле описать все критерии проверки будет сложно — их 288. Сама процедура довольно длительная, потому что затрагивает проверку ряда сложных технических моментов. Полностью список критериев, разбитый на 12 групп, выглядит следующим образом:

Сам программный код библиотек проверяется выборочно, наибольшее внимание уделяют ядру, непосредственно обрабатывающему данные платёжных карт, при этом внимание обращают на соответствие внешнему стандарту безопасности OWASP, который описывает основные требования к поиску и исключению в коде уязвимостей. Также в бизнес-процессе разработки присутствует звено Code Review, на котором, собственно, проходит дополнительная проверка другим разработчиком, не участвующим в самом написании кода.

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

Сами серверы, так же как и все остальные компоненты инфраструктуры, например, сетевое оборудование, также подлежат обязательной проверке. Основным требованием здесь является актуальность статуса PCI-DSS, который ставится в прямую зависимость от частоты изменений программного обеспечения, конфигураций оборудования или/и виртуальных машин и, что не менее важно, от ставших известными уязвимостей, таких как печально известный HeartBleed. Администраторы инфраструктуры обязаны проводить аудит системы на предмет поиска внутренних/внешних уязвимостей и приводить компоненты инфраструктуры в соответствие стандарту PCI DSS.

Аудит безопасности выполняется дважды. Первый раз используется автоматический сканер на известные уязвимости, который предоставляет сертифицированная организация ASV (Approved Scanning Vendor). В случае успешного прохождения этого теста, система проверяется на безопасность второй раз экспертами, что называется, вручную, с вынесением официального заключения.

Возможные трудности

Здесь хотелось бы привести пример из личного опыта. Во время последней сертификации PCI-DSS наши специалисты организовали специальную службу мониторинга, которая следила за тем, чтобы транзакции между нашим дата-центром и банками выполнялись непрерывно. Источником потенциальных проблем было то, что некоторые банки сообщают о том, что их сертификат TLS 1.0 был обновлён до версии 1.2 уже постфактум. Потенциально могло произойти так, что мы пытаемся общаться с банком, имея старый сертификат, тогда как на их стороне он уже обновлён. Благодаря тому, что теперь у нас отдельная служба мониторинга непрерывности транзакций, такая проблема больше невозможна.

Вообще можно привести несколько примеров, как работает проверка, и как мы приводили нашу инфраструктуру в соответствие с требованиями. Как известно, согласно PCI-DSS, платёжная система не должна хранить у себя так называемые Критичные аутентификационные данные (КАД), к которым относят, к примеру, CVV или PIN-код (последний обычно поступает из POS-терминалов супермаркетов). Реализовано это таким образом:

Когда транзакция получает от процессингового центра специальный статус, говорящий о том, что она завершена (независимо от того успешно или нет), то в системе инициируется специальный программный код, решающий две задачи. Если во время транзакции по какой-либо причине её данные были записаны на диск, то специальная операция, удаляющая эту запись, получает максимальный приоритет и выполняется специальным воркером. Если обращения к диску не было, то всё еще проще: процесс транзакции удаляется из памяти сервера и таким образом фиксации КАД не происходит. Единственные данные, которые можно хранить — это номер карты PAN (Primary Account Number), и то исключительно в зашифрованном виде.

Еще один пример напрямую связан с одним из наших пользователей (хотя на самом деле таких историй много, просто эта последняя по времени), который покупал товар в интернет-магазине. После того, как что-то «пошло не так», он не стал читать достаточно подробные сообщения об ошибке, а просто сфотографировал свою платёжную карту с обеих сторон (наверно, потому, что в форме платежа ему объяснили, что надо вводить три последние цифры после магнитной полосы на оборотной стороне) и прислал её нам в службу поддержки. По мнению покупателя, это должно было помочь нам выяснить статус его платежа — «снялись деньги» или нет. Надо сказать, что даже такие курьёзные и одновременно печальные случаи оговорены стандартом PCI-DSS.

В случае компрометации данных пользователя платёжная система обязана уведомить его самого и банк-эмитент, выпустивший «засвеченную» карту. Кроме того, необходимо было удалить письмо с вложениями-картинками из клиентской почтовой программы оператора службы поддержки, а также на почтовом сервере. Всё это делалось для того, чтобы следовать золотому правилу обеспечения безопасности индустрии платёжных карт — «Если тебе не нужна эта информация, то не храни её».

Интеграция PayOnline с интернет-магазином

Как уже упоминалось выше, задачу интеграции конкретного интернет-магазина с платёжной системой вряд ли можно назвать сложной. В интернете можно найти множество примеров для многих шлюзов. Всё обычно сводится к установке на сервер специально написанной библиотеки (у нас их много и под разные платформы) и написанию какого-то клиентского кода, который будет собирать информацию пользовательской формы и отправлять её платёжному шлюзу. Единственным моментом, на который хотелось бы обратить внимание, должно быть месторасположение самой платёжной формы — будет она находиться на стороне интернет-магазина или будет работать на стороне PayOnline. Несмотря на то, что многие решения вполне могут позволить принимать платежи прямо на своём сайте, в случае отсутствия у мерчанта собственного сертификата PCI-DSS, необходимо будет организовать всё так, чтобы платежи выполнялись на стороне платёжного шлюза. Обоснование тут одно — это безопасность финансовых данных пользователя. При этом платёжную форму можно кастомизировать под компанию, так что отторжения у конечного пользователя не возникнет.

Что получает интернет-магазин

Среди основных преимуществ системы электронных платежей PayOnline мы можем выделить особо наши технические возможности, нацеленные на увеличение конверсии в успешные платежи. В первую очередь, конечно, это тонкая работа с 3-D Secure, позволяющая сохранить высокий уровень защиты от мошеннических операций и одновременно увеличить платежную конверсию.

Мы внимательно изучаем поведение плательщиков, которое из года в год меняется вслед за технологическим прогрессом. Благодаря возможности измерять конверсию и поведение человека на платёжной странице в момент заполнения данных и совершения платежа, мы технологически позволяем своим клиентам шаг за шагом отследить путь покупателя, представить себя на его месте и максимально упростить его пользовательский опыт на основе полученной статистики. В случае же, если при совершении платежа у покупателя по какой-то причине не получается провести оплату, магазин получает от процессингового центра точную причину отклонения, далее магазин транслирует причину отклонения плательщику в любом кастомизированном виде. Таким образом, клиент сразу понимает, почему платеж не прошел и что ему необходимо сделать, чтобы приобрести товар или услугу.

Если вас заинтересовала такая возможность, обращайтесь, наши специалисты предоставят дополнительную информацию и, в случае необходимости, помогут настроить прием платежей на сайте и в мобильном приложении по защищенному шлюзу, отвечающему требованиям стандарта PCI DSS 3.1.

Источник