Bộ xử lý thanh toán - Tôi cần biết những gì nếu tôi muốn chấp nhận thẻ tín dụng trên trang web của mình? [đóng cửa]

Câu hỏi này nói về các bộ xử lý thanh toán khác nhau và chi phí của chúng, nhưng tôi đang tìm câu trả lời cho những gì tôi cần làm nếu tôi muốn chấp nhận thanh toán bằng thẻ tín dụng?

Giả sử tôi cần lưu trữ số thẻ tín dụng cho khách hàng, do đó không có giải pháp rõ ràng dựa vào bộ xử lý thẻ tín dụng để thực hiện việc nâng vật nặng.

Bảo mật dữ liệu PCI , rõ ràng là tiêu chuẩn để lưu trữ thông tin thẻ tín dụng, có một loạt các yêu cầu chung, nhưng làm thế nào để thực hiện chúng ?

Còn những nhà cung cấp, như Visa , những người có những thực hành tốt nhất của riêng họ thì sao?

Tôi có cần phải có quyền truy cập keyfob vào máy không? Điều gì về bảo vệ vật lý nó khỏi tin tặc trong tòa nhà? Hoặc thậm chí nếu ai đó chạm tay vào các tệp sao lưu với tệp dữ liệu máy chủ sql trên đó thì sao?

Còn sao lưu thì sao? Có bản sao vật lý khác của dữ liệu đó xung quanh không?

Mẹo: Nếu bạn có tài khoản người bán, bạn nên thương lượng rằng họ tính phí cho bạn "trao đổi cộng" thay vì định giá theo từng cấp. Với mức giá theo từng cấp, họ sẽ tính cho bạn các mức giá khác nhau dựa trên loại Visa / MC được sử dụng - nghĩa là. họ tính phí bạn nhiều hơn cho các thẻ có phần thưởng lớn kèm theo. Trao đổi cộng với thanh toán có nghĩa là bạn chỉ trả cho bộ xử lý những gì Visa / MC tính phí cho họ, cộng với một khoản phí cố định. . phạm vi 2%). Dịch vụ này được cho là để thương lượng cho bạn (Tôi chưa sử dụng nó, đây không phải là quảng cáo và tôi không liên kết với trang web,

Bài đăng trên blog này cung cấp một danh sách hoàn chỉnh về việc xử lý thẻ tín dụng (đặc biệt đối với Vương quốc Anh).

Có lẽ tôi đã đặt câu hỏi sai, nhưng tôi đang tìm kiếm những lời khuyên như sau:

1. Sử dụng SecurID hoặc eToken để thêm một lớp mật khẩu bổ sung vào hộp vật lý.
2. Đảm bảo hộp nằm trong phòng có tổ hợp khóa vật lý hoặc mã khóa.

Tôi đã trải qua quá trình này cách đây không lâu với một công ty tôi làm việc và tôi dự định sẽ sớm hoàn thành nó với công việc kinh doanh của mình. Nếu bạn có một số kiến ​​thức kỹ thuật mạng, nó thực sự không tệ đến thế. Nếu không, bạn sẽ tốt hơn khi sử dụng Paypal hoặc một loại dịch vụ khác.

Quá trình bắt đầu bằng cách thiết lập tài khoản thương gia và gắn với tài khoản ngân hàng của bạn. Bạn có thể muốn kiểm tra với ngân hàng của mình, vì rất nhiều ngân hàng lớn cung cấp dịch vụ giao dịch. Bạn có thể có được giao dịch, bởi vì bạn đã là khách hàng của họ, nhưng nếu không, thì bạn có thể mua sắm xung quanh. Nếu bạn có kế hoạch chấp nhận Discover hoặc American Express, những thứ đó sẽ tách biệt, bởi vì họ cung cấp dịch vụ giao dịch cho thẻ của họ, không phải loanh quanh điều này. Có những trường hợp đặc biệt khác cũng có. Đây là một quá trình ứng dụng, được chuẩn bị.

Tiếp theo, bạn sẽ muốn mua chứng chỉ SSL mà bạn có thể sử dụng để bảo mật thông tin liên lạc của mình khi thông tin thẻ tín dụng được truyền qua mạng công cộng. Có rất nhiều nhà cung cấp, nhưng quy tắc của tôi là chọn một thương hiệu theo cách nào đó. Họ càng được biết đến nhiều, khách hàng của bạn có thể đã nghe nói về họ tốt hơn.

Tiếp theo, bạn sẽ muốn tìm một cổng thanh toán để sử dụng với trang web của mình. Mặc dù điều này có thể là tùy chọn tùy thuộc vào mức độ lớn của bạn, nhưng phần lớn thời gian sẽ không có. Bạn sẽ cần một cái. Các nhà cung cấp cổng thanh toán cung cấp một cách để nói chuyện với API Internet Gateway mà bạn sẽ liên lạc. Hầu hết các nhà cung cấp cung cấp giao tiếp HTTP hoặc TCP / IP với API của họ. Họ sẽ xử lý thông tin thẻ tín dụng thay mặt bạn. Hai nhà cung cấp là Authorize.Net và PayFlow Pro . Liên kết tôi cung cấp dưới đây có thêm một số thông tin về các nhà cung cấp khác.

Giờ thì sao? Đối với người mới bắt đầu, có hướng dẫn về những gì ứng dụng của bạn phải tuân thủ để truyền các giao dịch. Trong quá trình thiết lập mọi thứ, ai đó sẽ xem trang web hoặc ứng dụng của bạn và đảm bảo bạn tuân thủ các nguyên tắc, như sử dụng SSL và bạn có các điều khoản sử dụng và tài liệu chính sách về thông tin mà người dùng cung cấp cho bạn được sử dụng cho Đừng ăn cắp điều này từ một trang web khác. Hãy đến với chính bạn, thuê một luật sư nếu bạn cần. Hầu hết những điều này thuộc liên kết bảo mật dữ liệu PCI mà Michael cung cấp trong câu hỏi của mình.

Nếu bạn có kế hoạch lưu trữ số thẻ tín dụng, thì tốt nhất bạn nên chuẩn bị áp dụng một số biện pháp bảo mật trong nội bộ để bảo vệ thông tin. Đảm bảo rằng máy chủ lưu trữ thông tin trên chỉ dành cho những thành viên cần truy cập. Giống như bất kỳ bảo mật tốt, bạn làm mọi thứ trong lớp. Càng nhiều lớp bạn đặt vào vị trí càng tốt. Nếu bạn muốn, bạn có thể sử dụng bảo mật loại khóa fob, như SecureID hoặc eTokenđể bảo vệ phòng máy chủ đang ở. Nếu bạn không đủ khả năng cho tuyến đường chính, thì hãy sử dụng hai phương pháp chính. Cho phép một người có quyền truy cập vào phòng để đăng xuất một chìa khóa, đi cùng với một chìa khóa họ đã mang theo. Họ sẽ cần cả hai chìa khóa để truy cập vào phòng. Tiếp theo bạn bảo vệ thông tin liên lạc đến máy chủ bằng các chính sách. Chính sách của tôi là thứ duy nhất liên lạc với nó qua mạng là ứng dụng và thông tin đó được mã hóa. Máy chủ không nên truy cập dưới bất kỳ hình thức nào khác. Để sao lưu, tôi sử dụng truecryptđể mã hóa khối lượng, các bản sao lưu sẽ được lưu vào. Bất cứ khi nào dữ liệu được xóa hoặc lưu trữ ở một nơi khác, sau đó bạn lại sử dụng truecrypt để mã hóa âm lượng dữ liệu được bật. Về cơ bản bất cứ nơi nào dữ liệu là, nó cần phải được mã hóa. Hãy chắc chắn rằng tất cả các quy trình để có được dữ liệu đều mang theo dấu vết kiểm toán. sử dụng nhật ký để truy cập vào phòng máy chủ, sử dụng máy ảnh nếu bạn có thể, v.v ... Một biện pháp khác là mã hóa thông tin thẻ tín dụng trong cơ sở dữ liệu. Điều này đảm bảo rằng dữ liệu chỉ có thể được xem trong ứng dụng của bạn, nơi bạn có thể thực thi những người nhìn thấy thông tin.

Tôi sử dụng pfsense cho tường lửa của tôi. Tôi chạy nó ra một thẻ flash nhỏ gọn và có hai thiết lập máy chủ. Một là vì thất bại vì dư thừa.

Tôi tìm thấy bài đăng trên blog này của Rick Strahl đã giúp rất nhiều để hiểu về thương mại điện tử và những gì nó cần để chấp nhận thẻ tín dụng thông qua một ứng dụng web.

Vâng, điều này hóa ra là một câu trả lời dài. Mình hy vọng rằng những mẹo này sẽ có ích.

Hãy tự hỏi mình câu hỏi sau: tại sao bạn muốn lưu trữ số thẻ tín dụng ngay từ đầu ? Rất có thể là bạn không. Trong thực tế, nếu bạn làm lưu trữ chúng và quản lý để có một bị đánh cắp, bạn có thể nhìn vào một số trách nhiệm nghiêm trọng.

Tôi đã viết một ứng dụng lưu trữ số thẻ tín dụng (vì các giao dịch được xử lý ngoại tuyến). Đây là một cách tốt để làm điều đó:

• Nhận chứng chỉ SSL!
• Tạo một biểu mẫu để nhận CC # từ người dùng.
• Mã hóa một phần (không phải tất cả!) Của CC # và lưu trữ nó trong cơ sở dữ liệu của bạn. (Tôi muốn đề xuất 8 chữ số ở giữa.) Sử dụng phương thức mã hóa mạnh và khóa bí mật.
• Gửi phần còn lại của CC # cho bất kỳ ai xử lý các giao dịch của bạn (có thể là chính bạn) với ID của người cần xử lý.
• Khi bạn đăng nhập sau, bạn sẽ nhập ID và phần được gửi qua thư của CC #. Hệ thống của bạn có thể giải mã phần khác và kết hợp lại để có được số đầy đủ để bạn có thể xử lý giao dịch.
• Cuối cùng, xóa hồ sơ trực tuyến. Giải pháp hoang tưởng của tôi là ghi đè lên bản ghi với dữ liệu ngẫu nhiên trước khi xóa, để loại bỏ khả năng không thể xóa.

Điều này nghe có vẻ nhiều việc, nhưng bằng cách không bao giờ ghi lại CC # hoàn chỉnh ở bất cứ đâu, bạn khiến hacker cực kỳ khó tìm thấy bất cứ thứ gì có giá trị trên máy chủ web của bạn. Tin tôi đi, nó đáng để yên tâm.

Tài liệu PCI 1.2 vừa xuất hiện. Nó đưa ra một quy trình về cách thực hiện tuân thủ PCI cùng với các yêu cầu. Bạn có thể tìm thấy tài liệu đầy đủ ở đây:

https: //www.pcisecuritystiterias.org/security_stiterias/pci_dss.shtml

Câu chuyện dài, tạo một phân đoạn mạng riêng cho bất kỳ máy chủ nào sẽ được dành riêng để lưu trữ thông tin CC (thường là máy chủ DB). Cô lập dữ liệu càng nhiều càng tốt và đảm bảo chỉ có quyền truy cập tối thiểu cần thiết để truy cập dữ liệu. Mã hóa nó khi bạn lưu trữ nó. Không bao giờ lưu trữ PAN. Lọc dữ liệu cũ và xoay khóa mã hóa của bạn.

Ví dụ Don'ts:

• Đừng để cùng một tài khoản có thể tra cứu thông tin chung trong cơ sở dữ liệu tra cứu thông tin CC.
• Đừng giữ cơ sở dữ liệu CC của bạn trên cùng một máy chủ vật lý với máy chủ web của bạn.
• Không cho phép lưu lượng truy cập bên ngoài (Internet) vào phân đoạn mạng cơ sở dữ liệu CC của bạn.

Ví dụ Dos:

• Sử dụng tài khoản Cơ sở dữ liệu riêng để truy vấn thông tin CC.
• Không cho phép tất cả lưu lượng truy cập được yêu cầu đến máy chủ cơ sở dữ liệu CC thông qua tường lửa / danh sách truy cập
• Hạn chế quyền truy cập vào máy chủ CC đối với một nhóm người dùng được ủy quyền hạn chế.

Tôi muốn thêm một nhận xét phi kỹ thuật mà bạn có thể muốn nghĩ về

Một số khách hàng của tôi điều hành các trang web thương mại điện tử, bao gồm một vài người có cửa hàng lớn vừa phải. Cả hai trong số đó, trong khi họ chắc chắn có thể thực hiện một cổng thanh toán cũng không chọn, họ lấy số cc, lưu trữ mã hóa tạm thời trực tuyến và xử lý thủ công.

Họ làm điều này vì tỷ lệ gian lận cao và xử lý thủ công cho phép họ kiểm tra bổ sung trước khi điền đơn đặt hàng. Tôi đã nói rằng họ từ chối hơn 20% tất cả các giao dịch của họ - xử lý thủ công chắc chắn sẽ mất thêm thời gian và trong một trường hợp họ có một nhân viên không làm gì ngoài xử lý giao dịch, nhưng chi phí trả lương của anh ta rõ ràng ít hơn họ tiếp xúc nếu họ chỉ vượt qua số cc mặc dù một cổng trực tuyến.

Cả hai khách hàng này đều đang phân phối hàng hóa vật lý có giá trị bán lại, do đó, đặc biệt được tiếp xúc và đối với các mặt hàng như phần mềm mà việc bán hàng gian lận sẽ không dẫn đến bất kỳ tổn thất thực tế nào mà số dặm của bạn sẽ thay đổi, nhưng đáng để xem xét trên các khía cạnh kỹ thuật của cổng trực tuyến nếu thực hiện như vậy thực sự là những gì bạn muốn.

EDIT: Và kể từ khi tạo ra câu trả lời này, tôi muốn thêm một câu chuyện cảnh báo và nói rằng thời gian đã qua khi đây là một ý tưởng tốt.

Tại sao? Bởi vì tôi biết về một liên hệ khác đang thực hiện một cách tiếp cận tương tự. Các chi tiết thẻ được lưu trữ được mã hóa, trang web được truy cập bởi SSL và các số đã bị xóa ngay sau khi xử lý. Bạn nghĩ sao?

Không - một máy nào trong mạng của họ bị nhiễm bởi một bản ghi nhật ký chính. Kết quả là họ được xác định là nguồn cho một số giả mạo thẻ tín dụng - và do đó bị phạt tiền lớn.

Do đó, tôi không bao giờ khuyên ai đó tự xử lý thẻ tín dụng. Cổng thanh toán đã trở nên cạnh tranh hơn và hiệu quả hơn về chi phí, và các biện pháp gian lận đã được cải thiện. Rủi ro bây giờ không còn giá trị nó.

Tôi có thể xóa câu trả lời này, nhưng tôi nghĩ tốt nhất nên để lại chỉnh sửa như một câu chuyện cảnh báo.

Hãy nhớ rằng việc sử dụng SSL để gửi số thẻ từ trình duyệt đến máy chủ cũng giống như che số thẻ tín dụng của bạn khi bạn đưa thẻ cho nhân viên thu ngân trong nhà hàng: ngón tay cái của bạn (SSL) ngăn khách hàng khác trong nhà hàng (Net) khi nhìn thấy thẻ, nhưng một khi thẻ nằm trong tay nhân viên thu ngân (máy chủ web), thẻ không còn được bảo vệ bởi trao đổi SSL và nhân viên thu ngân có thể làm bất cứ điều gì với thẻ đó. Truy cập vào số thẻ đã lưu chỉ có thể bị dừng bởi bảo mật trên máy chủ web. Tức là, hầu hết các vụ trộm thẻ trên mạng không được thực hiện trong quá trình truyền, chúng được thực hiện bằng cách phá vỡ bảo mật máy chủ kém và đánh cắp cơ sở dữ liệu.

Tại sao phải tuân thủ PCI? Tốt nhất bạn sẽ giảm một phần trăm phí xử lý. Đây là một trong những trường hợp mà bạn phải chắc chắn đây là những gì bạn muốn làm với thời gian của bạn cả về sự phát triển và theo thời gian để theo kịp các yêu cầu mới nhất.

Trong trường hợp của chúng tôi, sẽ hợp lý nhất khi sử dụng cổng thông tin đăng ký và ghép nối với tài khoản người bán. Cổng thông tin đăng ký cho phép bạn bỏ qua tất cả các tuân thủ PCI và không làm gì khác hơn là xử lý giao dịch đúng cách.

Chúng tôi sử dụng TrustC Commerce làm cổng thông tin của mình và hài lòng với dịch vụ / giá cả của họ. Họ có mã cho một loạt các ngôn ngữ giúp tích hợp khá dễ dàng.

Hãy chắc chắn để có được một công việc bổ sung và ngân sách cần thiết cho PCI. PCI có thể yêu cầu phí kiểm toán bên ngoài rất lớn và nỗ lực / hỗ trợ nội bộ. Ngoài ra, hãy lưu ý các khoản tiền phạt / hình phạt có thể được áp dụng đơn phương đối với bạn, thường không tương xứng với quy mô của 'ofense'.

Có rất nhiều cho toàn bộ quá trình. Cách đơn giản nhất để làm điều đó là sử dụng các dịch vụ tương tự như paypal, để bạn không bao giờ thực sự xử lý bất kỳ dữ liệu thẻ tín dụng nào. Ngoài ra, có khá nhiều thứ phải trải qua để được chấp thuận cung cấp dịch vụ thẻ tín dụng trên trang web của bạn. Bạn có thể nên nói chuyện với ngân hàng của bạn và những người cấp ID thương gia của bạn để giúp bạn thiết lập quy trình.

Như những người khác đã đề cập cách dễ nhất vào lĩnh vực này là sử dụng Paypal , thanh toán Google hoặc Nochex . Tuy nhiên, nếu bạn có ý định kinh doanh một số lượng đáng kể, bạn có thể muốn tìm kiếm "nâng cấp" lên các dịch vụ tích hợp trang web cấp cao hơn như WorldPay , NetBanx (Anh) hoặc Neteller (Hoa Kỳ) . Tất cả các dịch vụ này đều dễ dàng thiết lập. Và tôi biết rằng Netbanx cung cấp tích hợp thuận tiện vào một số giải pháp giỏ hàng ngoài kệ như Intershop (vì tôi đã viết một số trong số họ). Ngoài ra, bạn đang xem xét việc tích hợp trực tiếp với các hệ thống ngân hàng (và hệ thống APAX của họ) nhưng điều đó rất khó và tại thời điểm đó, bạn cũng cần chứng minh với các công ty thẻ tín dụng rằng bạn đang xử lý an toàn số thẻ tín dụng (có thể không đáng xem xét nếu bạn không lấy giá trị $ 100k mỗi tháng).

Làm việc từ thứ 1 đến cuối cùng về chi phí / lợi ích là các tùy chọn ban đầu dễ dàng hơn nhiều (nhanh hơn / rẻ hơn) để thiết lập khiến bạn phải trả chi phí xử lý khá cao cho mỗi giao dịch. những cái sau sẽ tốn kém hơn nhiều để thiết lập nhưng bạn sẽ trả ít hơn trong thời gian dài.

Ưu điểm khác của hầu hết các giải pháp không chuyên dụng là bạn không cần bảo mật số thẻ tín dụng được mã hóa. Đó là vấn đề của người khác :-)