Требует ли API authorize.net (AIM) соответствия PCI или какой-либо дополнительной сертификации?

Мне интересно, использовал ли кто-нибудь здесь API authorize.net "Расширенный метод интеграции".

Я просмотрел часто задаваемые вопросы на их сайте, но не могу найти прямого ответа или дозвониться до них в этот час.

Я знаю, что API требует SSL (очевидно), но требует ли их соглашение TOS соответствия PCI или какой-либо сертификации, если вы не храните номера кредитных карт? Кроме того, если кто-нибудь узнает, есть ли что-нибудь в их TOS против использования этого для приложения, в котором хранятся учетные данные продавца (конечно, с явным разрешением продавца)?

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


php authorize.net pci-compliance
person Greg    schedule 30.04.2011    source источник

Ответы (4)


arrow_upward
5
arrow_downward

Да, это требует соответствия PCI. AIM требует, чтобы вы собирали пользовательские данные на своем собственном веб-сервере, прежде чем отправлять их на Authorize.Net для обработки. Это означает, что вы обрабатываете и передаете информацию о кредитной карте и, следовательно, должны соответствовать стандарту PCI.

Это не требование Authorize.Net, это требование индустрии платежных карт. Authorize.Net не несет ответственности за то, как продавец обрабатывает свои платежи, если они не нарушают условия обслуживания Authorize.Net. Поэтому, если вы не соответствуете требованиям PCI, Authorize.Net не волнует. Но эмитенты карт делают и будут поднимать проблемы с продавцом, если их сайт не соответствует требованиям PCI и не использует API AIM.

person John Conde    schedule 02.05.2011
comment
даже если информация о карте никогда не сохраняется и не сохраняется каким-либо образом? - person Greg; 21.05.2011
comment
Ага. PCI охватывает обработку и передачу информации, а также - person John Conde; 21.05.2011
comment
Должен ли я предположить, что они ожидают сертификации, а не только соответствия? PS: Должен сказать, время задержки вашего ответа (14 секунд) намного лучше моего (19 дней)... - person Greg; 21.05.2011
comment
Они более-менее одинаковые. Но они редко проявляют инициативу в этом. Большинство, если не все, провайдеры торговых счетов не проводят проверки PCI, и я знаю, что платежные шлюзы этого не делают. Мне приходилось иметь дело только с одним потенциальным клиентом, который на самом деле заставил кого-то связаться с ним по поводу несоблюдения требований, но они так и не выполнили с нами обязательство, поэтому я не знаю, было ли это настоящим нарушением или кто-то просто пытался получить немного денег от их (вроде тех SEO-компаний, которые всем говорят, что их сайт не оптимизирован). - person John Conde; 21.05.2011
comment
Мой (плохой и неофициальный) совет — используйте AIM с учетом лучших практик (безопасный код, использование SSL и т. д.), и если кто-то из индустрии платежных карт скажет, что вы не соответствуете стандарту PCI, тогда узнайте, где вы несоблюдение и устранить его. Скорее всего, просто сервер не соответствует требованиям (нет брандмауэра и т. д.). - person John Conde; 21.05.2011
comment
Спасибо за совет. И последний вопрос: есть ли какой-то фактический «сертификат» или «лицензия», которые вы должны получить/поддерживать? Или в основном бренды должны жаловаться, если они считают, что вы делаете что-то явно небезопасное? - person Greg; 21.05.2011
comment
Есть компании, которые проводят сертификацию PCI. У меня не было клиентов, которые это делали, поэтому я не знаю точно, как они доказывают, что вы соответствуете требованиям PCI, но я уверен, что они предоставляют вам то, что PCI считает удовлетворительным. Как правило, большинство компаний реагируют (как предложил мой совет), а не проактивны (быть добросовестным гражданином сети). Это, вероятно, наполовину из-за стоимости и наполовину из-за невежества. Но в любом случае я не думаю, что какая-либо сертификация пригодится, пока кто-то не придет ее искать, поскольку я не знаю, как сообщить властям, что ваш сайт соответствует требованиям. - person John Conde; 21.05.2011
comment
В качестве примечания, соответствие PCI — это своего рода отвлекающий маневр. Это действительно не означает, что сайт безопасен. Это просто означает, что он соответствует рекомендациям PCI, которые на самом деле представляют собой просто набор простых советов по безопасности. Да, хорошо иметь стандарты, но многие люди обманываются, полагая, что соответствие PCI = безопасно, что просто не соответствует действительности. - person John Conde; 21.05.2011

arrow_upward
2
arrow_downward

Если вы используете AIM, вы попадаете под действие PCI. Многие многие разработчики намеренно думают, что они не попадут в сферу действия, если будут просто передавать данные карты на Authorize.net с помощью AIM API.

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

Чтобы использовать Authorize.Net и оставаться вне области PCI, используйте методы интеграции SIM или их новый Direct Post Method< /а>. Оба держат ваш сервер вне области видимости.

Подробнее об этом на сайте Auth.net.

person Larry K    schedule 17.08.2011

arrow_upward
1
arrow_downward

Вся инициатива по соблюдению требований PCI — это полный беспорядок, и она станет неисполнимой, потому что нет реальных окончательных ответов. Те немногие, что существуют, туманны и неоднозначны.

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

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

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

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

person ATL_DEV    schedule 14.12.2011
comment
Разница в том, что когда он идет к мерчанту, он не попадает на ваши серверы. Когда он попадает на ваши серверы, есть шанс, что он будет сохранен в журналах доступа, и тогда вам придется беспокоиться о тех, кто потенциально может иметь доступ к этим журналам доступа. И любой, кто может иметь доступ к учетным данным для доступа и т. д. - person Dustin Graham; 08.11.2013

arrow_upward
-1
arrow_downward

что касается первой части вашего вопроса.. нет, это не требует соответствия PCI. Одним из основных преимуществ использования Authorize.net является перекладывание на них ответственности за соответствие PCI. При этом использование Authorize.net, конечно же, не снимает с вас автоматически никаких обязательств PCI.

person Jason Cragun    schedule 30.04.2011
comment
Вы случайно не знаете, нарушает ли это какие-либо правила хранения учетных данных продавца? - person Greg; 01.05.2011
comment
уточните, пожалуйста.. ваши учетные данные продавца? чьи учетные данные продавца? - person Jason Cragun; 01.05.2011
comment
предполагая, что я использую SaS POS/приложение для выставления счетов (например, freshbooks), с продавцами в качестве моих основных пользователей - могу ли я хранить эти идентификаторы продавцов и т. д. и использовать API AIM, а не упрощенный, который работает больше как Google Checkout? - person Greg; 01.05.2011
comment
это отличный вопрос... можете ли вы проводить оплату через Authorize.net от имени другого продавца. Я не знаю точного ответа на этот вопрос, но думаю, что нет. Причина в том, что... и это скорее обоснованное предположение... в том, что Authorize.net хранит информацию о вашем продавце в связи с вашей учетной записью. Это не отношение один ко многим. Много мерчантов == много аккаунтов в их глазах. Бизнес. - person Jason Cragun; 01.05.2011
comment
да.. вероятно, они заключили с ними сделку. не бойтесь протянуть руку и связаться с ними. - person Jason Cragun; 01.05.2011
comment
-1 Это неверно, если вы используете AIM в соответствии с текущими стандартами PCI, поскольку вы передаете данные на Auth.net. Если вы используете интеграцию Auth.Net AIM, ваше программное обеспечение/сервер соответствует требованиям PCI. Что это повлечет за собой, зависит от вас и вашей Ассоциации карт через поставщика вашего торгового счета. - person Larry K; 17.08.2011
comment
Я не понимаю, как это может быть проблемой. Все, что вам нужно, это логин продавца, который вы им предоставляете. - person ATL_DEV; 15.12.2011