제 3 자 판매자를 통한 반복 청구를 위해 신용 카드 번호를 저장해야합니다.
세부 정보 저장과 관련하여 준수해야 할 표준이 있습니까? 우리는 몇 년 동안 신용 카드를 받아 왔지만 우리가 신용 카드를 처리하자마자 세부 정보를 폐기했습니다. 고객이 매월 구독료를 수동으로 지불 할 필요가 없도록 세부 정보를 저장하도록 요청했습니다.
가입을 활용하기 위해 PayPal로 이동하는 것은 옵션이 아닙니다. 우리는 그것들을 저장해야하며, 스토리지가 안전한지 확인해야합니다!
우리는 데이터를 위해 MSSQL 2005를 활용하고 모든 것이 이미 SSL을 사용했습니다.
답변:
(문자로) 따라야 하며 PCI DSS 표준을 초과 하는 것이 좋습니다 . 결코 쉬운 일이 아니며 사소한 일도 아닙니다.
나는 강하게 당신이 당신을 위해이 문제를 처리하고 결제 시스템에 통합 할 수있는 타사의 프로세서를 찾을 것이 좋습니다. SSL을 사용하고 데이터베이스의 정보를 암호화하는 것 이상으로 진행됩니다. 또한 액세스를 모니터링하고, 침입을 탐지하고, 위반시 영향을받은 사람에게만 알리고 (어떤 데이터가 손상되었는지 확인할 수있는) 시스템을 마련해야합니다.
그러면 서버, 네트워크 등에 물리적으로 액세스 할 수 있습니다. 즉, 물리적 LAN이 보호되는 곳에서 소유 한 서버에서 공유되지 않는 캐비닛이 잠 깁니다. 컴플라이언스는 저렴하거나 쉽지 않을 것입니다.
실제로,이를 제 3 자에게 오프로드하기 위해 가능한 모든 노력을 기울이십시오. 매월 수십만 건 (여기에 통화를 삽입하십시오)에 이르는 거래에 대해 이야기하지 않는 한 부채만으로는 가치가 없습니다. 이 경우 비용을 절약하면 정보를 저장하는 시스템을 구현하고 모니터링하는 데 필요한 인재를 확보 할 수 있습니다. 너는 필요할거야:
그리고 다시, 당신은 모든 것을 제 3 자에게 상당히 싸게 내릴 수 있습니다.
그것은 신용 카드 정보를 저장하는 것이 좋습니다 결코 이제까지 . 신용 카드 세부 정보를 저장할 필요가없는 토큰으로 반복 지불 거래를 할 수 있습니다.
당신이 찾는 많은 답변은 Payment Card Industry Compliance Guide 웹 사이트 에서 찾을 수 있습니다 . 그들의 링크 페이지는 특히 유용합니다.
가장 좋은 제안은 타사가이 스토리지를 처리하도록하는 것입니다.
타사 판매자에 지속적인 신용 카드 결제 옵션이 포함되어 있지 않습니까? 영국의 대부분의 주요 결제 수단 (DataCash, RBS World Pay 등)이 있습니다.
기본적으로 CCC 당국에 요청하여 카드 세부 정보를 한 번 제출하십시오 (정확하게 리콜 할 경우 예상 일정과 일정 금액을 포함해야합니다). 그러면 토큰을 돌려받습니다. 그런 다음 매월 / 당신이 토큰으로 상인을 폴링하고 그들은 당신을 위해 후속 거래를 처리합니다-일반적으로 가변적이고 임시 요청을 위해 이들을 설정하는 시설이 있습니다. 최종적으로 중요한 요구 사항은 지불을하기 전에 고객에게 (일반적으로 10 일 이상) 알리는 것입니다.
이렇게하면 CC 세부 정보를 어디에도 저장하지 않고 요구 사항을 충족하는 사람들이 처리 할 수 있습니다.
이는 카드에서 사전 승인을 수행하는 것과 유사하므로 신용 카드를 저장하지 않아도되며 필요에 따라 판매자의 토큰 만 보관하면됩니다.
우리는 그것들을 저장해야하며, 스토리지가 안전한지 확인해야합니다!
하나의 질문 : 왜?
나는 PCI를 직접 다루어야하기 때문에 요청 만하고,이를 유지하는 것은 고통 스럽다. 나의 일상적인 업무가 우리에게 PCI 규정 준수를위한 가장 낮은 단계라고 할 수 있지만, 여전히 많은 부분이 있습니다. 암호화, 최소 권한 고려 사항, 서버 OS 보안, 내부 네트워크 보안, 경계 보안, 타사 감사 ... 모두 따라야합니다. 신용 카드 정보를 저장하지 않은 경우에도 마찬가지입니다!
(Sidenote : 전자 상거래를하는 경우 CC 데이터를 저장하지 않더라도 PCI를 준수해야합니다. 지금 불만이 없다면 아직 물지 않은 운이 좋습니다.)
프로세서가 처리하도록하십시오. 우리는 Authorize.net을 사용하고 멋진 API를 사용하여 자체 맞춤형 프런트 엔드를 만들 수 있지만 실제 지불을 저장하고 처리합니다. 반복 청구를 설정하려면 정보를 저장하는 시스템이 있습니다. 솔직히, 나는 나 자신을 신뢰하는 것보다 더 신뢰합니다.
다른 사람들이 언급했듯이 PCI-DSS를 찾고 있습니다. 또한 다른 사람들이 언급했듯이 소규모 사이트의 경우 규정 준수 비용이 엄청나게 비쌀 수 있습니다.
가입을 활용하기 위해 PayPal로 이동하는 것은 옵션이 아닙니다. 우리는 그것들을 저장해야하며, 스토리지가 안전한지 확인해야합니다!
지불 게이트웨이에서 고객의 신용 카드 정보를 식별하는 ID를 로컬로 저장할 수 있습니다. PayPal이이 옵션을 제공하는지 잘 모르겠지만 다른 지불 게이트웨이가 있습니다.
또한 신용 카드 데이터를 디스크에 저장하지 않더라도 여전히 일부 PCI-DSS 요구 사항의 범위에 속합니다. 준수하는 가장 쉬운 방법은 CC 데이터를 사용하지 않는 것입니다 (예 : 결제 양식을 결제 게이트웨이에 직접 POST).
http://chargify.com/ 과 같은 서비스 는 기존 지불 게이트웨이 위에 추가 계층을 제공합니다. 신용 카드를 저장하고 반복 지불을 구현하고 보고서를 작성하는 모든 방법을 제공 할 것입니다.
이를 통해 전체 책임 및 PCI 준수 문제를 피할 수 있습니다. 내가 가진 한 가지 우려는 언젠가 공급 업체, 판매자 계정 또는 게이트웨이를 변경하려는 경우입니다. 10,000 명의 고객을 어떻게 데려가십니까? 그들은 신용 카드 데이터베이스를 넘겨 주는가? 신용 카드 정보를 이전하기 위해 경쟁 업체와 협력합니까?
나는 그것을 의심한다. 공급자를 변경하면 모든 고객에게 청구 정보를 다시 제출하도록 요청해야 할 수도 있습니다. 이것은 신용 카드 정보를 직접 저장하는 데 유리한 작은 주장입니다. 많은 고객과 많은 수익을 얻는 경우에만 가치가 있습니다. 이 특별한 수수께끼에 대한 다른 사람들의 생각을 듣는 것이 매우 흥미로울 것입니다.
신용 카드 정보를 자신의 DB에 저장하기로 결정한 경우 어떤 상황에서도 3 자리 카드 보안 코드를 저장해서는 안됩니다 . 그렇게하는 것은 카드 협회에 의해 엄격히 금지되어 있습니다.
BTW, 거래를하기 위해 카드 보안 코드가 필요하지 않습니다. 사기 탐지율은 향상되지만 고객과 지속적인 관계가있는 경우에는 필요하지 않습니다. (필요하다고 생각하더라도 저장할 수 없습니다. 무엇이든 상관 없습니다.)
정보를 저장하지 않는 다른 권장 사항도 두 번째입니다. Authorize.Net의 고객 정보 관리자 는 사용하기 쉽고 저렴합니다. 자체 서버에 정보를 저장하는 데 고유 한 PCI 비용이 발생하는 대신 사용하는 것이 훨씬 저렴합니다.
데이터베이스에 신용 카드를 저장하려는 경우 암호화가 핵심입니다. 또한 시스템이 제대로 작동하는지 확인하기 위해 타사에서 정기 준수 테스트를 수행해야 할 수도 있습니다.