Хранение Информации О Кредитной Карте

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

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

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

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

EDIT 4.28.2011-я бьюсь об стену с этим. Что делать, если мы вообще не храним информацию о кредитной карте, клиенты вводят ее, а затем передают... как нам сделать это безопасно? Не храни его, проходи мимо. HTTPS, шифровать данные карты во время транзита?

8
credit-card payment payment-gateway pci-dss

3 ответов

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

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

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

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

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

  • либо сделать один раз, или
  • сохранить как "клиент", а затем счет в будущем, либо по мере необходимости, или автоматически повторяющимся способом

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

3

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

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

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

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

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

стандарты PCI

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

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