결제 우수 사례 수락

Question

결제 게이트웨이 DPS를 사용하는 전자 상거래 사이트를 만들고 있습니다. 지불 게이트웨이는 사용자 정보를 가져 와서 지불이 성공했는지 여부를 반환합니다.

많은 양의 거래를 안전하게 처리 할 수있는 강력한 지불 페이지를 만드는 방법에 대한 좋은 자료가 있다면 궁금합니다. 고용량 지불 페이지에 대해 잘 테스트 된 기술 및 전략이 있습니까?

Answer 1

내가 지불 처리 및 개발 전자 상거래 응용 프로그램에 대한 전문가가 아니에요

,하지만 내 (상식) 가이드 라인의 일부는 다음과 같습니다

1. 포스 HTTPS 사용자의 CC 정보의 제출 (거의 모든 지불 처리에 대한 게이트웨이는 게이트웨이와 통신 할 때 SSL 사용을 강제합니다).
2. 처리 후 데이터베이스에 신용 카드 정보를 저장하지 마십시오. *
3. 일반 보안 지침 (예 : 일반 텍스트 암호 또는 전자 메일 암호 저장 안함)을 따르십시오.

* 참고 :

PCI 가 처리 후 신용 카드 정보의 저장을 허용 않습니다,하지만 당신은 일반적으로 매우 비싼 PCI 준수 호스팅을해야합니다. 그리고 그때조차도 당신은 엄청난 위험에 처해 있습니다. 따라서 고객에게 옵션을 제공하기로 결정한 경우 (아마존과 같은 큰 사이트에서 "원 클릭"체크 아웃을 제공하므로 매우 유혹적입니다) 애플리케이션과 서버가 꽉 잠겨 있는지 확인하는 것이 좋습니다.

해당 지역에서 경험이 없으므로 지불 처리와 관련된 확장 성 문제에 관해 많이 알지 못합니다. 모든 신청서는 하루에 약 5-25 개의 주문 만 처리합니다.

Answer 2

PayPal을 지원하는 SagePay (이전 Protx)를 사용하면 카드 결제를 할 수 있습니다. 또한 Sage Suite (accoutants dream)에 통합되어 많은 시간을 소비하는 데이터 입력을 자동화 할 수 있습니다.

www.sagepay.com

다른 사람들이 말하는 것처럼 - 때로는 카드에 직접 저장하는 위험을 감수 가치가 없어 작은 사이트. 나는 많은 돈이이 소프트웨어를 확보하는데 소비된다는 것을 알고 있으므로 잘 알려진 지불 서비스 (예 : 페이팔, 샐비 페이 또는 구글 체크 아웃)로 리디렉션되는 웹 사이트에서 지불하는 것을 선호합니다. 당신이 처음으로 사용하는 웹 사이트라면, 나는 연기 될 것입니다.

Answer 3

데이터를 유효한 상태로 유지하는 방식으로 코드를 디자인해야합니다.

당신이 직면하는 큰 책임은 당신이 Auth/Capture를 위해 데이터를 보내지 않는다는 것입니다. 그리고 어떤 이유로 든 당신의 마지막 무언가가 실패합니다. 귀하는 고객에게 요금을 청구했으나 어떤 이유로 든이 사실을 알지 못합니다! 결국 일부 성난 고객이 전화로 너에게 소리 치기 시작할 것입니다. 그것은 나쁜시기입니다.

일반적인 아이디어는 이러한 종류의 문제를 식별 할 수 있도록 몇 가지 안전 장치를 마련하는 것입니다. 문제가 발생하는 경우는 매우 드물지만 혼란을 수정하는 것은 아마도 수동 프로세스 일 것입니다.여기

내가 할 것이 무엇 :

1. 디자인 지불을 추적하는 데이터베이스 테이블 (의는 "지불"을 부르 자) 등 payment.order_id 참조 order.id (당신의 "주문"테이블에 관련).
2. 게이트웨이와 상호 작용할 때 중요한 정보가 포함 된 새로운 지불 기록을 설정하여 지불 게이트웨이로 전달하려고합니다. 지불 테이블에 "상태"항목이 있고 "보류 중"으로 설정하십시오.
3. 게이트웨이로 인증/캡처 트랜잭션을 시도하십시오. 응답을 받으면 결제 기록 상태를 '승인 됨', '거부 됨'또는 '오류'로 업데이트하고 관련 메타 데이터 (거부 이유, 거래 ID 등)를 저장합니다. 게이트웨이가 시간 초과되면, 아마도 일종의 "오류"일 것입니다. 단 한번 또는 두 번 다시 시도 할 수도 있습니다.

지금 cron 작업을 실행 한 다음 "보류 중"이고 30 초보다 오래된 지불 레코드를 찾으십시오. 무엇이든 찾으면 당황하고 개발자/운영자에게 알리십시오.

분명히 잘못 될 수있는 것들이 많이 있지만 이것은 큰 마음입니다. 제가 설명한 전략은 위험을 완화하기 위해 여러 번 사용했습니다.