Хранение информации о кредитной карте

Question

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

Мы рассмотрели Authorize.net CIM , и это, кажется, идеальное решение (мы просто храним идентификатор профиля или токен, который возвращает номер кредитной карты) ... но это можетне отвечают нашим потребностям, поскольку информация о кредитной карте не обрабатывается (обязательно) компанией authorize.net, но независимо от того, с какого торгового счета мы отправляем платеж.Другими словами, мы хотим хранить информацию о кредитной карте как кошелек ... не обязательно каждый раз обрабатывать с Authorize.net.

Читая документацию CIM XML (стр.94), похоже, что getCustomerPaymentProfileResponse маскирует данные возврата кредитной карты ... поэтому я не вижу, как это было бы полезно для обработкиесли данные замаскированы?

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

РЕДАКТИРОВАТЬ 4.28.2011 - Я бью стену с этим.Что если мы вообще не храним информацию о кредитной карте, заказчики вводят ее, а затем передают ее ... как мы можем это сделать безопасно?Не хранить его, передавать HTTPS, шифровать данные карты во время транспортировки?

Answer 1

К сожалению, простого способа достичь этого не существует.

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

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

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

Answer 2

Stripe делает что-то вроде этого.Они обрабатывают данные карты без необходимости их сохранения и возвращают токен, представляющий кредитную карту, который вы затем можете:

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

Существует хороший RailsCast для выставления счетов с Stripe, который стоитпроверяя.Очень дружелюбный к разработчикам.

Answer 3

Редактировать
Я только что понял, что Authorize.Net CIM - это своего рода сервис токенизации. Таким образом, вы, вероятно, знаете о большей части этого. Я оставлю этот пост здесь, хотя он может быть полезен для кого-то еще.

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

Затем вы можете сохранить эти токены и передать их платежным приложениям поставщика, которые, в свою очередь, будут использовать их для обработки транзакций. Я предполагаю, что эти токены будут уникальными для конкретного продавца, поэтому вам, вероятно, придется хранить 1 токен на продавца / продавца для конкретного пользователя.

Может быть, есть правило об этом, когда продавец / продавец не может получить токены-прокси или иным образом получить их от третьей стороны. Если это так, ваши поставщики могут предоставить новый токен / guid, который сопоставляется с токеном, который они хранят внутри, для использования со своим процессором карты ...

Google - токенизация кредитной карты

Стандарты PCI

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

• Поставщик может быть вынужден запретить вашему приложению использовать API
• Ваше приложение должно пройти сертификацию PCI