Что нужно и чего нельзя делать при интеграции платежного шлюза без соответствия PCI - PullRequest
Новая
       111

Что нужно и чего нельзя делать при интеграции платежного шлюза без соответствия PCI

0 голосов
/ 19 сентября 2018

Я хотел бы получить некоторые разъяснения относительно интеграции платежного шлюза на моем веб-сайте, поскольку наша компания не имеет PCI DSS Compliance. Хотелось бы узнать законно ли передавать данные карты на платежный шлюз через JavaScriptкод?

Я знаю, что мы не должны сохранять или хранить эту информацию или передавать ее на наш сервер.И мы тоже этим не занимаемся.

Мы планируем интегрировать Razorpay платежный шлюз, используя файл JavaScript , предоставленный Razorpay.Этот файл JS предоставляет функцию для создания платежа с помощью метода createPayment, где мы должны передать данные платежа.Ниже приведены примеры данных: 

var paymentData = {
      email: email,
      contact: '9999999999',
      method: 'card',
      'card[name]': cardName,
      'card[number]': cardNumber,
      'card[cvv]': cardCvv,
      'card[expiry_month]': cardExpiryMonth,
      'card[expiry_year]': cardExpiryYear
};

Вот как выглядит поток кода:

  1. Мы отображаем поля ввода для ввода данных карты
  2. Считать данные вкаждое поле ввода из JavaScript
  3. создает объект данных, который необходимо передать в платежный шлюз
  4. Вызовите метод, предоставленный платежным шлюзом JavaScript, и передайте объект этой функции в качестве параметра.

Итак, мой вопрос - это юридически правильный способ реализации?Кроме того, я не могу увидеть какую-либо документацию, относящуюся к этому виду реализации, в Razorpay.Но они и сейчас поддерживают этот подход.

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

1 Ответ

0 голосов
/ 21 сентября 2018

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

Legal будет зависеть от контекста.В США соответствие PCI не требуется никаким федеральным законодательством.Вместо этого соответствие PCI обеспечивается на договорной основе с поставщиками торговых услуг.Например, вот выдержка из документации ProPay :

Все продавцы должны соответствовать стандарту безопасности данных индустрии платежных карт (PCI DSS).Для продавцов, которые интегрируются в API ProPay, который включает в себя обработку и передачу данных карты напрямую, продавцы должны подтвердить, что они выполнили соответствующие требования PCI DSS.

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

У вас будет выбор, в какой форме заполнить SAQ, в зависимости отна вашем воздействии данных кредитной карты.SAQ A можно выполнить, если у вас абсолютно нет контроля над тем, как собираются данные кредитной карты.Если вы имеете право на прохождение SAQ A, работа, необходимая для самооценки, должна быть тривиально простой.

SAQ A-EP аналогична SAQ A, но имеет много больше требованийдля самооценки.Для справки: SAQ A имеет 4 страницы вопросов, SAQ A-EP 30 страниц вопросов.SAQ A имеет меньше вопросов, потому что некоторые вопросы просто не актуальны, если у вас нет доступа к данным кредитных карт.

К вашему конкретному примеру: используемая вами библиотека звучит как you несут ответственность за доступ в DOM для извлечения данных кредитной карты из <input> s, которые вы создали.Это делает вас неподходящим для выполнения SAQ A из-за этого требования в части 2g:

Вся информация о всех платежных страницах, доставляемых в браузер потребителя, происходит непосредственно от стороннего поставщика услуг, подтвержденного PCI DSS..

SAQ A-EP (опять же, часть 2g) позволяет вам создать страницу, на которой фиксируются данные, при условии, что вы фактически не отправляете ее на свой веб-сервер:

Веб-сайт электронной коммерции Merchant не получает данные о держателях карт, но контролирует, как потребители или данные их держателей перенаправляются на сторонний платежный процессор, утвержденный по стандарту PCI DSS;

...

Все элементы платежных страниц, которые доставляются в браузер потребителя, берутся либо с веб-сайта продавца, либо с поставщика (ов), соответствующих стандарту PCI DSS;

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

Как ни странно, Целевая страница Razorpay предполагает, что не требуют, чтобы продавцы были совместимы с PCI.Я скептически отношусь к этому заявлению, но если они на самом деле не требуют соответствия PCI, вам, возможно, не придется добиваться его.Я не могу рекомендовать игнорировать PCI ... но если они никогда не попросят вас подтвердить соответствие PCI, вам никогда не придется заполнять ни SAQ A, ни SAQ A-EP.

...